Меня зовут Артём Волков и на данный момент я являюсь редким в наших кругах гейм-дизайнером фрилансером. Я успел насмотреться на разные маленькие игровые команды, которые пытаются сделать свой проект. Все они допускают приблизительно одни и те же ошибки. О них мы и поговорим.
У большинства маленьких молодых команд одни и те же проблемы. Нормальные процессы не построены, простейшее планирование отсутствует, концепция шаткая и не проработана до конца, а документация представляет собой просто творческие идеи, сваленные в кучу.
В итоге сроки разработки затягиваются, путь игрока не отстроен и в игру банально не интересно играть. Деньги утекают быстрее, чем планировалось, а результаты заметно ниже ожидаемых.
Чтобы избежать всех этих проблем надо следовать универсальному правилу ППД — Процессы, Планирование, Документация. Налаживайте процессы, планируйте разработку, следите за своей документацией. Хорошие процессы и документация не гарантируют вам успеха, но с ними заметно проще сделать хорошую игру и довести её до релиза.
Цель ППД — максимально прозрачная структура всех работ над проектом и налаженная коммуникация между членами команды.
Первая проблема у большинства команд — разработка изначально не делится на этапы. Классические крупные этапы разработки:
- Препродакшен
- Продакшен
- Постпродакшен
Не смешивайте этапы препродакшена и продакшена, ни к чему хорошему это не приведёт. Все крупные этапы также необходимо разбить на более мелкие майлстоуны, а их, в свою очередь, на итерации.
Препродакшен — очень важный этап. Его отсутствие в большинстве случаев и приводит к тем описанным выше проблемам. В больших компаниях на данном этапе решается огромное количество вопросов по дизайну, визуальному стилю, технологическим аспектам игры, монетизации, но так как речь идёт о маленьких командах, где ресурсы крайне ограничены, всё будет попроще.
На этом этапе для вас будет самым важным следующее:
- Концепт игры
- Целевая аудитория и сеттинг
- Ключевые игровые механики
- План разработки
- Бюджет
Вы ещё не делаете саму игру, вы только готовитесь к этому. Начните с небольшого прототипа, на котором будет можно попробовать основную механику. Помните — на этом этапе вы максимально гибки и можете разворачивать концепцию на 180 градусов в любой момент и по любой причине. Оценивайте идею, целевую аудиторию, свои ресурсы, риски — и формируйте видение игры.
Препродакшн — лучшее время закапывать мёртвую стюардессу и убивать неудачные идеи, чтобы самолёт летел дальше.
По итогу этого этапа у вас должны быть точно подготовлены:
- Концепт-документ
- Дизайн-документ
- Технические задания
- UX
- Прототип основной механики
- План разработки
Концепт арты тоже желательны, но тут уже зависит от вашей команды и средств на препродакшн. Если нет денег на концепты — собирайте референсы на визуальный стиль, который хочется получить.
Продакшен — это этап непосредственного производства игры. Производство стройте по плану, который вы сделали на препродакшене. На этом этапе не должно быть крупных и необоснованных изменений.
Конечно, избежать проблем не получится и что-то менять придётся, т.к. препродакшен не панацея, а некоторые проблемы всплывают на этапе продакшена:
- Механики. Несмотря на дизайн-документ, при разработке всегда будут всплывать проблемы игровых механик. Поэтому я советую проводить быстрое прототипирование “на кубиках” во время препродакшена.
- Баланс. Только с готовыми механиками можно понять, что балансировать и как, а во время разработки работать с балансом придётся очень много и меняться будет он часто. Да и сразу не получится получить необходимый баланс.
- Технические аспекты. Проблемы технического характера всегда будут появляться, и точно предсказать их никто не сможет.
Эти проблемы естественны и существуют на каждом проекте, главное не начинать всё заново и в разгар разработки вместо сюжетного топдаун шутера про цветы-убийцы не делать сессионный FPS про зомби.
Не забывайте играть в свою игру, особенно это касается гейм-дизайнера. Играйте всей командой. Вы найдёте не только новые баги, но и недоработки и неочевидные дыры в балансе или механиках.
После релиза у вас начинается этап постпродакшена или, говоря проще, поддержки. В крупных компаниях данный этап планируют заранее. В случае с маленькими командами, всё зависит от воли случая.
Если ваша игра стала популярной и приносит деньги, то её надо поддерживать. Поддержка игр заключается в создании дополнений и патчей. Их производство — это очередная цепочка из препродакшена и продакшена, только не всей игры, а конкретного патча или дополнения.
Даже если игра не выстрелила сразу, то не сдавайтесь. Анализируйте фидбек от пользователей и совершенствуйте ваш продукт до тех пор, пока это не станет откровенно убыточным занятием.
Теперь перехожу к самому интересному — документации:
- Концепт-документ
- Гейм-дизайн документ
- UX
- Балансные таблицы
Концепт-документ описывает идею игры и определяет вектор её развития.
Простые правила хорошего концепт-документа:
- Краткость. Пишите тезисами. подробностей механик не надо, они ещё несколько раз изменятся при написании ГДД.
- Ёмкость. Он должен отражать все основные особенности проекта, концепцию ключевого игрового процесса, предполагаемый визуальный стиль.
- Исправляйте концепт-документ как угодно и сколько угодно раз — но только во время препродакшена.
- Оформляйте концепты в виде презентаций. Это наглядно и привьёт вам навыки структурирования информации.
- Альтернативный вариант концепта — User Story с упором на то, какие ощущения будет получать игрок.
В концепте вы обязательно должны прописать:
- На какую аудиторию он рассчитан. Делать игру про зомби-нацистов на луне с кровавой кашей на экране и заявлять детскую аудиторию 7 лет — не лучшая идея.
- Игровой фокус. Самое краткое возможное описание концепции игры. Подробнее о нём можно узнать из доклада Григория Чопорова “Гейм-фокус: как не заблудиться в разработке”, который он читал на DevGamm 2017 в Москве
- User Selling Points (USP). Фичи, которые привлекут игрока, чем будет уникален проект.
- Список конкурентов и похожих игр. Определите размер рынка, целевую аудиторию конкурентов, их и ваши сильные и слабые стороны в контексте выбранного рынка.
Как только готов и утверждён концепт, можно приступать к написанию гейм-дизайн документа, в простонародье ГДД.
С ГДД всё сложнее. Основная проблема большинства начинающих гейм-дизайнеров, особенно в молодых командах — это желание написать в одном документе всё. Не надо так делать.
Гейм-дизайн документ — это совокупность разных небольших документов. Каждый документ описывает полностью определенную механику или фичу игры и ничего другого.
Для удобства ведения документации советую написать вводный документ, который будет представлять собой текстовую версию концепта, который расширен и описывает концепции механик с ссылками на ГДД.
Ещё важный момент — ГДД обсуждают все, но редактирует всегда 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 шутки:
- Стартовое — во время которого происходит планирование, что будете делать на данной итерации. Проводится для того, чтобы ПМ мог оценить насколько корректно все поняли задачи и насколько корректно составили себе приоритеты на неделю, а остальные участники работ узнали бы про планы других. И смогли бы скорректировать планы по задачам, если они завязаны друг на друга.
- Промежуточное — это быстрая синхронизация команды, на которой важно понять, есть ли у кого проблемы и как они влияют на завершение задачи. Нельзя врать о проблемах и их состоянии. Никого нельзя наказывать за проблемы и затыки. Проблемы надо находить и совместно решать, вы команда.
- Конечное обсуждение — тут подводятся итоги итерации.
И ещё немного советов напоследок:
- Процессы — не серебряная пуля успешных проектов. Это револьвер, при помощи которого выпускаемые вами пули летят кучнее, точнее и дальше.
- Лучше потратить 2-3 месяца на препродакшен, а не 2-3 года на провальный проект
- Лучше закрыть проект на препродакшене, чем мусолить его закрытие на продакшене
- Убивайте проект на любом этапе, не превращайте его в ненужную работу ради работы, вытягивающую силы, деньги и ресурсы команды.
- Идеальных документов не бывает
- Документация зависит от жанра, объёма работ, методологии, привычек команды
- Хорошие документы получаются не сразу, пишите постоянно, набивайте опыт
- Пишите как можно однозначнее! Всё, что может быть понято более, чем одним образом — БУДЕТ понято не так, как хотелось.
Отдельное спасибо за помощь по докладу и статье Александру Пашину, Артёму Турушину, Алексею Калинину и Сергею Гиммерлейху.
Related posts
18 комментариев
Добавить комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Отличная статья! Спасибо.
какая невероятно ценная и полезная статья!
Отличная статья! Всё изложено очень доступно. На мой взгляд будет полезна не только начинающим, но «продвинутым» руководителям позволит оценить ситуацию в проекте.
Очень хочется увидеть рассуждения авторов на тему «инструментов анализа» требований к игре, каких-нибудь хороших практик (например, «таблица плотности контента», «оценка влияния новых возможностей на систему», «оценка трудозатрат» и т.п.), которыми пользуются ГД и ПМ-ы.
P.S. От себя могу добавить, что о дисциплине «Разработка требований» в гейм-деве практически не слышал. В ней другой «понятийный аппарат», но некоторые моменты лучше описывают те или иные аспекты разработки продукта. Хорошая книга на эту тему у Карла Вигерса: https://www.ozon.ru/context/detail/id/27995134/
Для начала, хотел бы уточнить, что вы подразумеваете под «требованиям» к играм.
Это такой тип информации, который говорит о том, какими свойствами должна обладать (или не обладать) система. Требования, бывают разных уровней (бизнес, пользовательский, функциональный), у них разный потребитель (инвестор, гем-дизайнер, маркетолог, разработчик, тестировщик и т.д). И, от этого, могут быть задокументированы в различной форме: концепции проекта, скейч персонажа, юзер стори, юз-кейс, диаграммой (определенной нотации) и т.д.
В разработке игр очень тяжело систематизировать разработку требований из-за обилия жанров и платформ. Таких методов много и они зависят от игры к игре. Кроме этого, игровая индустрия ещё очень молодая.
Хорошая статья. Тем, кто хочет внедрить у себя джиру со скрамом, могу порекомендовать эту небольшую книжку: http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf
Небольшое дополнение о системах хранения документации и о трекерах:
— Хорошей бесплатной альтернативой Confluenсе конечно же будет любой бесплатный wiki-движок, хотя бы даже Media Wiki (движок Wikipedia) или dokuwiki.
Предложенная вами альтернатива в виде Google Doc — крайне плоха, например из-за сложности создания и поддержания системы перекрёстных ссылок.
— Хороший и полностью бесплатный (в отличии от предложенной вами Asana) трекер — Redmine.
У Trello слишком мало возможностей, и в команде из 5+ человек он не удобен (или я не умею его готовить).
Я не согласен на тему WiKi движка, тут нужна система комментирования сильная, особенно при совместной работе. Не говоря уже о редакторе текста. В Confluence есть сейчас улучшенные комментарии, но они никак не лучше системы комментариев и советов в Google Docs. В Google проблема только со структурой документации, приходится постоянно следить за сводным документом + ссылки нормальные делать.
Asana для маленьких команд бесплатная, платить там надо при росте команды и количеству проектов и не более того. В целом, она лучше Redmine по быстроте настроек и работы из коробки. Trello я добавил по совету тех людей, кто с ним много работает. Лично я его не люблю, но малоли, кому-то он понравится. В целом, как доску To Do, in Progress, To Test и Done в нём можно сделать, но когда задач много и много связанных задач, то он не очень.
А что на счет ассемблы думаете? Она вроде как пытается вместить в себя и вики движок и трекер задач и кучу всего еще.
Я правда в нее заходил последний раз года три наверное назад, не знаю что там сейчас.
не пользовался, так что ничего хорошего или плохого сказать не могу.
Парни, отличная статья. Сам повторил азы и сохранил линку
для всех интересующихся у меня Инди) Спасибо
Замечательная статья, спасибо! Сюда бы еще шаблоны документов или хотя бы скриншоты того как это выглядит в живую, вообще цены бы не было)
Очень хорошая статья, за первое прочтение много чего не уложилось, но автор статьи очень красиво все описывает, что хочется вернуться к ней снова и снова! Хочу добавить что в статье маленькая некорректность в описаниее концепт-документа, вроде как USP это Unique Selling Point, а не User Selling Points.
Спасибо за статью! Помогла структурировать имеющиеся знания.
Спасибо! Очень многое почерпнул, в чем-то убедился, что на правильном пути.
Вот тут:
«основой для вашего плана:» и далее идет список, там немного пропадают точки в конце предложений.
Перехожу к следующим главам, надеюсь в них увидеть уже практические примеры. Еще раз спасибо!
Хотел только сказать, что, к сожалению, с экрана читать неудобно, т.к. мало текста помещается на экран — с обоих боков полосы, а сверху и снизу блоки текста между картинок, поэтому получается, что перематываешь и сразу теряется место, где ты читал, нужна точность перемотки.