Руководство проектом: что при разработке игры может пойти не так?

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

Иными словами, давайте помнить, что банальность — это уставшая истина. И чтобы идти дальше, хорошо бы о ней помнить.

Какие есть общие места, которые касаются, в первую очередь, не самих проектов, но всего того, что творится вокруг них? Из-за чего вместо хитов мы часто сталкиваемся с проходняком?

1. При разработке не должно быть конфликтов в команде, но должен быть стресс

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

Конфликт в команде — это большая проблема

Важность хороших отношений в коллективе с приходом free-to-play (игр-сервисов) — стала важным условием благополучности самого проекта.

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

Если команда не волнуется, то тут возможны три варианта:

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

Есть еще один вариант: когда всем, вроде, не все равно, но работа начинается только когда майлстоун маячит где-то недалеко. Ключевое слово здесь — “вроде”. То есть, на самом деле, проектом никто не хочет заниматься, он команде или ее части неинтересен. И на выходе получается игра, далекая от ожиданий.

2. Не надо нанимать, кого попало, с кем попало проект не сделаешь

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

Убедитесь, что тылы прикрыты

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

Разработчик: Привет! Мы молодая команда инди разрабов, нам нужен программер юнити, делаем 2д палтформер шутер!

Автор: Привет! Это замечательно.

Разработчик: Это значит ты согласен к нам присоединиться?

Автор: Нет, я не программист и совершенно не понимаю, почему Вы мне пишете)

Разработчик: Черт, хахаха, не повезло. Ты в группе Unity был.

Автор: Где связь между подпиской человека на группу Unity и умением программировать?

Разработчик: Обычно такая имеется.

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

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

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

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

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

Скажем, решили делать 3D-экшен от первого лица, одной из фич которого является возможность взаимодействия с большим количеством устройств с собственным UI. И сразу становится понятно, что тут выбор ограничивается Unity и Unreal, поскольку оба недавно внедрили поддержку подобного функционала. И так далее.

UI, созданный в Unreal 4 Engine

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

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

4. Придумывая игровой функционал, фичи, ставьте перед каждой вопрос — зачем?

Если честно, то вопрос “зачем” — вообще для жизни очень полезный, поскольку прекрасно работает в качестве бритвы Оккама (иными словами, отсекает все лишнее). Работает он и при разработке игр.

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

Но вовремя заданный вопрос “зачем нужны караваны в игре” (плюс, уточнения к нему, вроде, что караваны дадут игроку, что дадут игре, поднимут ли ей удержание, улучшат ли монетизацию и так далее), рассеивает эту атмосферную картинку.

Поэтому зачастую лучше вообще идти от задач к фичам, нежели наоборот.

5. Любите свой проект и жанр, в котором работаете

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

Разработчик может быть настоящим профессионалом, гением, но если на него не действует, к примеру, магия match-3, как он ее сможет воплотить в своей игре? Он же (или она), играя, не поймет, есть ли от процесса удовольствие или нет.

Так любить — необязательно

Так как же он сможет говорить, что его игра лучше других проектов, которые он, на самом деле, не ценит?

6. Верьте в свой проект

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

Иными словами, можно бегать по офису с флагом компании и кричать: “мы всех порвем”, а можно спокойно поделиться с командой соображениями, чем ваш проект лучше остальных и что необходимо сделать, чтобы он в действительности стал таковым.

7.  Будьте критичны

В любви и вере важно не уходить в крайности. Часто бывает, что разработчики банально не видят недостатка в свои проектах (это особенно свойственно совсем небольшим командам, чей состав насчитывает максимум трех сотрудников). Поэтому, повторимся, очень важно хорошо ориентироваться в своем жанре. Фанат трехмерных шутеров, прошедший пару раз последний Wolfenstein или Far Cry, вряд ли сможет гордиться тем, что разработал экшен в серых коридорах.

У нас все.