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