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

В игровых студиях для этого пишут техническое задание (иногда его называют дизайн документом для отдельной фичи) — там гейм-дизайнер подробно описывает, что он хочет получить, какие особенности должны быть у механики и так далее. В этом тексте мы ответим на вопросы, как в студиях составляют ТЗ, какие детали там обязательно расписывают, нужны ли референсы и многое другое. Своим опытом поделились: ведущий гейм-дизайнер студии ITT Михаил Сипцов, ведущий гейм-дизайнер студии Panzerdog Олег Снисаренко, ведущий программист ITT Олег Агеев, старший гейм-дизайнер ITT Алексей Анискин.

Структура ТЗ

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

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

Хорошая практика в составлении ТЗ — идти от общего к частному. В самом начале стоит написать общий принцип работы фичи. Например: «Добавляем возможность делать кувырок. Во время переката есть период неуязвимости». А дальше нужно последовательно описать механику, разбивая информацию по блокам — подробно описать ее с точки зрения геймплея, настроек и так далее.

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

• можно ли использовать кувырок во время других действий — прерывает ли он текущее действие или нет; 

• можно ли использовать другие действия во время переката — например, может ли персонаж использовать зелья в процессе этого действия; 

• как во время кувырка персонаж взаимодействует с другими объектами — ломает ли он объекты, сквозь которые проходит;

• есть ли зависимость параметров кувырка и характеристик героя — например, герой в тяжелой броне перекатывается на меньшее расстояние.

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

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

Какие референсы нужны 

Наличие референсов заметно упрощает работу — чем сложнее сущность, тем заметнее их помощь. В зависимости от ситуации можно обойтись схемой, а где-то можно приложить ссылку на ролик из YouTube. Чаще всего референсы нужны в том случае, если гейм-дизайнер не уверен в том, что добился полного взаимопонимания с программистом. 

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

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

Чем больше прототипов делает сам гейм-дизайнер, тем больше ошибок он может предвосхитить. Меньше переделок — больше успеваешь сделать в срок, меньше жалоб на «сырой дизайн». Так что делать прототипы, может быть даже не для своей игры, а «для души» — это рекомендация для любого гейм-дизайнера. — Михаил Сипцов, ведущий гейм-дизайнер студии ITT

Примеры ТЗ

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

«Танцовщица с клинками»

Эта механика предназначена для игры Rush Royale в жанре Merge Tower Defence, в которой пользователи выставляют на стол пешки, стреляющие по проходящим мимо противникам. Монстры стремятся достичь ворот замка и уничтожить его. Пешки стреляют по врагу, увеличивая свой урон или меняя определенные параметры при правильной расстановке. 

Для пешки «Танцовщица с клинками» текстовое описание работы выглядит следующим образом:

«Атакует первую цель. Если по соседству (на ближайших клетках по горизонтали и вертикали) нет других танцовщиц, то переходит в усиленный режим, увеличивая свою скорость атаки и урон. Урон увеличивается с количеством танцовщиц на поле боя. Максимальный бонус достигается при восьми танцовщицах».

Сами пешки представляют собой некие универсальные сущности, на которые надстраиваются уникальные механики. При этом у всех пешек есть стандартные параметры: например, «урон» и «скорость атаки».

Чтобы из базовой пешки сделать «Танцовщицу с клинками», нужно реализовать следующие механики:

• проверка на то, что пешка стреляет именно по первой цели (могут быть другие варианты, например, случайная, цель с самым большим числом здоровья или босс);

• проверка на наличие рядом пешек такого же типа;

• проверка количества пешек такого же типа на столе;

• бонус для параметров пешки, если выполняются заданные условия;

• ограничение на рост параметра.

В итоге у «Танцовщицы с клинками» есть несколько характеристик, настройкой которых занимается гейм-дизайнер:

• урон;

• интервал между атаками;

• ускорение;

• боевой дух;

• минимальное усиление;

• максимальное усиление.

Механика переключения режимов выглядит так:

«Имеет 2 weapon механики. При условии равенства каунтера соседей 0, начинает работать изменение параметров, заданное в PawnBladeDancer_NeighborAttackChange и PawnBladeDancer_NeighborIntervalChange».

«Падение зомби из труб»

В этой части речь пойдет про механику «доставки» зомби на поле боя в изометрическом шутере.

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

Предлагаю сделать новый компонент, который вешаем на юнита. В нем указываем:

• кость, за которую прицепляем рэгдолл к сплайну;

• список коллайдеров, для которых отключаем физику на время полета;

• минимальную скорость, с которой тащим юнита по сплайну.

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

• переводим юнита из рэгдолла в нормальный режим и включаем аниматор;

• дергаем триггер Spawn в аниматоре;

• включаем прочую логику (можно выбрать как цель, нанести урон и так далее)».

В результате получается, что зомби неуязвимы во время «доставки» на поле боя, но сразу после спавна они становятся полноценными целями.

Возможность определять и сравнивать угол движения аватара

А эта механика предназначается для экшен-RPG от третьего лица.

«Что нужно сделать: в зависимости от угла движения аватара относительно сторон света (направления ветра) ускорять его или замедлять. Например, если ветер дует на север и аватар едет под углом не более 45° к северу, то ускорять, а если более 135° — то замедлять.

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

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

Есть AngleCalcerToLocator или AngleCalcerRelative, они были сделаны для эффекта EffectSpin, чтобы задавать угол поворота. Но эти калкеры не получается использовать с PredicateGreater (нельзя даже соединить их в ДД). Хотелось бы заставить эти калкеры работать с предикатом или изобрести иной способ вычисления угла движения аватара».

Советы гейм-дизайнерам

• Дайте программисту прочитать ваше ТЗ и спросите его, все ли там понятно — возможно, там чего-то не хватает, или у него возникли вопросы.

• Не забывайте, что и вы, и программист хотите одного и того же — сделать отличную игру вместе. И если что-то реализовано не так, то точно не из-за злого умысла программиста. 

• Если появилась проблема, стоит разобраться в том, почему так вышло и решить, как этого избежать в будущем. 

• Самые частые проблемы связаны с тем, что ТЗ недостаточно понятное, недостаточно полное или же в процессе разработки в него внесли изменения. 

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

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

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