1.3 Описание требований к модулю планирования и разработки игры
Данная работа направлена на создание модуля планирования и разработки игры «IT-менеджер», целью которого является реализация двух соответствующих этапов разработки. Главным образом программа должна реализовывать функции, отражающие действия во время командной разработки программного продукта, и содержать этапы анализа, планирования, разработки, тестирования и внедрения. Кроме того, в игре должны быть определены сроки проекта, чтобы студент мог составить план согласно установленной длительности. Несоблюдение установленных правил влияет на игровой процесс и удовлетворенность заказчика. Для завершения проекта обязательным условием является показ продукта всем участвующим стейкхолдерам для получения от них оценки. В случае если имеются ошибки в разработанной программе или появляются новые требования со стороны стейкхолдеров, то следует доработать программу.
Функциональным назначением всего программного продукта является представление одной из методологий разработки программного обеспечения в игровой форме, а также осуществление ведения разработки виртуального проекта. В узком плане данная работа направлена на проектирование и реализацию программного модуля планирования и разработки внутриигрового проекта. Система должна иметь удобный интерфейс взаимодействия с пользователем и выполнять необходимые для данных этапов расчеты, которые будут влиять на игровой процесс.
Предполагается, что данные об имеющихся требованиях к игровому продукту, количестве и характеристиках сотрудников для разрабатываемого модуля будут поступать из другого модуля анализа требований. Выходным результатом работы модуля планирования и разработки является составленный пользователем план работ, а также выполненная реализация модулей по составленному ранее плану с генерацией ошибок в разработанных игровых модулях.
Для наглядного отображения основной работы разрабатываемого модуля было проведено описание системы на концептуальном уровне с помощью диаграммы прецедентов, изображенной на рис. 1.3.
Рисунок 1.3. Диаграмма прецедентов модуля планирования и разработки
Предполагается, что в системе будет участвовать только один актор, он же пользователь системы, контролирующий все процессы, происходящие в игре на этапах планирования и разработки. При переходе на этап составления плана разработки пользователь должен выполнить функцию создания архитектуры внутриигровой программы, где на основе найденных на предыдущем этапе требований, составляется набор модулей, реализующих их. За это действие отвечает прецедент «Формирование модулей для реализации найденных требований». Также перед составлением модулей необходимо выбрать архитектора из списка сотрудников, нанятых ранее на этапе анализа. Характеристики выбранного человека будут влиять на полученные в игре данные. Так если навык архитектора окажется низким, то полученные данные о необходимом количестве строк разработки модуля будет сильно варьироваться от идеального значения, установленного в программе для данного модуля. За определение количества строк кода необходимого для реализации определенного требования отвечает прецедент «Расчет количества строк кода модуля с использованием навыка архитектора». В данном случае назначенный пользователем сотрудник задает предположительную размерность выбранного модуля, которая в дальнейшем будет использоваться при составлении плана работ.
Следующий прецедент «Добавление работ в план» содержит в себе выбор модуля для разработки и двух сотрудников, выполняющих роль разработчика и тестировщика. Пользователю предоставляется для выбора только список тех модулей, которые были определены архитектором на продолжительности всего проекта. Дополнить этот список можно, повторно запустив процесс определения модулей на основе найденных требований, предварительно выбрав архитектора. Назначение разработчика и тестировщика определяется самим пользователем с помощью специальных выпадающих списков, располагаемых на экране. Допускается назначение одного сотрудника сразу на две роли и выбор нескольких модулей для одновременного назначения разработки и тестирования сразу для всех.
«Удаление работы из плана» предполагает то, что модуль, ранее добавленный в план работ, не будет задействован в разработке или тестировании. При добавлении или удалении модуля происходит перерасчет ожидаемой длительности разработки и тестирвоания, отображаемой на экране для того, чтобы пользователь мог ориентироваться по запланированным временным затратам.
После выбора модуля и участника разработки выполняется прецедент «Расчет длительности разработки выбранного модуля с использованием навыка разработчика», в результате которого пользователь получает информацию о предположительном затрачиваемом времени, необходимом на разработку выбранного модуля. Аналогичным образом выглядит прецедент расчета длительности тестирования, где результатом является ожидаемое время выполнения тестов назначенным тестировщиком.
После определения запланированных работ пользователь выполняет «Переход на этап разработки» посредством нажатия на соответствующую кнопку интерфейса.
Этап разработки начинается автоматически при переходе на соответствующий экран. Прецедент «Запуск виртуальной разработки по составленному плану» подразумевает начало разработки модулей согласно установленному на предыдущем этапе плану. Связанный с ним другой прецедент подразумевает выполнение специальных алгоритмов, которые рассчитывают продолжительность разработки и тестирования добавленных в план модулей и количество строк кода для них в зависимости от характеристик разработчика. С течением времени на экране отображается прогресс разработки, где количество прошедших дней увеличивается на единицу, а разработанные за этот период модули добавляются в список на экране.
Во время процесса разработки для модулей, участвующих в данном процессе, рассчитывается количество допущенных при их создании ошибок в зависимости от навыка назначенного на эту работу разработчика. За это отвечает прецедент «Расчет количества ошибок во время создания модуля».
Рассмотренные прецеденты отражают основное взаимодействие пользователя с системой и описывают его действия на этапах планирования и разработки. При этом можно выделить основные возможности, предоставляемые разрабатываемым модулем:
1. Определение модулей, реализующих требования игрового проекта, в зависимости от навыков архитектора.
2. Выбор модулей для добавления в план работ.
3. Выбор разработчика и тестировщика на реализацию работы.
4. Добавление и удаление работы на разработку и тестирование выбранных модулей.
5. Расчет ожидаемого количества строк кода разработки для определяемого нового модуля в зависимости от характеристик аналитика.
6. Расчет прогнозируемой длительности разработки модуля в зависимости от характеристик назначенного разработчика и установленного архитектором количества строк разработки этого модуля.
7. Расчет реальной длительности разработки модуля в зависимости от характеристик назначенного разработчика и установленного архитектором количества строк разработки этого модуля.
8. Расчет прогнозируемой длительности тестирования модуля в зависимости от характеристик назначенного тестировщика и количества строк кода разработки этого модуля.
9. Расчет реальной длительности тестирования модуля в зависимости от характеристик назначенного тестировщика и количества строк кода разработки этого модуля.
10. Расчет прогнозируемой длительности итерации в зависимости от добавленных в план работ и индикация превышения установленной для проекта максимальной длительности итерации для пользователя.
11. Генерация ошибок в разработанном модуле в зависимости от характеристик разработчика.
Более подробные требования к разрабатываемой системе приведены в техническом задании, которое расположено в прил. А.
1.4 Анализ существующих решений
Рассмотренная тема обучения навыкам командной разработки проявляется в некоторых уже существующих обучающих игровых симуляторах. Был проведен анализ наиболее популярных решений и составлена сравнительная таблица по различным оценочным критериям. Главным образом разрабатываемая игра должна быть ориентирована на молодую аудиторию и иметь образовательную составляющую, так как планируется использовать ее в учебных заведениях. Также симулятор должен иметь понятный интерфейс и краткую инструкцию правил для того, чтобы пользователь с легкостью мог самостоятельно начать прохождение и играть в подходящем для него темпе. В рамках обучения виртуальный проект должен иметь завершение, чтобы игрок мог увидеть конечный результат и оценить последствия своих действий.
1.4.1 Game Dev Tycoon
Game Dev Tycoon [16] - это игра, где пользователю предстоит взять на себя роль начинающего разработчика и своими усилиями создать IT-компанию. Игрок начинает создавать игры на заре игровой индустрии в гараже с достаточным для проживания на пару месяцев денег. Создавая качественные игры, нравящиеся внутриигровым пользователям, игрок получает большую прибыль, которую он должен тратить на развитие собственной компании. Параллельно можно отправить игрового персонажа где_то подрабатывать для получения дополнительных денег.
В начале пользователю случайным образом присваиваются 4 тематики, которые нужно использовать для создания игры. Данный фактор значительно вносит дисбаланс между несколькими участниками, так как программно в игре заложено, что для некоторых тем проще создать популярную игру, чем для других, тем самым одному пользователю может повезти больше, чем другому. Каждую тематику можно изучать, чтобы делать более качественные игры. Также на качество влияют технологии и дизайн, постоянно улучшая которые можно сделать хорошую игру. В начале предоставляется только эти три фактора, влияющие на игру, но в дальнейшем при развитии собственной компании их количество увеличится и добавятся маркетинг, виды игр (такие как средние, большие и высокобюджетные) и много другое.
Во время создания игры пользователь должен распределить отведенное на разработку время между тремя показателями (рис. 1.4), проработанность которых будет влиять на итоговую оценку разработанной программы. Это распределение поначалу невозможно верно составить, поскольку только после проб и ошибок пользователь должен самостоятельно подобрать верное соотношение, в результате которого будет получена максимальная оценка продукта.
Рисунок 1.4. Окно распределения ресурсов между тремя показателями игры
После выпуска игры для нее появляются обзоры из различных журналов и отзывы пользователей, которые влияют на продажи игры и, соответственно, на прибыль компании издателя. Чем больше игрок производит игры, тем больше он развивается и накапливает свой капитал.
Спустя какое-то время появляется возможность открыть свой собственный офис (рис. 1.5) и нанять людей на работу. Существует несколько типов сотрудников для найма: дизайнер, технолог и разработчик. Каждый из них имеет свой навык, который отражается на качестве создаваемой им игры, а также появляется необходимость выплачивать зарплату, что в свою очередь также влияет на игровой бюджет.
Рисунок 1.5. Окно игры, отображающее прогресс работы в офисе
Нет каких-то четких границ сроков создания игры, пользователь самостоятельно решает сколько нужно потратить время на изучение технологий, разработку и исправление ошибок. Игра продолжается до тех пор, пока у него не закончатся деньги, или не пройдет 35 игровых лет, когда программно останавливается развитие игровой индустрии. Игроку предоставляется выбор продолжить свободную игру самостоятельно, либо завершить ее.
В целом игра подходит для увлекательного времяпровождения для любого типа людей, как знакомых с реальным выпуском программных продуктов, так и нет. Однако ее нельзя назвать обучающей, так как кроме правильного распределения денег и трудовых ресурсов компании она ничему не учит. Кроме того, в своем контенте она не содержит образовательных целей, а только направлена на развлечение игрока.
1.4.2 Game Corp DX
Еще один симулятор игровой студии носит название Game Corp DX [17]. Он содержит в себе стандартные для подобного жанра элементы свободного управления миром и построения успешного бизнеса. Отличительными особенностями данной игры являются простой дизайн, легкость освоения правил и отсутствие каких-либо ограничений на выпуск игр.
Game Corp DX построена полностью на 2D графике, что может оттолкнуть современное поколение людей и наоборот привлечь более взрослое. На протяжении всей игры пользователю помогает виртуальный персонаж, изображенный на рис. 1.6. В начале игры он кратко объясняет, что нужно делать и куда нажимать, чтобы создать свою первую игру, а в дальнейшем участвует при возникновении различных игровых событий в качестве диалогового лица.
Рисунок 1.6. Окно начала игры Game Corp DX
Игроку предстоит с начальным бюджетом нанять нескольких сотрудников и назначить им создание новой игры. Существует игровое время, которое длится 8 рабочих часов, после которых все сотрудники компании идут домой и на следующий день приходят обратно на работу. У нанятого работника имеется несколько показателей влияющих на продуктивность его работы, можно накормить его различной едой и его эффективность повысится в несколько раз. Также при назначении работы пользователь должен обращать внимание на навыки сотрудника. Всего в игре существует 4 вида специальности: кодинг, арт, звук и сценарий. Каждый такой навык можно развивать у конкретного человека до четвертого уровня мастерства, однако для одного человека разрешается выбрать только один вид постоянной занятости. На рис. 1.7 изображено окно создания игры, где пользователь должен ввести название будущей игры, выбрать ее размер и тип.