Дипломная работа: Проектирование модуля планирования и разработки игры

Рисунок 1.7. Окно создания нового проекта игры

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

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

1.4.3 SimulTrain

Тренинговый бизнес-симулятор SimulTrain [18] - это компьютерный симулятор, используемый для обучения управлению проектами. Моделирование ведения проекта позволяет обучающимся получить знания о различных нюансах менеджмента, научиться следить за сроками и стоимостью проекта, качеством его ведения и влиянием человеческого фактора. В режиме реального времени пользователь видит последствия принимаемых им решений в компании и может проследить их влияние на различные затраты по времени или стоимости проекта. Главное окно симулятора представлено на рис. 1.8, на котором отображается виртуальный офис компании игрока. Здесь в процессе игры будут появляться различные сообщения о произошедших событиях, а также о необходимости выбора решения, которое будет влиять на процесс игры.

Рисунок 1.8. Главное окно бизнес-симулятора SimulTrain

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

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

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

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

Рисунок 1.9. Диаграмма Ганта, отображающая процесс составленного плана в игре

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

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

1.5 Сравнение игровых симуляторов

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

Таблица 1.2. Таблица сравнения игровых симуляторов, реализующих командную разработку

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

Глава 2. Проектирование модуля планирования и разработки

На основании выявленных требований к разрабатываемой программе выполняется проектирование архитектуры игры «IT-менеджер». Для модуля планирования и разработки описываются алгоритмы, реализующие функциональность соответствующих этапов, с помощью нотаций диаграмм UML. Затем определяется статическая структура системы, выраженная в виде диаграммы классов, и выполняется описание поведения системы. После чего создается пользовательский интерфейс программы с учетом специфики описанных алгоритмов.

2.1 Построение архитектуры игры

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

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

Рисунок 2.1. Архитектура игры «IT-менеджер»

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

Также любое действие пользователя в программе должно записываться в текстовый файл, для того чтобы в дальнейшем можно было анализировать собранную статистику для улучшения игры и обнаружения ошибок. Данное действие логирования осуществляется с помощью компонента «NLog», предоставляющего методы для быстрой и удобной записи данных в текстовый файл. А для добавления нескольких панелей в рамках одного окна, отображающих различные данные о текущих найденных требованиях, добавленных модулях и нанятых сотрудниках проекта, используется компонент «AvalonDock».

2.2 Моделирование алгоритмов, реализуемых в программе

Этап планирования игры «IT-менеджер» должен содержать назначение работ для разработки внутриигровых модулей. Для этого необходимо составить алгоритм создания архитектуры игрового приложения на основе обнаруженных ранее требований.

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

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

Рисунок 2.2. Диаграмма активностей определения модулей для реализации найденных требований

Данный алгоритм расчета представляет собой установление количества строк кода модуля, исходя из навыков архитектора выбранного пользователем сотрудника. Определяемое количество строк рассчитывается по формуле (1):

, (1)

где РОКС - рассчитываемое ожидаемое количество строк кода модуля от аналитика;

УОКС - установленное ожидаемое количество строк кода модуля в программе;

случайная погрешность (%) - разброс от идеального установленного числа строк кода с учетом навыка архитектора.

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

, (2)

Так, например, если навык архитектора равен 80 процентам, то разброс погрешности будет равен 20, а, соответственно, случайная погрешность будет задана случайным числом от 80 до 120.

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

Также существует ограничение по количеству определенных модулей в один игровой день. Оно устанавливается на основании характеристики производительности выбранного сотрудника. Для каждого рабочего заранее закладывается его объем работ в день, выше которого он не может отработать. Так, например, при установлении производительности сотрудника равным 5 требованиям в день рабочий не сможет определить модули более чем для 5 требований за один игровой день.

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