Текст книги "Игра как бизнес. От мечты до релиза"

Описание стадии

Задача данной стадии – производство прототипа в полном игровом цикле: от экрана запуска до завершения выполнения всех игровых задач и экрана выхода. По итогу стадии мы должны получить сырой – с багами, кучей прокси-объектов, прикидочными камерами и основой интерфейса – но играбельный общий билд.

Задачи

Игровой цикл

Запускаемый билд, включающий в себя полный игровой цикл вертикального среза, соответствующий запланированным параметрам (время, последовательность действий, совмещение компонентов). Билд нашей игры-примера запускается на ПК и использует геймпад.

Производство основных фичей

Это главный приоритет стадии с точки зрения программирования. Фичи должны быть представлены в альфа-качестве. В нашем случае в них входят: работа камеры, передвижение, взаимодействие, инвентарь героя, AI[24]24
  АI (Artificial Intelligence) – искусственный интеллект (иногда используется русскоязычная аббревиатура ИИ).


[Закрыть] противников, система укрытий/стелс, детективный режим и прототип системы рукопашного боя и стрельбы.

Производство второстепенных фичей

Фичи второго порядка, представленные в зачаточном состоянии. Сюда входят все определенные на первой стадии cool small things, в нашем примере это могут быть: slow motion в боевой системе, стелс-убийства, какие-то мелкие акробатические элементы, наличие NPC[25]25
  Non-player character (NPC) – персонаж, который не контролируется игроком.


[Закрыть] и так далее. Не приоритет, производятся по принципу бэклога[26]26
  Backlog – термин из методологии проджект-менеджемента. Упрощенно говоря, это журнал пожеланий проекта. В книге обычно подразумевается, что это специальная база данных, содержащая опциональные задачи, которые можно подхватить, если в распоряжении оказались какие-то свободные ресурсы.


[Закрыть].

Производство арт-ассетов

Произведенные и введенные в игру необходимые арт-ассеты, приоритетно включающие настроенную модель главного героя, один тип противника, один тип архитектурного сета, базовый рабочий вариант интерфейса, базовый набор спецэффектов. Финализированная и введенная в движок библиотека материалов.

Производство кат-сцен

Если есть – а в нашем базовом примере кат-сцены есть. Итак, одна типовая кат-сцена, остальные в тестовом качестве или в качестве разметки в рамках игрового цикла. Сделаны все раскадровки на кат-сцены в рамках всего вертикального среза.

Подготовка производства маркетинговых материалов

Определение всего пакета (тизер, трейлер, скриншоты, финальная презентация), ассет-лист производства тизера и трейлера, определение производственных мощностей. При необходимости – список дополнительных подрядчиков.

Настройка итерации процессов

В рамках стадии должна быть настроена внутренняя итеративность процессов. Например, каждые две недели происходит общая интеграция в билд, который подается продюсеру, недельный фидбек, правки, месячный билд. Процедура должна быть отлажена, задокументирована, результаты должны быть поданы в отчетность.

Срок: 2 месяца.

Deliverables: игровой билд прототипа, игровое видео прохождения прототипа с комментариями, отчетность.

Бюджет: X, из которых Y – заранее заложенная сумма на анимационный аутсорс.

Описание стадии

Команда находится на запланированной пиковой мощности (в рамках вертикального среза, а не проекта вообще) и входит в линейное производство. В итоге альфа-версии билд готов на 50 % в окончательном качестве – с точки зрения как контента, так и фичей. Функционирует на ПК.

Задачи

Производство альфа-версии

В рамках альфа-версии упор делается на системные вещи – как с точки зрения фичей, так и с точки зрения контента. Максимально повторяемые в игре элементы на данный момент готовы, уникальным или реже используемым элементам уделяется вторичное внимание. Билд полностью проходим, может содержать баги, в том числе мажорные, но не содержит блокирующих ошибок.

Производство фичей

Все фичи первого порядка готовы и функционируют без сбоев. Приоритет на этой стадии делается на продвинутые версии самых сложных уникальных систем (таких как система боя). Второстепенные фичи, характеризующие игру, также готовы в альфа-состоянии (в нашем примере это такие системы, как детективный режим, взаимодействие с персонажами и стелс-режим). Две важные глобальные программные задачи на этой стадии: тест версии на одну из консолей (помним, что наша игра-пример является мультиплатформенной) и старт выведения в бэклог всех проблемных задач (и расстановка приоритетов по результатам этой процедуры).

Производство контента

Произведены ключевые персонажи, ключевые архитектурные билдинг-сеты, подключаются все тестовые анимационные системы – которые пока еще в черновом состоянии, но технически правильно реализованы.

Производство кат-сцен

Все кат-сцены вертикального среза, но в состоянии превизуализации. Анимации на этой стадии не финальные, камеры могут меняться на следующем этапе, нет facial animations (лицевой анимации).

Подсистемы и дополнительные игровые компоненты

В игру подключаются (в стартовом состоянии) звук, спецэффекты, пост-эффекты, итерация настройки движка по свету, фильтрам и прочие задачи технического арта.

Производство маркетинговых материалов

Предварительная визуализация трейлера, набор скриншотов, базовая презентация. На этой стадии начинается отдельная работа над сложными шотами анонс-трейлера и производство уникальных ассетов под него. Готов тизер проекта, который используется как пробный шар для бизнес-девелопмент целей.

Бизнес-девелопмент

Предварительный контакт и посещение двух выставок на шестом месяце. Замер конъюнктуры рынка, старт подготовки лонг-листа партнеров, детализация спроса и окончательное формирование предложения.

Срок: 2 месяца.

Deliverables: билд альфа-версии вертикального среза, тизер, превиз[27]27
  Это превизуализация кат-сцен, не в финальном качестве, но с анимациями. – Прим. ред.


[Закрыть] трейлера, отчетность.

Бюджет: X, из которых Y – дополнительное оборудование, связанное с введением полного объема штата и необходимостью закупки девкитов (устройства для разработки на консолях), еще Z – стартовые затраты на бизнес-девелопмент.

Описание стадии

По итогу стадии вертикальный срез должен быть готов на 80 %, он находится почти в финале: некоторые элементы все еще не присутствуют, но отсутствуют баги-блокеры, игра работает как на ПК, так и еще на одной платформе. Версия все еще может быть не оптимизирована под консоль. Все маркетинговые материалы представлены в окончательном качестве и готовы к релизу, однако могут пройти через дополнительный, финальный фидбек. Готовы к пред-публичному показу любым партнерам.

Задачи

Производство бета-версии

Итогом версии является почти финальный вертикальный срез, количество багов минимально, все системы и контент добавлены и функционируют. Могут быть какие-то минорные недочеты, какие-то объекты все еще прокси[28]28
  Заместитель (англ. Proxy) – объект проектирования, по сути – шаблон, который делает то, что должен делать тот объект, который прокси сейчас замещает. — Прим. ред.


[Закрыть]. Может недоставать элементов озвучки, некоторые спецэффект-системы дублируют друг друга, не все анимации являются финальными.

Производство фичей

Все фичи финализированы в билде, могут быть какие-то минорные баги. Версия работает как на ПК, так и на одной из консолей. Ничего нового из основного списка уже не добавляется, все усилия технически-интеграционной команды направлены на чистку багов, оптимизацию и настройку-корректировку минорных элементов в игре. Также команда обращается к бэклогу и определяет 4–5 фичей, которые не влияют на основную работу билда, но могут в нужных моментах существенно улучшить игру – и разрабатывает их как опциональное решение.

Производство контента

Практически весь контент на данной стадии готов, приводятся в порядок библиотеки ассетов и материалов, поддержка в оптимизации, игровая часть с точки зрения ассетов полностью отдается команде технического арта в настройку. Ресурсы арт-команды перенаправляются на улучшение окончательного качества кат-сцен и работу над маркетинговыми материалами.

Производство кат-сцен

На данной стадии все кат-сцены готовы в альфа-качестве, в них интегрированы финальные анимации, лицевые анимации, звук и финальные камеры.

Подсистемы и дополнительные игровые компоненты

Полностью интегрированы в игру, полностью готовы, находятся в состоянии окончательной настройки в движке.

Производство маркетинговых материалов

Тизер и ролик готовы для непубличного показа. Анонс-ролик содержит все основные элементы, но не финальный с точки зрения сложных анимаций, спецэффектов и особо сложных кадров. Финальный пакет скриншотов.

Бизнес-девелопмент

Определение шорт-листа предложений, посещение еще двух мероприятий, заключение договоренностей по маркетинговому содействию продвижения предложения и вывода материалов, подготовка к публичному анонсу.

Срок: 2 месяца.

Deliverables: билд бета-версии вертикального среза, предфинальные тизер и трейлер, скриншоты и отчетность.

Бюджет: X, из которых еще Y запланированы на анимационный аутсорс и Z на продолжение посещение выставок и встречи с партнерами.

Описание стадии

Результатом стадии является на 100 % готовый вертикальный срез, включающий в себя все запланированные материалы, функционирующие как на ПК, так и на одной из консолей. Маркетинговые материалы готовы к публичному анонсу.

Задачи

Производство релиз-версии

Финальный вертикальный срез, проведение нескольких раундов тестирования, фиксирование билда как окончательного.

Производство фичей

На этой стадии только тестирование, отладка, чистка багов, оптимизация и полировка.

Производство контента

Вся контент-команда сфокусирована на производстве и введении финальных материалов в маркетинговом блоке, но готова содействовать технически интеграционной команде в оптимизации и настройке.

Производство кат-сцен

Полностью готовы и введены в версию.

Подсистемы и дополнительные игровые компоненты

Полностью готовы и введены в версию.

Производство маркетинговых материалов

Тизер и трейлер готовы к публичному анонсу, полностью в финале.

Бизнес-девелопмент

Частные визиты в офисы по шорт-листу партнеров, реализация сделки на полное производство, анонс работы над проектом в публичном поле.

Срок: 2 месяца.

Deliverable: вертикальный срез.

Бюджет: X, из которых еще Y запланированы на анимационный аутсорс и Z на продолжение посещения выставок и встречи с партнерами.

В итоге этого плана мы должны получить вертикальный срез нашей игры, с которой будут параллельно происходить две вещи. Первая – внутри студии продукт отправляется в полномасштабное производство в соответствии с планами. Второе – продукт начинает путешествовать по выставкам и партнерским встречам в поисках издателя.

На этом, можно сказать, мы готовы с планами и можем смело закатывать рукава, вступая на тропу производства. Но перед этим давайте еще раз пройдемся по ключевым моментам первых семи глав, посвященных подготовительным процессам.

› Перед фактическим стартом работ вы обязаны определить стратегию и долгосрочный план как вашего продукта, так и вашего бизнеса. Направлений достаточно много. Мы попробовали описать ключевые, но гибридов может быть бесконечное множество.

› Помните, что с точки зрения глобальной системы продукт, компания, команда и вот вы конкретно как учредитель и носитель идеологии представляете собой основные компоненты ценности запланированной истории. И вы обязаны соответствующим образом относиться и заботиться о них всех.

› Планирование деятельности в игровой сфере – это многофакторный процесс с многочисленными перехлестами, кросс-чеками и итерациями. Вы будете возвращаться к определенным элементам по несколько раз, приводя их в порядок, добавляя новые элементы, от которых будут постепенно меняться уже собранные разделы плана. Это нормально.

› Основной сложностью и тонким моментом является учет и сведение всех неочевидных моментов, связанных скорее с бизнесом и хозяйственной деятельностью, чем непосредственно с разработкой игры. Стоит помнить, что мелочей здесь не существует и каждый стартовый недочет где-то потом выстрелит – как то самое пресловутое ружье на стене.

› О бизнес-деятельности вообще. Если уж вы считаете себя обязанным играть во множество проектов и просматривать кучу историй про прочие игровые компании, то почему, открывая собственное предприятие, вы считаете, что вам не нужно изучать основы управления предприятиями и финансового менеджмента? Конечно же нужно. И даже придется. Иначе в итоге будет больно.

› Итеративность, стадийность, понимание, какие из ваших процессов параллельные, а какие последовательные, являются вашими лучшими друзьями и инструментами контроля. По-хорошему, если вы можете распланировать продукт таким образом, что будет более или менее понятен прогресс на каждую неделю-две (сборка билда), – это идеально для внутреннего ощущения темпа разработки. При этом понятно, что при большем размере проекта глобальные стадии будут исчисляться месяцами.

› В производстве практически всегда лучше заложить дополнительные материалы, которые позволят снять фактор «здравого смысла» и вещей вроде «и так поймут, ясно же написано», так как игровая разработка является сложной кросс-дисциплинарной историей и практически наверняка на старте будет много недопонимания между участниками команды. Как пример – проработка текста для ключевого концепт-арта и последующий разбор ключевого арта на черно-белые производственные, грубые скетчи звучит для многих как лишняя работа для препродакшена. Но, как показывает практика, в долгосрочной перспективе снимает множество рисков и скорее выгодна. Автор, к примеру, если есть возможность, вообще скетчил бы и раскадровывал все на свете до старта фактических работ. К сожалению, это обычно невозможно, но в целом определяет отношение – все, что предварительно можно сделать исключительно на бумаге, лучше сделать на ней.

› Мы коснемся этого элемента еще в дальнейшем, но уже с момента позднего планирования, при вовлечении первых дополнительных членов команды, необходимо учиться делегировать, четко соблюдать границы экспертиз и вообще грамотно отделять мух от котлет. Системная разработка не приемлет авторитарного шапкозакидательства, при том что требует аккуратного кураторства. Это достаточно тонкая грань, которую нужно научиться ощущать, и чем раньше, тем лучше.

Подведя итоги, приступим же к разделу о производстве. В нем мы разберем процесс разработки отдельно взятой игры в нескольких перспективах: линейной – отталкиваясь от описанных выше планов – и прикладной, рассматривая распространенные техники и подход к процессам, позволяющие оптимизировать затрачиваемые усилия без потери, а зачастую и с ростом качества.

Раздел 2
Производство

2.1. Организация рабочей среды

Перед тем как перейти к главам, посвященным производству, нам понадобится небольшое вступление к разделу.

Во-первых, тематика настолько обширна и глубока, что на нее при практически любой методологии не хватило бы и трех вот таких книг – даже если бы перед нами стояла такая задача. Фокусом данной работы является скорее рассмотрение логики, методов внедрения и интеграции планов в работу, правильный подход в постановке задач и построение процессов их выполнения. Все игры, команды и контексты разные, однако существует определенный набор общих правил, которые вам в любом случае пригодятся.

Во-вторых, с точки зрения хронологии действий важно держать в голове тот момент, что после первого, в общем-то, крайне понятного и последовательного раздела, в случае плана подписания проекта с партнером производство и бизнес-девелопмент после реализации вертикального среза происходят одновременно. Это значит, что после прочтения этого раздела вам будет необходимо мысленно вернуться на момент производства демоверсии и пакета готовых материалов и параллельно представлять ситуацию из конкретно этой точки времени и пространства.

В-третьих, любые производственные цепочки обслуживают планы и задачи проекта, и в данном случае вообще выстраиваются конкретно под нужды детально подготовленного плана разработки игры. Но стоит держать в голове тот момент, что реальность имеет склонность вносить в любые планы изменения. И реальные цифры, и корректировку расчетов вы получите только после производства вертикального среза.

Учитывая все это, давайте приступим к первому и самому важному моменту, на который стоит обратить самое пристальное внимание, а именно – организации среды разработки. Мы рассмотрим здесь три аспекта данной задачи: организация физический среды, софтверной среды и инфраструктуры.

Офисное помещение

Несмотря на то что распределенная разработка становится все популярнее, мы предполагаем, что после завершения стадии планирования команда решила арендовать офис, который используется для разработки проекта. В среднем считается, что в современных реалиях комфортным будет минимум 6–8 квадратных метров на одного человека. Офис должен включать в себя рабочее пространство, отдельное помещение под серверную, а также (крайне желательно) отдельно вынесенную площадь под переговорку и подсобные помещения (кухня, санузел и так далее). Хотите вы того или нет, но или сразу, или после вам так или иначе придется обеспечить определенные западные стандарты для офиса – если вы собираетесь работать с западными компаниями размерами выше среднего. С точки зрения помещения это значит, что у вас должно быть как минимум два контура охраны: один на все помещение, второй – конкретно в помещении, где находятся серверы. Я крайне рекомендовал бы посмотреть по этому поводу информацию в онлайне и вообще ознакомиться с деталями подобных требований и стандартов – например, для того, чтобы в будущем иметь хотя бы гипотетическую возможность выполнения этих пунктов без смены помещения. Также всегда полезно закладывать возможность роста команды. Ну или же вы с самого начала понимаете, что будете менять офис после какой-то стадии – тогда требований накладывается существенно меньше. Помещение должно быть хорошо кондиционированным, соответствовать нормам пожарной безопасности и поддаваться возможности зонирования. Помещение и все находящееся в нем должно быть застраховано.

Рабочие машины

Здесь есть несколько подходов, но по возможности старайтесь брать наиболее мощные машины – каждую в комплекте с двумя мониторами. Это, во-первых, существенно сэкономит вам рабочее время, а во-вторых, вы все равно так или иначе потом потратитесь на апргейд и поддержку техники. Устоявшейся практикой является самостоятельная сборка машин (это эффективнее и дешевле), стандартной стоимостью одной сборки на практически любой момент является $1500–2000. Теоретически можно совсем поиграть в эффективность и попробовать продумать разные конфигурации для разных специализаций в команде, но реально – учитывая тот момент, что любые современные технологии умеют распределенно компилировать билды и считать рендеринг – попытка сэкономить на подходе скажется на времени и итеративности подготовки билдов. Поэтому я бы просто брал за основу – на технике экономить нельзя. Кроме того, нормальной практикой является то, что с точки зрения безопасности рабочие машины не имеют никаких альтернативных способов обмена данными, кроме как сеть.

Серверы

Практически все начинают с того, что в начале разработки это просто одна отдельно выделенная машина, а ко второй половине проекта (даже если это не онлайн) – это все равно небольшая серверная, обслуживающая как задачи проекта, так и десятки (если не сотни) автоматизированных задач, что экономит вам как время, так и деньги. Сейчас бытует мнение, что в целом без сервера в офисе можно обойтись и сразу держать все в онлайне. Но я считаю, что нужно иметь обе опции. Опять же, по сложившимся практикам безопасности и принципам работы со сторонними источниками, куча западных издателей – из исключительно консервативных соображений – не сильно обрадуется отсутствию физических серверов в офисе. Как и, скажем, системе обеспечения их безопасности.

Сеть и прочая связь

Сразу думайте о нескольких каналах: один основной, другой – резервный. Помимо доступа в сеть, интернет для вас – это, в первую очередь, возможность постоянной оперативной работы с системой хранения версий – с регулярными бекапами данных в онлайне. Ситуация, в которой вы вдруг потеряли доступ к сети, – это уже форс-мажор и серьезная проблема, даже если это произошло краткосрочно. Помимо сети, опять же, по требованию многих партнеров, офис должен содержать выделенную телефонную линию. Учтите, что для упрощения получения сертификаций с некоторыми компаниями (в частности Sony) вам понадобится статический IP. Это опять же все решаемо посредством VPN, но если есть возможность его получить, то лучше ею воспользоваться. Сеть должна быть максимально безопасной: если в офисе используется Wi-Fi, он должен быть разделен на рабочий и гостевой.

Девкиты

Если вы разрабатываете на приставки, вам понадобится сертифицироваться у владельцев консоли для получения так называемых девкитов – устройств для разработки. Процессы сертификации минорно различаются между компаниями, но суть примерно всегда одинакова: вы подаете заявку от студии по конкретному проекту, ее рассматривают, если все хорошо (а в 99 % случаев да) – вас регистрируют как разработчика на данную конкретную платформу. После этого вы имеете право приобрести девкиты, которые отправляют к вам в офис. Ну или вы как-то альтернативно их привозите. Без девкитов вы не соберете и не сможете оттестировать билд на конкретную консоль, и заниматься вопросом их приобретения нужно максимально заранее.

Прочее

Не стоит забывать о том, что вы – компания, которая занимается разработкой игр, и как минимум вам нужно обеспечить доступ вашей команды к постоянному тестированию, исследованию и ознакомлению с игровой продукцией. Хорошей практикой является установка в офисе доступных на данный момент на рынке консолей с телевизорами и отведение под это специальной небольшой игровой зоны. Также старайтесь думать об эргономике процесса, и если, скажем, вы снимаете офис не в торговом центре с кучей заведений, где можно поесть, то стоит задуматься о кухне и комплексных обедах, чтобы экономить себе и людям время и силы на беготню.

В целом задача сборки офиса для разработки игрового продукта – это всегда совмещение баланса между эффективностью, комфортом, безопасностью данных и возможностью в дальнейшем принимать гостей и проводить переговоры.