Рекомендации геймдизайнеру от программиста (архитектора).


Вступление

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

Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.

Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.

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


Самое важное:

  1. Четкое понимание конечного результата. (Контроль качества.)
  2. Сроки исполнения.


Зачем нужна документация:

  1. Экономия времени на коммуникациях. (Один раз написать, вместо того чтобы 100 раз пересказывать, путаясь в показаниях.)
  2. Способ увидеть, как будет выглядеть готовый проект.
  3. Анализ и выявление проблем еще на стадии планирования. (Чем раньше будет выявленна архитектурная ошибка — тем дешевле ее исправить)
  4. Фиксирование принятых решений. (Точные данные, вместо разрозненных слухов разной степени свежести.)
  5. Планирование работ.


Какие бывают документы:

  1. Концепция («Про че игра?»)
  2. Спецификация (Что мы хотим получить?)
  3. Техническое задание (Как это устроено — именно о нем будет идти речь.)
  4. План работ (Как мы это будем делать.)


Кто участвует в обсуждении ТЗ:

Чем раньше будет получена обратная связь от заинтересованных специалистов — тем меньше будет сделано лишней работы.
  1. Геймдизайнер (Написание документации)
  2. Архитектор (Отслеживание полноты и подробности описания, декомпозиция.)
  3. Программист (Оценка объемов работ.)


Требования к оформлению документации:

Чем более неряшливо будет оформление — тем меньше людей вообще начнет это читать. Читатели проявляют невероятную изобретательность, чтобы избежать неприятной для них работы. Поэтому так важно прилагать усилия к тому чтобы чтение документации было легким и приятным настолько, насколько это вообще возможно.
  1. Форматирование. (Легко напечатать и приятно читать/держать в руках)
  2. Выделение ключевых фраз. (Для чтения документа по диагонали)
  3. Составление списков. (Вместо сплошного текста)
  4. Разбиение длинных списков по группам. (По три пункта в группе)
  5. Многократные повторения. (Избегать ссылок по документу)
  6. Дата, номер страницы, количество страниц, нумерация пунктов. (Для точных ссылок при обсуждении прочитанного)
  7. Оглавление, список документов, история изменений. (Для поиска по документации/версиям)


Требования к содержанию ТЗ

Нет четкого списка требований, которому должна удовлетворять документация. Поэтому разработка ТЗ приостанавливается задолго до приближения к ее полноте. В итоге следующий этап разработки начинается без ТЗ, в надежде, что ТЗ будет дописана по ходу, или даже по итогам разработки.
  1. Русский язык. (Никаких мемов, искаженных аглийских терминов, албанского языка и прочего мусора. Даже внутреннюю документацию читают очень многие.)
  2. Никаких общих слов типа:
    • все возможные варианты
    • карта придумывается компьютером
    • взаимодействие различных объектов
    • после всех действий и т.д.
  3. Все названия видов сущностей(классов) должны иметь:
    • русское название (для игрока)
    • английское (для кода)
    • краткое описание (расшифровка/подсказка/комментарий)
  4. Сущность должна иметь только одно название. (Чтобы “броня” не превращалась на другой странице в “армор” или “щит”).
  5. Предложения должны быть полными и понятными читателю без пристального изучения контекста. (Не надо подразумевать, что читатель сам догадается до того, что подразумевал автор)
  6. Все что можно измерить, должно быть измерено.
    • размеры картинки в пикселях и байтах
    • количество столбцов и клеток в таблице
    • количество символов в текстовом поле
    • количество оружия на уровень
    • время сессии и т.д.


Главные требования к результату работы программиста:

Эти важные требования подразумеваются, но никогда никем не озвучиваются.
  1. Гибкость системы к изменениям. (Динамические требования.)
  2. Автоматический сбор данных об ошибках. (Обратная связь.)
  3. Простота запуска и настройки заказчиком. (Демонстрация результата.)


Первый этап написания ТЗ:

Описание предметной области, ее формализация в понятных программистам терминах.

  1. База данных (метаданные)
    • список типов объектов
    • характеристики объектов
    • связь/зависимость между объектами
  2. Бизнес-процессы (полный игровой цикл)
    • список процессов (сценарии работы)
    • список функционала (что должен уметь)
    • список ожидаемых изменений (что вообще может быть)


Второй этап написания ТЗ:

Как должен выглядеть/работать продукт для всех типов пользователей (игроки и администраторы).
  1. Интерфейс (визуальная часть)
    • список экранов игры с названиями (или группы элементов)
    • список элементов на каждом экране с названиями и текстом подсказок
    • описание поведения элементов (подмигивание, подсказка, блокирование, всплывающие диалоги и т. д.)
  2. Админка (управление)
    • сервер (жизненные/системные показатели )
    • игровой контент(распродажи, квесты, монстры, вещи, магазины, дроп, локации и т.д.)
    • игровые данные(контент генерируемый игроками)
    • статистика и отчеты (какую статистику нужно собирать?)


Третий этап написания ТЗ:

Как мы собираемся это все делать.

  1. Исследование необходимых технологий
    • Список требований к каждой технологии
    • Описание тестов/демонстрации работы каждой технологии
    • Список будущих требований/возможных проблем (что дальше?)
  2. Список требований к разным видам контента(ресурсов) для игры (размеры картинки мечей, длинна названий квестов, разновидности спецэффектов, размеры видеороликов и т.д.).
  3. Список небходимых инструментов для работы с контентом (редактор карт, админка квестов, ).
  4. Расстановка приоритетов по задачам.
  5. Требования к первой работающей сборке (что должен уметь первый прототип).
  6. Список остальных итераций разработки проекта с требованиями к их результатам. (Что нужно показать в конце каждого этапа, чтобы закончить его)


Сопровождение документации

  1. Большая часть того, что написано на первых этапах – устареет и будет нуждаться в переписке заново задолго до окончания планирования.
  2. Главный принцип первых этапов планирования: расставить список разделов и составить список вопросов по каждому разделу.
  3. Чем ниже детализация на начальных этапах – тем лучше. (количество типов оружия, вместо полного списка с названиями, количество квестов по уровням, вместо их подробного перечня и т.п.)
  4. Чем легче найти нужный пункт в документации и изменить его, не затрагивая остальное – тем лучше. Поэтому нужно избегать графических схем и сплошного текста из сложноподчиненных предложений. Оставьте графические презентации и эмоциональные описания для финальной отчетности.
  5. После каждого цикла планирования — проверять и тестировать полноту документации и равномерность уровня ее детализации. (Если в доме из 5 комнат описана только одна – нужно описать остальные четыре, или выкинуть подробное описание одной комнаты, чтобы все комнаты были описаны одинаково подробно.)
  6. Составить список неудобных вопросов. Темные пятна всегда есть, и их стараются обойти и замолчать, не осознавая этого.
  7. Предоставлять краткие инструкции конечным исполнителям. Конечные исполнители не должны сталкиваться с полной документацией, и мучительными поисками нужного упоминания по всему объему.
  8. Признак мастерства: каждый следующий уровень планирования уточняет, но не изменяет результаты описания более абстрактных уровней. Именно хороший навык перемещения по уровням абстрагирования/детализации позволяет перейти от припадочного описания деталей к планомерному перечислению сущностей.


Срезание углов

Любая технология будет упрощена до абсурда, чтобы уменьшить количество работы и расходов. Хлеб из химических дрожжей, вино из спирта, разработка без документации.
Многие считают что документация не нужна, если:
  1. Проект в 2-3 месяца.
  2. Команда из 2-3 человек.
  3. Ограниченный бюджет. (Он всегда ограничен)
  4. Нет требований к документации. (Никто не знает как надо делать)
  5. От нее нет никакой пользы. (Никогда не использовали документацию)

Однако следует помнить: разработка документации занимает 40% всех усилий. И определяет на 90% вероятность успешного завершения разработки проекта.

Первые шаги

Настоятельно рекомендуется новичкам выбирать в качестве первых проектов «клоны» классических игр. Пока нет успешного опыта такой игры — нет виденья всего цикла разработки продукта. А значит нет понимания того, как дойти до финиша.
Не стоит начинать разработку игры, не написав хотя бы двух полноценных ТЗ в качестве упражнения. Это может быть ТЗ по арканоиду. Но это обязательно должен быть ТЗ по которому разработчики смогут написать полноценный арканоид, даже если они никогда не видели этой игры прежде.