От абстрактной идеи к готовой механике: как гейм-дизайнеру составить ТЗ для программиста
С примерами технического задания и советами от гейм-дизайнеров.
Когда идея игровой механики возникает в голове гейм-дизайнера, она существует в виде абстрактной задумки, у которой нет конкретного воплощения. И чтобы реализовать ее в реальности, он должен как-то объяснить программисту, в чем ее суть — гейм-дизайнеру нужно понятно и однозначно описать свою затею, чтобы разработчик воплотил ее в виде работающей механики.
В игровых студиях для этого пишут техническое задание (иногда его называют дизайн документом для отдельной фичи) — там гейм-дизайнер подробно описывает, что он хочет получить, какие особенности должны быть у механики и так далее.
В этом тексте мы ответим на вопросы, как в студиях составляют ТЗ, какие детали там обязательно расписывают, нужны ли референсы и многое другое. Своим опытом поделились: ведущий гейм-дизайнер студии ITT Михаил Сипцов, ведущий гейм-дизайнер студии Panzerdog Олег Снисаренко, ведущий программист ITT Олег Агеев, старший гейм-дизайнер ITT Алексей Анискин.
Структура ТЗ
В разных проектах структура ТЗ может отличаться, но в любом случае основная задача документации — в простой и недвусмысленной форме донести до исполнителя список требований и условий, в которых будет применяться игровая сущность.
В нашей разработке дополнительно к описанию самих механик еще описывается, как это действие выглядит с точки зрения игрока. Другими словами, желательный результат работы фичи.
Хорошая практика в составлении ТЗ — идти от общего к частному. В самом начале стоит написать общий принцип работы фичи. Например: «Добавляем возможность делать кувырок. Во время переката есть период неуязвимости». А дальше нужно последовательно описать механику, разбивая информацию по блокам — подробно описать ее с точки зрения геймплея, настроек и так далее.
При описании механики нужно сделать упор на логических взаимосвязях и ограничениях. Важно описать четкую последовательность действий в рамках конкретной механики, а также всевозможные сценарии использования. Если продолжить пример с перекатом, то в описании механики нужно указать:
- можно ли использовать кувырок во время других действий — прерывает ли он текущее действие или нет;
- можно ли использовать другие действия во время переката — например, может ли персонаж использовать зелья в процессе этого действия;
- как во время кувырка персонаж взаимодействует с другими объектами — ломает ли он объекты, сквозь которые проходит;
- есть ли зависимость параметров кувырка и характеристик героя — например, герой в тяжелой броне перекатывается на меньшее расстояние.
При составлении ТЗ гейм-дизайнер должен упомянуть основные параметры механики. Но при этом не стоит указывать конкретные числовые значения — для гейм-дизайнера важно, чтобы в дальнейшем он мог их самостоятельно менять, пробуя разные варианты. К примеру, у переката это может быть дальность, скорость, длительность неуязвимости.
Также стоит учитывать, что ТЗ нужно не только гейм-дизайнеру и программисту, но и другим членам команды. Например, QA-специалисты используют ТЗ, чтобы проверить правильно ли работает механика. В некоторых случаях исполнитель или заказчик конкретной фичи может поменяться, а зафиксированное ТЗ поможет сохранить оригинальную задумку.
Какие референсы нужны
Наличие референсов заметно упрощает работу — чем сложнее сущность, тем заметнее их помощь. В зависимости от ситуации можно обойтись схемой, а где-то можно приложить ссылку на ролик из YouTube. Чаще всего референсы нужны в том случае, если гейм-дизайнер не уверен в том, что добился полного взаимопонимания с программистом.
Еще один вариант референса — самостоятельно сделать прототип. Обычно это не требуется, но в некоторых студиях сами гейм-дизайнеры реализуют механики при помощи внутренних инструментов. Если же задача слишком сложная, гейм-дизайнер обращается с ней к программистам.
Для большинства новых пешек в Rush Royale существует этап пре-продакшна, на котором мы из кирпичиков собираем что-то максимально близкое к желаемому результату, попутно ставя задачи на новые механики для программистов.
Чем больше прототипов делает сам гейм-дизайнер, тем больше ошибок он может предвосхитить. Меньше переделок — больше успеваешь сделать в срок, меньше жалоб на «сырой дизайн». Так что делать прототипы, может быть даже не для своей игры, а «для души» — это рекомендация для любого гейм-дизайнера.
Примеры ТЗ
Техническое задание напрямую зависит от проекта и от механики, которую нужно реализовать. Для наглядности мы решили привести несколько примеров ТЗ, которые различаются по содержанию, но при этом их структура в целом схожа.
«Танцовщица с клинками»
Эта механика предназначена для игры Rush Royale в жанре Merge Tower Defence, в которой пользователи выставляют на стол пешки, стреляющие по проходящим мимо противникам. Монстры стремятся достичь ворот замка и уничтожить его. Пешки стреляют по врагу, увеличивая свой урон или меняя определенные параметры при правильной расстановке.
Для пешки «Танцовщица с клинками» текстовое описание работы выглядит следующим образом:
«Атакует первую цель. Если по соседству (на ближайших клетках по горизонтали и вертикали) нет других танцовщиц, то переходит в усиленный режим, увеличивая свою скорость атаки и урон. Урон увеличивается с количеством танцовщиц на поле боя. Максимальный бонус достигается при восьми танцовщицах».
Сами пешки представляют собой некие универсальные сущности, на которые надстраиваются уникальные механики. При этом у всех пешек есть стандартные параметры: например, «урон» и «скорость атаки».
Чтобы из базовой пешки сделать «Танцовщицу с клинками», нужно реализовать следующие механики:
- проверка на то, что пешка стреляет именно по первой цели (могут быть другие варианты, например, случайная, цель с самым большим числом здоровья или босс);
- проверка на наличие рядом пешек такого же типа;
- проверка количества пешек такого же типа на столе;
- бонус для параметров пешки, если выполняются заданные условия;
- ограничение на рост параметра.
В итоге у «Танцовщицы с клинками» есть несколько характеристик, настройкой которых занимается гейм-дизайнер:
- урон;
- интервал между атаками;
- ускорение;
- боевой дух;
- минимальное усиление;
- максимальное усиление.
Механика переключения режимов выглядит так:
«Имеет 2 weapon механики. При условии равенства каунтера соседей 0, начинает работать изменение параметров, заданное в PawnBladeDancer_NeighborAttackChange и PawnBladeDancer_NeighborIntervalChange».
«Падение зомби из труб»
В этой части речь пойдет про механику «доставки» зомби на поле боя в изометрическом шутере.
«Нам нужно, чтобы зомби могли выпадать из труб. Сами трубы могут быть любых форм и размеров. Выпадать зомби будут по стандартным сплайнам, которые будут преднастроены в сценах.
Предлагаю сделать новый компонент, который вешаем на юнита. В нем указываем:
- кость, за которую прицепляем рэгдолл к сплайну;
- список коллайдеров, для которых отключаем физику на время полета;
- минимальную скорость, с которой тащим юнита по сплайну.
В точки спавна нужно добавить галочку, которая будет говорить нам, что отсюда мы спавним по следующей логике: юнит появляется в виде рэгдолла и, по сути, едет по сплайну. Все это время он полностью неуязвим и его нельзя выбрать как цель. В конце сплайна:
- переводим юнита из рэгдолла в нормальный режим и включаем аниматор;
- дергаем триггер Spawn в аниматоре;
- включаем прочую логику (можно выбрать как цель, нанести урон и так далее)».
В результате получается, что зомби неуязвимы во время «доставки» на поле боя, но сразу после спавна они становятся полноценными целями.
Возможность определять и сравнивать угол движения аватара
А эта механика предназначается для экшен-RPG от третьего лица.
«Что нужно сделать: в зависимости от угла движения аватара относительно сторон света (направления ветра) ускорять его или замедлять. Например, если ветер дует на север и аватар едет под углом не более 45° к северу, то ускорять, а если более 135° — то замедлять.
Вариант сборки: овертаймово во время движения сравнивать угол аватара с нужным значением с помощью PredicateGreater и при определенных результатах сравнения вешать баффы с замедлением/ускорением. Возможно, даже пробовать скейлить скорость относительно угла.
Тут нужен калкер, который сможет определить угол между аватаром и локатором или угол аватара относительно абсолютных координат мира.
Есть AngleCalcerToLocator или AngleCalcerRelative, они были сделаны для эффекта EffectSpin, чтобы задавать угол поворота. Но эти калкеры не получается использовать с PredicateGreater (нельзя даже соединить их в ДД). Хотелось бы заставить эти калкеры работать с предикатом или изобрести иной способ вычисления угла движения аватара».
Советы гейм-дизайнерам
- Дайте программисту прочитать ваше ТЗ и спросите его, все ли там понятно — возможно, там чего-то не хватает, или у него возникли вопросы.
- Не забывайте, что и вы, и программист хотите одного и того же — сделать отличную игру вместе. И если что-то реализовано не так, то точно не из-за злого умысла программиста.
- Если появилась проблема, стоит разобраться в том, почему так вышло и решить, как этого избежать в будущем.
- Самые частые проблемы связаны с тем, что ТЗ недостаточно понятное, недостаточно полное или же в процессе разработки в него внесли изменения.
- В ходе работы над механикой гейм-дизайнер должен общаться с программистом, чтобы удостовериться в том, что его задумка понята правильно, а в ТЗ есть вся нужная информация.
- Чем лучше гейм-дизайнер понимает техническую сторону проекта, тем более точные и понятные ТЗ он будет создавать. Поэтому всегда интересуйтесь подробностями движка и технологий, общайтесь с программистами, задавайте им вопросы по теме.
- Гейм-дизайнеру в ТЗ стоит делать упор на то, что в итоге должно получиться, а не то, как это реализовать. Зачастую именно программист лучше понимает, какое решение будет наиболее подходящим. Но если у гейм-дизайнера есть опыт разработки, и он точно уверен в своих знаниях, то он может предложить свое решение прямо в ТЗ.
Комментарий недоступен
Комментарий недоступен