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

[RPG diary]

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

DoubleBear Productions была основана в 2009 году командой из четырёх человек (двое из DoubleBear и ещё двое из Iron Tower Studio), чтобы работать над Dead State в свободное от основной работы время. О разработке Dead State официально объявили в середине 2010, тогда же к нашей команде присоединилось несколько человек, помогавших с художественным оформлением. Со временем стало понятно, что создание игры после работы вряд ли закончится чем-то хорошим, поэтому мы должны были отменить её или перейти к полноценному циклу разработки.

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

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

Составляющие игрового процесса Dead State создавались под впечатлением от оригинальных серий Fallout и X-Com, а также Jagged Alliance и Suikoden. Кроме того, в нашей команде были люди, ранее уже занимавшиеся разработкой ролевых игр в таких студиях, как Black Isle, Troika и Obsidian.

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

Несмотря на расширение команды, Dead State вышла на год позже запланированного срока (декабрь 2013), появившись в «Раннем доступе» Steam в феврале 2014. Полная версия игры была готова лишь 4 декабря 2014 года. Отзывы на вышедшую игру были по большей части сдержанно-положительными, покупатели похвалили Dead State за сюжет и управление убежищем, раскритиковав техническую часть и низкую сложность боёв. Мы продолжили поддерживать игру, исправляя ошибки и баланс, добавляя новые игровые материалы.

Что было сделано правильно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Разработка уровней

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

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

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

Продолжение следует...

Источник: Gamasutra
Перевод: core-rpg.ru

[RPG diary]

Что было сделано неправильно

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 тысяч строк текста, и это не считая боевых возгласов. Хотя я и считаю, что мы проделали огромную работу, чтобы сделать дружественных персонажей как можно более разнообразными и интересными, всё же не посоветовал бы никому создавать больше сорока возможных союзников. Ну разве что только если вы собираетесь делать очень короткую игру.

[RPG diary]

Чему мы научились

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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