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