[Dead State] Послесловие Брайана Митсоды

1. Kickstarter и поддержка фанатов

Dead State получила то, чего не хватает многим, а именно увлечённых фанатов. Мы рано объявили о разработке, что позволило сформировать фанатскую базу. Мы старались как можно лучше взаимодействовать с фанатами Dead State, обсуждать идеи, держать в курсе процесса разработки. Когда мы падали духом, именно фанаты мотивировали нас продолжать.

Без фанатов, рассказывавших другим о нашей игре — в сообществах, прессе и на форумах, — наша кампания на Kickstarter не увенчалась бы успехом. Несмотря на то, что Kickstarter повышает степень ответственности разработчиков, заставляя чаще рассказывать о ходе разработки, без этих денег и поддержки сообщества игра бы не вышла. Когда работа переходит в самую напряжённую и болезненную фазу, очень важно знать, что есть люди, которым это нужно.

2. Инструменты управления проектом

Перед началом работы над Dead State мы задокументировали всю проектную информацию во внутренней вики, обновляя её в процессе разработки. Какого бы размера ни была ваша студия, трудно переоценить важность отдельного ресурса с проектной документацией. Работающим удалённо проще получить доступ к необходимой информации и изображениям, не ожидая ответа по электронной почте. Если у вас нет собственной вики, стоит потратить день на её создание и обучить людей её использовать. Из всех вариантов отслеживать информацию о проекте именно постоянно обновляемую вики я считаю лучшим и дешёвым способом донести нужные сведения до каждого.

Ещё одним инструментом, существенно облегчившим процесс разработки, стал Assembla. Он ускорил загрузку и обновление игровых ресурсов, создание резервных копий, отслеживание ошибок, раздачу заданий сотрудникам. Как только все научились работать с Assembla, скорость разработки значительно возросла.

Используя указанные выше инструменты и программы обмена сообщениями, мы создали «виртуальный офис», в котором работающим удалённо стало намного проще отслеживать ход разработки.

3. Оценка масштаба проекта

Многие игры, особенно ролевые, в конце концов подвергаются урезанию механик и уровней. Основу проекта Dead State составляли три ключевых (и очень больших) компонента: концепция убежища (управление диалогами, сюжетом и союзниками), нелинейный сюжет и диалоги (более 15 тысяч строк для десятков персонажей), а также пошаговые сражения в рамках свободного исследования мира.

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

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

4. Неизменность основной идеи

С самого начала разработки мы оставались верны идее «осознанного риска», к которой относились следующие ключевые концепции проекта: механика шума, привлекающего зомби и других противников; убежище, включающее управление ресурсами и систему распределения занятий; система кризисов (особых событий), в которой используются механики морали и связанных с персонажами событий.

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

К счастью, за исключением незначительных правок, нам не пришлось отказываться от основных составляющих игры или изменять их, а отзывы в «Раннем доступе» были вполне ожидаемыми. Если бы отзывы об одной из основных составляющих Dead State оказались плохими, нам пришлось бы значительно пересмотреть ход разработки. Отсутствие необходимости переделывать основные игровые механики сэкономило нам много времени и сил. Не зря мы с самого начала ответственно подходили к проектированию и реализации этих трёх важнейших элементов.

В Dead State вошло более 75 уровней различных размеров, однако сделали их достаточно быстро. Создание уровня для прототипа заняло больше месяца. Так как наша игра во многом посвящена исследованию мира и поиску вещей, мы знали, что его придётся несколько раз переделывать.

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

В конце концов, мы достигли такого уровня мастерства, что размещали случайные события на карте всего за час. Большие области создавались за день. Если бы мы не отладили создание уровней, игра оказалась бы гораздо меньше, а её качество в целом — хуже.

1. Плохое обучение новичков

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

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

2. Проблемы с бюджетом

Почти все проблемы разработки компьютерных игр сводятся к деньгам. За деньги можно нанять больше людей или заменить существующих более опытными, что в свою очередь сокращает цикл разработки и повышает качество проекта. Несмотря на успешность Kickstarter-кампании, средств хватило лишь на небольшую команду. Над большинством ролевых игр, в создании которых я участвовал, работало минимум 25-30 человек, в то время как в команду Dead State входило человек 8-10.

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

Мы планировали бюджет, исходя из средств, полученных на Kickstarter, не поддаваясь на соблазн включить возможную прибыль от «Раннего доступа». Имея сходный с крупными ролевыми проектами 2014 года бюджет, мы бы сразу наняли ещё несколько опытных разработчиков, а новички помогали бы в тестировании и устранении ошибок.

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

3. Технические проблемы

Dead State создавалась на основе Torque 3D, потому что главный программист хорошо знал этот движок, к тому же он дешёвый (фактически бесплатный) — но, как оказалось, не поддерживает большинство инструментов разработки ролевых игр.

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

Torque — неплохой движок для игр на ПК, но он устарел — не только графически, но и в возможностях переноса игр на Mac/Linux/консоли. Отказ от Unity в пользу Torque был огромной ошибкой. Сложность переноса игры на другие платформы существенно сократила возможную прибыль.

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

4. Проблемы удалённой разработки

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

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

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

5. Слишком много персонажей

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

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

В игре представлено 45 дружественных персонажей, у каждого от 6 до 30 разветвлённых диалогов. Количество диалогов быстро разрасталось, написание текстов, переработка и создание программной части отнимали всё больше времени. Ситуация усугублялась тем, что диалоги писали два человека, у которых и без того было дел по горло.

Сложнее всего было с персонажами, находящимися в убежище более 85 дней. Игроки (и критики) ждали от них новых диалогов практически каждый день или не меньшей общительности, чем у спутников главного героя в других ролевых играх. Но в большинстве ролевых игр полноценно прорабатываются от силы персонажей десять, да и реплики обновляются лишь в некоторых точках линейного сюжета.

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

1. Заранее определиться с масштабом и смоделировать игровые механики

Проект нужно воплощать как можно скорее. Начните с временных вариантов меню, наполнения и интерфейса. Протестируйте планируемые концепции и механики. Скучно и некрасиво? Обновите визуальную составляющую, но помните: графика графикой, только вот на одной графике далеко не уедешь. Если требования тех или иных подсистем или графического интерфейса кажутся запредельными, постарайтесь что-то сократить, упростить, убрать. Заранее рассчитывайте время разработки и размер команды, соответствующим образом планируйте масштаб игры с учётом имеющегося времени. Всё это очевидно, да? А мы вот загнали себя в ловушку, пытаясь выдать игру раньше срока.

2. Раньше выпускать бета-версию

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

3. Планировать масштаб и структуру проекта с учётом бюджета и размера рабочей группы

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

4. Наладить взаимодействие между разработчиками

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

5. Анонсировать игру ближе к выходу, не тратить силы на раскрутку на ранних стадиях разработки

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