Визуализация деловой игры в Unity 3D
Оглавление
Введение
Глава 1. Анализ предметной области и средств
разработки
1.1 Понятие деловой игры
1.2 Компьютерные деловые игры
1.3 Студия компетентностных деловых игр
1.4 Платформа Unity, как средство для разработки
компьютерных деловых игр
1.4.1 Сравнение средств разработки компьютерных игр
1.4.2 Возможности Unity3D для разработки компьютерной
деловой игры
1.5 Структура игрового движка Unity3D
Глава 2. Проектирование подсистемы визуализации
деловой игры
2.1 Проектирование подсистемы взаимодействия подсистемы
визуализации и СКДИ
2.2 Описание требований к подсистеме взаимодействия
2.3 Спецификация прецедентов
2.4 Проектирование структуры строки-взаимодействия
2.5 Проектирование архитектуры игры
2.5.1 Серверная часть деловой игры
2.5.2 Клиентская часть деловой игры
Глава 3. Реализация подсистемы взаимодействия на
примере компьютерной деловой игры «Проезд перекрестка»
3.1 Реализация сервиса СКДИ
3.2 Реализация клиентской части игры в подсистеме
визуализации
3.2.1 Настройка проекта в подсистеме визуализации
3.2.2 Организация игровых сцен
3.2.3 Реализация кодирования и декодирования
строки-взаимодействия
3.3 Реализация деловой игры «Проезд перекрестка»
3.3.1 Описание бизнес-процесса «Проезд перекрестка»
3.3.2 Проектирование визуального представления игры
3.3.3 Создание игрового объект «Машина»
3.3.4 Создание пустой дороги
3.3.5 Создание события «Светофор»
3.3.6 Реализация проезда светофора в подсистеме
визуализации
3.3.7 Формирование игрового уровня
3.3.8 Отслеживание событий
Заключение
Библиографический список
Введение
визуализация
деловой игра компьютерный
В настоящее время становятся популярными методы активного обучения[1,2].
В отличие от традиционной формы обучения, которая отводит студенту пассивную
роль, и предполагает передачу обучающемуся системы обобщенных знаний, умений и
навыков, данная концепция создает условия для активного участия учеников, что
дает им возможность приобрести знания и опыт на практике. Одним из таких
методов являются деловые игры. Проведение деловых игр позволяет погрузить обучающегося
в имитационную среду, которая в свою очередь воссоздает условия и динамику
реального бизнес-процесса[3].
На данный момент ведется разработка среды проектирования и проведения
деловых игр СКДИ (студия компетентностных деловых игр), которая позволяет создавать
сценарии деловых игр для игрока. По окончанию игры СКДИ может анализировать
результаты деятельности в ходе выполнения сценария игры и выдавать рекомендации
для улучшения деятельности обучающегося. Деловая игра не должна отличаться от
обычных игр по способам визуализации, что определяет актуальность использования
готового игрового движка, а, следовательно, возникает необходимость разработки
подсистемы взаимодействия между веб-сервисом, реализующим логику деловой игры,
и подсистемой визуализации. В качестве средства визуализации было решено
использовать игровой движок Unity3D. Исследование возможностей игрового
движка показали, что на данный момент существует ряд ограничений во
взаимодействии между средством визуализации, и ее логической составляющей на
веб-сервисе[4].
Проблемой работы является то, что сценарий игры представляет собой
автомат в виде ЛСА и необходимо найти способ, с помощью которого автоматная
модель СКДИ будет взаимодействовать с подсистемой визуализации, которая будет
реализована с помощью Unity.
Для решения проблемы необходимо разработать систему передачи сценария,
реализованного в виде ЛСА, в модуль визуализации. Вид, в котором передаются
команды сценария, также проектируется в данной работе.
В работе [5] вопрос генерации деловой игры и изменение сценариев,
происходит при помощи встроенной в игру логики. В большинстве деловых игр все
процессы формирования сценариев и логика уже встроена внутри самой игры.
Объектом данной работы является процесс визуализации деловой игры в Unity 3D. Предметом данной работы является взаимодействие
веб-сервиса, реализующего сценарий ДИ, и визуальной части ДИ на движке Unity 3D.
Целью работы является разработка подсистемы взаимодействия между
подсистемой визуализации и веб сервисом СКДИ, на котором создается сценарий
игры. Для того чтобы достичь поставленной цели, необходимо решить следующие задачи:
. Анализ предметной
области:. Анализ систем визуализации существующих компьютерных и деловых
игр.. Формирование требований к инструменту для реализации визуализации
ДИ.. Анализ функциональных возможностей Unity3D.. Формирование
требований к подсистеме взаимодействия между подсистемой проведения ДИ СКДИ и
модулем визуализации.
. Проектирование
подсистемы взаимодействия.
. Реализация
подсистемы взаимодействия.
. Апробация подсистемы
взаимодействия на примере разработки ДИ «Проезд перекрестка».
В качестве методов
исследования используются методы лабораторного эксперимента, моделирование, ОО
анализ и проектирование. Они призваны для того, чтобы провести моделирование,
проектирование и тестирование подсистемы взаимодействия и разработанной деловой
игры.
Глава
1. Анализ предметной
области и средств разработки
В этой главе будут описаны ключевые понятия, которые используются в
работе, проведен анализ и сравнение наиболее популярных современных средств
разработки компьютерных игры и выбрано наиболее подходящее цели данной работы.
1.1 Понятие деловой игры
Ключевым понятием работы является понятие деловой игры. У разных авторов
точки зрения на деловую игру могут отличаться, однако можно выделить
определение, которое отражает ключевые черты деловой игры. Деловая игра - это
метод имитации принятия решений работниками или специалистами посредством
специально смоделированной ситуации. Это позволяет развить необходимые в работе
знания, умения и навыки. Деловая игра является методом эффективного обучения
профессиональной деятельности. Данный формат обеспечивает гораздо более высокий
уровень вовлеченности и мотивации, чем классические формы обучения, что
способствует быстрому и качественному усвоению материалов [9].
Применение деловых игр позволяет обучать в процессе деятельности,
способствуя в значительной мере улучшению межпредметных связей, приближению
полученных теоретических знаний к потребностям производства и воспитанию профессионально
значимых качеств будущих специалистов [10]. В основе деловой игры лежит
имитационная модель реальной профессиональной деятельности. Участники игры в
смоделированных условиях наделяются ролями и в соответствии с инструкцией
выполняют заданные действия.
Деловые игры воссоздают реальные ситуации, имеющие место в
профессиональной деятельности. Термин деловая игра у разных авторов может
отличаться, при этом в определениях акцент делается либо на объект
моделирования (организации, сложные социально-экономические ситуации), либо на
процессы (процесс функционирования организации, процесс управления,
производство-хозяйственная деятельность) [11].
Процесс проведения деловой игры основывается на определенном сценарии,
который определяет правила работы, входные данные, определяет ход и содержание
игры. В ходе игры обучающийся погружается в среду бизнес процесса. Он вынужден
использовать полученные теоретические знания на практике. По окончанию игры
анализ действий игрока позволит оценить уровень овладения профессиональными
навыками и умениями, его способность реагировать на изменение ситуации и
принимать решения.
К числу сильных сторон деловых игр можно отнести то, что они позволяют:
рассмотреть определенную проблему при значительном сокращении времени; освоить
навыки выявления, анализа и решения конкретных проблем; развить ориентацию в
нестандартных ситуациях; концентрировать внимание игрока на главных аспектах
проблемы и устанавливать причинно-следственные связи.
Метод активного обучения, одним из которых являются, деловы игры
способствуют развитию качеств необходимых в определенных процессах и на
предприятиях, что позволяет сократить затраты на обучение специалистов.
Обучение на реальном процессе дает возможность оценивать и развивать именно те
знания и навыки, которые необходимы специалисту.
1.2 Компьютерные деловые игры
Использование игровых элементов в ходе обучения способствует развитию
личности специалиста и активации учебного процесса, повышает внимание,
мобилизует усилия, направленные на решение проблемы, позволяет ощутить чувство
успеха и поверить в собственные силы.
Ю.В. Геронимус [12] выделяет следующие факторы, которые способствуют
появлению интереса к игре:
· удовольствие от контакта с партнером;
· удовольствие от демонстрации партнерам своих возможностей как
игрока;
· азарт ожидания непредвиденных ситуаций;
· удовлетворение от успеха;
· корыстный интерес к денежному выигрышу и др.
Исходя из этого, применение игрового подхода в обучении являются
закономерным. Именно на игровые мотивы опираются методы активного обучения [4].
В настоящее время, когда компьютерные технологии применяются во всех
аспектах человеческой деятельности, необходимо разрабатывать и применять
компьютерные деловых игр.
Компьютерные деловые игры (КДИ) - это учебно-тренингов система
построенная на основе математической модели, описывающей приближенные к
реальности ситуации по определенным правилам. КДИ позволяет отрабатывать навыки
принятия решений в условиях меняющейся ситуации. Созданная при помощи КДИ
имитация служит средством актуализации, применения и закрепления знаний. КДИ
характеризуется динамизмом и непрерывным изменением ситуации под воздействием
решений, а также непосредственном участии обучающегося в изучении процесса.
Современные концепции развивающего обучения утверждают, что умственная
деятельность включает в себя не только чисто познавательные функции, но и
эмоциональные отношения, и волевые акты. Исходя из этого, интенсификация
умственной деятельности достигается путем напряжения волевых усилий совместно с
другими сферами психической деятельности (внимание, восприятие, память,
мышление и творческих функций). Однако установлено, что при релаксации
(расслаблении физическом и психическом), происходит наиболее продуктивная
деятельность. Именно в таком состоянии наблюдается эффект быстрого запоминания
[9].
Особенностью деловой игры является то обстоятельство, что усвоение
знаний, формирование умений, навыков происходит в условиях игровой модели
профессиональной деятельности в ее предметных и социальных аспектах. В компьютерную
деловую игру заложена идея расслабления, она позволяет почувствовать себя в
другой роли, более успешной, независимой. Этим обусловлен большой интерес к
компьютерным играм, как детей, так и взрослых.
Еще одним фактором, который влияет на повышенный интерес к КДИ, является
потребность в самообразовании. С каждым днем дистанционное образование получает
все большее распространение. Развитие компьютерных технологий и технологии
интернет позволяют получать знания, где и когда удобно, затрачивая на это столько
времени, сколько необходимо обучающемуся. ДО объединяет в себе качество знаний
от обычных форм обучения и в тоже время сокращает временные затраты. В
дистанционном обучении, средства КДИ и активные методы обучения являются
основой учебного процесса.
Классификация компьютерных игр является довольно сложным вопросом. Это
связанно с тем, что критерии принадлежности игр к тому или иному жанру не
определены однозначно, классификация компьютерных игр недостаточно
систематизирована, и в различных источниках могут различаться. Тем не менее,
существует консенсус, к которому пришли разработчики игр:
. Аркада - игра, в которой игроку приходится действовать быстро,
полагаясь в первую очередь на свою реакцию;
. Симулятор - всевозможные симуляторы реальных механизмов, техники,
спортивные игры и т.д.;
. Стратегии - игры требующие планирования и выработки определенной
стратегии для достижения некоторой цели. Разделяют два типа стратегий:
пошаговые (TBS), где игроки по очереди делают свои
ходы, и стратегии в реальном времени (RTS), где игрокам выполняют действия одновременно;
. Ролевые игры - главный герой обладает какими то
характеристиками, которые влияют на его умения и способности. Обычно главной
характеристикой является уровень, который необходимо прокачивать, выполняя
задания и убивая других персонажей. Жанру свойственен большой мир, развитая
сюжетная линия и вариативность ответов в диалогах;
. Головоломки - игры со сложной системой уровней, интерактивной
системой поиска предметов. Как правило, не требует реакции от игрока.
КДИ могут быть представлены в любом из перечисленных жанров. Выбор жанра
заключается в определении целей обучения, будь то стратегическое мышление или
быстрое умножение, развитию реакции или изучению английского языка, разработке
технических и методических средств реализации деловой игры.
Также компьютерные деловые игры можно поделить на два типа по количеству
участников: коллективные и индивидуальные.
Коллективная КДИ рассчитана на участие группы игроков, где каждый
участник самостоятельно принимает решения. Такая игра наиболее реалистичная,
так как принятие решений предоставлено живым людям, а не компьютеру. В игре
такого типа участники могут свободно обмениваться ролями, что позволяет им
взглянуть на смоделированную ситуацию с разных сторон. Однако успех такой КДИ
зависит не только от организации процесса, но и от первоначальных знаний
участников. В случае если уровень знаний будет низкий, есть вероятность того,
что у участников сложится неправильное представление о процессе и эффект будет
отрицательным.
Индивидуальные КДИ отличается от коллективных тем, что в них моделируется
не только ситуация и условная среда, но и действия всех участников, кроме
одного. Такая игра рассчитана на самостоятельное обучение или самообразование.
В этих играх человек за компьютером выполняет те или иные функции управления
объектом, а компьютер одновременно создает ему конкретную среду, в которой
функционирует виртуальное предприятие, и играет роль помощника во всех делах.
Индивидуальные игры имеют потенциально большую аудиторию. Можно установить
программу дома, на рабочем месте и проводить обучение. Выполненные участником задания
хранятся в памяти компьютера, поэтому обсуждение результатов может проходить в
любое удобное время. Также участник индивидуальной КДИ не зависит от уровня
знаний участников игры и от их присутствия вообще, поэтому процесс прохождения
игры и анализа принимаемых решений здесь происходит в разы быстрее, нежели при
проведении коллективной КДИ.
Основным элементом любой КДИ является сценарий игры, так как в нем
описана моделируемая модель, правила поведения и взаимодействия внутри игры,
описаны основные элементы, свойства и параметры, роли и границы обязательств
для каждой из них.
.3 Студия компетентностных деловых игр
Для того чтобы развивать компетенции у студентов и специалистов, обучение
необходимо проводить в условиях максимально приближенным к производственным.
Для имитации таких условий предполагается использовать модель
производственной деятельности, которая включает в себя все основные этапы
жизненного цикла процесса. Для ее реализации будем использовать
инструментальную среду разработки и проведения деловых игр - студия
компетентностных деловых игр (СКДИ). Структурная схема СКДИ представлена на
рис. 1.1.
Рисунок 1.1 Структурная схема СКДИ
Структурная схема включает в себя ряд подсистем.
Подсистема проектирования предназначена для разработки сценариев деловых
игр.
Подсистема проведения предназначена для проведения деловой игры с
использованием сценариев разработанных в подсистеме проектирования.
Подсистема мониторинга предназначена для отслеживания хода игры и
результатов игроков.
Подсистема анализа предназначена для обработки результатов прохождения
деловой игры и получения отчетов качества методического обучения.
Подсистема корректировки предназначена для оперативного изменения
элементов и процесса деловой игры.
Подсистема измерения использует контрольно-измерительные материалы,
которые позволяют определить уровень сформированных компетенций [13].
Результатом прохождения деловой игры можно считать уровень выработанных в
процессе обучения компетенций.
При реализации среды СКДИ возникает несколько проблем, в том числе и
проблема представления деловой игры для обучаемого, отображение, разработанных
в подсистеме проектирования, сценариев игры, а так же, как осуществить
управление элементами и действиями игрока в соответствии с логикой деловой
игры.
В качестве средства для визуального отображения игровых сценариев будет
служить игровой движок. На данный момент существует огромное множество
представителей игровых движков, и их количество с каждым годом только увеличивается.
В зависимости от требований которые ставятся перед игрой можно сделать выбор в
пользу того или иного средства разработки.
Игровых движков, которые могут быть использованы для разработки деловой
игры, существует огромное множество. Их спецификации варьируются от
конструкторов с простой графикой до промышленных игровых движков, с передовыми
возможностями и графикой нового поколения. Также выбор средства разработки
может зависеть от целевой платформы и средств разработки, которые будут
использованы в ходе создания игры.
.4 Платформа Unity, как средство для
разработки компьютерных деловых игр
1.4.1
Сравнение средств
разработки компьютерных игр
На данный момент в сфере игровых движков существует большой выбор, что
позволяет найти подходящее средство разработки каждому. Для того чтобы
определить наиболее подходящий именно для данной работы, необходимо сравнить
самые популярные игровые движки, которые представлены на рынке.
Для сравнения возьмем четыре наиболее популярных и востребованных
движков.
Unity3D является активно развивающимся
игровым движком. В первую очередь его популярность связана с низким уровнем
вхождения и удобством использования, что позволяет вести разработку без особых
глубоких знаний. Unity распространяется абсолютно бесплатно с пользовательской
лицензией. Она позволяет использовать программу до тех пор, пока ежегодных
доход не превысит 100 тыс. долларов, после чего разработчики предлагают перейти
на одну из трех платных программ подписки. Unity содержит огромное количество
инструментов, которые помогают в разработке. Для программирования используется
высокоуровневый язык C# или JavaScript. Unity позволяет создавать игры
абсолютно любых жанров, а также экспортировать их на 21 платформу, среди
которых: Windows, iOS, Android, macOS, Xbox, Playstation и другие [14]. Unity
также отличает огромное сообщество и колоссальный магазин компонентов для
движка - Asset Store, в котором продаются элементы для игр.
Unreal Engine 4 игровой
движок от студии разработчиков Epic Games. За
последние несколько лет UE
кардинально изменился. На данный момент движок распространяется по бесплатной
лицензии, взымается 5% роялти от продажи проекта, приносящего более 3000
долларов в квартал. С помощью движка можно разрабатывать как простые двухмерные
игры так и трехмерные игры любых жанров. UE предоставляет два пути создания проекта: при помощи
графического скриптового языка Blueprint или C++. В первом случае операции
связываются между собой с помощью графического редактора. Во втором случае
описание геймплея осуществляется на языке C++. UE
оснащен всеми необходимыми для разработки игр редакторами и поддерживает все
популярные платформы.
Cryengine также является одним из бесплатных игровых движков. Он главным образом
нацелен на разработку MMO-игры
с передовой графикой. В движке хорошо проработана сетевая подсистема, есть
поддержка широкого ряда современных технологий. Движок активно развивается и
часто получает обновления. Причиной этому является открытый код, доступ к
которому может получить любой желающий. Также Crytek активно занимается поддержкой инди-разработчиков на
движке Cryengine. Абсолютно любой проект,
разработанный на игровом движке, может получить финансовую и техническую
поддержку, победив в конкурсе.
Игровой движок Lumberyard является ответвлением от оригинального Cryengine. Этот движок разрабатывается
компанией Amazon. Разработчики встроили в игровой
движок поддержку облачных технологий -Amazon Web Services и Twitch [14]. Это позволяет работать и хранить данные в
облаке Amazon. Вместе с тем, эти сервисы подходят
для разработки массивных мультиплеерных проектов. Игровой движок абсолютно
бесплатный с открытым кодом. В Lumberyard есть графический редактор кода, схожий с редактором в UE4, он позволяет связывать сущности с
компонентами. Также система генерации кода позволяет модифицировать старый код C++ и создавать новый.
Ниже, в табл.1.1 представлено сравнение описанных выше игровых движков.
Таблица 1.1 Сравнение игровых движков
|
Показатели
|
Unity3D
|
Unreal Engine 4
|
Cryengine
|
Lumberyard
|
|
Цена
|
Персональная версия - бесплатно Плюс версия - 35 долл/мес с
человек Про версия - 125 долл/мес с человек
|
Бесплатно + 5% роялти с проектов с доходом 3000 долл./мес
|
Бесплатно
|
Бесплатно
|
|
Порог вхождения
|
Низкий
|
Средний
|
Средний
|
Средний
|
|
Исходный код
|
Закрытый
|
Открытый
|
Открытый
|
Открытый
|
|
Платформа для использования
|
Windows, macOS
|
Windows, macOS
|
Windows
|
Windows
|
|
Способ создания проекта
|
C#
|
Blueprint, C++
|
C++, C#
|
Графический редактор, C++
|
|
Целевые платформы
|
iOS, Android, Windows 8 Store,
Windows 10 Store, macOS, PS3, PS4, Xbox 360, Xbox One, Wii U, Oculus Rift,
Gear VR, PlayStation VR, Samsung Smart TV и тд.
|
iOS, Android, Windows 8 Store,
Windows 10 Store, macOS, PS3, PS4, Xbox 360, Xbox One, Wii U, Oculus Rift,
Gear VR, PlayStation VR, Samsung Smart TV и тд.
|
Windows, Linux, PlayStation 4, Xbox
One.
|
Windows, PlayStation 4, Xbox One.
|
Сравнение показывает, что все современные игровые движки обладают как
достоинствами, так и недостатками, однако в основном предоставляют схожие
возможности. В результате для данной работы выбор был сделан в пользу Unity3D. Это в первую очередь связано с предпочтением языка
программирования C#. Также игровой
движок является относительно простым для понимания и использования, что позволит
сократить время на разработку игры.
1.4.2
Возможности Unity3D для
разработки компьютерной деловой игры
В рамках выполнения выпускной квалификационной работы необходимо понять,
возможно ли применение платформы Unity
для создания деловых игр. Для этого выделим основные критерии, которые
необходимы при реализации компьютерных деловых игр.
. Основой любой КДИ является сценарий, программы руководителя и
участника и регламент.
. Игра должна быть привлекательной для пользователя, чтобы
сосредотачивать его внимание на себе, для продуктивного обучения.
. Одно из главных преимуществ индивидуальной КДИ является то, что
у пользователя есть возможность установить программу дома.
В работе предполагается, использовать игровые сценарии, которые будут
созданы средствами СКДИ. Реализованы модули СКДИ будут при помощи веб-сервисов,
что ставит перед игровым движком требование поддержки данной службы.
На основе описанных критериев можно провести проверку пригодности
платформы Unity для разработки КДИ.
Для того чтобы задавать необходимые правила взаимодействия внутри игровых
элементов Unity3D использует скрипты - программный код, описывающий эти
правила на языках C# и JavaScript.
.5 Структура игрового движка Unity3D
Благодаря архитектуре игрового движка игры можно создавать для любой
платформы и в случае необходимости легко сменить ее. Это позволит создавать как
настольные, так и мобильные приложения.
Для работы необходимо реализовать визуальное представление игровых
сценариев СКДИ при помощи средств Unity3D, в то время как игровая логика
должна быть реализована при помощи веб-сервиса. Для того чтобы понять, возможно
ли выделить игровую логику отдельно от визуальной части, определим какие элементы
отвечают за игровую логику, а какие за визуальное представление [15].
Для того чтобы визуализировать игровые элементы движок использует GameObject. В случае с 3D игрой это могут быть геометрические
фигуры, 3D модели и т.д. В 2D играх используются Sprites чтобы отобразить игровой объект.
Также Unity обладает элементами UI, которые используются для реализации
пользовательского интерфейса и могут быть одним из ключевых элементов в ходе
разработки компьютерной деловой игры. Для отображения игровых элементов на
экране используется Camera.
Для того чтобы задавать логические связи и правила взаимодействия внутри
игрового мира Unity использует скрипты, которые
описываются при помощи высокоуровневого языка программирования C# или JavaScript. При помощи скриптов можно задавать
как порядок действий на сцене, так и правила по которым будут взаимодействовать
друг с другом и с игроком игровые элементы.
Также при помощи скриптов игровой движок позволяет взаимодействовать с
реляционными базами данных, такими как Microsoft SQL Server а также позволит взаимодействовать с управляющими
модулями СКДИ, реализованными с помощью веб-сервисов.
Исходя из возможностей игрового движка, которые были описаны выше, можно
сделать вывод, что Unity обладает
необходимым для разработки КДИ функционалом. Также, благодаря структуре
игрового движка, становится возможным разделить визуальную и логическую части
игр, что позволит нам выделить игровую логику отдельно в модуль СКДИ. Движок
является отличным инструментом, который можно использовать для разработки
деловой игры на основе сценариев СКДИ.
Глава
2. Проектирование
подсистемы визуализации деловой игры
В рамках данной работы необходимо разработать подсистему взаимодействия
между логической и визуальной частью ДИ. Для реализации визуальной части
используется игровой движок Unity3D. Выделим основные функции, за
которые будет отвечать движок. В первую очередь игровой движок будет
отрисовывать все элементы и сцены внутри игры. Также при помощи
высокоуровневого языка программирования C# зададим основные правила взаимодействия игровых элементов в
сцене, их свойства и характеристики, эти свойства не будут меняться в рамках
игры.
В отличие от других компьютерных игр, где игровая логика прописана на
игровом движке и находится внутри игры, в работе за игровую логику будет
отвечать СКДИ. Веб-сервис, на котором планируется реализовать СКДИ, будет брать
модель бизнес-процесса и, основываясь на ней, создавать игровые сценарии.
Игровой сценарий должен хранить в себе игровую логику, правила взаимодействий
игрока с игровыми предметами, свойства игровых сцен и предметы в них.
.1 Проектирование подсистемы
взаимодействия подсистемы визуализации и СКДИ
В работе необходимо создать подсистему взаимодействия между веб-сервисом
СКДИ и визуальной частью игры. Проблема заключается в том, что сценарии СКДИ
должны быть представлены в виде строки на языке логический схем алгоритмов
(ЛСА), в то время как Unity
располагает своими сущностями, сценами и объектами в сцене.
Для взаимодействия визуальной части деловой игры и для проведения деловой
игры СКДИ предлагается использовать зашифрованную шестнадцатеричную
строку-взаимодействия. Строка-взаимодействия должна хранить информацию об одном
или нескольких ресурсах, их свойствах и задачах, которые необходимо
визуализировать для обучающегося в игре.
2.2 Описание требований к подсистеме
взаимодействия
Для того чтобы два модуля могли взаимодействовать друг с другом
необходимо сформировать структуру, которую можно будет использовать как при
кодировании, так и при декодировании сообщений между СКДИ и подсистемой
визуализации:
. При совершении игроком действия должна посылаться информация об
этом действии в СКДИ.
. При изменении свойств игровых объектов, происшествии каких либо
событий, должна посылаться информация об этом в СКДИ.
. При изменении свойств или параметров ресурсов в СКДИ, должна
посылаться информация игровому движку об изменениях у тех или иных объектов, с
параметрами для них.
. При изменении игровой сцены в СКДИ, должна посылаться информация
об изменении и состоянии игровой сцены которую необходимо применить в игровом
движке.
Для пересылки информации будет использоваться шестнадцатеричная
строка-взаимодействия.
.3 Спецификация прецедентов
На основе сформированных функциональных требований выделим прецеденты:
. Передать информацию в СКДИ от подсистемы визуализации о ресурсе.
. Передать информацию в подсистему визуализации от СКДИ о ресурсе.
. Передать информацию в СКДИ от подсистемы визуализации о
произошедшем в сцене событии.
. Передать информацию в подсистему визуализации от СКДИ о
произошедшем в сцене событии.
. Передать информацию в СКДИ от подсистемы визуализации о сцене.
. Передать информацию в подсистему визуализации от СКДИ о сцене.
Главной целью системы взаимодействия между подсистемы визуализации и СКДИ
является передача информации между двумя визуальной частью и логической частью
деловой игры.
2.4 Проектирование структуры
строки-взаимодействия
Как видно из выделенных нами прецедентов при помощи строки нам необходимо
передавать информацию о трех сущностях: сцена, ресурс и событие. На основе
выделенных сущностей будем делить строку на три типа: строка с информацией о
сцене; строка с информацией о ресурсе; строка с информацией о событии. Исходя
из этого, сформируем структуру данной строки, для взаимодействия СКДИ и
подсистемы визуализации между собой.
Первоначально разделим строку на две структурные части:
. Первая часть. Информационная часть.
. Вторая часть. Параметризованная часть.
Первая часть строки будет нести общую информацию о типе и количестве
взаимодействий данного типа, которые описаны в этой строке. На основе этого,
можем сформировать первую часть строки. Для определения типа выделим один
символ в строке, для определения количества взаимодействий выделим два символа,
что позволит нам в одной строке описывать до двухсот пятидесяти шести
взаимодействий одного типа. Закодируем типы взаимодействия следующим образом: 0
- сцена, 1 - ресурс, 2 - событие. Пример представлена в табл.2.1. В данной
строке закодировано, что строка хранит информацию о десяти событиях.
Таблица 2.1 Пример первой части строки-взаимодействия
|
Тип взаимодействия
|
Количество взаимодействий
|
|
2
|
0
|
A
|
Ограничением для строки будет является то, что в одной
строке-взаимодействия может храниться информация только об одном типе
взаимодействий.
Для того чтобы сформировать вторую часть строки необходимо определить
какие параметры должны в ней храниться. Так как в одной строке может быть
закодирована информация о нескольких сущностях одного типа, первоначально
необходимо определить к какой сущности относятся параметры. Для этого во второй
части строки первые два символа будут отвечать за кодировку сущности, к которой
относится взаимодействие, будь то игрок или игровой объект.
Следующие два символа строки будут нести информацию о методе, который
необходимо вызвать для сущности или о действии, если тип строки является
событие. Пример второй части строки-взаимодействия представлен в табл.2.2.
Таблица 2.2 Пример второй части строки-взаимодействия
|
Кодировка сущности
|
Кодировка метода/действия
|
|
С
|
6
|
9
|
В
|
|
|
|
|
Так как одна строка может содержать в себе информацию о нескольких
сущностях, следовательно, количество параметризованных частей может меняться в
соответствии с количеством взаимодействий. Пример полной строки-взаимодействия
приведен в табл.2.3.
Таблица 2.3 Пример строки-взаимодействия
|
Тип взаимодействия
|
Количество взаимодействий
|
Кодировка первой сущности
|
Кодировка метода
|
Кодировка второй сущности
|
Кодировка метода
|
|
1
|
0
|
2
|
A
|
4
|
0
|
2
|
D
|
2
|
F
|
D
|
|
|
|
|
|
|
|
|
|
|
|
В приведенном примере строка передаст информацию о двух ресурсах и методах,
которые необходимо применить к ним.
.5 Проектирование архитектуры игры
В работе игра разбита на две части, серверную часть, которая отвечает за
игровую логику и клиентскую, которая отвечает за визуальное представление игры.
За игровую логику будет отвечать модуль СКДИ, который представляет собой
веб-сервис, а за визуальное представление отвечает подсистема визуализации. На
рис.2.1 представлена архитектура взаимодействия двух служб между собой.
Для передачи информации между клиентом и сервером будем использовать
запросы к сервису, и возвращать необходимую информацию обратно клиенту.
.5.1 Серверная часть деловой игры
Веб-сервисом называется программная компонента, предоставляющая сервис
удаленного вызова на основе стандартов WSI(Web Service
Interoperability), основными из которых является
протокол обмена сообщениями SOAP,
язык описания интерфейса WSDL и
HTTP как основной транспортный протокол.
На основе этих стандартов служба ASP.NET
организует сервис удаленного вызова методов объектов. Веб-служба на основе
интерфейса.NET обрабатывает приходящие от клиента
сообщения. После чего веб-сервис вызывает методы объекта с извлеченными из
сообщений параметрами, после чего возвращает сообщение с результатом выполнения
метода. Описание функциональности веб-сервиса производится на C#.
Для того чтобы управлять элементами визуальной части согласно игровому
сценарию и логике игры, которая установлена в СКДИ будут вызваны методы веб-сервиса.
Методы, которые включает в себя веб-сервис, будут отвечать не только за
передачу и получение сообщений от клиента, но и устанавливать параметры для
сцен, ресурсов и событий для деловой игры.
.5.2 Клиентская часть деловой игры
Для того чтобы в игре, которую обозначили как клиент, реализовать
взаимодействие с веб-сервисом и игровыми методами будем использовать запросы к
веб-сервису. По запросам, которые подсистема визуализации будет отправлять,
будет возвращаться ответ с результатами выполнения методов.
Для того чтобы получать и обрабатывать данные от веб-сервиса нам
понадобится класс GameManager. С его
помощью становится возможным реализовать управление игровыми объектами на
основе информации переданной с веб-сервиса. Кроме этого нам понадобится создать
вспомогательный класс, который назовем NetworkService. Он будет выполнять функцию
посредника между клиентом и веб-сервисом. NetworkService необходим для того, чтобы
обрабатывать данные подключения к веб-сервису и создавать запросы.
GameManager будет обращаться к NetworkServic, чтобы тот в свою очередь будет совершал запросы к сервису, и возвращал
от него ответы. Структура взаимодействия между GameManager и NetworkServic показана на рис.2.2.
Рисунок 2.2 Структура клиентской части
Для того чтобы обращаться к веб-сервису используется встроенный в Unity класс WWW. С его помощью возможно создавать запросы к сервису.
Для этого будем вызывать объекты класса WWW, используя url-адрес сервиса, после чего будем посылать запрос по этому адресу.
Также в работе будет использоваться функция Coroutine, это позволит работать с классом WWW в фоновом режиме, для того чтобы
ожидать ответа от сервиса. Coroutine является специальной функцией, которая позволяет работать в фоновом
режиме программы или в цикле.
Глава
3. Реализация подсистемы
взаимодействия на примере компьютерной деловой игры «Проезд перекрестка»
В рамках данной главы описаны этапы реализации веб-сервиса СКДИ,
подсистемы визуализации при помощи игрового движка Unity3D. Также
описано проектирование и разработка деловой игры «Проезд перекрестка».
.1 Реализация сервиса СКДИ
Для работы ключевым требованием было реализовать возможность
взаимодействия игры на Unity
с WCF сервисом. Также необходимо чтобы
управление игрой было извне, на стороне сервиса. Для реализации WCF сервиса, с
которым будет связываться деловая игра, используется Visual Studio Community 2015. Для начала создаем проект WCF Service Application и назовем его CBGS (рис.3.1).
Рисунок 3.1 Создание проекта WCF сервиса
Для того чтобы реализовать связь с сервисом изменим файл IService как показано на рис.3.2. Также
создадим метод GameCall в файле Service1.
Рисунок 3.2 Связь с сервисом
В качестве переменных в метод будет посылаться строка-взаимодействия. Для
того чтобы сервис мог ее распознавать необходимо разделить ее на составные
части. Это позволит распознавать тип взаимодействия, который передается в
строке-взаимодействия, количество взаимодействий и сами сущности которые
закодированы в ней. Для этого создадим метод Parse, который будем использовать как в сервисе, так и в
подсистеме визуализации для разделения строки-взаимодействия на смысловые
части. Часть метода Parse представлена
на рис.3.3.
Рисунок 3.3 Метод Parse
В методе Parse на вход
получаем строковую переменную и перебираем ее по символам. Символы в этой
строке записываем в char массив для
того чтобы потом выделить необходимые нам элементы строки: тип взаимодействия,
количество и сущности.
После того как строка будет расшифрована необходимо чтобы сервис
определил как реагировать на то что содержала в себе строка и на основе
сценария игры сформировать ответ. Как было описано ранее в работе, строка-взаимодействия
может быть трех типов: сцена, ресурс и событие. Основываясь на этом, в основном
методе будет три случая, по которым будет формироваться ответ клиентской части
игры.
Так как сценарий игры и порядок действий в СКДИ формируется при помощи языка
ЛСА, то для того чтобы продвигаться по игровому сценарию в качестве ответа от
клиентской части будет ожидаться состояния ресурсов, а в ответ будет возвращены
сцены игры, которые необходимо отобразить игроку. В случае если тип
строки-взаимодействия будет ресурс, то сервис сопоставит ресурсы и их состояния
с тем, которые описаны в ЛСА.
Если запустить WCF-сервис
при помощи средства Test Client то можно увидеть, что клиенту
доступен метод GameCall, а сам
сервис расположен на localhost.
Рисунок 3.4 Test Client
.2 Реализация клиентской части игры в
подсистеме визуализации
.2.1 Настройка проекта в подсистеме
визуализации
Для выполнения работы было использовано Unity3D
5.6.0f3 personal edition. Создадим для игры 2D проект и назовем его Driving test.
Для того чтобы организовать взаимодействие между подсистемой визуализации
и WCF сервисом прежде всего необходимо
сгенерировать прокси-класс. Для этого используется инструмент svcutil. Для того чтобы его использовать
необходимо открыть папку, в которой в которой установлен Unity и пройти по следующему пути:
…Editor\Data\Mono\lib\mono\2.0. В этой папке должен быть расположен файл svcutil.exe. После чего необходимо запустить командную строку от
имени администратора и ввести следующую команду: (путь в папку в которой
установлен Unity)
…\Editor\Data\Mono\lib\mono\2.0\svcutil -out:CBGSClient.cs #"896569.files/image008.jpg">
Рисунок 3.5 Создание проекта Unity
Рисунок 3.6 Генерация прокси класса
После этого будет сгенерирован файл «CBGSClient.cs» в папке, которая указана в командной строке. Этот файл и
будет прокси-классом для Unity.
Также необходимо настроить проект в Unity и изменить режим совместимости.
Для этого пройдем по следующему пути: (File → Build Settings → Player Setting), выберем «OtherSettings» и установим в поле «API Compatibility Level» на.NET 2.0 (рис.3.7).
Рисунок 3.7 Настройка совместимости проекта
Также в проекте необходимо создать папку «Plugin» и скопировать в нее файл «System.ServiceModel.dll»,
который расположен в папке: …Editor\Data\Mono\lib\mono\2.0. Также создадим
папку «Scripts» и скопируем в нее файл «CBGSClient.cs» (рис.3.8).
Для вызова методов сервиса создадим скрипт «NetworkService», создадим пустой игровой объект и
прикрепим скрипт к нему и назовем. Назовем созданный нами игровой объект «GameManager». Часть скрипта представлено на
рис.3.9.
Рисунок 3.8 Иерархия проекта
Рисунок 3.9 NetworkService
Как видно выше, скрипт содержит в себе два метода. «Send2Service» необходим для того чтобы вызывать его из других
скриптов и отправлять строку-взаимодействия на WCF-сервис. Для того чтобы избежать зависания программы,
во время ожидания ответа от сервиса, используется Coroutine, которая вызывается из метода «Send2Service».
.2.2 Организация игровых сцен
Для игры создали четыре основные игровые сцена: MainMenu, GameScene, GameWin и GameLose (рис.3.10).
Рисунок 3.10 Сцены проекта
Сцены GameWin и GameLose используются для того, чтобы
отображать игроку, когда тот прошел игру либо наоборот проиграл, нарушив
правила. Игровая сцена MainMenu необходима для того чтобы игрок мог запустить и начать играть. В сцене
же GameScene и будет проходить вся игра.
Для того чтобы игру можно было запустить необходимо добавить все сцены в
сборку игры. Первой сценой, которую будет видеть игрок, сделаем игровую сцену MainMenu. Для этого расположим ее первой в
окне сборки игры.
Рисунок 3.11 Добавление сцен в сборку проекта
3.2.3
Реализация кодирования и
декодирования строки-взаимодействия
Создадим для игры скрипт «GameManager» и прикрепим его к одноименному игровому объекту. Этот скрипт необходим
нам для того чтобы организовывать внутри игровое взаимодействие.
Двумя основными методами данного скрипта можно считать методы «Encrypt» и «Decrypt». Они позволят кодировать и декодировать
строку-взаимодействия для того чтобы общаться с WCF сервисом. Для того чтобы вызывать методы шифрования и
дешифрования из других скриптов сделаем их public. Также проинициализируем сам класс GameManager. Для этого напишем следующий код
(рис.3.12).
Рисунок 3.12 Инициализация класса GameManager
Теперь, когда проинициализировали класс «GameManager» можем вызывать его методы из других
скриптов. Пример такого вызова представлен на рис.3.13
Рисунок 3.13 Пример вызова метода
Для того чтобы формировать строку-взаимодействия в методе Encrypt создадим несколько переменных,
которые будут хранить ID
ресурсов, их состояние (выбран ресурс или не выбран) и тип сообщения который
необходимо сформировать.
По ходу игры состояние переменных будет постоянно обновляться. Когда
будем вызывать метод Encrypt,
то в нем из этих переменных будет сформирована строка, которую и будем
передавать в метод Send2Service в качестве свойства.
Метод Decrypt будем вызывать только из скрипта NetworkService, когда будем получать сообщение от
сервиса. Для того чтобы дешифровать сообщение, также как и в WCF сервисе будем использовать метод Parse. Также как и в методе GameCall в зависимости от типа сообщения и
свойств, которые в нем переданы игре будет необходимо совершить ряд действий
или присвоить состояния переменным. На рис.3.14 представлена часть метода. К
примеру, если тип переданного сообщения будет «сцена», а ID ресурса будет «00», то будет вызван
метод ShowScene, который отобразить игроку сцену с
соответствующим названием.
Рисунок 3.14 Дешифратор
.3 Реализация деловой игры «Проезд
перекрестка»
.3.1 Описание бизнес-процесса «Проезд
перекрестка»
Для данной работы взят бизнес-процесс «Проезд перекрестка». Целью данного
процесса является проезд перекрестка со светофором на машине. Светофор на
перекрестке может принимать два состояния, состояние, когда горит красный свет
и состояние когда горит зеленый свет. Еще одним элементом игры является машина
на перекрестке. Она также как и светофор может иметь два состояния: автомобиль
стоит и автомобиль едет. Пользователем данного процесса является игрок, он
управляет автомобилем.
Для того чтобы начать игровую сессию игроку необходимо запустить игру,
после чего СКДИ сформирует игровой сценарий. После этого подсистема
визуализации, согласно сценарию, отобразить сцену игроку. Взаимодействия
пользователя с игрой начинается после того, как СКДИ посылает сценарий сцены игроку.
Для игры опишем основные элементы в сцене и состояния, которые они могут
принимать. В качестве игровых ресурсов, как было сказано выше у нас выступают
машина и светофор. В табл.3.1 представлены состояния, которые могут принимать
ресурсы.
Таблица 3.1 Возможные состояния ресурсов
|
Ресурс
|
Состояние 1
|
Состояние 2
|
|
Светофор
|
Горит зеленый свет
|
|
Автомобиль
|
Стоит на месте
|
Едет через перекресток
|
Опишем для сцены все возможные состояния, которые на ней могут принимать
ресурсы (табл.3.2).
Таблица 3.2 Возможные состояния сцены
|
Номер состояния сцены
|
Состояние светофора
|
Состояние машины
|
|
1
|
Красный свет
|
Стоит
|
|
2
|
Красный свет
|
Едет
|
|
3
|
Зеленый свет
|
Стоит
|
|
4
|
Зеленый свет
|
Едет
|
Для того чтобы представить процесс «Проезд перекрестка» будем использовать
диаграмму активности (рис.3.15).
После того как игрок запускает игру, СКДИ формирует игровую сцену и
задает состояния для ее ресурсов, автомобиля и светофора. В начале игры сцена
принимает первое состояние, автомобиль стоит, горит красный свет.
После этого подсистема визуализации отображает игровую сцену игроку. Если
игрок нажимает на кнопку «Вперед», СКДИ изменяет состояние ресурсов на сцене и
посылает сигнал в подсистему визуализации. Сцена принимает второе состояние,
при котором горит красный свет и автомобиль едет. После этого сеанс игры
завершается и игрок получает сообщение, что он нарушил правила. Если игрок не
совершает действий, то по истечению таймера СКДИ изменяет состояние сцены и
посылает сигнал в Unity. Сцена
принимает третье состояние. Если игрок нажимает кнопку «Ехать», то СКДИ
получает сигнал от Unity, после чего
изменяет состояние сцены на четвертое и посылает сигнал в подсистему
визуализации. После этого игрок получает сообщение, что он успешно справился с
заданием. Если игрок бездействовал, то по истечению таймера СКДИ снова изменяет
состояние сцены на первое и посылает сигнал в подсистему визуализации, после
чего последовательность повторяется до тех пор, пока не придет в конечную
точку.
Рисунок 3.15 Диаграмма активности
На рис.3.16 представлена диаграмма последовательности. Диаграмма позволит
определить сообщения, которые передаются между объектами и очередность событий.
Рисунок 3.16 Диаграмма последовательности
.3.2 Проектирование визуального
представления игры
Для реализации деловой игры необходимо будет создать игровую сцену, на
которой будет происходить основное действие игры. Ключевыми элементами на ней
будут являться кнопки управления, автомобиль и светофор. Разработанный прототип
светофора представлен на рис. 3.17.
Рисунок 3.17 Прототип светофора
Игровой элемент светофор согласно выделенным нами ранее свойствам может
принимать два состояния, когда горит красный свет и когда горит зеленый свет,
для этого создали два состояния для каждого из цвета светофора, которые можно
будет изменить согласно сценарию.
Как видно на рис.3.18 представлен прототип игрового уровня. На нем будет
один элемент управления кнопка. С ее помощью игрок сможет управлять
автомобилем.
Рисунок 3.18 Прототип игрового уровня
В игре игроку предстоит управлять автомобилем, который будет ехать по
дороге и сталкиваться с различными препятствиями. Для этого в сцене GameScene сформируем начальную игровую сцену и
создадим ключевые объекты.
3.3.3
Создание игрового объект
«Машина»
Так как игрок будет управлять автомобилем, добавим в сцену пустой игровой
объект и назовем его Car. В
компонент Sprite Render добавим объекту спрайт автомобиля. Добавим объекту
компонент Box Collider и отметим галкой свойство Is Trigger. Также добавим компонент Rigidbody 2D и выставим свойство Body Type на Kinematic. Для того чтобы можно было реализовать движение объекта в пространстве
добавим скрипт CarScript
(рис.3.19).
Рисунок 3.19 Создание игрового объекта автомобиль
В игре автомобиль сможет ехать вперед по дороге и стоять на месте. За
движение машины будет отвечать метод Ride (рис.3.20).
Рисунок 3.20 Скрипт Ride
Этот метод будет вызываться в стандартном методе Update каждый кадр и в зависимости от того, какое состояние
сейчас имеет ресурс автомобиль, машина будет либо стоять, либо ехать.
.3.4 Создание пустой дороги
В то время пока игрок не встречает на пути препятствия, он будет ехать по
пустой дороге. Для того чтобы реализовать пустую дорогу создадим игровой объект
и назовем его emptyRoad. Он будет включать в себя два
элемента, фон и пустой игровой объект, который расположен на конце дороги (рис.3.21).
Рисунок 3.21 Создание объекта «Пустая дорога»
Пустой игровой объект назовем EndPoint и он понадобится для того, чтобы формировать бесконечную
дорогу. К самому объекту emptyRoad добавим элементы Rigidbody, BoxCollider2D и RoadScript (рис.3.22).
Рисунок 3.22 Настройка объекта «Пустая дорога»
Скрипт RoadScript нам нужен для того, чтобы, когда
игрок задевал область BoxCollider. перед игроком создавалась следующая часть дороги и таким образом не
обрывалась пустотой (рис.3.23).
Рисунок 3.23 Создание дороги
На рис.3.23 показан вызов метода SpawnRoad, который и будет отвечать за
создание нового участка дороги перед игроком. Подробнее создание бесконечной
трассы будет описано дальше в работе.
.3.5 Создание события «Светофор»
Одним из ключевых событий игры, с которым предстоит встретиться игроку,
будет проезд светофора. Для этого представим в виде схемы само событие. Как
видно на рис.3.24 проезд перекрестка состоит из двух возможных состояний
светофора: если горит красный светофор или если горит зеленый светофор.
Рисунок 3.24 Возможные состояния светофора
Игрок может подъехать к переезду в любой из двух состояний светофора. И в
каждой ситуации ему предстоит принять решение. На рис.3.25 представлено
событие, когда горит красный светофор. В таком случае в точке принятия решения
игрок может проехать светофор и тогда он совершит ошибку, а если остановится,
то сделает все правильно.
Рисунок 3.25 Горит красный свет
На рис.3.26 представлена схема события, когда горит зеленый светофор. На
ней видно, что если игрок будет стоять на перекрестке с включенным зеленым
светофором, то он совершит ошибку, а в случае если проедет перекресток,
совершит правильное действие.
Рисунок 3.26 Горит зеленый свет
3.3.6
Реализация проезда
светофора в подсистеме визуализации
Для того чтобы реализовать описанную выше схему возьмем за основу уже созданную
пустую дорогу и переименуем ее в tlRoad.
Немного изменим внешний вид и создадим еще один пустой объект, который назовем
TrafficLight. Он будет включать в себя два света, между которыми будет
переключаться. Для того чтобы реализовать переключения света светофора добавим
игровому объекту элемент скрипт и назовем его TrafficLight. В этом скрипте
будет выполняться переключение между красным и зеленым светом светофора. Для
того чтобы хранить информацию о состоянии светофора создадим переменную activeLight, которая будет принимать значение
«0», когда горит красный свет и «1», когда светофор горит зеленым светом.
Значение этой переменной
будем передавать в
качестве состояния ресурса «светофор». На
рис.3.27 представлен метод, который отвечает за переключение света. Метод ChangeColor будет вызван сначала при появлении
светофора в игре, для того чтобы установить тот или иной свет, а потом каждые
10 секунд, чтобы изменить свет на противоположный.
Рисунок 3.27 Скрипт изменения света светофора
Также добавим к игровому объекту элемент BoxCollider2D и пометим его на уровне со светофором. Он будет отслеживать
стоит игрок перед светофором или он проехал мимо (рис.3.28).
Рисунок 3.28 Область принятия решения
Область BoxCollider2D и будет выступать в качестве точки принятия решения. Для
этого в скрипт TrafficLight
добавим два контролера, которые будут реагировать, когда игрок подъедет к
светофору и когда проедет мимо. После того как игрок подъедет к светофору будет
запущен таймер, который отслеживает, стоит игрок перед светофором или нет. В
случае если игрок будет стоять перед светофором дольше половины
продолжительности действия сигнала светофора или игрок пересечет светофор, то
будет вызван метод, который инициализирует метод tlController в классе GameManager, чтобы отследить принятое игроком
решение (рис.3.29). В нем тип строки-взаимодействия приравнивают 1, а состояние
ресурса «светофор» становится равно переданному в метод значению, после чего
вызывается метод кодирования сообщения.
Рисунок 3.29 Реакция на проезд светофора
.3.7 Формирование игрового уровня
Для того чтобы формировать дорогу перед игроком будем в классе GameManager создадим массив игровых объектов roadPrefabs, в который добавим пустую дорогу и
дорогу со светофором.
Также нам понадобятся два метода. При вызове метода CreateRoad, будет создано указанное количество
экземпляров объектов дороги всех видов. Следом, в зависимости от вида дороги эти
экземпляры будут добавлены в стек объектов. Такой способ инициализации игровых
объектов позволит нам в начале игры создать необходимое количество экземпляров
и хранить их внутри игры. Такой затрачивает меньше вычислительных мощностей
компьютера в сравнении с созданием каждый раз нового экземпляра игрового
объекта (рис.3.30).
Рисунок 3.30 Создание стека дорог
Второй метод SpawnRoad,
необходим для непосредственного расположения экземпляров дороги перед игроком
(рис.3.31).
Рисунок 3.31 Расположение дорог в игре
Когда игрок будет подъезжать к краю дороги, будет вызван этот метод. В
случае если стеки, в которых находятся экземпляры дорог пустые, будет вызван
метод, чтобы заполнить их. Если в стеках есть экземпляры дорог, то случайным
образом из одного из стеков возьмем экземпляр дороги и расположим его перед
игроком.
Для того чтобы было возможно использовать те экземпляры дорог, мимо
которых уже проехал игрок, тем самым экономя ресурсы компьютера, добавим в
скрипт RoadScript еще один метод, который назовем Recycle (рис.3.32). Этот метод позволит
возвращать уже «использованные» экземпляры дорог обратно в стек. Вместо того,
чтобы их просто уничтожать объект, сможем постоянно использовать уже созданные
ранее экземпляры дорог.
Рисунок 3.32 Повторное использование экземпляров
3.3.8
Отслеживание событий
Так как одной из главных задач работы является возможность реализовать
удаленное управление игрой и игровой логикой, то нам необходимо отслеживать
действия, которые совершает игрок и реагировать на них не напрямую в игре, а
через WCF сервис. Для этого будем использовать
строку-взаимодействия с типом «событие».
Для того чтобы отслеживать нажатие игроком какой либо кнопки на
клавиатуре либо в игре, создадим метод ButtonDown в классе GameManager. В качестве свойства в него будут
передаваться ID нажатой кнопки, после чего будет
вызван метод шифрования (рис.3.33).
Рисунок 3.33 Реакция на нажатие клавиши
К примеру, если будет нажата клавиша «Пробел», то ID клавиши будет равно «01», что
соответствует «Пробелу». В сервисе в ответ будет отправлено сообщение, которое
вызовет метод изменения состояния ресурса «машина». В случае если до этого
автомобиль стоял, он поедет или наоборот.
На примере, разработанной в рамках данной главы, деловой игры «Проезд
перекреста» демонстрируется работоспособность подсистемы взаимодействия.
Подсистема взаимодействия позволяет проводить деловые игры, в подсистеме
визуализации используя игровую логику, которая заложена в веб-сервисе.
Взаимодействия между двумя частями игры производится посредством
строки-взаимодейстия.
Заключение
Подсистема взаимодействия является основным связующим элементом между
игроком и разработанными в СКДИ сценариями. Данная система необходима для
проведения деловых игр на основе сформированных в СКДИ сценариев. Это позволит
вырабатывать у игрока компетенции и впоследствии их измерять.
В ходе работы проведен анализ уже существующих систем визуализации
компьютерных и деловых игр, который послужил основой для разработки требований
к игре и способу взаимодействия между ее элементами. Была спроектирована
подсистема взаимодействия, которая позволяет взаимодействовать логической и
визуальной части игры между собой.
В выпускной квалификационной работе была спроектирована и реализована
деловая игра «Проезд перекрестка». Она была создана при помощи выделенных
средств разработки и с использованием описанных в работе методов взаимодействия.
На примере данной деловой игры была проведена апробация подсистемы
взаимодействия. Описанные в работе средства взаимодействия СКДИ с визуальной
частью могут послужить основой для дальнейшего проектирования и реализации
других подсистем студии.
Библиографический
список
1. Карауылбаев С.К. Особенности применения
учебно-деловых игр в обучении студентов / Мир науки, культуры, образования № 3
(34) 2012.
2. Лаврентьев С.Ю. Интерактивные методы обучения как
средство активизации познавательной активности будущих учителей технологии и
предпринимательства // Комелина В.А. Современные проблемы науки и образования.
- 2011. - №6.; URL: https://www.science-education.ru/ru/article/ view?id=5218
(дата обращения: 10.12.2016).
. Панина Т.С. Современные способы активизации
обучения: Учеб. пособие для студ. высш. учеб. заведений / Т.С. Панина, Л.Н.
Вавилова; 4-е изд., Под ред. Т.С. Паниной. - М.: 2008. - 176 с.
4. Webservices In Unity [Электронный ресурс] // URL: http://wiki.unity3d.com/index.php?title=Webservices_In_Unity (дата
обращения: 10.12.2016)
5. Maria Bielikova, Marko Divecy, Rudolf Kajan,
Peter Jurnecka, L’ubos Omelina (2008) «Automatic generation of adaptive,
educational and multimedia computer games» - Springer-Verlag London Limited
2008, pp. 371-384
. Ulrich Wechselberger «Teaching Me Softly:
Experiences and Reflections on Informal Educational Game Design» -
Springer-Verlag Berlin Heidelberg 2009, pp.90 - 104
. Gwo-Jen Hwang, Han-Yu Sung, Chun-Ming Hung,
Li-Hsueh Yang and Iwen Huang «A knowledge engineering approach to developing
educational computer games for improving students’ differentiating knowledge» -
British Journal of Educational Technology Vol 44, No. 2, 2013, pp. 183-196.
. Richard Moss. The state of educational games
in the Minecraft era [Электронныйресурс]//URL:http://www.gamasutra.com/view/news/283507/The_state_of_educational_games_in_the__Minecraft_era.php.
(дата обращения: 05.12.2016)
9. Карауылбаев С.К. Особенности применения
учебно-деловых игр в обучении студентов / Мир науки, культуры, образования № 3
(34) 2012.
. Занько C.Ф. Игра и учение: теория, практика и перспективы игрового обучения: В 2
ч. - М.: Логос, 1992.
. Геронимус Ю.В. Игра. Модель. Экономика. - М.: Знание,
1989. - 208 с.
12. Кавтарадзе Д.Н. Обучение и игра: введение в активные
методы обучения / Моск. психолого-соц. ин-т. - М.: Флинта, 1998. - 91 с.
. Викентьева О.Л. Концепция Студии Компетентностных
Деловых Игр / Викентьева О.Л., Дерябин А.И., Шестакова Л.В. //Современные
проблемы науки и образования. - 2013. - № 2.; URL: https://www.science-education.ru/ru/article/view?id=8746 (дата обращения: 15.02.2017).
. Язев Ю. ][-обзор: сравниваем топ-6 лучших игровых
движков для программиста// Хакер - 2016 - №213.; URL: https://xakep.ru/2016/10/17/top6-game-engines/ (дата обращения: 20.02.2017).
15. Technologies, U. (2017). Unity - Manual: Unity
User Manual (5.5). // [Электронный ресурс] Docs.unity3d.com.; URL:
https://docs.unity3d.com/Manual/index.html?_ga=1.217506718.980491208.1456416711
(дата обращения: 01.02.2017).