Войти
Игровой ДизайнФорумОбщее

Смерть Гейм-Дизайн Документов

Страницы: 1 2 Следующая »
#0
20:56, 17 окт. 2014

Всем привет!

Вы меня не знаете, я уже давно не заходил сюда, но, так получилось, что в своих целях я перевёл одну статейку про гейм-дизайн документы и захотел поделиться с вами, может, окажется полезным. Не скажу, что перевод идеальный, но суть донесена - это точно. Сам проработал гейм-дизайнером 6 месяцев (пока что). Это немного, но, ссылаясь на свой опыт, могу сказать, что со всем нижеперечисленным категорически согласен.

Надеюсь, статья вам пригодится.

Приятного чтения и успехов в геймдеве!

Джеймс Суэтмэн из Jagex о том, почему общие дизайн-документы не всегда работают и какие есть альтернативы



В течение всех этих лет их называли по-разному - ГДД, Дизайн-Библия, Документ-Обзор Игры. Вне зависимости от названия, они все описывают одну вещь: актуальный дизайн-документ видео-игры. ГДД десятилетями был опорой для дизайна игр, обеспечивая бесчисленное количество разработчиков и художников единым видением игры. Звучит круто, да? Кто бы не хотел иметь одно место, в котором можно хранить всё, что нужно знать об игре?

Я бы не хотел.

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

Начну с того, что я был прав: наша команда работала бок о бок с EA, которые в то время хотели жёсткой дизайн-документации, с инструкциями к инструкциям и документами о документах. Превосходно! Для меня это как нефиг делать. И около года это работало. Мы поставляли солидные, шаблонные игры, соблюдая все требования, которые нам выставляли, и не падали с коня. Всё началось меняться, когда мы столкнулись с парочкой новых, более креативных проектов в 2010-м.

Старые способы, в которые я свято верил, начали рассыпаться в пух и прах. Всё безумнее и безумнее казалась идея писать тысячи слов об игре, которая даже не существует, с концептами, шатко сидящими один на другом, как карточный домик. Требовался лишь лёгкий ветерок неуверенности, чтобы развалить его и убить весь проект.

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

Почему же ГДД не работают?

1. Слишком много предположений

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

2. Они всегда устарели

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

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

3. Никто их не читает

Нам всегда говорят, что руководству нужен ГДД. Это доказательство того, что идея игры продумана и хорошо исследована, и того, что есть данные о всех подготовках перед разработкой (о подготовках, которые нам, обычно, приходится переписывать).

Круто, но сколько раз их на самом деле читают? Каждый раз? Каждый второй раз? Наверное, "никогда" - правильный ответ. Хоть и может быть необходимость, у директоров, продюсеров или лидов чего-либо почти наверняка нет времени, чтобы читать ваш документ из 50,000 слов, и, возможно, они и не хотят (или им это не нужно).

Что же насчёт разработчиков? Художников? Они ведь прочитали каждое слово, так? Не-а. У большинства из вашей команды есть хорошее представление об игре, которую вы все пытаетесь сделать, и им не нужно читать все детали, которые вы запихали в свой документ. Им нужны лишь моменты, которые важны для их работы - вот и всё. Время, потраченное на чтение и перечитывание - время, не потраченное на разработку прикольной игры.

4. Они слишком жёсткие

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

5. Они не могут содержать ошибок

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

В чём же альтернатива?

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

1. Придерживайтесь лёгкости на раннем этапе

Идея - всего лишь идея, пока её не признали. Сведите документацию к абсолютному минимуму. Под минимумом я имею ввиду одно предложение. Определите, что вам нужно, чтобы вашу идею признали и воплотили. Способ, который я отметил для себя - "юзер-стори". Простая история, которая объясняет суть вашей идеи и почему она будет забавная или интересная. Рассказывайте от лица игрока: "Как игрок, я могу сделать А с помощью Б, чтобы почувствовать В".

2. Придерживайтесь гибкости

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

3. Придерживайтесь совместной работы

Не сидите в уголке, пока пишете вашу прекрасную идею. Такой вид разработки игр, как стиль "одинокого художника", должен быть и, надеюсь, станет мифом. В какой бы команде игровой индустрии вы не работали, все в этой команде должны быть и будут такими же страстными к играм и дизайну, как и вы.

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

4. Исследуйте и записывайте

Раз уж вы производите большие наборы документаций, они должны сводиться к двум видам: исследования и записи. Документирование исследований на конкретные темы, если сделано в достаточно лёгкой форме, может стать великолепным источником помощи в принятии групповых решений и проводником в расширении дизайна продукта. Записи же являются определением дизайна игры и результатом обсуждений дизайна или прототипирования, что полностью определяет направление вашего продукта. Это документы, на которые вы можете ссылаться, когда вас будут спрашивать о решениях, которые были приняты в дизайне игры.

5. Не делайте это в Word

Если вам необходимо написать какого-либо вида диздок, не делайте его в Ворде. Не поймите меня неправильно, Ворд - хорошая штука (я вот как раз сейчас его использую), но это не инструмент для документирования игры. Его жёсткость, ограниченность и плохая поддержка расширенных возможностей (в т.ч. управления изображениями) делает его непригодным для дизайн-документации. Делайте ваши документы открытыми, в онлайне, общими и, что самое важное, визуальными. Wiki's, Prezis, Google Docs и другие великолепные формы "живых" документов гораздо лучше для быстрой, визуальной документации, которую смогут увидеть все.

Нет утопии дизайна

Хоть я и хотел бы закопать традиционный ГДД (так, чтоб наверняка), будут случаи, в которых что-то наподобие всё ещё может пригодиться. Аутсорс, сторонние разработчики или совместная работа нескольких команд - в этих случаях для референса всегда понадобится какая-то форма основной документации.

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

Джеймс Суэтмэн, GD lead в RuneScape и разработчик Transformers Universe в Jagex Games Studio

--------------------------------------------------------------------------------------------------------


#1
21:42, 17 окт. 2014

Если хочешь быть богатым и счастливым - не ходи в школу. (с)

#2
21:44, 17 окт. 2014

Недостаточное условие, но в школе точно не учат, как стать богатым и быть счастливым, это да :)

#3
21:54, 17 окт. 2014

thepirate
> Сам проработал гейм-дизайнером 6 месяцев
Браузерные игры? Сервис, где всегда идет правка по ходу пьесы. Еще бы - ГДД не нужен.

thepirate
> Джеймс Суэтмэн, GD lead в RuneScape и разработчик Transformers Universe
А что, для этих игр нужен ГДД?:)

Документация по разработке давно работает по другим схемам. Сейчас от термина ГДД осталось лишь название.
Давно работают и пишут модульными блоками и по ТЗ в самом процессе, которое планируется по этапам коротким.
Что в малых конторах, что в больших. Просто течение рек стало казуальное и около-казуальное.
Полноценные ГДД и монолитные - это редкое явление всегда было. Чаще писалось оно уже после:)
И частенько на для рабочего процесса, а для ориентиров.

Если есть штатный гейм-дизайнер/сценарист (компетентный), то на его всегда все и свалят по документации.
Без этого никто делать игру и не будет. После "аудита" ГДД, он еще и распишет и раздаст ТЗ (на основе ГДД-бумажки).
В нормальных конторах и с нормальными проектами - так. В мировой индустрии - тем более.
Просто ГДД это фундамент, а не догма

#4
23:08, 17 окт. 2014

Еще не читал, но за Jagex уже спасибо. Герои моего детства.

#5
1:15, 18 окт. 2014

thepirate
> В процессе чтения люди будут делать кучу предположений, и вот фундамент вашего
> продукта уже пошатывается.

И с ходу противоречие. Если люди делают кучу предположений в процессе чтения, то что вату пишет этот гд.

#6
3:15, 18 окт. 2014

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

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

Самая полезная идея здесь, как мне кажется - это то, что прототипирование должно происходить во время (или даже до) создания диздока, а не после.

#7
4:16, 18 окт. 2014

Классическая схема:
- концепт.
- анализ (написания дд/тз).
- создание прототипа.
- верификация.
- создание продукта.
- тестирование.
- разворачивание.

Гибкая разработка:
- идея (чего-то там где-то нарисовали и заценили).
- создание продукта с минимальным набором фич, возможны в две стадии:
1) создание кривой демки без четких сроков.
программеры чего-то там кодят, параллельно пилится арт.
2) создание рабочей версии используя scrum.
из пред. опыта становится примерно понятно сколько времени нужно, какие фичи можно смело выкинуть, какие спрятать в backlog или запланировать на след версии.
- разворачивание с тестированием на конечном потребители.
- анализ результата.

#8
7:43, 18 окт. 2014

Зачем постить такое? Тут пожалуй один из десятка "геймдизайнеров" способен продумать и логически собрать воедино свои обрубки мыслей на костылях.
Про Ворд написали так зря. Если ДД пишет и редактирует один человек - Ворд, Эксель, Фотошоп(по вкусу), Визио(тоже по вкусу) - пожалуй самые простые средства. Нет нужды запихивать в него сложные схемы и прочее. Гиперссылки никто не отменял.
Вернусь к тому, что это тема - повышенной сложности, а наш юный геймдиз - это даунёнок, который не в состоянии связать свои мысли, не то выстроить целую концепцию.
Лучше выкладывайте что-то реальное, пусть у людей сложится образ, как строить ДД, пусть они видят, что идея бывает не так проста даже в изложении,
что есть такие моменты в игре, которые требуют очень тщательного продумывания.

#9
12:05, 18 окт. 2014

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

#10
12:36, 18 окт. 2014

Dmitry10

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры
#11
14:57, 18 окт. 2014

Dmitry10
> Дальше читать не стал, и так ясно почему у него там чего то не работает, когда
> у всех всё работает.
Ой, уж не тот ли это самый Дмитрий, который удаляет любой "мусор" из своей ветки про супер-киллер-аццки движок? Дмитрий, а какую смысловую нагрузку несёт Ваш пост тут, кроме мусора?

#12
15:09, 18 окт. 2014

ElDorado
> Дмитрий, а какую смысловую нагрузку несёт Ваш пост тут, кроме мусора?
Это рекомендация не прислушиваться к советам дилетантов и лузеров, выраженная в более мягких тонах.

#13
15:37, 18 окт. 2014

ElDorado

Судя по всему, Dmitry10 - местный юморист :)

#14
15:48, 18 окт. 2014

thepirate
> Судя по всему, Dmitry10 - местный юморист :)
Это скорее местный неадекват. Посмотри посты с его участием, если нервная система крепкая - то получишь немало лулзов. Велком к нам)

Страницы: 1 2 Следующая »
Игровой ДизайнФорумОбщее

Тема в архиве.