Далее будет изложена методология запуска проектов в разработку, которой я пользуюсь примерно с 2018 года, регулярно ее полируя и дополняя. Так что все изложенное далее уже проверено на практике и доказало свою эффективность. Ключевым моментом тут, наверное, является следующая мысль: да, этого набора практик и документов достаточно для того, чтобы запустить разработку игрового проекта. Больше вам ничего не потребуется. Но при этом попрошу воспринимать этот текст лишь как tip, а не как prescription, потому что в данном случае мое дело – показать вам, как выглядит удочка, а сделать ее себе и поймать рыбку вы должны сами. В этом есть важный элемент освоения и закрепления полученной информации, тем более что почти наверняка вы переработаете часть этой методологии под окружающие вас реалии и свои нужны. В любом случае, приятнее выстраивать такую важную систему, «сверяясь с книжечкой», где изложен спрессованный в строки чужой опыт, чем пытаться изобрести этот инструментарий с нуля.
И еще одна важная оговорка, эта методология заточена под мобильные коммерческие проекты, а для «инди-проектов вашей мечты» она, скорее всего, не так хорошо подходит, так как решает прежде всего рыночные, коммерческие задачи. Но даже если вы заняты разработкой инди-проекта в свободное время, я бы все равно советовал вам обратить на эти выкладки пристальное внимание – они, скорее всего, помогут вам структурировать вашу деятельность, что, безусловно, благотворно скажется на качестве вашей игры.
Как сделать хорошую игру, Способ № 13: Использовать методологический подход при запуске и разработке проектов. Не обязательно брать именно мою схему, можно сделать свою инструкцию, здесь много важнее философия: ваши действия должны быть осмысленны, последовательны и уложены в некую канву, которая приведет вас к результату.
Это инструкция, следуя которой, вы сможете выполнить такое комплексное и сложное действие, как запуск в разработку игрового проекта. Если вы когда-нибудь самостоятельно собирали роликовый шкаф, то при слове «инструкция» сразу же поймете все плюсы (как и некоторые неизбежные минусы) такого подхода.
Итак, зачем вообще нужна методология запуска проектов?
• Ориентация на один, даже потенциально хитовый, проект представляет собой максимальный риск в условиях сформировавшегося игрового рынка.
• Для того чтобы максимизировать шансы на успех, нужно оперировать линейкой игровых проектов, даже если вы небольшая команда (в таком случае ваша линейка будет разрабатываться последовательно, а не одновременно, но все равно останется линейкой).
• Поскольку каждая из попыток может быть неудачной, следует максимально сократить затраты до момента получения первых релевантных метрик после запуска игры.
• Это подразумевает более гибкую парадигму разработки со значительно большим уровнем контроля над процессами.
Другими словами, для успеха на современном игровом рынке надо научиться оперативно и без серьезных затрат доводить проекты до стадии пробного запуска, быстро принимать по ним решения и основные вложения делать уже после того, как перспективность проекта подтверждена метриками, то есть объективными данными. Для этого процесс запуска проектов в работу должен быть стандартизован. Стандартизация в данном случае достигается путем применения в проектах одной и той же методологии, то есть последовательности действий.
Каким образом возможно интегрировать эту последовательность в процессы компании или команды?
• На уже начатых проектах – эту методологию можно интегрировать частично, отдельными элементами.
• На новых проектах – по возможности полностью, начиная с первых этапов.
В любом случае перед интеграцией необходимо предусмотреть процесс ознакомления всех участников с методологией и обучения их работе с основными документами.
Мы начинаем со стандартизации этапов подготовки проекта к производству и получаем вот такой список (в скобках указаны роли, ответственные за тот или иной пункт).
1. Формулирование бизнес-установок проекта от руководства компании (руководитель компании/команды или инвестор);
2. Написание на основании этих установок документа Strategic Statement (менеджер по продукту, продюсер или координатор проекта);
3. Формирование core team проекта, в которой должны быть закрыты роли: менеджер проекта, главный программист, главный художник, главный гейм-дизайнер.
4. Обсуждение/корректировка Strategic Statement силами core team и развитие его до Concept Document (главный гейм-дизайнер).
5. Декомпозиция фичей из Concept Document и оценка трудозатрат на их разработку руководителями групп (вся core team).
6. Формирование, заполнение и балансировка документа Feature List (менеджер проекта, продюсер или координатор проекта).
7. Создание предварительной бизнес-модели проекта (специалист по маркетингу либо продюсер или координатор проекта).
8. Приемка Feature List заказчиками и инвесторами проекта (руководитель компании/команды или инвестор) – внутренний Greenlight.
9. Создание финальных версий документов Strategic Statement, Concept Document, Feature List и презентации one pager (вся core team).
10. Опционально приемка проекта на внешнем Greenlight (наблюдательный совет, инвестор, издатель, etc.).
Описание методологических документов, упомянутых ранее:
• Strategic Statement;
• Concept Document;
• Feature List;
• Business Model;
• Presentation.
Я не буду давать вам готовые шаблоны документов, так как практика показывает, что достигнутое понимание целей, сути и формата документа дает лучший результат, чем имеющийся готовый шаблон. Скорее всего, под свои задачи вы все равно его переделаете, поэтому лучше начать создавать эти документы и таблички сразу с чистого листа. Кроме этого, я много раз давал готовые шаблоны документов специалистам, и каждый раз они в итоге создавали свою версию, вполне решавшую их проектные задачи. Итак, пройдемся коротко по всем перечисленным в прошлом абзаце документам.
Strategic Statement (Стратегическое позиционирование проекта)
Строго говоря, данный документ представляет собой адаптацию идеи проекта под сформулированные бизнес-задачи. Документ состоит из двух частей – в первой перечисляются бизнес-задачи, вторая должна раскрыть, каким образом эти задачи будут выполнены. Ключевая цель на этом этапе – осознать, какую бизнес-задачу решает проект (это обязан сделать тот, кто является основным заказчиком или инвестором проекта), и максимально четко ответить на эти вопросы в концепции игры. Тут, конечно же, в полной мере работает старый проверенный принцип – чем четче поставлена задача, тем более адекватным будет ее решение. Структура документа может меняться в достаточно широких пределах, при этом он должен четко раскрывать следующие пункты:
1. Платформа/технология.
2. Референсные проекты.
3. Описание базового геймплейного цикла.
4. Мета-уровень проекта.
5. Модель монетизации.
6. Потенциальная аудитория.
7. Сеттинг проекта.
8. Параметры разработки (основные приоритеты и критерии качества, планируемый бюджет, ожидаемые сроки).
9. Наработки и опыт команды, которые могут быть использованы в проекте.
Крайне важный момент – если у вас не получается сделать этот документ (или он выглядит не очень логично), проект начинать делать пока не надо. Если вы не знаете, чего хотите, или не можете понять, чего именно хотят от вас – эта дорога, скорее всего, не приведет вас к успеху. Strategic Statement – это ядро всего проекта, дальше вы будете только развивать заложенные в этот документ мысли. В этом сильная сторона данной методологии (последовательность и логичность), но в ситуации, когда вдруг «вся концепция поменялась», вам придется откатываться в самое начало (это, скажем так, обратная сторона медали).
Обратите внимание – сеттинг (то есть игровой антураж) стоит фактически на последнем месте. Крайне распространенная ошибка строить весь проект на сеттинге, пренебрегая собственно игрой.
Concept Document (Концепция проекта)
Концепция проекта развивает идеи, заложенные на предыдущем этапе. Назначение этого документа – максимально раскрыть игровые механики проекта, то есть сформировать так называемый Feature Set, с которым в скором времени продолжится работа. Концепт – это первая и базовая прямая инструкция для ядра команды разработки, и качественная реализация этого этапа нужна для того, чтобы подготовить базу для создания Game Design Document (Дизайн-документа игры). На основании документа с концепцией проекта команда дает оценки трудозатрат для следующего этапа – Feature List. Формат документа определяется геймдизайнером команды и адаптируется под нужды проекта. Опционально к документу обычно прилагается декомпозиция референсных игр (надеюсь, вы внимательно читали предыдущие главы и собрались делать не что-то уникальное, совсем не имеющее аналогов). Проверить качество работы на этом этапе можно простым тестом – все члены команды после прочтения концепта должны понимать, что за игра делается, мочь членораздельно сформулировать это понимание и не иметь по этому поводу возражений. Если не получается (например, мы хотим сделать прорывную многопользовательскую игру на десять тысяч игроков в одном инстансе, а главный программист очень даже против и не знает, как это вообще реализовать) – идем на следующую итерацию доработки концепции/переговоров с программистом в поисках компромисса либо вообще возвращаемся на этап Strategic Statement.
Feature List (Смета проекта)
Тут все уже немного попроще, так как мы от дизайна переходим к этапу планирования. А в чем-то и посложнее, потому что планирование требует более скрупулезного подхода и системности. По сути, Feature List – это смета проекта, где задачи сведены в план разработки и согласованы с размером команды и бюджетом. Название документа может ввести в заблуждение, но это традиция еще со времен Nival (а вообще, корни этого формата, по слухам, уходят во тьму веков и относятся к периоду разработки Heroes of Might