Описание циклов игры: примеры и советы

Директор игрового департамента Rocket Jump о проектировании геймплея.

Директор игрового департамента студии Rocket Jump Константин Сахнов написал для DTF статью, в которой рассказал о построении и описании игровых циклов — одном из ключевых аспектов в работе геймдизайнера.

В этой статье я структурирую методику описания игровых циклов (core gameplay loop) и поделюсь своим опытом в этой области, а также расскажу, как наша команда использует её в работе над одним из проектов студии — Dakota Farm Adventures.

У каждого, кто связан с геймдизайном, есть своё представление об игровых циклах. Главное — понимать, какие задачи решаются их описанием. Начинать работу над игрой стоит не с подбора инструментов и даже не с проработки концепта, а с осознания результатов, которых команда хочет достигнуть. Руководствуясь этой логикой, можно выделить следующие цели описания core gameplay:

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

На крупных проектах, которые разрабатываются в течение нескольких лет, команда неизбежно меняется в процессе работы. Кто-то уходит, кто-то приходит. Лучший способ донести до нового сотрудника суть игрового процесса — показать core loop. Ни тонны продуктовой документации, ни многочасовые собрания не смогут так быстро объяснить, о чём проект. Лучше геймплейной схемы в курс дела может ввести только сам продукт.

Для описания игровых циклов чаще всего используются UML-диаграммы. Такая практика сложилась давно и остаётся общепризнанной, однако никаких ограничений инструментария нет. Каждый геймдизайнер сам выбирает формат и логику построения диаграмм с учётом особенностей продукта и сложившейся в команде практики. Далее я поделюсь правилами, которыми пользуюсь сам.

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

Для лучшего понимания я разделил процесс на несколько шагов. Чтобы алгоритм был нагляднее, рассмотрим его на примере популярных игр: Clash of Clans, Game of War, Candy Crush Saga.

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

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

— Поток ресурсов;

— Жёсткий «лок»;

— Прогресс и мощь.

Рассмотрим связи на примере Game of War. Поток ресурсов в ней — это, например, захват камня или дерева с точек на глобальной карте. Жёсткий «лок» — это требование по уровню одного здания, без которого невозможен апгрейд другого. А прогресс и мощь — это развитие армии за счёт её прокачки.

Деление на три группы — условное, и необходимо только для удобства и структурирования связей. Как разграничить связи и поделить их на группы? Можно ли отнести юнитов в Clash of Clans (которых можно считать и ресурсом) к прогрессу и мощи?

В принятой мною модели нельзя. Прогресс — это односторонняя связь. Он может только расти. Чаще всего показатель прогресса — это уровень игрока или персонажа. Ресурсы — это элементы, которые можно добывать и расходовать по желанию. Так, юниты, которые могут погибнуть в бою — это расходуемый ресурс. А развитие бессмертного героя — прогресс. В Candy Crush ресурсом выступают очки здоровья, расходуемые игроком при неудачном прохождении уровней.

И, наконец, жёсткие «локи». Почему это не ресурс и не прогресс? «Локи» отличаются от других типов связей необратимостью. Для доступа к новым уровням Candy Crush предлагает заплатить реальной валютой или активностью. Однажды сняв один «лок», игрок с ним больше не столкнётся. Но впереди могут быть другие преграды.

Выделив основные элементы игры и осознав типы имеющихся между ними связей, завершаем создание диаграммы — расставляем направляющие стрелки и подписываем потоки. В нашем случае ситибилдер даёт боёвке юнитов (нанимаемых за эликсир), забирая себе ресурсы обратно. Себя же боёвка обеспечивает рейтингом. Обратите внимание, что рейтинг не является ресурсом, так как его нельзя «потратить» в прямом смысле этого слова. Его можно «повысить» или «понизить» в зависимости от ваших умений и опыта, он может влиять на матчмейкинг и ощущения от игры, но за него нельзя покупать сущности.

Напоследок отмечу несколько простых правил, соблюдение которых поможет сделать вашу схему лучше.

Лаконичная схема удобнее слишком подробной. Чем дольше нужно вчитываться, чтобы вспомнить или понять геймплейную структуру, тем хуже. Если вы понимаете, что схема слишком сложна, задумайтесь, не перемудрили ли вы с геймплеем. Может, стоит убрать двенадцатую вариацию механики охоты за подводными кроликами? Проигнорируйте незначительные детали и даже некоторые правила, если это поможет сделать схему core gameplay понятней.

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

Очевидно, что каждая игра имеет свои особенности, а значит и описание диаграммы циклов для каждого продукта может отличаться в нюансах. Где-то есть только поток ресурсов, где-то важно обозначить расход энергии. Каждый геймдизайнер может по-своему прочесть схему. Для исключения разночтений мы сопровождаем диаграммы легендой. Важно следить за тем, чтобы выбранная логика обозначений сохранялась внутри проекта на всех диаграммах. Если вы выбрали красный цвет стрелок для жёстких «локов» на первой диаграмме, не стоит отмечать их синим в дальнейшем.

Давайте посмотрим, как можно использовать приведённую модель на примере недавно запущенной нами фермы Dakota Farm Adventures.

Нашим игрокам открываются три ключевых геймплейных блока — ферма, дом и исследовательские локации. На ферме игрок выращивает овощи и деревья, кормит животных и перерабатывает урожай в более ценные ресурсы, а также зарабатывает деньги, торгуя продуктами и материалами на доске заказов. В доме живут родственники главной героини, открывающие доступ к новым типам производства по мере разблокировки комнат. На карте мира можно путешествовать по различным локациям, где выполняются квесты и добываются особые производственные ресурсы — например, древесина, лён, глина. К примеру, кузина Дженни лепит горшки из глины, а дядюшка Бен стругает доски из древесины.

Это — схема core gameplay проекта, которую мы используем в пайплайне разработки:

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

Я пользуюсь описанным методом, так как он довольно прост, удобен и достаточно универсален. Но, возможно, вы сможете предложить другие способы и модели. Как происходит построение и описание игровых циклов в вашей команде? Расскажите в комментариях.