Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение

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

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

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

На рис. 19.6 вы можете увидеть ту же инфографику диаграммы сгорания задач через несколько дней после рис. 19.4 и 19.5. Обоим членам команды удалось выполнить еще немного работы, но их скорость значительно снизилась. Вы можете видеть, что ступени лестницы на сером фоне становятся все мельче. Возможно, команда столкнулась с неожиданными проблемами в разработке, из-за которых задачи занимали намного больше времени, чем ожидалось, или, возможно, какие-то внешние факторы отвлекли их от работы над проектом.

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

Рис. 19.6. Та же инфографика диаграммы сгорания задач через несколько дней. Авторы изображения: Джереми Гибсон Бонд, Ричард Лемаршан, Питер Бринсон и Аарон Чейни

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

Решаем, что можно убрать

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

Однако не каждую низкоприоритетную задачу можно запросто выкинуть. Одни задачи удалить будет куда проще, нежели другие. Некоторые относительно низкоприоритетные задачи на самом деле могут быть прочно закреплены в дизайне игры благодаря их взаимосвязи с другими ее частями. Марк Черни недавно напомнил мне: «Здесь важно знать, какие части можно удалить, а какие нельзя. Если какая-то локация необходима для развития повествования или персонажа, ее нельзя убрать… поэтому очень важно постоянно проверять содержание проекта и корректировать дизайн со знанием того, что необходимо сохранить. Таким образом, вы сможете вносить коррективы на поздних стадиях разработки, не вредя игре». У каждого типа игр есть свои критерии относительно того, что можно легко вырезать, а что должно остаться, и по мере развития ваших навыков в гейм-дизайне вы научитесь отличать одно от другого.

Изменение планов в диаграмме сгорания задач