Конкурс геймдизайнСтатьи

Геймдизайн - взгляд дилетанта. (3 стр)

Автор:

Часть четвёртая. Диздок. Как делать, чем делать, зачем делать...

Диздок. Собственно, это вся ваша игра в текстовом формате. На его основе будете делать всю игру, соответственно, он должен содержать всю информацию ,которая потребуется  для разработки. Это не только описание юнитов, объектов их поведения. Как я уже писал в начале статьи, функциональную спецификацию не стоит делать, пока вы не сможете точно ответить на вопрос, а действительно ли стоит делать вашу игру. То есть сначала должен быть чёткий, короткий, ясный концепт документ. Когда вы уже точно уверены, что подобную игру стоит делать, только тогда стоит приниматься за диздок, и функциональную спецификацию. Первый вопрос возникает, как это организовать. Я для себя уже решил, что стоит использовать html для организации диздока.  То есть привести к следующему виду.

Изображение удалено

Слева находится меню, в котором указаны ссылки на соответствующие части диздока. Как сделать подобную html страничку описывается в любом нормальном учебники HTML. Но я пытаюсь рассказывать всё-таки о геймдизайне, а не основах языка HTML, так что html вам придеться изучить самостоятельно. Поверьте, мне это, совсем не трудно. Теперь, как всё это использовать. Первой страницей всегда делайте список последних исправлений, дополнений, которые вы сделали в диздок с ссылками на части, которые вы изменили, дополнили. Также разделите логически диздок на части, а потом создайте файлы html, назовите их так, чтобы легко было понять, что они содержат. Создавать и редактировать подобные файлы лучше при помощи Word'a  ибо он спокойно позволяет сохранять в формате html. Ибо делать таблицы, вставлять рисунки, делать диаграммы, удобней из Word'a, нежели из какого-либо специального редактора html. Да, код будет плохим, но вас это не должно волновать. Всё равно итоговый размер диздока будет меньше, нежели в формате doc. Что очень ощутимо, если все члены вашей команды работают удалённо.

Плюс ко всему, диздок можно будет спокойно читать без использования спец-программ. Такой доступ к информации более удобен (ИМХО!). Плюс ко всему, советую сделать условные обозначения. То есть, скажем, курсивом вы пишите информацию, которая ещё может измениться в дальнейшем, а чёрным выделенным цветом то, что уже точно будет и никогда не изменится. И не забудьте сделать соответствующий раздел в диздоке, который объясняет условный обозначения.

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

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

Далее уже можно переходить к более чётким понятиям, то есть определять сколько будет уже нормальных игровых уровней – локаций, описать отличия, выделить типы  игровых объектов (здания, бонусы, оружие противники), и теперь уже расписывать какие типы объектов, на каком уровне-локации будут использоваться, то есть создаётся примерное описание того, какие будут враги, какое будет их общее количество, типы бонусов и прочее. И, собственно, указать какие игровые объекты, на каких уровнях-локациях используются. После этого уже можно указывать взаимодействия между объектами, характеристики  и прочее.

На этом же этапе надо чётко решить, какие инструменты могут понадобиться в игре. Игре, вероятно, понадобится какой-нибудь редактор уровней, и поэтому нужно определиться, разрабатывать свой редактор или расширить возможности уже существующего. Тоже самое с редакторами диалогов, скриптов, моделей и прочего. Всегда пытайтесь чётко определить, какие инструменты понадобится вместе с людьми, которые будут этими инструментами пользоваться, точно опишите требования к этим инструментам. Далее можно заниматься балансировкой геймплея, написанием диалогов, реплик, более конкретно указывать, что происходит на определённых уровнях, прописывать точные характеристики игровых объектов. Думаю, этого достаточно. А теперь вывод:

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

Часть пятая и последняя. Приоритеты и последние советы. На что лучше всего потратить свои силы.

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

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

Так же не забывайте о таких вещах, с которыми игроку постоянно придется сталкиваться, то есть как обыграть экраны загрузки (если они будут), какого типа должны быть сохранения (опять же если будут, но это надо описать как можно раньше). В каждой игре есть ошибки, но с некоторыми можно мириться, а с другими нет. Как правило, это кажется в начале проекта мелочами, но эти мелочи, если часто используются игроком, оказывают очень сильное влияния на геймплей, к таким вещам скажем относится игровой пользовательский интерфейс (HUD). В одних играх он носит чисто информационную роль, в других игроку постоянно приходиться с ним работать. Всегда тщательно прорабатывайте игровой GUI, от неудобного интерфейса впечатление от игры портится гораздо сильнее, чем скажем от какого-либо небольшого графического бага (враги проходят сквозь двери и т.д. и т.п.). Имеет даже значение вид прицела в шутерах. Скажем если у какого-либо типа оружия, очень хорошая убойная сила на расстоянии, то дайте игроку возможность использовать эту силу. Создайте такой прицел, чтобы он не мешал при стрельбе по отдалённым целям. Вообще приоритетными являются те фичи, которую собственно делают вашу игру настоящей игрой. Главное создать основу, а остальное можно дорабатывать по ходу дела.

Вместо вывода и заключения.

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

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

Лучшее обучение-практика. И неудачный опыт - тоже опыт =)


12.12.2005
Алексей «jusio» Быков
Специально для конкурса сайта GameDev.ru

Страницы: 1 2 3

14 декабря 2005 (Обновление: 27 янв 2006)

Комментарии [5]