Особенности разработки механики видеоигры с голосовым управлением

Компьютерная игра, или видеоигра (англ. video game) — вид игровой деятельности, в которой присутствуют мультимедийные технологии, а также технологии виртуальной реальности [1]. Другими словами, видеоигра является электронной игрой, которая базируется на взаимодействии человека и устройства посредством визуального интерфейса, например, телевизора или монитора компьютера.

Видеоигра включает в себя следующие аспекты [2]:

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

В СПбГУПТД на кафедре информационных и управляющих систем разработана и реализована логика видеоигры на игровом движке Unity с голосовым управлением на базе API pocketsphinx. Сформирована концепция игры, описаны условия проигрыша и выигрыша для игрока, содержимое игры, продумано приложение голосового управления в игре. Разработанная игровая механика успешно реализована и создана демо-сцена с использованием голосового управления.

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

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

• Игровой движок (англ. game engine) — это центральный программный компонент компьютерных и видеоигр и других интерактивных приложений с графикой, обрабатываемой в реальном времени [3, 4]. Он обеспечивает основные технологии, упрощает разработку и часто даёт игре возможность запускаться на нескольких платформах, таких как игровые консоли и настольные операционные системы, например, GNU/Linux, Mac OS X и Microsoft Windows. Для маленьких игр (например, «Косынка») наличие движка необязательно, но для игр, соответствующих современным требованиям, сложность разработки игры без движка огромна и ее отладка и расширение крайне затруднены, и потому наличие движка считается само собой разумеющимся. Возможна как разработка движка с нуля, так и использование существующего;
• Визуальный и аудио-контент: модели, текстуры, анимации, музыка, звуки. В последствии проект будет передан дизайнеру, а на момент разработки будет использован контент, выложенный в открытый доступ.
• Модуль для голосового управления в рамках выбранного способа голосового управления (анализ уровня микрофона, распознавание речи или другие). Для простых вариантов голосового управления допустимо создание модуля с нуля, однако, например, для распознавания речи может быть более обосновано использование существующих API.

Реализация включает в себя следующие задачи:

• Разработка концепции механики игры, постановка цели игрока, его задач и средств, описание архитектуры игры;
• Создание скриптов для взаимодействия с игровыми объектами и модулем голосового управления;
• Разработка структуры игровых уровней, создание схемы и реализации игрового уровня.

Рассмотрим основные этапы работы над проектом.

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

Условиями проигрыша являются: падение; полное израсходование маны при отсутствии магик на сцене; попадание в ядовитый коридор.

Условием выигрыша является нахождение и достижение финальной зоны. Время прохождение уровня — от 3 до 10 минут в зависимости от сложности. Время прохождение тестового уровня — 3 минуты.

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

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

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

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

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

Интерфейс содержит следующие элементы:

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

Большая часть визуального контента была найдена среди ассетов, выложенных в открытый доступ, часть была нарисована с использованием графического пакета PaintToolsSAI2 и 3D редактора Blender.

В качестве основы скрипта для управления персонажем были взяты скрипты ThirdPersonCharacter и ThirdPersonUserControl из стандартного Unity ассета. Для управления камерой был написан скрипт CameraController (рис. 1), обеспечивающий движение камеры вслед за персонажем, и позволяющим вращать камеру вокруг него. Скрипт имеет поле Transform, которому назначается персонаж (в данном случае, объект, дочерний персонажу), а также поля, позволяющие регулировать скорость поворота и дистанцию камеры. Скрипт ThirdPersonUserControl уже имеет код, разворачивающий героя в направлении, куда смотрит камера, при движении.

 
Рисунок 1 — Скрипт CameraController

Скрипт, отвечающий за управление магией, является самым объемным из всех написанных. В функции Update вызывается функция CheckKeyboardSpell, при нажатии клавиш вызывающая функцию Attack с кодом заклинания в качестве аргумента (рис. 2).

Рисунок 2 — Вызов и реализация функции CheckKeyboardSpell

 

Функция Attack принимает на вход индекс заклинания. Заклинание выполняется в случае, если выполняются три условия: мана игрока еще не закончилась, в данный момент не воспроизводится анимация (подразумевается анимация атаки) и истекло время блокировки магии (currentRelax). Последний параметр является издержкой особенностей бесплатной версии API Watson и необходим для избежания многократных срабатываний. В аниматор героя, передается триггер «Attack», провоцирующий переход в анимацию из любого состояния, и индекс вызванного заклинания. Устанавливается таймер анимации.

Функция Prepare предназначена для API, требующих соединения с интернетом, то есть, имеющих задержку. Она позволяет начать анимацию подготовки к заклинанию заранее, чтобы вызвать ее до отправки запроса распознавания на сервер. Когда ответ будет получен, будет вызвана FireBall, завершающая вызов заклинания. Если функция не будет вызвана за время, назначенное в переменной prepareTimer, то Animator перейдет в анимацию неудачного заклинания. Функция FireBall воспроизводит звук заклинания, выбирает префаб, соответствующий заклинанию, создает его на сцене и вызывает функцию Destroy, которая разрушит экземпляр через 5 секунд, а также уменьшает количество маны. Для всех заклинаний, кроме пятого, для компонента Rigidbody вызывается функция AddForce — таким образом, заклинания «летят» вперед. Пятому заклинанию соответствует Gust (волшебный прыжок), которое применяется «на себя», а потому не должно перемещаться. Для этого заклинания вызывается функция MagicJump и увеличивается показатель опыта. Для остальных заклинаний для увеличения опыта не вызвается, поскольку опыт повышается только в случае «успешного» применения заклинания — когда заклинание зажжет лампу или разобьет контейнер. Для заклинания Gust нет критерия успешности, поэтому опыт дается в любом случае.

Префаб заклинания представляет собой объект, содержащий компонент ParticleSystem, отвечающий за его визуальное отображение, и Rigidbody, позволяющий применять к объекту силу через функцию AddForce, а также скрипт Fireball, уничтожающий объект при пересечении других объектов или столкновении с ними. Префаб не содержит на себе скриптов, целевые объекты определяют предназначенные для них заклинания по названию экземпляра заклинания: оно всегда содержит в себе строку «AttackN», где N — индекс заклинания.

Функция MagicJump реализует действие заклинания магического прыжка. Назначается таймер, и множитель скорости движения и сила прыжка увеличиваются.

Компонент ExpController отвечает за опыт игрока и контролирует шкалу опыта. В функции Update (рис. 3) контролируется размер шкалы способом аналогичным тому, как контролируется шкала маны. В текстовые поля также вносится информация о текущем уровне игрока и количестве доступных очков навыков.

Функции AddSpellExp и AddCrystallExp вызываются, соответственно, объектами, активируемыми заклинаниями (кроме заклинания магического прыжка) и кристаллами опыта. В каждой функции вызывается также функция CheckLevel, вызывающая функцию LevelUp, если количество опыта превысит единицу.

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

Этот компонент отвечает за управление общими игровыми процессами, условиями выхода из сцены и другое. В функции Update (рис. 4) вызываются функции выхода из игры ExitGame, перезапуска уровня (смерти игрока) Death, а также переключение на отображение подсказок по заклинаниям ShowSpellWindow.

Рисунок 4 — Функция Update скрипта GameController

 

В функции Death в объект Text пишется строка с причиной «смерти», если была передана, после чего вызывается функция Death в контроллере персонажа, а затем запускается корутина DeathCoroutine. Функция Death в контроллере персонажа отключает для него действие гравитации, включает триггер в аниматоре для запуска анимации смерти, и назначает переменную dying, которая заблокирует возможность управления персонажем (но не камерой). В корутине DeathCoroutine после задержки, необходимой для анимации смети, сцена перезагружается.

Функция ShowSpellWindow (отображает или скрывает окно с подсказками заклинаний, а вызываемая внутри нее функция GUIMode соответственно ставит игровое время на паузу во время отображения окна подсказки, а когда оно скрыто, блокирует курсор в центре экрана.

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

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

 

Рисунок 5 — Общая структура кода воздействуемых компонентов

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

Алгоритм воздействуемых объектов представлен на рисунке 6.

 

Рисунок 6 — Общая структура кода воздействуемых компонентов

Остальные скрипты реализуют действие оставшихся объектов. Скрипт DeathButtom (рис. 7) вызывает метод Death объекта GameController.

Компонент EndMark вызывает метод EndLevel компонента GameController, после чего уничтожает объект, содержащий этот компонент. Скрипт Magicka при инициализации увеличивает счетчик не взятых магик в компоненте MagicController. При столкновении с игроком количество маны игрока увеличивается, счетчик не взятых магик уменьшается, объект пропадает, создавая префаб с источником звука, чтобы воспроизвести соответствующий звук.

Скрипт PressurePlate в случае столкновения с игроком телепортирует его в случайную из изначально заданных точек и воспроизводит звук.

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

Конечные модули ничего не знают о модуле, модуль обращается к ним в одностороннем порядке. В данном случае модуль SpeechController обращается к MagicController, и может вызывать в нем методы Attack, Fail и Cancel, означающие вызов заклинания в случае правильного распознавания, анимацию прерывания в случае, если распознанное слово не совпадает с существующими командами, и отмену ожидания заклинания соответственно;

API распознавания речи, в данном случае pocketsphinx или Watson, ничего не знают о SpeechController, но предоставляют событие OnRecognize, наступающее, когда API распознало некоторый результат, и набор публичных методов:

• Init — инициализирует API;
• StartListening — начинает запись, если возможно отделить этот процесс от инициализации;
• StopListening — останавливает запись и/или распознавание;
• GetResult — возвращает распознанную строку;
• Destroy — останавливает необходимые процессы.

Корневой скрипт SpeechController осуществляет непосредственный контроль, запуская или останавливая API и обрабатывая полученную строку. Алгоритм представлен на рис. 9.

Рисунок 9 — Алгоритм модуля голосового управления

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

S: стартовая позиция;

E: конечная позиция;

B: контейнеры;

C: кристаллы опыта;

L: темная комната с фонарем;

P: нажимная плита;

T: места, куда телепортирует нажимная плита.

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

Коридоры, помимо обычных, могут содержать преграды:

P: отравленный;

D: дверь;

B: куст;

F: пропасть;

H: скрытый коридор.

Для демо-сцены был создан уровень из девяти комнат (рис. 10), содержащий все перечисленные объекты и препятствия по крайней мере однократно, а также содержащий достаточное количество кристаллов опыта, чтобы было возможно перейти на следующий уровень один раз.

 Рисунок 10 — Схема уровня демо-сцены

 

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

Созданная демо-сцена была протестирована на 5 машинах с системами Windows 7 и Windows 10. Для модели языка, построенной только для существующих команд, тестирование показало, что 91% команд распознаются верно для естественного языка (длина слов в среднем 2 слога) и 79% для искусственного языка (длина слов в среднем 3 слога). Однако, распознавание также нередко давало ложноположительные результаты. Для выбранного режима управления это некритично, однако в дальнейшем требуется исследовать успешность распознавания для большого количества команд, от нескольких десятков и выше.

Голосовое управление с помощью CMU Sphinx понижает производительность игры на 5-7 кадров в секунду в сравнении с той же игрой без голосового управления. Стандартный алгоритм pocketsphinx пытается построить строку в каждом кадре, что представляется нерациональным. Возможно, следует пересмотреть исходный код и создать событие OnRecognize внутри исходных библиотек.

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

• Многосложные команды;
• Анализ уровня сигнала микрофона;
• Распознавание эмоций;
• Боевая система с голосовым управлением.

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

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

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

• Создание дизайна и анимации для проекта;
• Вариации каждого объекта: создание комнат и коридоров разных размеров, несколько вариантов каждого объекта, различные реакции: например, растение одного типа восстановится через 10 секунд, второго — через 5;
• Введение системы боя и тестирование возможностей голосового управления в ней;
• Разработка сюжета;
• Создание других уровней с повышением уровня сложности;
• Внедрение многосложных команд;
• Внедрение режима диктовки текста.

Также, следует провести некоторые изменения в коде самих средств Sphinx:

• Более точная информация об ошибках во время поиска и чтения входных файлов;
• Создание события распознавания или иной похожей структуры внутри pocketsphinx.

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