1.4. Из диздока можно сделать фичелист. Каждую фичу можно оценить по требуемым ресурсам (два месяца программистов, неделя UX дизайнера, пять минут геймдизайнера). Сложив оценки фичей получаем оценку времени разработки проекта. Если помножить на зарплаты команды и другие расходы, то можно получить бюджет проекта. Хоба! Если не влезаем в бюджет, сроки, команду, то пересматриваем фичи. Понятное дело, что оценки грубые, обязательно ошибетесь, что-то забудете. Ошибиться в 2-4 раза не так страшно, как ошибиться в 20 раз, если не сделать этот этап. Впрочем, всё равно закладывайте буферы. Сколько именно закладывать поймете с опытом и пониманием команды. Для первого раза начните с умножения всех сроков в два раза. Не факт, что поможет, но хотя бы снизит вероятность остаться без денег с игрой на 60% готовности.

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

1.6. Когда на руках есть проотип геймплея, то можно его дополировать до состояния демонстрационной версии (демки). То есть заменяем плейсхолдеры на арт плюс-минус похожий на то, что хочется увидеть в финале. Создаем контент на 5-10 минут геймплея. Это не обязательный этап, но очень поможет чтобы уже на раннем этапе можно было тестировать игру на аудитории, а также показывать игровой билд издателям и инвесторам. Тем более, что этот этап хорошо пересекается со следующим этапом.

1.7. Наконец-то тот самый вертикальный срез. Когда делаются все необходимые фичи и по единице каждого типа контента. Типа одна локация, с одним видом оружия, одним типом ползающих противников, одним типом летающих противников, одним боссом, одной катсценой, одним доспехом. Суть этапа очень простая - если для игры что-то надо сделать N раз, то сначала это надо сделать 1 раз и посмотреть какие вылезут нюансы. Потому что проще исправить ошибку в одной единице контента, чем когда наклепали N единиц.

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

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

Про следующие этапы смотрите в следующих сериях...