Диздок для игры «не на продажу»
Введение
Почему?
Дизайн-документ, далее ДД(диздок, game design document, GDD) - документ, содержащий полную и детальную информацию об игре. Суть диздока - передать все что есть в игре на случай если вы забудете что-то, запутаетесь в своей игре, захотите передать ее кому-то.
Это определения дизайн документа "не на продажу". Все потому что ДД можно поделить на 2 типа, а так как официальных названий у них нет я их условно назову "коммерческий" и "технически" (или "на продажу" и "для себя" если простым языком).
Коммерческий диздок от технического отличается тем, что его задача - привлечь инвесторов, для него можно использовать шаблон, например этот.
Обязательно использование систем контроля версий. Например, связка git+github
Поскольку ДД - техническая литература, самое важное это не красивый текст, а избавиться от разночтений. То есть чтобы 99% прочитавших поняли изложенные идеи одинаково.
Важно, очень важно ни когда не удалять информацию "по настоящему", используйте систему контроля версий (git) или делайте "комментарии", если почему-то не используйте ее (а вообще лучше постарайтесь использовать git).
Также хорошая практика - комментировать внесенные изменения. Потому что сегодня вы помните что изменили атаку босса из-за сложно повторяемого бага, а через пол года разработки вы уже забудете, что не так с этой константой.
Шаблон
Шаблон статьи написанной мой 1,5 года назад на хабре немного отличается от настоящего, поэтому я приведу оба варианта, а вы можете выбрать тот, что вам больше понравится.
Старый шаблон
Новый шаблон
Скачать шаблон вы можете с моего github.
Жанр и синопсис
Жанр
Достаточно просто лаконично указать жанр ограничившись одним словом
Например: RPG или adventure
Главное - чтобы читатель понимал общий характер игры: что речь идет о мобильной казуалке, а не о визуальной новелле на несколько рутов и 30 часов геймплея.
Однако можно более конкретно указать жанр, добавив деталей и приведя подобные игры:
Тактическая компьютерная настольная игра с элементами adventure и мини-играми.
Похожие игры: Mario Party, Jackbox
Top-down экшен-adventure
Также можно указать сочетание для более точной передачи:
Например: survival-horor
Синопсис
Синопсис - краткое изложение концепции игры, истории, сеттинга, которое охватывает завязку, основные действия, поворотные точки, кульминацию и развязку. Также описывает место и время действия.
Нужен чтобы читатель правильно представил игровой мир и помогает правильно интерпретировать дальнейшие детали.
Например, если будет упоминаться огнестрельное оружие, читатель будет понимать что речь идет о старом, гладкоствольном, однозарядном пистолете, современное тактическое оружие или футуристическое лазерное.
Синопсис должен не просто познакомить с игрой, а создать контекст необходимый для понимания всех элементов, упомянутых далее, в дизайне.
Game style (Стиль игры), дизайн
Я решил объединить стиль и дизайн, потому что, по-моему, это очень схожие разделы. А чтобы было легче ориентироваться я разбил эту часть на несколько подпунктов:
Визуальная часть
Под стилем здесь подразумевается его максимально широкое понимание. Здесь важно передать атмосферу игры, ее визуальный образ и эмоциональную составляющую.
Смело добавляйте: концепт-арты, зарисовки, референсы из других игр и фильмов, да просто картинок из pintrest сюда напихайте, чтобы читающий смог представить визуальную составляющую игры, как она чувствуется и воспринимается
Мир и взаимодействие с ним
Стоит описать структуру игрового мира: Является он линейным, с четкими уровнями или открытым, с возможностью свободного исследования. Нужно упомянуть ключевые особенности окружения: это может быть футуристичный мегаполис или он же, но в пост апокалипсисе.
Не менее важно кратко описать как происходит передвижение персонажа по миру. Будет ли он перемещаться пешком или на машине. Возможно он может летать или телепортироваться. Важно дать читателю представление о том как игрок будет взаимодействовать с игровым пространством.
Общие принципы
С т.з. геймплея стиль охватывает то, как устроена игра, но без углубления в технические и мелкие детали. ДД - не является сюжетом игры не стоит тут расписывать весь ее лор. Подумайте об этом как о текстовом трейлере своей игры (но добавить сюда картинок никто вам не мешает). Вам нужно упомянуть все ключевые аспекты игры, но сделать это кратко и информативно.
Дизайн
Эту часть стоит писать после того как будет создан прототип и заданы основные параметры. Потому что от размера и скорости персонажа будет зависеть размер уровня.
А задача этой части дать понять всей команде, работающей с ui/ux, что от них требуется. Стоит более-менее объяснять что здесь содержится, потому что через пол года разработки вы забудете чем отличается звук удара_по_дереву 1.ogg от звука ходьбы_по_дереву 2.ogg. Также если изначально в этом разделе содержалась информация для арт и аудио отделов, то после это больше пригодится для тех. отдела, потому что они смогут понимать какие модели к какому персонажу относятся, и какое аудио в какой момент должно воспроизводится.
Системы, механики
В этом разделе должна быть описана вся логика игры, так сказать ее backend. Это не значит что здесь должны быть указаны все параметры (точнее они не должны быть здесь указаны, для них есть отдельное место). Но принципы всех систем и механик должны быть обязательно указаны.
Начинайте с систем, а потом переходите к механикам: Система - та логика игры, которая работает по умолчанию и отключается только иногда при определенных условиях. Например: передвижение игрока или стрельба. Механика - та логика, которая работает только при выполнении ряда определенных условий. Например: крафтинг.
Но не стоит эти примеры воспринимать как нечто константное и неизменное. Одна и та же логика может быть как механикой так и системой, в зависимости от игры (например в игре "Алхимия" - крафтинг - система, (это чуть ли не единственная логика игры), а в каком-нибудь rust или raft крафтинг - механика, потому что может использоваться только в определенных условиях), так что это деление - чистая условность, главное чтобы вы и все, кто будут читать этот документ, понимали логику и когда она должна исполнятся.
Старайтесь избегать лишнего текста и не стремиться к "литературности" текста. Как я уже говорил ДД - техническая литература. Ваша задача написать текст, который будет максимально точно передавать суть, например:
Когда игрок активирует способность "Щит", персонаж получает эффект "Щит", который блокирует урон и поглощает N единиц урона.
Это стилистически ужасное предложение, прекрасно передает смысл, который был в него заложен, поэтому прекрасно подходит для ДД. А также его очень легко перевести в код (пример на псевдо-коде):
fn _on_shield_activated():
Character.buffs.append(Buff.SHIELD)
fn activate_buffs():
for unit in units:
for buff in unit.buffs:
match buff:
case Buff.SHIELD:
Character.shield += N
fn _on_damage_receiving(int damage):
Character.shield -= damage
if Character.shield < 0:
unabsorbed_damage = Character.shield
Character.shield = 0
Character.hp -= unabsorbed_damage
... // Дополнительные проверки
Так что не бойтесь писать "некрасиво". Бойтесь разночтений и двусмысленности.
При описании логики поведения ИИ можно столкнуться с проблемой нарушения принципа DRY (don't repeat yourself) (обычно его относят к программированию, но тут он тоже применим) когда много разных сущностный должны выполнять шаблонные действия. Такая проблема хорошо решается тегами (# в md). Но со временем тегов может стать очень много и они будут очень длинными, поэтому можно использовать сокращения и в одном месте их расшифровать.
Я использую редактор Obsidian, который поддерживает систему тегов. Это позволяет ссылаться на теги, и отслеживать где они используются.
Тут должен был быть большой пример на теги, но мне показалось что он слишком избыточный, поэтому я оставлю только пример тегов
Безоружный — атакует без оружия.
Штурмовик — использует оружие средней дальности.
Снайпер — использует дальнобойное оружие.
Перезаряжается — перезаряжает оружие после окончания патронов.
Находит оружие — выбрасывает старое оружие и находит новое после окончания патронов.
Укрывается — ищет укрытие перед перезарядкой.
Управление
Не очень понятно когда именно стоит писать этот раздел, у вас может быть свое мнение на эту тему, но мне кажется что параллельно с логикой. Постараюсь аргументировать свое мнение: До того как описана логика игры, а только то, как она выглядит не понятно о чем вообще говорит управление, потому что пока игра не существует, пока существует только картинка. А почему нельзя после? Можно, но могут возникнуть проблемы. Об этом дальше по тексту.
Управление нужно сразу проектировать для всех устройств, которые планируются поддерживаться: клавиатура и мышь, геймпад, мобильное устройство, может вы решите сделать что-то необычное из разряда руль или vr-гарнитура.
Но необязательно сразу "сделать" все элементы управление - всегда можно будет вернуться и что-то изменить.
Ранняя разработка управления важна по нескольким причинам:
- Любой сможет взять геймпад или мышку и клавиатуру в руки и попробовать управление. Если для клавиатура-мышей если обычное сложившееся управление, то вот для геймпада может оказаться что кастовать заклинание крестовиной и левыми стиками.
- Будет очень неприятно если на позднем этапе разработки выяснится что на геймпаде или VR-гарнитуре не хватает кнопок для всего управления
Также стоит помнить про создание алиасов (вынос параметров) в одном месте, например:
А - клавиша действия
B - клавиша доп. действия
5 сек - время удержания клавиши
Прогрессия
Прогрессия - важная часть почти каждой игры (хотя может так не казаться). Она определяет продвижение игрока по миру и его развитие.
В разных играх прогрессия выражается по-разному. В одних происходит ускорение темпа: уровни становятся сложнее, враги - быстрее и сильнее. В других она тесно связана с сюжетом, где каждая новая глава открывает игроку новые ресурсы, способности или возможности. А есть игры, где она почти незаметна или отсутствует вовсе, сохраняя постоянный игровой опыт на протяжении всей игры.
Прогрессия необходима в игре, потому что она поддерживает интерес игрока, создает ощущение роста и прогресса. Без нее геймплей становится однообразным и быстро наскучивает игрокам. Прогрессия нужна чтобы игрок сначала освоился в базовых механиках, а потом смог комбинируя их пройти игру.
В этом разделе ДД необходимо указать как именно происходи прогрессия и как она вписывается в логику игры. Например, как изменяется искусственный интеллект врагов с прогрессией. Также опишите как должен изменяться левл-дизайн с развитием игрока.
Раздел о прогрессии - своего рода таймлайн игры. Он рассказывает как в процессе прохождения изменяется мир, как вводятся новые механики, как персонаж развивает новые способности и как изменяется сложность уровней. Например, в середине игры игроку придется освоить комбо - определенную последовательность способностей, которая позволяет улучшить эффект от механик, если бы они были выполнены по отдельности. Если это атака - то увеличивается урон, а если лечение, то добавка хп и т.п. Помимо этого прогрессия может быть связана с открытием новых локаций или миров. Где враги будут кардинально отличатся.
Интерфейс
Интерфейс - то, что стоит делать в самом конце. Почему? Потому что хороший интерфейс создается под программу, а не наоборот (игру же можно назвать программой?). А еще переделывать интерфейс - всегда боль, поэтому стоит сделать его один раз, и сразу хорошо. И делая его держите в голове дизайн игры и то, с чем взаимодействует игрок. В этом разделе нужно описать каждый элемент интерфейса: кнопки, окна, ползунки, индикаторы, текст на экране, любые данные на экране, а также переходы между экранами, визуальные эффекты (связанные с интерфейсом, а не игрой).
А также можете придумать необычный экран загрузки и меню игры. Вместо статичной картинки можно внедрить интерактивные элементы: подсказки или мини-игры. Также стоит это сделать если у вас есть долгие экраны загрузки, потому что это хоть немного скрасит ожидание игрока. Главное меню можно сделать динамически: например изменять его в зависимости от прогресса в игре или от времени суток или года в реальном мире.
Если вы планируете делать интерфейс на нескольких языках, стоит предусматривать это сразу, потому что переводы имеют свойство быть несколько длиннее чем вы предполагали (не или не предполагали).
Параметры
Этот раздел пишется на самом финальном этапе игры - на этапе тестов. Конечно параметры стоит накидывать сюда изначально, чтобы во время тестов не копаться в ДД на несколько тысяч строк и не выписывать параметры сюда, однако раньше вы просто не сможете вставить сюда правильные значения, а точнее пока игры не существует (хотя бы прототипа), правильных параметров тоже.
Итого
Стоит помнить что ДД - живой документ, работа над ним начинается, когда вы задумали игру и заканчивается, когда вы выпустили игру, или перестали ее поддерживать, если игра с обновлением контента. Поэтому важно не бояться вносить правки, обновлять его и адаптировать к новым требованиям, сохраняя при этом структуру и ясность. Цель - сделать самую лучшую игру из возможных ресурсов, а они будут изменяться в процессе разработки, так что иногда можно добавить новые фичи, а иногда нужно вырезать старые. И главное помните, что хороший ДД экономит время, предотвращает ошибки и упрощает коммуникацию в команде.
А еще помните, что правила созданы для того, чтобы их нарушать. Если бы все игры были бы одинаковыми, то они бы не были интересными. Все что указано в этой статье носит рекомендательный характер, поэтому если ваше мнение отличается от моего, или еще по какой-то причине хотите отступить от них - то отступайте. Тут уместна фраза:
Я художник, я так вижу