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

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

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

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

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

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

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

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

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

ДОКУМЕНТАЦИЯ: БЮДЖЕТ ПРОЕКТА И БИЗНЕС-ПЛАН ПРОЕКТА

Бюджет проекта – это план затрат, необходимых для его исполнения. Сюда включают заработную плату сотрудников, стоимость оборудования, закупку материалов, программного обеспечения, ассетов, налоги и пр. В игровой индустрии обычно он состоит из двух частей: планируемые расходы и прогнозы доходов. К сожалению, без грамотно составленного feature-листа сделать адекватный план бюджета и бизнес-план невозможно. А это влечет за собой большую проблему: если бюджет будет сильно завышен, то издатель/инвестор не захочет с ним работать, если же вы ошибетесь в сторону уменьшения, не исключена ситуация, когда вы подпишете договор на определенную сумму, а деньги закончатся задолго до завершения проекта.

План бюджета – это обычно именно внутренний документ, по которому фактически работает команда. А бизнес-план предназначен для демонстрации планов и прогнозов инвесторам/издателям.

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

Нельзя не сказать о том, что четкое планирование больше подходит для крупных профессиональных команд, потому что имеет те же недостатки, что и Waterfall: любые планы имеют тенденцию расходиться с реальностью, особенно когда вы делаете что-то впервые. Идеи, которые вы собираете в бэклоге, – это прежде всего цели, и для многих команд эффективнее дать исполнителям определенную свободу на пути к их достижению. Главное, чтобы эти задачи были реальными и выполнимыми в указанные сроки.

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

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

И конечно, каждая команда индивидуальна; выбирайте или придумывайте что-то свое, главное – результат.

Выбор игрового движка

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

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

Игровые движки в современном понимании зародились в середине 90-х. В то время инди-разработки как таковой практически не было, созданием игр занимались более или менее профессиональные компании – хотя, конечно, по современным меркам многие из них были инди. Каждый движок делался под специфический жанр или игру.

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