Digital Oxygen 
Тендеры и лиды
Информация
Меня зовут Вадим Хазеев — я продюсер игр (game producer) в Digital Oxygen. В этой статье делюсь практическим гидом по созданию сценариев для бизнес-игр и приложений. А еще, я спрятал маленькую геймификацию в самой статье, так что читай внимательнее!
Представьте, менеджер по продажам приносит горячего лида, передает бриф гейм-дизайнеру и просит составить самый вкусный и сочный сценарий.
С этого момента у вас на руках самая важная информация: сроки, количество концепций, предполагаемая платформа и суть проекта.
Теперь стоит задача, в которую необходимо вложить максимум креатива, сохранив при этом изначальные сроки и бюджет клиента.
На этом этапе может возникнуть небольшая проблема с определением «идеальной формулы» приложения или игры. И тут я советую обратиться к инструментам проектирования поведения игроков — это некая шпаргалка, которая помогает подобрать механики и понять, как из простых элементов сделать интересный продукт.
Помните, что главная задача гейм-дизайнера – понять бизнес-задачу клиента и сформировать пресейл в рамках интереса заказчика.
Со опытом я выработал следующую структуру пресейла:
Хорошим тоном будет и подготовка документов по балансу, который покажет ваши компетенции. Если клиент не из мира игр, а например, простой производитель мыла, то не делайте это основной частью, пожалейте его. Просто сделайте игру про варку мыла… Желательно в сеттинге фильма «Бойцовский клуб».
Чтобы упростить составление, делюсь с вами моим примером: Предновогодняя геймификация для завлечения аудитории на страницу итогов года. Он не идеальный, но адаптированный.
После написания концепта выходим на звонок с заказчиком. По опыту скажу: чаще всего этим занимается не продюсер, а менеджер по продажам. В 90% случаев готовый пресейл улетает сейлзу и он уже сам общается с клиентом и пересылает материалы напрямую.
Иногда это даже лучше: вы сосредотачиваетесь на создании концепта, а сейлз — на переговорах.
Ты прошел первую главу, держи ачивку: «Ты». 1/4 Собери все чтобы открыть слово)
Итак, пресейл сработал — клиент заинтересовался и хочет увидеть концепцию в реальности. Наступает следующий этап: подготовка технической документации.
Теперь предстоит коммуницировать с заказчиком, и это прекрасно: так вы напрямую можете уточнить детали и сразу фиксировать все договорённости.
Бывает и иначе — заказчик выбирает один из предложенных концептов (скажем, «номер 3»), и именно он идёт в разработку.
Далее перейдем к важной части – написание технического задания. Это не формальность, а подробное описание сущностей и процессов будущего проекта. По сути, это карта, по которой движется вся команда разработки.
Начнём по порядку. Вначале займемся оглавлением, ведь без него никак: все разделы вашего ТЗ собраны в одном месте, что упрощает поиск и ориентацию по проекту.
После — история изменений. Она становится особенно важной, когда ТЗ утверждено и уже запущено в работу (разумеется, после оплаты).
В процессе разработки иногда возникает необходимость внести корректировки — по инициативе заказчика или, пусть и реже, со стороны исполнителя. Чтобы не потеряться в потоке правок, фиксируйте каждое изменение: указывайте раздел, который был изменён, кратко описывайте суть правки, а также отмечайте, кто и когда внёс изменения. Простейший формат: фамилия, имя и дата.
Следующий раздел — общие сведения. Это основа любого ТЗ. Здесь указывается, кто является заказчиком и кто исполнителем (ваша компания или студия).
После этого идёт цель проекта. В нём описывается суть будущего продукта: для чего он разрабатывается, на каких платформах будет работать, какие технологии и дополнительные возможности планируются. В этом разделе важно вкратце показать, что будет происходить в проекте. Например, если речь идёт об игре, то игроку предстоит выполнять определённые действия, чтобы достичь успеха.
Не забудьте и про материалы. Это отдельный пункт, который обязательно включается в ТЗ. Здесь перечисляются все ресурсы, предоставленные заказчиком или созданные вами в процессе разработки. Это могут быть ссылки на Level Design, макеты интерфейса в Figma, документацию, а также облачные хранилища с контентом и другими файлами.
Перейдем к разделу «Технические требования». Здесь фиксируются все параметры, которые определяют основу проекта. В первую очередь указывается ориентация приложения: горизонтальная или вертикальная. Далее — особенности платформы: будет ли это мобильный телефон, VR-шлем или, возможно, обе платформы сразу.
Обязательно прописываются минимальные требования для сборки под iOS и Android: версии операционных систем, ограничения по памяти, а также совместимость с устройствами. Сюда же добавляется информация о движке, на котором будет разрабатываться проект — Unity, Unreal Engine или другой. Если в проекте планируется использование дополнительных инструментов (например, 3D-редакторов или специализированных плагинов), всё это нужно указать в этом разделе.
Когда основа готова, пора переходить к деталям, которые различаются в каждом конкретном проекте. Если заказ включает только 2D-контент, то в техническом задании подробно описываются: карты, изображения, текстуры и форматы файлов.
Работу с 3D-разработкой стоит выносить в отдельный блок и также подробно описывать все модели: их количество и уровень детализации. А если разрабатывается полноценное приложение, логично начать с описания механик, а затем последовательно перейти к контенту.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13201 тендер
проведено за восемь лет работы нашего сайта.
Здесь есть маленький секрет. Многие сотрудники, особенно те, кто работает с контентом, признавались: удобнее всего, когда материал разбит по категориям, а не свален в одну общую кучу. И это действительно так. Проще и логичнее разделять контент: 3D-модели — в одном разделе, 2D-элементы — в другом, звуковые ресурсы — в третьем. Так каждый специалист быстрее находит именно ту информацию, которая ему нужна, без долгих поисков в громоздких документах.
Для примера: в моих ТЗ я обычно сначала описываю игровые механики, чтобы у разработчиков было чёткое понимание, как должен работать проект. После этого перехожу к локациям — перечисляю, какие 3D-модели должны быть размещены, какие звуки используются и какие дополнительные элементы входят в сцену.
В итоге, когда техническое задание заполнено, у вас на руках уже полная картина будущего проекта. Но важно помнить: излишняя детализация иногда играет злую шутку. Например, если вы укажете, под каким углом должен быть повернут куб на сцене, то разработчику придётся строго следовать этим инструкциям. А позже окажется, что куб всё же нужно развернуть иначе, тогда ваши же требования могут стать препятствием. Поэтому сбалансируйте: фиксируйте важные детали, но избегайте чрезмерной «микро-менеджерской» точности.
Следующий этап — согласование технического задания с заказчиком. Этот пункт считается опциональным, так как не во всех компаниях он практикуется. Иногда достаточно короткого созвона с менеджером. Но бывают и случаи, когда гейм-дизайнер или технический писатель должен презентовать документ, объясняя ключевые моменты.
Здесь есть два простых, но полезных совета:
Правки со стороны заказчика — это нормальная часть процесса. Важно относиться к ним спокойно и конструктивно. Обычно компании закладывают до двух крупных итераций правок, после чего документ утверждается окончательно.
Конечно, бывают клиенты, которые стремятся бесконечно вносить изменения. Но если компания не располагает ресурсами, чтобы оплачивать бесконечные циклы доработок, она вправе ограничить количество правок или даже отказаться от сотрудничества.
Не забывайте: всё, что зафиксировано в ТЗ, напрямую попадает в смету разработки. Программисты, художники 2D/UI, 3D-моделлеры оценивают, сколько времени займёт реализация каждой функции или элемента контента. Из этого складывается стоимость проекта.
Иногда возникает ситуация, когда итоговая цена не соответствует ожиданиям заказчика. В таком случае происходит пересмотр объёма — часть механик или элементов контента исключается для сокращения бюджета. Это, по сути, новая итерация технического задания. Да, такие корректировки не всегда приятны, но они неизбежны. Главная задача здесь — грамотно обсудить всё с командой и заказчиком, чтобы оптимизировать проект и при этом сохранить его ключевую идею.
Бам! Ты нашёл скрытую ачивку: «Ми». 2/4 Собери все чтобы открыть слово)
Итак, формальности позади. Заказчик принял техническое задание, документы подписаны, деньги поступили на счёт — и вот он, долгожданный момент: старт разработки. Первые секунды — это эйфория, лёгкое чувство победы. Но буквально сразу приходит и осознание: настоящая работа только начинается.
Вы спросите: «А что, собственно, изменилось?» Отвечаю: всё. Всё, что было до этого, — лишь подготовительный этап, своего рода «детский сад». Теперь вам и вашей команде предстоит доказать, что все те красивые слова и планы из ТЗ можно воплотить в реальный продукт. И если с креативной частью вы справились блестяще, но опыта именно в разработке пока немного, путь к результату будет совсем непростым.
На этом этапе многое зависит от того, каким именно гейм-дизайнером вы являетесь. Я обычно выделяю четыре типа:
Этап продакшна — один из самых интересных и в то же время самых разнообразных периодов работы. Его нельзя описать одним сценарием: всё зависит от конкретного проекта и команды. Бывает и такое, что на одном проекте вы будете погружены больше в конфигурацию геймплея, а на другом — в управленческую рутину или плотную коммуникацию с разработчиками.
Именно поэтому глава о продакшне может быть короткой по тексту, но по насыщенности и вариативности она — одна из самых значимых.
Ой, новая ачивка: «лаш». 3/4.
И вот наконец, финальная точка. Все исполнители закрыли свои задачи, проект собран и готов к выкладке в стор.
Это достаточно важный момент: у вас уже есть готовый продукт, прошедший тестирование и проверку качества. Вы передаете его заказчику, собираете обратную связь и вносите последние правки (если они будут) — и только теперь вы можете выдохнуть с облегчением.
Далее возникает вопрос: « А что дальше?» На первый взгляд может показаться, что на этом история заканчивается. Проект завершён, документы подписаны, заказчик доволен. Однако на самом деле именно здесь открываются новые возможности.
Вы можете предложить дополнительные услуги — улучшения уже готового проекта. Это может быть расширение функционала, добавление нового контента, работа над обновлениями или оптимизация. Как правило, заказчики ценят, когда разработчик думает наперёд и заботится о будущем продукта.
Возможно развитие и другой ветки событий — разработка нового проекта для того же заказчика. Если вы хорошо проявили себя на предыдущем этапе, вероятность долгосрочного сотрудничества значительно возрастает.
Завершение проекта — это не точка, а, скорее, запятая. Конец одной истории открывает путь к следующей.
Дошёл до конца, держи ачивку: «ка». 4/4, поздравляю, если ты внимательно читал, то нашёл все ачивки, гордись собой!
