Автор критикует практику длинных дизайн-документов (GDD) как вредную для разработки игр. Такие документы предполагают фиксированную инженерную спецификацию, по которой команда последовательно реализует фичи. Это убивает необходимую раннюю итерацию, мешает находить «фан» через прототипирование и плейтесты и привязывает ресурсы к бумажному плану, а не к реальному прогрессу игры.
При этом документация всё равно нужна: она фиксирует решения и формирует общее видение следующего шага. Вместо GDD автор предлагает формат «дизайн-лога» — живого документа, который отражает процесс итераций вокруг рабочего билда.
Структура дизайн-лога
1. Концепт внизу документа. В основании лога — исходная концепция (2–10 страниц): ключевая идея и целевой базовый цикл взаимодействия, достаточные для старта прототипа.
2. Быстрый прототип. Лог существует только вместе с рабочим билдом. Задача — как можно быстрее сделать играбельный прототип, отбрасывая графику, сюжет и второстепенные фичи.
3. Ежедневные записи сверху. После существенной работы с билдом добавляется новая запись над концептом. Формат записи:
- Заголовок: дата.
- Play Notes: впечатления от текущего билда, что работает/не работает; к каждой проблеме — возможное решение.
- Prioritized Next Steps: при большом списке проблем — приоритезированный список следующих шагов (аналог JIT-бэклога).
- Tasks accomplished: что уже сделано (отдельным списком или зачёркиванием в тексте).
- Experiments: крупные рискованные эксперименты, которые могут вывести дизайн на новый уровень.
Новые записи добавляются раз в день-два, старые постепенно уходят вниз, как в блоге.
Инструменты
Автор рекомендует Google Docs:
- одновременное редактирование и «живые» сессии обсуждения;
- комментарии, привязанные к конкретному тексту, с ответами;
- возможность «resolve» комментариев для очистки документа;
- email-уведомления как триггер для повторного вовлечения.
Неудачные варианты: Microsoft Word (плохая коллаборация, версии, локи), email (расползающиеся треды, хаос на горизонте больше недели), блоги (нет совместного редактирования и привязки комментариев к фрагментам текста).
Практические советы
- Ограничивать объём в день. Запись должна читаться за ~5 минут; лишние идеи лучше отфильтровать.
- Делить логи по направлениям. Например, отдельный дизайн-лог и арт-лог.
- Делать из лога диалог. Документ должен быть площадкой для обсуждения, а не монологом одного дизайнера.
Преимущества дизайн-лога
- Реалистичность: записи основаны на последнем билде, а не на абстрактных идеях.
- Действенность: каждый день формируется конкретный список улучшений.
- Общность: вся команда может комментировать и предлагать идеи.
- Фокус: единая линия эволюции дизайна от концепта до текущего состояния, понятная новичкам.
- Актуальность: свежие мысли всегда наверху, устаревшее уходит вниз.
- Гибкость: лог позволяет легко менять курс по мере понимания игры; в препродакшене может заменить бэклог и таск-листы.
Ключевая мысль: дизайн игры — это не статичный план, а живой процесс, завязанный на реакции игроков и команды. Толстый GDD плохо вписывается в такую динамику, а дизайн-лог поддерживает её и смещает фокус с «выполнения плана» на ежедневное улучшение реальной игры.
Выводы
- Длинные GDD вредят итеративной разработке и поиску фана.
- Дизайн-лог фиксирует решения и видение, оставаясь живым и кратким.
- Структура: концепт внизу, ежедневные записи с плейтест-заметками и приоритетами сверху.
- Нужен коллаборативный инструмент (Google Docs), а не Word/email/блог.
- Лог должен быть диалогом команды и напрямую опираться на текущий билд.
