Описание процесса разработки игры в нотации BPMN

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

Условные обозначения для моделирования бизнес-процессов (Business Process Modeling Notation, BPMN) — система условных обозначений (нотация) для моделирования бизнес-процессов. BPMN была разработана Business Process Management Initiative (BPMI) и поддерживается Object Management Group, после слияния организаций в 2005 году. Предыдущая версия BPMN — 1.2; последняя версия — 2.0.

Спецификация BPMN описывает условные обозначения для отображения бизнес-процессов в виде диаграмм бизнес-процессов (ДБП). BPMN ориентирована как на технических специалистов, так и на бизнес-пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Кроме того, спецификация BPMN определяет, как диаграммы, описывающие бизнес-процесс, могут быть трансформированы в исполняемые модели на языке BPEL. Спецификация BPMN 2.0 так же является исполняемой и переносимой (т.е. процесс, нарисованный в одном редакторе от одного производителя может быть исполнен на движке бизнес-процессов совершенно другого производителя, при условии если они поддерживают BPMN 2.0).

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

В настоящий момент существует несколько конкурирующих стандартов для моделирования бизнес-процессов. Распространение BPMN поможет унифицировать способы представления базовых концепций бизнес-процессов (например, открытые и частные бизнес-процессы, хореографии), а также более сложные концепции (например, обработка исключительных ситуаций, компенсация транзакций).

Для разработки моделей BPMN воспользуемся онлайн сервисом signavio.com. Из основных возможностей стоит отметить: возможность создавать модели в нотации BPMN 1.2 и 2.0; хранение файлов на сервере; возможность открытого онлайн доступа к своим моделям. 

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

Моделирование в нотации BPMN как и любой метод имеет свои сильные и слабые стороны. 

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

В качестве недостатков можно отметить отсутствие оценки количественных показателей времени и как следствие невозможность оценить критерии качества – цена и время. Как ни странно, большая детализированность процесса для некоторых целей может оказаться излишней и даже вредной. Рассмотрим каждую BPMN модель более подробно.

Подготовка

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

Разработка дизайн-документа

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

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

Разработка игры

Как уже отмечалось данный процесс основной в разработке игры. Здесь следует отметить следующие основные принципы:

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

 все что делается подчинёнными проходит жёсткий контроль сперва лицом руководящим подчинёнными и потом и игровым дизайнером.

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

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

Результатом работы процесса является полностью готовый код, графические и звуковые ресурсы, игровые элементы. Однако все это пока находится в разделённом состоянии.

Сборка и тестирование

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

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

Публикация и продвижение

Данный этап финальный. Основную роль здесь играет PR-менеджер. Стоит отметить, что работать он начинает задолго до публикации финальной версии техническим директором. 

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