Текст книги "Хочу в геймдев! Основы игровой разработки для начинающих"

Выбор управленческих методологий для команды

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

Когда вы собираете свою первую команду, иногда лучше заранее договориться, что проект должен быть простым и может даже ничего не заработать. Часто цель совместной работы над дебютной игрой – налаживание процессов, обучение и опыт. Можно, например, создать клон любимой игры, добавив туда одну самостоятельную фичу, или переработать сеттинг. Работая над жанром с устоявшимся геймплеем, вы можете сосредоточиться на создании контента, чтобы в будущем четко понимать, какое время занимает реализация той или иной фичи.

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

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

WATERFALL[36]36
  . Waterfall, «Каскадная модель» (от англ. waterfall model – «модель «Водопад») – методика управления проектами, которая подразумевает последовательный переход с одного этапа на другой без пропусков и возвращений на предыдущие стадии.


[Закрыть]

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

Такой подход основан на линейном, последовательном цикле разработки: концепт → составление документации → аналитика и сбор информации по рынку → дизайн → программирование → тестирование → поддержка.

Рис. 9. Цикл разработки Waterfall

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

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

AGILE

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

Если следовать Agile, внесение изменений в процессе разработки намного важнее следования планам. Конечно, документации никто не отменяет, но работающий софт и прямое взаимодействие сотрудников в приоритете.

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

Цикл разработки в Agile выглядит так:

Рис. 10. Цикл разработки в Agile

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

SCRUM

Scrum – один из самых популярных способов практического внедрения философии Agile. Он подходит в основном небольшим командам до 10 человек, причем используется повсеместно, не только в IT-сфере. Предполагается, что некоторые члены команды возьмут на себя определенные роли, обязанности и будут соблюдать четыре постоянно повторяющиеся «церемонии»:

• планирование спринта[37]37
  . Спринт – это короткий период времени, в течение которого команда Scrum работает над выполнением заданного объема работы.


[Закрыть] (итерации);

• регулярный стенд-ап;

• подведение итогов по задачам спринта;

• ретроспектива спринта.

Давайте разберем их подробнее.

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

Рис. 11. Схема Scrum

Если коротко, на практике все это выглядит так.

1. Прежде всего назначается ВЛАДЕЛЕЦ ПРОДУКТА (PRODUCT OWNER). Это человек, который лучше всех знает, что за продукт вы делаете, и определяет его видение. Чаще всего именно ему принадлежит идея, и именно он отвечает за бэклог[38]38
  . Бэклог (от англ. product backlog) – это упорядоченный набор элементов, очередь задач, перечень всех функций продукта.


[Закрыть]. В реальных условиях роль этого человека во многом схожа с ролью продюсера проекта.

2. После того как команда собрана, следует выбрать СКРАМ-МАСТЕРА (SCRUM MASTER). Это должен быть самый организованный человек на проекте, способный следить за эффективной работой всех участников. Он не обязательно хороший управленец; главная его задача – помогать всем соблюдать методы Scrum, приоритезировать задачи и улаживать кризис. Можно не назначать его специально: подходящий на эту роль человек сам, скорее всего, не выдержит беспорядка и предложит свою кандидатуру.

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

Чтобы не возникало конфликта интересов, один человек не должен выполнять роль и Scrum Master, и Product Owner – они должны дополнять друг друга. Кроме этих двоих, все занимаются своей обычной работой.

3. Далее СОЗДАЕМ БЭКЛОГ – хранилище всех идей, связанных с проектом. Во многом Scrum – про демократию, так что обычно любой участник команды может внести свою идею для дальнейшего ее обсуждения с командой. К тому же, когда каждый может высказаться, уменьшается риск пропустить эффективное решение.

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

4. Потом команда собирается, чтобы обсудить и ОЦЕНИТЬ ЗАДАЧИ. Молодым командам сложно сразу правильно определить, сколько времени и ресурсов уйдет на то или иное действие. Определите хотя бы два параметра: длительность (насколько задача трудоемкая) и риски (что может пойти не так).

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

5. Далее ПЛАНИРУЕМ СПРИНТ. Мы просмотрели, оценили наши задачи и убедились, что можем уложиться в сроки спринта (это может быть неделя, две недели, три недели, месяц).

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

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

6. ЕЖЕДНЕВНЫЙ СТЕНД-АП позволяет всем членам команды знать, чем заняты остальные. Scrum должен обеспечивать прозрачность процессов и результатов, так что обычно с такой встречи и начинается рабочий день. Хороший стенд-ап длится недолго. Достаточно, чтобы каждый за пару минут обозначил, каких результатов добился вчера, какие у него планы на сегодня и есть ли какие-то проблемы, мешающие выполнению задачи. Возможные трудности не должны решаться здесь и сейчас, лучше назначить отдельное обсуждение, а на следующем собрании обозначить, что было сделано, чтобы исправить положение.

7. По пятницам обычно команда собирается для ОБЗОРА СПРИНТА (ДЕМО): обсуждаем прошедшую неделю, удалось ли воплотить в жизнь все запланированное, показываем заказчику результаты. Хорошей практикой считается, когда демо проводят не одни и те же люди, это дает разным сотрудникам ощущение причастности к проекту.

8. РЕТРОСПЕКТИВУ СПРИНТА лучше проводить также в конце недели, но отдельно от демо. Этот этап – позитивная точка окончания рабочей недели. Здесь не обсуждают задачи (мы уже все обсудили во время демо); это время обсуждения проекта без давления, с целью укрепления командного духа. Правильное окончание ретроспективы: «Ребята, всем спасибо, на сегодня работать закончили, на кухне вас ждет пицца».

Недельная итерация завершилась, можем двигаться к пункту 5 и планировать следующий спринт.

Пункты 5–8 идут циклично. Так что логично планировать спринт в один и тот же день, например в понедельник, чтобы поставить задачи на неделю.

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

Зачастую административные процессы (зарплаты, часы работы и пр.) устанавливаются руководителем для всей компании, продуктовые же – можно менять, исходя из команды и проекта: это нормально, если проектный менеджер предпочитает работать, например, в Trello, а лид программистов любит развешивать на доске бумажки. Хотя руководители некоторых игровых компаний настаивают на одинаковых методологиях и подходах для всех проектов студии.

Проектное управление на этапе препродакшен

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

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

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

Без предварительной документации довольно трудно понять, какие сотрудники на каком этапе разработки могут понадобиться. Ваша идея должна обрести новую форму, которая поможет ответить на этот вопрос. У проекта уже есть концепт, вижн, теперь предстоит еще немного углубиться в детали и составить FEATURE-ЛИСТ.

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

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

Многие разработчики, особенно начинающие, игнорируют этот документ, так как неопытным специалистам составлять его нелегко. В этом случае можно обойтись просто оценкой бэклога, о которой мы писали выше, когда говорили о Scrum. Однако помните, что без feature-листа вы сможете оценить общее время разработки игры только очень приблизительно. Именно на основании этого документа вы (ваш продюсер или ПМ) будете ставить конкретные сроки для своих задач.

Рис. 12. Пример feature-листа

Чтобы не терять понимания, когда мы вообще сможем запустить проект, лучше заранее составить майлстоуны[39]39
  . Майлстоун – контрольная точка, важный момент, этап. Исторически майлстоуны – это каменные плиты с указанием расстояний до населенных пунктов, которые расставлялись вдоль дорог и служили ориентиром путешественникам.


[Закрыть]. Допустим, мы насчитали 10 фичей, по одному месяцу на реализацию каждой. Так что мы надеемся завершить проект за десять месяцев. Но что должно быть готово, например, на пятом месяце разработки? Укладываемся ли мы в сроки? Если мы хотим сделать клановые войны, логично, что перед этим надо завершить создание самих кланов. Одни фичи могут тянуть за собой другие. Чтобы не блуждать во тьме, мы разбиваем список задач на отдельные большие блоки с конкретными сроками. Для людей, работающих за деньги, это критично, ведь ресурсы нужно распределить так, чтобы их хватило до конца проекта.

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

Обычно в feature-листе вы можете найти ссылку на отдельные части ГДД (гейм-дизайн-документа) с более подробным описанием каждой задачи.

Рис. 13. Майлстоун проекта

ФИЧЕКРИП[40]40
  . Фичекрип (от англ. feature creep) – насаждение возможностей, разрастание фичей или одной конкретной фичи.


[Закрыть] И ФИЧЕКАТ[41]41
  . Фичекат (от англ. feature cut) – удаление или урезание функционала лишних фичей.


[Закрыть]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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