ИСПОЛЬЗОВАНИЕ ГИБКОЙ МЕТОДОЛОГИИ В ИГРОВОЙ РАЗРАБОТКЕ

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

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

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

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

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

Основные роли в Scrum:

• скрам-мастер;
• владелец продукта;
• команда разработки.

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

Скрам-мастер ответственен за корректное ведение скрам-процесса: его задача проводить совещания, следить за соблюдением всех принципов скрама, разрешать противоречия и защищать команду от отвлекающих факторов.

Команда разработки — кросс-функциональная команда разработчиков проекта, которая чаще всего состоит разных специалистов. Идеальным размером команды принято считать 3-9 человек. Команда занимается разработкой и отвечает за результат как единое целое.

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

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

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

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

Рисунок 1. Визуальное представление процесса разработки игры в Scrum

Цель команд при обзоре итогов спринта — продемонстрировать «вертикальный срез» игры. Не все игровые механики могут быть реализованы в рамках одной итерации — отдельные их части становятся «вертикальными срезами» на которых и сосредотачивается команда. Например, ИИ персонажа очень сложно реализовать в рамках одной итерации, но один сценарий поведения ИИ вполне может быть запрограммирован, анимирован, иметь звук и быть показанным на игровом уровне. То есть заинтересованные лица получают функционал, который могут увидеть своими глазами и протестировать, а также при необходимости запланировать внесение правок.

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

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

В рамках гибкий методологий, таких как Scrum, разработчики получают огромное количество преимуществ. Отдельные лица, такие как руководители, продюсеры и ведущие гейм-дизайнеры не просто видят отчёты о сдаче функционала, а могут «прикоснуться» к нему и сыграть в него. Левел-дизайнеры могут создавать уровни, которые будут сфокусированы вокруг уже готовых механик, а не дожидаться пока будут готовы все.

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

Список литературы:

1. Джефф Сазерленд. Scrum. Революционный метод управления проектами. М.: Манн, Иванов и Фербер, 2017. — 272 с.
2. Э. Стеллман, Д. Грин. Постигая Agile. Ценности, принципы, методологии. М.: Манн, Иванов и Фербер, 2018. — 448 с.
3. Agile Manifesto. [Электронный ресурс]. — Режим доступа: http://agilemanifesto.org, свободный. — Загл. с экрана (дата обращения 02.04.2018)
4. Разработка игр в Post-Agile мире. [Электронный ресурс]. — Режим доступа:http://dev.by/lenta/main/razrabotka-igr-v-post-agile-mire, свободный. — Загл. с экрана (дата обращения 05.04.2018)