Как делать хорошие игры. От идеи до запуска - Петр Прохоренко
Каким образом возможно интегрировать эту последовательность в процессы компании или команды?
• На уже начатых проектах – эту методологию можно интегрировать частично, отдельными элементами.
• На новых проектах – по возможности полностью, начиная с первых этапов.
В любом случае перед интеграцией необходимо предусмотреть процесс ознакомления всех участников с методологией и обучения их работе с основными документами.
Мы начинаем со стандартизации этапов подготовки проекта к производству и получаем вот такой список (в скобках указаны роли, ответственные за тот или иной пункт).
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 & Magic V). Документ обычно создается в формате таблицы Excel (или Google Tab) и состоит из 4-х листов:
• Tasks – перечень всех известных нам на данный момент задач проекта с оценками по времени и атрибуцией по проектным этапам (прототип, альфа-версия, бета-версия, релиз, апдейты) и направлениям разработки (арт, программирование, дизайн и т. д.).
• Resume – суммированные трудозатраты по этапам, здесь мы видим сколько надо сотрудников на тот или иной этап, а также раскладку по необходимым проектным ролям (таким образом можно спланировать участие определенных специалистов и быть заранее готовыми к моменту, когда они понадобятся).
• Roadmap – тут уже не все, а
