Цель предлагаемых нами моделей – выпустить качественный проект в срок, потратив определенные, в том числе денежные, ресурсы. Поэтому, если вы инди-одиночка, который делает игру для себя и рискует только тратой собственного времени (что, конечно, тоже нежелательно), тщательная подготовка ко всем этапам может быть необязательной. Если что-то пойдет не так, вы просто поработаете над игрой лишний месяц/год. Если вы при этом учитесь или работаете, как обычно, и уверены, что страсть доделать игру не пропадет, то в общем-то в этом нет ничего страшного. Если же время, которое вы тратите на создание игры, не позволяет полноценно зарабатывать, а, как говорится, надо кормить семью, риски многократно возрастают.
Игровые компании в свою очередь рискуют миллионами долларов, и для них правильное построение процессов критично: даже один убыточный проект – это риск закрытия студии навсегда.
Без предварительной документации довольно трудно понять, какие сотрудники на каком этапе разработки могут понадобиться. Ваша идея должна обрести новую форму, которая поможет ответить на этот вопрос. У проекта уже есть концепт, вижн, теперь предстоит еще немного углубиться в детали и составить FEATURE-ЛИСТ.
Это краткое описание всех фичей, из которых состоит игра, например строительство базы, клановые бои, система повышений и т. д. Также этот документ – анализ всех действий с точки зрения приоритетов и временных затрат. Он состоит из списка задач, категории, к которой можно отнести задачу (программный код, графика и т. д.), и времени на реализацию. Можно просто оценить задачи одной строкой по времени, а можно разбить по этапам (препродакшен, продакшен или релиз).
Обычно такой документ составляется в два этапа: первый раз вы встречаетесь всей командой и просто составляете полный список фичей, затем каждый ответственный заполняет свою часть. Вторая встреча посвящена согласованию этих оценок, после чего можно приступать к планомерной работе. Грамотно составленный feature-лист может сэкономить в будущем уйму времени.
Многие разработчики, особенно начинающие, игнорируют этот документ, так как неопытным специалистам составлять его нелегко. В этом случае можно обойтись просто оценкой бэклога, о которой мы писали выше, когда говорили о Scrum. Однако помните, что без feature-листа вы сможете оценить общее время разработки игры только очень приблизительно. Именно на основании этого документа вы (ваш продюсер или ПМ) будете ставить конкретные сроки для своих задач.
Чтобы не терять понимания, когда мы вообще сможем запустить проект, лучше заранее составить майлстоуны[39]. Допустим, мы насчитали 10 фичей, по одному месяцу на реализацию каждой. Так что мы надеемся завершить проект за десять месяцев. Но что должно быть готово, например, на пятом месяце разработки? Укладываемся ли мы в сроки? Если мы хотим сделать клановые войны, логично, что перед этим надо завершить создание самих кланов. Одни фичи могут тянуть за собой другие. Чтобы не блуждать во тьме, мы разбиваем список задач на отдельные большие блоки с конкретными сроками. Для людей, работающих за деньги, это критично, ведь ресурсы нужно распределить так, чтобы их хватило до конца проекта.
Майлстоуны делят на более мелкие итерации, короткие промежутки времени, за которые необходимо успеть сделать определенный набор фичей. Если задачи комплексные, лучше разбивать их на более мелкие.
Обычно в feature-листе вы можете найти ссылку на отдельные части ГДД (гейм-дизайн-документа) с более подробным описанием каждой задачи.
Обычно жанр определяет некоторое количество игровых фичей, ожидаемых игроками. Гейм-дизайнеры стараются добавить также несколько свежих фичей, чтобы выделить свой проект среди конкурентов и чтобы игра стала интереснее. Принимая решение, гейм-дизайнеры всегда должны проанализировать три вещи: насколько фича полезная, насколько рискованная и насколько дорогая (сколько человеко-часов нужно для ее реализации).
Ошибки в оценках чаще всего происходят из-за того, что геймдизайнер не смог объяснить исполнителям, что именно представляет собой фича, над которой им предстоит работать. Особенно это актуально для экспериментальных проектов и команд новичков. Если на проекте нет ни одного опытного лида, который в состоянии хотя бы примерно оценить время реализации, можно попробовать дать исполнителям пробные задачи и по результатам работы сделать соответствующие выводы, а можно обратиться за внешней консультацией.