Написание Game Design Document, который ваша команда может использовать

04.05.2020
Posted in blog-article
04.05.2020 admin

Написание Game Design Document, который ваша команда может использовать

Для тех кто научился писать ТЗ и открыл для себя GDD. Отличный мануал по тому что следует делать и по тому что делать не следует.

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

Так вот, я написал множество GDDs и, возможно, несколько сотен подтверждающих документов для них, так что я не новичок в написании дизайна. Я беру новый проект каждые пару месяцев, что означает, что я начинаю с нуля, учусь на своих ошибках и часто пробую новые вещи. Это также означает, что для меня есть огромный потенциал быть похороненным в напрасной писанине, когда я мог бы вместо этого проектировать вещи.

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

Запуск GDD

Wiki или Word doc?

Я предпочитаю Wiki по следующим причинам:

— Наличие таймлайна. Если я не могу сказать, является ли док последней версией, не копаясь и не спрашивая кого-то, я немного психую.

— Легко ориентироваться. Все разделы GDD логично связаны. Разработчики могут быстро добраться до любого раздела без прокрутки или запоминания номеров страниц.

— Контроль доступа. В редком случае, когда я прошу кого-то изменить что-то, я могу предоставить им доступ только к этому разделу.

— Поощряет краткое написание и разделение функций. Я не знаю, что это за Word, но он склоняет людей к написанию длинных многословных абзацев. Мы дали талантливые дизайнерские проблемы, которые включают написание небольшого GDD для их дизайна, и поразительно, сколько из них отформатировано как мини-роман.

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

Определение Терминологии

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

За исключением того, когда я добрался до официальной терминологии для всего, что мы сделали. Мы потратили так много времени, постоянно отвлекая друг друга, чтобы прояснить, о чем мы все говорили… было бы комично, если бы это не случилось со мной. Обсуждение дизайна было похоже на реальную жизнь Эббота и Костелло.

В эти дни я определяю термины прямо из bat, прежде чем писать что-либо. Есть ли в этой игре уровни или головоломки? Или они называются вызовами, миссиями, этапами или мирами? Мы называем историю персонажа био или описание? Что же такое Turn в этой игре? Выберите обозначения и придерживайтесь их.

Установление Собственности

Вот моя мантра: «я Хранитель GDD, сопровождающий документы и обладатель ключа ко всем возможностям редактирования.» Чтобы сохранить порядок, я единственный, кто редактирует / добавляет / удаляет из документации по дизайну. Он держит все в едином голосе, обеспечивает правильное использование терминологии и помогает мне точно знать, что там и где все это. Я служу воронкой, через которую идеи команды перетекают в письменную форму.

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

Поддержание GDD

Начать с малого

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

Не забудьте отдельные документы!

Я много использую Google Docs, которые могут быть отредактированы в реальном времени и всегда актуальны. Они имеют историю ревизий, легко связаны с GDD и часто рассматриваются в большей степени, чем сам GDD. GDD не обязательно должен быть домом документации, он может быть просто хабом.

Документировать весь текст в игре

Я провел 5 часов на прошлой неделе, забивая весь текст из нескольких игр, потому что мы решили сделать скорректировать для стандартного английского языка. Текст не весь был в одном месте, некоторые из них не были актуальными, и много текста было просто введено прямо в игру и его даже не было в документе. Позор мне!

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

 

Чего не делать

Все, чего я избегаю 🙂

Не пишите GDD, если это никому не нужно

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

Не Сортируйте объекты по приоритетам в Doc

Я никогда этого не делаю! Документы проектирования являются источником ссылок, а не инструментом управления задачами. Все разделы расположены таким образом, что позволяет в них легко ориентироваться. Они никогда не помечены по приоритету.

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

Многословные объяснения -Нет и ещё раз Нет

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

GDD не предназначен для передачи новых проектов в команду

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

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

Нет Печати!

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

Задержите обновление GDD в соответствии с текущим состоянием игры

Есть чувство соблазна вернуться и обновить GDD, чтобы соответствовать тому, что уже реализовано? Я всегда спрашиваю себя сначала: нужно ли мне это документировать? Кто-нибудь из команды должен будет прочитать это в будущем? Если да, то сделайте это. Если нет, забей. Пусть разделы GDD умирают естественной смертью, поскольку функции добавляются в игру, сосредоточьтесь только на новых и важных вещах, о которых вам нужно написать.

Это всего лишь несколько моих философий, чтобы сохранить документы живыми и полезными. Лучший совет — поговорить с вашей командой и узнать, что именно им нужно, и быть непреклонным в поддержании документов таким образом, чтобы они отвечали этим потребностям. Вы будете в конечном итоге с хорошей, настроенной системой, которая работает для вас.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Contact

Давайте работать вместе!

Пишите нам и найдем точки соприкосновения, может станем партнерами, а может поможем вам зайти в нашу чудесную нишу

Вы разработчик?

Пишите! Нам постоянно нужны новые кадры, либо можем помочь в продвижении вашего приложения

Новичок?

Поможем быстро войти в нишу, не тратя годы на понимание

Давно в нише?

Рады будем пообщаться как на темы whitehat, так и blackhat тематики ^_^ + всегда есть что обсудить по поводу рекламных сетей

ПИШИ В TELEGRAM!

Contact