Методологии разработки обучающих игр: метод коллективного проектирования и метод повторного использования поведения

Введение

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

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

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

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

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

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

По выявленным критериям был построен первый прототип симулятора – виртуальная модель центра города Гаага, в которую включены типичные объекты данной области: трамваи, машины, велосипеды, растения и люди. Также в среду включены объекты, отклоняющиеся от нормы: снайпер на крыше дома, человек с ножом в руке и т.п. Цель игры – обнаружить все «ненормальные» объекты за отведенное игровое время.

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

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

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

·     в течение тестирования и после него участники заполняли опросные листы;

·     в течение тестирования наблюдатели фиксировали реакцию и возникающие вопросы участников;

·     после тестирования – финальный брифинг со всеми участниками тестирование, на котором они высказывали свое мнение о прототипах.

Результаты тестирования оказались следующими:

·     пользователи предпочитают упражняться в присутствии инструктора или после проведения инструктажа;

·     для того чтобы упражнения казались наиболее реалистичными, в течение тренировки пользователям важно общение с членами команды;

·     пользователи быстро погружаются в виртуальную среду;

·     для опытных профессионалов реалистичность обстановки оказалась предпочтительнее аутентичности среды.

После анализа процесса разработки и результатов были сделаны следующие выводы:

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

·     Инструктаж. Большинство участников не были ранее знакомы с симуляторами и поэтому оценили наличие инструктажа.

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

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

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

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

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

Повторное использование поведения при разработке приложений виртуальной реальности

Виртуальная реальность (3D Virtual Environment) обеспечивает симуляцию 3D пространства, где пользователи могут взаимодействовать друг с другом в режиме реального времени. Приложения виртуальной реальности могут быть применены для поддержки дистанционного обучения, воспроизведения исторических событий, имитации действий, которые невозможно продемонстрировать без компьютерных вычислений.

Под платформой виртуальной реальности будем понимать набор смоделированных объектов, управляемых поведением. Под поведением здесь понимается существенное изменение состояния в виртуальном пространстве.

В данном разделе обсуждается вопрос о том, можно ли повторно использовать поведение виртуальных объектов [1].

Принцип рассматриваемого подхода заключается в следующем: во-первых, необходимо декомпозировать виртуальное пространство на общие имитационные модули (generic simulation modules) и специфичные модули (application specific modules). Общие имитационные модули обеспечивают контроль, обмен данными и интерфейс событий, в то время как специфичные модули определяют поведение конкретных имитаций. Во-вторых, необходимо интегрировать платформу виртуальной реальности с сервисами, которые делают вышеупомянутые модули доступными для других модулей и скриптов. Подход назван «паттерн проектирования активного контента» (активный контент – контент виртуальной реальности; контент – статическое содержимое и динамическое, активное поведение).

Рисунок 1. Графическое представление подхода

Рассмотрим применение подхода на примере платформы виртуальной реальности OpenSimulation и трех входящих в неё симуляторов: Virtual Fernland, N-Body Visualization и Sort Lab.

OpenSim (OpenSimulation) – широко используемая платформа виртуальной реальности, поддерживающая мультиперспективную визуализацию. Ядро системы представляет собой множество отдельных симуляторов, составляющих интерактивное виртуальное пространство. Каждый симулятор обеспечен своим фреймворком, в котором объединены имитационные механизмы симулятора. Функционал симуляторов может быть расширен за счет дополнительных модулей, которые называются модули области (region modules).

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

Структура Virtual Fernland включает в себя 5 имитационных модулей:

1)  Модуль управления. Генерирует новые растения, которые унаследованы от других растений-родителей.

2)  Модуль грунта. Каждое растение получает информацию о текущем состоянии среды из этого модуля.

3)  Модуль параметров. Обеспечивает растениям наследственность и свои собственные особенности, отличные от родительских.

4)  Модуль визуализации. Изменяет внешний вид растений на основе их геномов.

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

N-Body Visualization: симулятор солнечной системы, созданный для демонстрации силы притяжения. Был разработан для студентов. Основная идея симулятора заключается в том, что в нем можно создать солнечную систему из планет со стабильными орбитами вокруг звезды и наблюдать эффект силы притяжения.

Структура симулятора сводится к двум составляющим:

1)  набор объектов – планеты и солнце. Объекты обеспечены интерфейсом для задания параметров: массы, позиции и скорости движения;

2)  фиксированная шкала времени.

Sort Lab: симулятор, созданный для наглядной демонстрации студентам классического алгоритма сортировки (быстрая сортировка): объекты – маленькие шарики – сортируются, передвигаясь по сортировочному пространству.

Его структура сводится всего к одному модулю с 4 функциями:

1)  Функция для объявления параметров (количество объектов для сортировки).

2)  Функция для контроля имитации сортировки (отсюда вызывается метод сортировки).

3)  Функция, реализующая алгоритм быстрой сортировки.

4)  Функция, обращающаяся к Сцене и изменяющая её состояние (создание/удаление объектов, изменение позиции объектов и т.д.).

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

·     Поведения и объекты зачастую жестко закодированы (закодированы таким образом, что обращаться к функциям из сторонних приложений просто невозможно) и специфичны (application specific).

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

·     У платформ виртуальной реальности, как правило, нет поддержки инфраструктуры для обмена и повторного использования поведения (т.е. нет библиотек).

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

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

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

Повторное использование поведения сортировки: во-первых, создали следующие методы: AddSortElement (добавление элементов), SotrConfig (настройка параметров) и SortControl (контроль сортировки). Далее для обеспечения повторного использования поведения необходимо следующее:

·     определить пространство для сортировки. Любой объект в этом пространстве будет вызываться с помощью AddSortElement;

·     настроить параметры сортировки с помощью SortConfig;

·     объекты сортировки попадают в пространство сортировки путем вызова SortControl.

Таким образом, все объекты в сортируемом пространстве будут подчиняться поведению (сортировке).

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

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

·     определить эволюционное пространство, где создаваемые объекты будут становиться виртуальными организмами;

·     настроить поведение организмов: задать жизненный цикл, генетическую расположенность и взаимоотношения с другими типами объектов;

·     отправить объекты в эволюционное пространство и позволить им начать взаимодействовать друг с другом.

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

Заключение

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