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

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

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

Я бы не хотел.

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

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

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

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

Итак, почему же ГДД не работают?

• В них слишком много допущений.

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

• Они всегда устаревшие.

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

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

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

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

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

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

• Они слишком сложные.

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

• Они не учитывают и не допускают ошибки.

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

Какова альтернатива?

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

• С самого начала придерживайтесь краткости.

Идея остается идеей до тех пор, пока ее не доказали. Сохраняйте документацию абсолютно минималистичной. Под минимумом я подразумеваю одно предложение. Определитесь что вам нужно для доказательства и воплощения идеи — и осуществите это. Я считаю  наиболее применимым метод “пользовательской истории”. Простая история, объясняющая вашу идею и ее перспективные стороны (интересность, юмор и т д). Излагайте ее от лица игрока. “Как игрок я могу следать х с у для того, чтобы ощутить z”.

• Следите за динамичностью документации

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

• Сохраняйте коллективность

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

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

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

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

• Не ведите документацию в Word.

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

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

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

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

Об авторе: Джеймс Светмен работает в Jagex Games Studio ведущим дизайнером над проектами RuneScape и Transformers Universe.

Перевод — П. Славин, оригинал — здесь.