Исследование и разработка образовательной компьютерной игры, управляемой пользовательским программным кодом

Шейдеры делятся на:

1. вершинные;

2. фрагментные (пиксельные);

3. геометрические;

4. вычислительные.

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

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

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

2.4 Постановка задачи

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

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

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

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

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

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

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

3. Практическая часть

3.1 Итоговое описание разрабатываемого проекта

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

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

Процесс изучения можно разбить на стадии:

1. изучение синтаксиса языка;

2. изучение вертексных и фрагментных шейдеров;

3. изучение вычислительных шейдеров.

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

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

Обучающий режим состоит из набора последовательных задач. Данный режим по структуре идентичен большинству аналогов с итеративным игровым циклом. Тематику задач и последовательность изучаемых тем предлагается выработать на основе существующих пособий по изучению языков шейдеров: официальному набору уроков Unity и наиболее популярному учебнику программирования шейдеров "Unity shaders and effects cookbook" [37].

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

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

Рис. 6 Последовательность изучения типов шейдеров

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

3.2 Структуризация задачи

Как упоминалось раньше, разработка игры - комплексный процесс, состоящий из множества подзадач. Для более полного понимания структуры процесса разработки построим дерево целей (Рис. 7). В качестве основы для декомпозиции задачи воспользуемся уровнями модели DPE. Отметим, что задача "Разработка прототипа" не была разбита на подзадачи, так как она затрагивает реализацию практически каждого подпункта уровня дизайна. При этом, непосредственная реализация игровых компонентов в игровом движке достаточно проста, поэтому акцент в работе будет смещён на логическую структуру разрабатываемого приложения.

Рис. 7 Дерево целей задачи на разработку игры

3.3 Разработка правил игры

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

3.3.1 Образовательный режим

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

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

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

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

Задачи можно разделить:

* по способу решения задачи:

* загрузка программы;

* написание части программы;

* манипулирование параметрами;

* по типу задания:

* копирование заданного эффекта;

* создание эффекта по описанию.

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

Задача на копирование заданного эффекта подразумевает следующее условие: дан объект, отрисованный при помощи эталонного шейдера. Задача - повторить этот эффект. Приведено описание критериев, на которые необходимо обратить внимание. Второй тип стиля даёт словесное описание требуемого эффекта (например “перекрасить красные объекты в зелёный цвет”). Такая задача может быть задана иносказательно, например как “перевербуйте вражеских воинов”, что по сути означает изменение цвета формы изображённых на экране персонажей. Такая формулировка должна включать подсказку, как конкретно данная задача может быть выполнена.

При прохождении задачи пользователю:

* открывается доступ к следующему уровню;

* выводится информация о количестве попыток, их успешности, допущенных ошибках и темах, которые было бы неплохо повторить.

3.3.2 Соревновательный режим

Правила соревновательного режима базируются на более ранней разработке [38], осуществлённой в процессе обучения.

Игровое поле состоит из 64 клеток, расположенных в виде 8 строк и 8 столбцов. Каждый игрок управляет одним персонажем. Ход персонажа состоит из двух действий -- передвижения и выстрела, выполняющихся строго в этом порядке. Передвижение перемещает персонажа на соседнюю незанятую клетку по вертикали или горизонтали. Выстрел уничтожает объект, находящийся на одной линии с персонажем в одной из сторон. При этом, чтобы объект был уничтожен, между ним и игроком должен находиться другой. Выстрел, в отличие от передвижения, является необязательным действием.

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

Кроме персонажей на поле размещаются и иные игровые объекты -- бочки, камни, деревья и рыба.

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

Камни являются недвижимыми и неуничтожаемыми объектами. В их клетку невозможно войти

Деревья как объекты аналогичны камням за исключением того, что могут быть уничтожены.

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

Данные игровые объекты располагается случайно в зонах, показанных на Рис. 8. В каждой зоне гарантированно есть ровно один объект соответствующего типа. Персонажи игроков появляются в двух противоположных по диагонали клетках - левой верхней и правой нижней.



Рис. 8 Зоны размещения игровых объектов

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

3.4 Выбор средств разработки

В качестве игрового движка для разработки данной игры был выбран Unity. Это обусловлено тремя основными факторами: бесплатностью, возможность сборки проекта под различные платформы без специальной замены кода, наличием у разработчика опыта работы в этом движке в том числе и с шейдерами. Первоначально использовалась последняя версия 5.4. Однако, оказалось, что Unity не поддерживает компиляцию шейдеров в процессе исполнения программы, а для данного проекта это необходимое условие. Тем не менее, как будет указано позже, есть способ выполнить данную функцию на более ранней версии движка - 4.3.4.

Язык программирования для игровых скриптов зависит от движка, и в данном случае им является C#. Шейдеры в Unity пишутся на Cg и HLSL. Движок поддерживает шейдеры и на GLSL, однако ради кроссплатформенности использования этого языка не рекомендуется.

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

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

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

3.5 Разработка образовательного режима

Игровой цикл разрабатываемого приложения основан на анализе аналогов и представляет собой наиболее популярный тип подачи заданий в виде уровней - итеративный. Сам цикл для единичного уровня представлен на Рис. 9.



Рис. 9 Игровой цикл уровня

В соответствии с моделью ATMSG был проведён анализ данного цикла, представленный в Таблице 4.

Каждый уровень представляет собой собранную сцену в игровом редакторе Unity. Теоретическая справка и окно результатов являются объектами графического интерфейса этой сцены. Более подробно данные объекты описаны в пункте 3.7 Разработка графического интерфейса.

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

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

Таблица 4

Анализ игрового цикла по модели ATMSG

Шейдерная программа написанная пользователем сохраняется как объект в ассетах Unity. Она может быть загружена игроком полностью или создана путём внедрения написанного пользователем фрагмента в заранее созданный код. Полученный шейдер необходимо скомпилировать, прежде чем применять к объекту на сцене. Как было отмечено ранее, Unity не поддерживает компиляцию программ затенения на лету. Тем не менее, до версии 4.5 [39] игровым движком использовался внешний компилятор. Зная его расположения и необходимые параметры, становится возможным вызов процесса компиляции не выходя из игры [40]. По сути, игровой менеджер использует стороннюю программу, чтобы вручную запустить этапы графического конвейера, не доступные обычно. Такой метод, увы, накладывает серьёзные ограничения, однако иных способов реализации требуемого функционала найдено не было.

3.5.1 Проверка пользовательских решений

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

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

Алгоритм проверки решений, заданных программным кодом

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

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

В играх для обучения программированию, как правило, результат работы программы очевиден, игровой элемент либо выполнил свою задачу, либо нет. В случае с шейдерами же результат представляет собой графическое отображение объекта на экране. Шейдер может выполняться успешно, но давать не совсем тот результат, который требовалось. Для контроля работы шейдеров существуют всевозможные программы-анализаторы, по шагам отображающие каждый этап рендера того или иного объекта. Но стоит понимать, что подобные решения рассчитаны на то, что успешность выполнения задачи будет оценена экспертом [37][41]. В обучающей игре же требуется производить проверку автоматически.

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

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

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

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

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

Рис. 10 Передача данных между элементами системы

Общий алгоритм проверки решения представлен на Рис. 11. На вход системе подаются эталонный и пользовательский шейдеры, а также все необходимые параметры для настройки программы-анализатора.



Рис. 11 Алгоритм проверки решения

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

Простейшая тестовая сцена показана на Рис. 12 и представляет собой плоскость, которая отрисована с использованием исследуемого шейдера, точечный источник освещения и ортогональную камеру. К сожалению, на данный момент наличие камеры необходимо для получения изображения, так как функция игрового движка, позволяющая сделать это программно, не работает должным образом. Результат Graphics.Blit() не только не учитывает влияние источников освещения, но и выдаёт чёрную текстуру в шейдерах, не предполагающих взаимодействие со светом. Поэтому в базовую настройку входит настройка камеры и установка в качестве фона однотонного цвета (как правило #00FF00), при этом один из цветовых каналов гарантированно не должен использоваться в итоговой текстуре. Это необходимо для проверки прозрачности объекта в некоторых задачах.

Рис. 12 Простейшая тестовая сцена

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

Классификация параметров проверки шейдеров

Параметры, подлежащие проверке в пользовательских решениях, делятся:

1. по причине потенциальных ошибок:

1.a. связанные с работой программы;

1.b. связанные с логикой шейдера;

2. по влиянию источников света:

2.a. зависимые от освещения;

2.b. независимые от освещения;

3. по логике работы:

3.a. с зависящим от элемента случайности результатом;

3.b. с фиксированным результатом;

4. по наличию анимации:

4.a. динамические;

4.b. статичные;

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

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

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

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

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

Примеры характеристик приведены в Таблице 5.

Таблица 5

Примеры характеристик для анализа шейдеров

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

Формулы расчёта влияний источников освещения зависят непосредственно от выбранной модели. Если какой-либо компонент в модели освещения отсутствует (например, блики), соответствующий параметр приравнивается нулю.

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

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

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

Проверка более ранних этапов также может основываться на текстурах, полученных путём обратного преобразования итога. Сами преобразования зависят от эффектов, создаваемых шейдером по условию задачи. Убирая последовательно простые эффекты (но не составные), можно отследить, на каком этапе происходят ошибки. Ошибочные части устраняются из рассматриваемой текстуры, как в пользовательском варианте, так и в эталоне. Таким образом, на каждом этапе сверки обе текстуры обработаны одинаковым набором эффектов, состоящим исключительно из правильных или непроверенных.

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

* Lambert Diffuse;

* Half-Lambert;

* Blinn-Phong Lighting;

Если проверки работы освещения не выявили конкретную ошибку, считается, что была использована неверная модель освещения, о чём и сообщается пользователю.

Обмен данными между вычислительным шейдером и управляющим скриптом

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

* изображение;

* источник освещения (включающий в себя тип источника, положение, интенсивность, радиус или направление, цвет);

* результат (массив булевых значений, каждое из которых отвечает за соответствие одному из основных критериев проверки).

Скрипт передаёт на вход шейдеру два изображения, полученные на тестовой сцене с использованием эталонного и пользовательского шейдеров при одинаковых условиях. Дополнительно, если требуется, вводится информация обо всех источниках освещения на сцене. Далее скрипт запускает необходимую функцию проверки на вычислительном шейдере. Если это одна из базовых функций (в данной работе базово реализована проверка влияния различных компонентов освещения в модели Lambert Difuse), анализатор возвращает массив оценок проверенных критериев. Если необходимо проверить уникальный для данной задачи параметр, имеющий для своей проверки отдельную функцию, возвращается одно значение. Оно может быть как булевым, так и числовым, если требуется указать пользователю степень допущенной ошибки.

3.6 Разработка соревновательного режима

В качестве правил для соревновательного режима в прототипе разрабатываемой игры выступает разработанная ранее пошаговая стратегическая игра BoardBomb [38]. Игровой цикл и анализ согласно модели ATMSG для соревновательного режима представлены на Рис. 13 и в Таблица 6.

Рис. 13 Игровой цикл соревновательного режима

3.6.1 Основные компоненты соревновательного режима

Управляет данной игрой специальный скрипт-менеджер. Его задачами являются:

* обеспечение соединения между сервером и клиентом;

* формирование игрового поля;

* загрузка программ для управления персонажами;

* обмен информацией с вычислительными шейдерами;

* осуществление, отображение и запись производимых ходов;

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

При помощи компонента Unity Network View организуется связь между двумя компьютерами. Один из них для этого должен стать сервером. Этот выбор осуществляется пользователями. Сервер принимает на себя всю нагрузку, получая программу от клиента, компилируя её и передавая ему уже результат работы - два выбранных алгоритмами хода. Клиент же интерпретирует полученные варианты и отображает процесс игры у себя. Это сделано для того, чтобы снять ограничение клиента и убрать необходимость наличия компилятора на его стороне. В будущем это даст возможность переноса всей системы в глобальную сеть.

Таблица 6

Анализ игрового цикла соревновательного режима по модели ATMSG

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

3.6.2 Ввод и вывод в соревновательном режиме

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

1. пуста;

2. занята Первым игроком;

3. занята Вторым игроком;

4. занята бочкой;

5. занята камнем;

6. занята деревом;

7. в клетке может находится рыба.

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

Разумеется, каждой программе нужно понимать, за какого игрока она отвечает. Данное число (эквивалентное состоянию клетки поля “Клетка занята i-м игроком”) передаётся шейдеру при старте игры до начала всех остальных расчётов.

После обработки, пользовательский алгоритм поведения персонажа должен передавать выбранный вариант хода менеджеру. В свой ход игрок должен переместиться одним из четырёх способов и может выстрелить в одном из четырёх направлений. Таким образом, всего возможно 4*5=20 вариантов хода. Случай пропуска хода возможен в одной единственной ситуации, если персонаж вошёл в клетку с рыбой, и отслеживается менеджером игры. В случае ошибки, если персонаж не может совершить данное действие или программа не выдала за отведённое время выбранный вариант хода, выполняется так называемое действие по умолчанию. Оно заключается в отсутствии выстрела и перехода в клетку, в которой находился персонаж в прошлом ходу, если такое возможно. Если и это не осуществимо, происходит переход в случайную свободную соседнюю клетку. Действие по умолчанию также обрабатывается менеджером и не требует передачи от вычислительного шейдера.

Таким образом, каждому состоянию клетки поля и каждому варианту действия игрока присваивается эквивалентное число. При старте игры вычислительные шейдеры получают одно число, указывающее, к какому игроку относится данная программа. Затем каждый ход им передаётся структура, включающая двумерный массив 8x8 переменных типа half с состоянием игрового поля и две переменных типа bool с состояниями двух игроков. Затем вычислительные шейдеры возвращают переменную типа half, значение которой соответствует одному из вариантов ходов.

Стоит отметить, что передача данных между центральным и графическим процессорами - всегда узкое место в системе. Существует два пути уменьшения количества передаваемых данных в данной игре. Первый заключается в уменьшении разрядности переменных. Безусловно, количество состояний ячеек поля можно описать всего тремя битами. Однако, не считая булевский тип, half (16 разрядов) -- наименьший тип переменных, поддерживаемый языком HLSL. Второй способ основан на том, что состояние игрового поля можно однозначно восстановить из предыдущего состояния и сделанных игроками ходов. В таком случае было бы достаточно передать всего одно число -- ход противника, а в шейдерах хранить данные о прошлом ходе. Данный способ оптимизации был отклонён в связи с желанием сконцентрировать внимание пользователя непосредственно на расчёте хода, исключая потенциальные ошибки, связанные с неправильной интерпретацией нынешнего игрового состояния.

3.7 Разработка графического интерфейса

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

При выборе задания открывается соответствующий ему уровень, реализованный в виде готовой сцены. Уровень состоит из четырёх окон:

* окно теории;

* окно задания;

* окно результатов;

* меню.

Окно теории необходимо для передачи игроку необходимых знаний. Оно состоит из двух основных разделов - заголовка и контента. Заголовок располагается сверху и указывает, к какому уровню необходимы данные теоретические знания. Дополнительно рядом с названием уровня указывается наименование главы. Контент - основное пространство, с которым взаимодействует пользователь. В его левой части расположен необходимый текст теории. Для оформления текста используется встроенная поддержка графическим интерфейсом Unity "обогащенного" текста (Rich Text). Правая часть состоит из поясняющего изображения или даже серии иллюстраций. Ниже может располагаться поясняющая подпись к картинке. В правом нижнем углу расположено три кнопки. Самая большая из них позволяет пользователю перейти непосредственно к заданию, то есть закрыть окно теории. Две другие возвращают игрока к списку задач или открывают меню.

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

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

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

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

3.8 Оформление игры

Все ресурсы для интерфейса и заданий, а также звуки взяты в студии Kenney [44]. Иконки для кнопок графического интерфейса - в студии Icons8 [45]. Данные материалы распространяются по свободной лицензии и могут быть использованы даже в коммерческих проектах. Лицензия Icons8, однако, требует указание ссылки на сайт студии в проекте, что и сделано внизу главной страницы.

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

Соревновательный режим полностью оформлен с использованием указанной выше графики.

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

3.9 Тестирование и результат работы

Разработанная игра была создана на движке Unity 4.3.4. Было реализовано двенадцать уровней: 3 на обучение синтаксису, 7 на работу с вертексными и фрагментными шейдерами и 2, относящихся в вычислительным шейдерам. Кроме того был разработан соревновательный режим, игроки в котором управляют персонажами при помощи вычислительных шейдеров.

Проведём оценку игры по аналогии с рассматриваемыми ранее схожими разработками. Данная игра изучает языки Cg и HLSL и является образовательной. Дополнительный режим относится к соревновательному типу. В виду технических ограничений пришлось отказаться от поддержки работы игры в браузере на данном этапе. На данный момент она работает исключительно на персональном компьютере под управлением операционной системы Windows. На данный момент игра не коммерческая и является прототипом. Для непосредственного выпуска требуются значительные улучшения. Графическое оформление в игре относится к категории "художественное". Звуковое же включает исключительно звуковые эффекты. Сильная реиграбельность игры обусловлена соревновательным режимом. Игровые циклы были описаны ранее. Для образовательного цикла это итеративный, для соревновательного - мультиплеерный, детерминированный. Несмотря на то, что изначально игра ориентировалась на начинающих разработчиков, итоговый проект всё же правильнее отнести к играм для обучающихся. Это вызвано структурой задач, в которых объясняются лишь основные моменты синтаксиса языка, но не основы написания программ в целом.

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

Для оценки получившейся игры было решено использовать модель 4C/ID. Задача анализа проекта по этой модели заключается в определении её положения на диаграмме и степени приближения к указанной идеальной игре.

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

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

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

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

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

Положение игры на диаграмме отображено на Рис. 14. Разработанное приложение носит рабочее название ShaderGame, именно так оно и обозначено на диаграммах. Таким образом, созданный проект не является идеальной игрой, с точки зрения модели 4C/ID. Для приближения к этому статусу требуется приблизить организацию задач и пользовательской поддержки к описанному в данном подходе эталону. Однако, это подразумевает изучение одной тематики в течение нескольких задач, что существенно увеличивает их количество. В данном же проекте было необходимо рассмотреть все ключевые темы для обучения написанию программ затенения и их разбиение на более маленькие однотипные задачи не представлялось возможным.



Рис. 14 Положение разработанной игры на диаграммах модели 4C/ID

Заключение

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

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

Был проведён комплексный анализ аналогов разработанной игры, включающий в себя оценку параметров связанных как с обучающей, так и с развлекательной стороной продуктов. Для этого был проведён обзор методов формального анализа серьёзных игр и отобраны три из них, использованные в разных частях процесса разработки. Основное сравнение аналогов, а также оценка полученного результата были произведены по модифицированной модели 4C/ID.

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

Разработанная игра была проанализирована и сравнена с аналогами по модели 4C/ID, в результате чего было сделано заключение о необходимости развития данного проекта, и определены направления для дальнейшей работы.

Таким образом, в ходе выпускной квалификационной работы были решены следующие задачи:

* проведён литературный обзор научных работ о влиянии серьёзных игр на обучение;

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

* проведён обзор и классификация аналогов разрабатываемого приложения;

* на основании обзора сформулированы требования к разрабатываемой игре;

* выработаны правила игры;

* разработана серьёзная игра, управляемая пользовательским исходным кодом;

* осуществлён анализ разработанного приложения.

Дальнейшее исследование предполагается проводить по следующим направлениям:

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

* улучшение логической составляющей игры путём структуризации уровней для удовлетворения концепции 4C/ID;

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

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

...