Добро пожаловать, berk
Twitter Группа Steam Страница Вконтакте Группа C.O.R.E. Dragon Age Контакте Новостная лента RSS
/ Статьи / Игры и игровые серии / Dead State

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

Автор: Brian Mitsoda | Добавил: m00n1ight, 15.03.2015 | Просмотры: 1068

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

Dead State (1)

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

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

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

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

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

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

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

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

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

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

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

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

Dead State (3)

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

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

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

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

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

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

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

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

Dead State (4)

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

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 был большой ошибкой. Сложность переноса игры на другие платформы существенно сократила возможную прибыль.

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

Dead State (5)

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

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

Мы не смогли избежать этих проблем.

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

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

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

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

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

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

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

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

Dead State (6)

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

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

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

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

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

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

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

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

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

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

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

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

Dead State (7)

Заключение

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

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

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

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

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


Обсудить статью на форуме

Обновления форума

Копирайты

  • C.O.R.E. © 2009 – 2016
Система Orphus Creative Commons License
Войти на сайт?
Логин:
Пароль: