Читаем Геймдизайн полностью

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

Дизайн

1. Краткий ГДД (англ. Game Design Overview) – документ, описывающий основные цели и функционал игры, который может занимать всего несколько страниц. Обычно этот документ создается для начальства команды, чтобы те, не углубляясь в детали, могли понять, что представляет собой ваша игра и для кого она предназначена. Обзорный документ может быть полезен и для всей остальной команды, потому что помогает им лучше представить полную картину.

2. Детальный ГДД (англ. Detailed Design Document) – этот документ описывает все игровые механики и интерфейс в мельчайших подробностях. Данный документ преследует две цели: позволяет дизайнеру помнить все идеи, приходящие ему в голову, а также помогает ему передавать эти идеи программистам, пишущим по ним код, и художникам, оборачивающим эти идеи в визуальную оболочку. Поскольку данный документ редко показывается людям, не связанным с проектом, он часто составляется в виде черновика и без особой структуры. Достаточно того, что этот документ может положить начало дискуссии и не позволяет забывать о важных деталях. Как правило, это самый длинный документ, который, кстати, редко обновляется и доводится до логического конца. Дело в том, что на полпути к окончанию проекта о документе часто забывают: к этому моменту сама игра содержит большую часть важных деталей, а те, которых в игре еще нет, распространяются между членами команды при помощи менее формальных средств, таких как электронные письма или короткие записки. Но в начале проекта важно найти правильную структуру ГДД. В большинстве случаев гораздо удобнее иметь несколько небольших документов со ссылками на подсистемы, нежели один гигантский документ. Дизайнер Рич Мармура удачно высказал эту мысль следующими словами: «Я всегда адаптирую ГДД под ту команду, с которой работаю сейчас. ГДД – это не только возможность структурировать мои мысли, это источник информации для членов команды. Для каждой конкретной игры структура и стиль ГДД меняется, хотя основа остается неизменной. Вы не найдете двух одинаковых команд или двух одинаковых игр – так и с ГДД. Он всегда разный».

3. Обзор истории (англ. Story Overview). Во многих играх для написания основного сюжета и диалогов нанимают профессиональных писателей. Обычно они работают удаленно, то есть находятся далеко от всей остальной команды. Геймдизайнеру периодически приходится составлять короткий документ, описывающий присутствующие в игре сеттинги, персонажи и события. Случается и так, что у ознакомившихся с документом писателей возникают собственные идеи, которые в итоге могут значительно повлиять на дизайн игры.

Технологии

4. Технический дизайн-документ (англ. Technical Design Document). Часто видеоигра включает в себя множество сложных систем, не имеющих ничего общего с механикой, но отвечающих за появление определенных элементов на экране, обмен данными и другие исключительно технические моменты. Обычно эти детали нужны только программистам, но если ваша инженерная команда состоит из более чем одного человека, будет полезно отмечать эти моменты в одном документе. В этом случае новые люди, присоединившиеся к вашей команде, сразу поймут, что и как должно работать. Так же как и ГДД, этот документ редко дописывают до конца, но его написание крайне важно для того, чтобы держать под контролем всю программную составляющую игры.

5. Пайплайн-документация (англ. Pipeline overview). Большая часть сложностей, сопряженных с разработкой игры, связана с правильной интеграцией графических элементов. Существует множество правил, которым должны следовать художники, если они хотят, чтобы их графика корректно отображался в игре. Обычно этот документ составляется инженерной командой специально для художников, и чем проще он написан, тем лучше.

6. Системные ограничения (англ. System limitations). Дизайнеры и художники часто не имеют ни малейшего представления о том, что возможно, а что невозможно в той системе, для которой они создают контент. Для некоторых игр программисты составляют специальные документы, где дают четкое представление о границах системы, которые нельзя пересекать: о количестве фигур, одновременно показанных на экране, количестве сообщений об обновлениях за секунду, количестве одновременных взрывов на экране и т. д. Системные ограничения редко описываются подробно, но если вы обозначите их (желательно в письменном виде), это впоследствии поможет вам сохранить немало времени. К тому же подобные документы могут подтолкнуть к новым дискуссиям, в результате которых часто находятся нестандартные решения, позволяющие выйти за существующие границы.

Графика