Процессы и документация для начинающих

Меня зовут Артём Волков и на данный момент я являюсь редким в наших кругах гейм-дизайнером фрилансером. Я успел насмотреться на разные маленькие игровые команды, которые пытаются сделать свой проект. Все они допускают приблизительно одни и те же ошибки. О них мы и поговорим.

У большинства маленьких молодых команд одни и те же проблемы. Нормальные процессы не построены, простейшее планирование отсутствует, концепция шаткая и не проработана до конца, а документация представляет собой просто творческие идеи, сваленные в кучу.

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

Чтобы избежать всех этих проблем надо следовать универсальному правилу ППД — Процессы, Планирование, Документация. Налаживайте процессы, планируйте разработку, следите за своей документацией. Хорошие процессы и документация не гарантируют вам успеха, но с ними заметно проще сделать хорошую игру и довести её до релиза.

Цель ППД — максимально прозрачная структура всех работ над проектом и налаженная коммуникация между членами команды.

Первая проблема у большинства команд — разработка изначально не делится на этапы. Классические крупные этапы разработки:

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

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

На этом этапе для вас будет самым важным следующее:

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

Препродакшн — лучшее время закапывать мёртвую стюардессу и убивать неудачные идеи, чтобы самолёт летел дальше.

По итогу этого этапа у вас должны быть точно подготовлены:

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

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

Конечно, избежать проблем не получится и что-то менять придётся, т.к. препродакшен не панацея, а некоторые проблемы всплывают на этапе продакшена:

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

Не забывайте играть в свою игру, особенно это касается гейм-дизайнера. Играйте всей командой. Вы найдёте не только новые баги, но и недоработки и неочевидные дыры в балансе или механиках.

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

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

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

Теперь перехожу к самому интересному — документации:

Концепт-документ описывает идею игры и определяет вектор её развития.

Простые правила хорошего концепт-документа:

В концепте вы обязательно должны прописать:

Как только готов и утверждён концепт, можно приступать к написанию гейм-дизайн документа, в простонародье ГДД.

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

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

Для удобства ведения документации советую написать вводный документ, который будет представлять собой текстовую версию концепта, который расширен и описывает концепции механик с ссылками на ГДД.

Ещё важный момент — ГДД обсуждают все, но редактирует всегда 1 человек.

Обновляйте ГДД, если по результатам разработки изменились детали некоторых механик, и обязательно оповещайте об этом команду.

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

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

ТЗ вам позволит:

ТЗ часто корректируются во время продакшена, это нормально.

UX (user experience) лучше проектировать уже после утверждения механик. В первую очередь напишите User Story — документ с блок-схемой, описывающий путь игрока по интерфейсам игры. Он поможет не только оценить объём интерфейсов, но и примерно прикинуть архитектуру продукта.

После утверждённого User Story делайте простые макеты без дизайна, мокапы. Это упростит работу не только программистам, но и дизайнерам UI.

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

Лучший формат для мат.модели — это таблицы Excel (или аналог в OpenOffice). Google таблицами пользоваться не советую — они медленнее, в них есть ограничения на столбцы и строки, и не так приятно работать с оформлением.

Визуальное оформление таблиц важно. Информация должна быть представлена в максимально доступном виде. Чтобы было ещё проще воспринимать вашу модель — старайтесь комментировать ячейки.

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

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

Хорошо написанный и структурированный ГДД является основой для вашего плана:

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

Записывайте все интересные идеи, которые пока не влезают в ваши сроки и бюджет, в отдельный лист.

Приоритезируйте ваши игровые механики и фичи по важности и сложности

Распишите их последовательность в реализации

Все очень крупные фичи старайтесь разделять на несколько маленьких

Обсудите с командой сроки реализации каждой фичи и не забудьте сразу прибавить 50% времени

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

Делите все крупные этапы на более мелкие майлстоуны, а их — на итерации.

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

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

Длину итерации выбираете сами. Оптимальной длиной итерации я лично считаю 1-2 недели, за это время вы можете успеть сделать что-то понятное и осязаемое.

На итерацию берите ровно столько, сколько сможете сделать, не пытайтесь сразу себя завалить всеми задачами. Если вам кажется, что задача не выполнится за итерацию, то разбейте её на подзадачи. Помните — не задачи существуют для итераций, а итерации для задач.

Почитайте подробнее про систему управления проектами Agile, чтобы вникнуть в эту тему глубже.

Ещё одна проблема, которую мало кто решает в молодых и маленьких командах — постановка и выполнение задач.

Для небольших и молодых команд проще всего использовать классическую Kanban-доску, со столбцами To Do, In Progress, Done. В To do лежат карточки задач, которые надо сделать. В In Progress — которые взяты в работу, а в Done уже завершённые задачи.

Для постановки задач удобно использовать Jira — у неё есть функционал дочерних задач (сабтасков), связи между задачами (например блокеры), и множество других удобных и полезных инструментов. В качестве альтернативы можно использовать Asana или Trello.

Приучите всю команду работать через задачи, это дисциплинирует.

Коммуникации внутри команды также надо налаживать и делать их более структурированными.

Все обсуждения должны быть сжатыми по времени и максимально полезными, без посторонних разговоров.

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

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

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

Важно проводить плановые обсуждения итераций, в идеале их должно быть 3 шутки:

И ещё немного советов напоследок:

Отдельное спасибо за помощь по докладу и статье Александру Пашину, Артёму Турушину, Алексею Калинину и Сергею Гиммерлейху.