Исследование и реализация игровой компьютерной среды дисциплины "Представление знаний в информационных системах"

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

2.2.1 Построение концептуальной модели предметной области

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

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

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

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

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

Рисунок 2.2.1 - Концептуальная модель разрабатываемой системы

3. Разработка алгоритмов построения игровой компьютерной среды

Игровую компьютерную среду дисциплины «Представление знаний в информационных системах» можно разбить на две основные задачи: построение игровой среды предметной области и алгоритм многоуровневой генерации заданий.

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

3.1 Построение игровой среды предметной области

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

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

Существуют игры, включающие в себя элементы нескольких жанров, способные принадлежать каждому из них (например, серия Grand Theft Auto, Космические Рейнджеры, Rome: Total War и многие другие). Подобные разработки относят либо к одному из жанров, который в игре является базовым, либо сразу ко всем, присутствующим в игре, если они в равной мере составляют геймплей проекта.

3D-шутер (англ. 3D Shooter) -- в играх такого типа игроку, как правило, действующему в одиночку, ставится задача уничтожения врагов при помощи оружия ближнего боя (чаще всего холодного) и стрелкового оружия (как правило огнестрельного оружия и энергетического). В шутерах от первого лица (англ. First person shooter, FPS) игрок не видит персонажа со стороны -- он наблюдает за происходящим от лица персонажа -- "глазами персонажа" (англ. First person look), и наблюдаемая игроком картина совпадает с тем, что "видит" персонаж. В шутерах от третьего лица (англ. Third person shooter, TPS) игрок видит персонажа со стороны с фиксированной (обычно со спины) или произвольной точки зрения (англ. Third person look). В ряде игр реализована возможность переключения первое/третье лицо и фиксированная/произвольная камера.

Геймплей «файтингов» составляют исключительно поединки двух и более противников с применением рукопашного боя. Beat'em up - одна из разновидностей файтингов, в которых сам бой проходит за пределами арены и с вовлечением большого числа противников единовременно. Слэшеры - игры с видом от третьего лица, основной частью игрового процесса в которых являются фехтовальные поединки с применением холодного и другого оружия.

Аркада (англ. Arcade) -- игра, основанная в первую очередь на быстродействии игрока, которому приходится полагаться в первую очередь на свои рефлексы и реакцию. Игровой процесс очень простой и стабильный на протяжении всей игры. Аркады можно охарактеризовать развитой системой бонусов: начисление очков, постепенно открываемые элементы игры и т. д. Первые популярные в мире игры чаще всего были аркадами. Именно поэтому начало 1980х годов называют "золотой эрой аркадных игр". Объем рынка аркадных автоматов был огромным и исчислялся миллиардами долларов.

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

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

Стратегии (англ. Strategy) -- игры, в которых от пользователя требуется спланировать и выработать какую-либо стратегию для достижения некоей конкретной цели, например, победы в военной операции. Игроку предстоит управлять не одним персонажем, а целым подразделением, предприятием или даже вселенной. Стратегии можно разделить на походовые или пошаговые стратегические игры (Turn-Based Strategy, TBS), где игроки по очереди делают ходы, и каждому игроку отводится неограниченное или ограниченное (в зависимости от типа и сложности игры) время на свой ход, и стратегические игры в реальном времени (Real Time Strategy, RTS), в которых все игроки выполняют свои действия одновременно, без прерывания хода времени.

Квест (англ. quest), или приключенческая игра (англ. adventure game) -- также является одним из основных жанров компьютерных игр. Перед игроком предстает интерактивная история с главным героем (управляемым игроком); вместе с тем повествование и обследование мира -- важнейшие элементы игры, а ключевую роль в игровом процессе играют решения головоломок и задач, требующих от игрока умственных усилий. Бои, экономическое планирование и задачи, требующие от игрока скорости реакции и быстрых ответных действий, в квестах сведены к минимуму или вовсе отсутствуют. Игры, объединяющие в себе характерные признаки квестов и жанра action, выделяют в отдельный жанр -- action-adventure.

Англоязычное название adventure game восходит к первой игре жанра, Colossal Cave Adventure, и должно пониматься как "игра, подобная Adventure", хотя современные игры могут сильно от нее отличаться. В русском языке закрепилось название "квест", которое первоначально также было именем собственным и использовалось в названии популярных игр этого жанра, разработанных компанией Sierra On-Line: King's Quest, Space Quest, Police Quest.

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

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

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

Графические квесты (или «point-and-click») - это поджанр квестов, который основывается на управлении курсором мыши, джойстика или клавиатурой, в отличии от текстовых квестов, где управление осуществлялось при помощи ввода команд с клавиатуры.

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

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

Подвид поджанра квестов головоломок «выход из комнаты» отлично подходит для выбора в качестве жанра и сюжетной опоры в нашей игровой компьютерной среде [9].

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

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

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

Рисунок 3.1.1 - Игра «100 дверей»

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

Простая задача - дверь с кодовым замком, код от двери - год рождения какого-то ученого, например, Алана Тьюринга. На стене какие-то случайные и не очень случайные надписи, которые подсказывают обучающемуся верный ответ: “Люблю Полину!<3” “А я люблю Алана” “Тьюринга?” “Да, прямо со дня его рождения” “Ты в 1912 ещё даже не родилась!”. После ввода кода дверь открывается, и игрок переходит на новую сцену.

Средняя задача - на двери висит электронный дисплей с надписями, над ним задача: «Лишь постигший все модели представления знаний сможет пройти». На дисплее перечислен список случайных терминов: продукционные, формальные логические, семантические сети, фреймы, безупречного обслуживания, закрытая, открытая, коммуникативная. При тапе на какую-то надпись, она меняет свой цвет с белого на зелёный. При клике по надписи “все модели” происходит проверка выделенных надписей. Если выделены все нужные, то дверь открывается. Если не все нужные выделены или выделены лишние, то выделение всех надписей сбрасывается.

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

Средняя задача - над дверью находится надпись “Определение ты знаешь! Но какие свойства его раскрывают?”. Словосочетание “свойства” выделено жирным курсивом и цветом. На стенах надписи: дискретность, определенность, результативность, массовость, непрерывность, неопределённость, безрезультатность, уникальность. Эта задача по своей типизации повторяет задачу номер два.

Сложная задача - решение задачи на машине Тьюринга. Вверху написан код “100100”, под ним другой “1#&10#”, причём первый код просто написан, у второго же каждый символ выделен рамочкой, которая подразумевает возможность изменять значения этого поля. Рядом с кодами ряд кнопок со списком возможных команд машине Тьюринга, также кнопка сброса прогресса и выполнить, которая проверяет правильность проведенных операций.

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

Важность кривой сложности в игровой среде сложно переоценить. Разные игры разных жанров работают по-своему над кривой сложности. Они стараются повысить показатели проекта при помощи уровней разной сложности. За уровень в данной ситуации может приниматься, как и обычный уровень в игре типа «три в ряд», так и очередной противник в MMO RPG. Кривая сложности влияет на основные показатели проекта - такие как монетизация и удержание пользователя. Именно ради удержания пользователя нам и нужно использовать кривую сложности при выдаче уровней-сцен.

Компания-разработчик казуальных игр Wooga на прошедшей в Сан-Франциско конференции игровых разработчиков поделилась своим исследованием на этот счёт. «Злость - очень сильная эмоция», - с этих слов началось выступление Флориан Стейнофф, главного по продукту в компании Wooga. По мнению Стейноффа, когда создаешь игру, не стоит делать ее во всем «милой и пушистой». Должно быть место и ненависти [14].

«В случае если игрок ненавидит игру, это означает, что он испытывает очень сильные эмоции по поводу нее, что вполне может стать следствием того, что он также немного ее любит», -- отметил Флориан. Оттолкнувшись от этой позиции, он рассказал об уровнях сложности в игре Jelly Splash.

В процессе разработки игры было испробовано множество вариантов роста сложности. Пробовали стремиться к постоянному увеличению сложности уровней (по аналогии с прямой, расположенной под углом в 45 градусов по отношению к оси абцисс). Кроме того, были проведены эксперементы с кривой сложности, внешне схожей с «хоккейной клюшкой» - графика в виде экспоненциальной функции, но в результате в Wooga пришли к кривой линии, утыканной пиками, которая изображена на рисунке 3.1.2.

Рисунок 3.1.2 - Кривая сложности в игре Jelly Splash

Пики представляют собой «очень сложные уровни», которые замедляют движение игрока по кампании. Проблема в том, что на этих уровнях процент поражений игроков достигает до 95%. Сразу после сложных уровней идут «долины» более легких уровней, на которых игроку дается передышка. Также Wooga добавила BuildUp-уровни, сложные этапы на склонах, ведущих к пикам. Не стоит вводить на первых этапах пики и BuildUp-уровни. Однако это не значит, что игра с самого начала должна быть простой. «Игроки должны проигрывать, они должны проигрывать даже в самом начале, в ином случае они подумают, что игра - для детей», -- отмечает Флориан [14].

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

Система рейтингов Эло представляет собой особую методику расчёта относительной силы игроков в играх, в которых принимают участие два игрока (например, сёги, го или шахматы). Данную систему рейтингов разработал американский профессор физики венгерского происхождения Арпад Эло. В текущей работе мы планируем жестко задавать сложность для уровней, а динамично меняться будет только рейтинг игрока [15].

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

Система рейтингов Эло была предложена Шахматной федерацией США в 1960 году. В 1970 году ФИДЕ приняла систему рейтингов Эло за основу при решении вопросов, связанных с присвоением званий гроссмейстера и международного мастера, комплектованием отборочных и других турниров и так далее.

Под рейтингом Эло в шахматах обычно подразумевают рейтинг ФИДЕ, который получают шахматисты после выступлений в турнирах с обычным контролем времени. В шахматах рейтинг Эло вычисляется по результатам игр шахматистов друг с другом. Система рейтингов Эло делит шахматистов на девять классов: высший класс начинается с рейтинга 2600, низший класс соответствует рейтингу 1200 и ниже [15].

В системе рейтингов Эло принято, что переход от одного класса игры к следующему происходит примерно через 200 пунктов рейтинга (начиная с игроков уровня первого разряда). Если различие между двумя игроками составляет 200 пунктов, то сильнейший игрок набирает в среднем около 0,76 очка за игру, если различие составляет 400 пунктов, то это среднее примерно равно 0,91. Различие в 600 пунктов означает, что сильнейший игрок выигрывает «почти» всегда (в среднем около 0,97 очка за игру). Если рейтинги обоих игроков равны, вероятность победы одного из них равна вероятности победы другого из них (что равносильно среднему количеству 0,5 очков за игру). Эти вероятности, конечно, не учитывают резко изменившуюся спортивную форму игрока в конкретный момент. Напротив, если сила игрока изменяется относительно медленно (в то время как игрок проводит статистически достаточно большое количество игр, учитываемых для изменения рейтинга), то рейтинг постоянно подстраивается под изменения силы игрока.

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

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

Вычисление рейтинга Эло для шахматистов - дело не простое. Вычисляется математическое ожидание количества очков, которое наберёт игрок A в партии с B (оно равно сумме вероятности выигрыша игрока A и половины вероятности ничьей):

,

где:

EA - математическое ожидание количества очков, которое наберёт игрок A в партии с B;

RA - рейтинг игрока А;

RB - рейтинг игрока B.

Новый рейтинг игрока A рассчитывается по формуле:

,

где:

К -- коэффициент, значение которого равно 10 для сильнейших игроков (рейтинг 2400 и выше), 20 (было 15) -- для игроков с рейтингом меньше чем 2400 и 40 (было 30) -- для новых игроков (первые 30 партий с момента получения рейтинга ФИДЕ), а также для игроков до 18 лет, рейтинг которых ниже 2300;

SA -- фактически набранное игроком A количество очков (1 очко за победу, 0,5 -- за ничью и 0 -- за поражение);

R'A -- новый рейтинг игрока A.

Несмотря на все достоинства системы Эло она слишком громоздкая, поэтому было принято решение использовать её, но в немного более упрощенном варианте.

3.2 Алгоритм многоуровневой генерации заданий

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

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

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

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

Технические дисциплины в большинстве своем представляют собой хорошо структурированные предметные области. Обозначим знания по какой-либо отдельно взятой технической дисциплине - PA, структуру данной предметной области - STPA. Структура тестов, создаваемых для выбранной дисциплины STTPA, должна отражать структуру заданной предметной области и охватывать все сегменты изучаемого курса (Sgi…k - учебный блок: раздел, подраздел, тема, …, предложение) упорядоченной последовательностью тестовых заданий Sgti : STTPA=<Sgt1, Sgt2, …, Stgk> , представлена на рисунке 3.2.1 [18, 19]. Мощность КТС определяется количеством различных заданий MKTS, которые могут быть предъявлены системой:

,

где - мощность сегмента (число дуплетов в сегменте), k - количество сегментов в предметной области.

Компьютерный тест KT является упорядоченной последовательностью заданий-ответов:

,

где n - конечное целое, Di=(Qi,Ai) - дуплет, обозначающий пару задание-ответ и представляющий собой предложение конечной длины ограниченного естественного языка. Таким образом, требуется получить правило преобразования П, позволяющее на основе знаний предметной области и заданной структуры теста создать множество тестов :

.

Рисунок 3.2.1 - Структура тестов выбранной дисциплины

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

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

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

,

где A(Di) - возможное множество дуплетов, соответствующих сегменту Sgti.

Повторение вопросов в сгенерированных тестах должно стремиться к нулю для всех вариантов тестов KTi, KTj:

, т.е. ,

где KTi =(Qi1, Qi2, … , Qif), KTj =(Qj1, Qj2, … , Qjf), Qik ,Qjk - тестовые задания, NT - множество номеров тестов.

Время преобразования (время поиска решения) tdec должно быть ограничено некоторой приемлемой с практической точки зрения величиной tmax:

tdec < tmax.

Программная реализация КТС должна поддерживать возможность генерации тестовых заданий по дисциплинам технического направления. Формальное описание тестовых заданий должно позволять включать в тест следующие виды информации: простые типы данных (целые и рациональные числа, символ, строка символов, рисунок, в заданном графическом формате); сложные типы данных (предложения, получаемые комбинированием простых данных); переменные (указывается тип данных и название переменной); функции, в том числе встраиваемые в КТС и подключаемые через библиотеку модулей, а также записываемые посредством переменных, для вычисления, например, правильного ответа для данного тестового задания; файлы, содержащие грамматики заданий, структуру тестов и информацию необходимую для генерации тестовых заданий (например, схемы).

Заданным требованиям удовлетворяет модель, которую представили авторы статьи «Алгоритм реализации метода автоматической генерации тестовых заданий» Сергушичева А.П. и Швецов А.Н. [17]. Предложенная авторами статьи модель КТС (MKTS) включает механизмы генерации тестовых заданий:

,

где:

StKTS - структура КТС;

{ScТ} - множество сценариев тестирования, реализованных в КТС;

{DKTS} - множество данных, необходимых для работы КТС и генерируемых КТС.

Структура КТС представлена блоком регистрации Reg, блоком редактирования баз знаний предметных областей EdtKSG, блоком формирования тестов FrmITS, генератором тестовых заданий GТT , блоками тестирования Tst и оценивания Est:

.

Редактор грамматик EdtKSG предназначен для ввода и редактирования базы знаний КТС, в которой порождаемые множества тестовых заданий описаны с помощью формальных грамматик (ФГ). Формирователь КТС FrmKTS обеспечивает формирование структуры теста, задания которого будут предъявляться в динамическом режиме. Процесс задания структуры теста определяется, в основном, техническими решениями по реализации блока, выполняющего указанную функцию. Генератор тестовых заданий GТT необходим для автоматического создания на основе имеющихся файлов с ФГ дуплетов тестовое задание {Qst}- ответ {Ans} в соответствии с заданной структурой теста.

Для реализации механизмов генерации тестов Сергушичевой и Швецовым был предложен оригинальный метод, который описывает динамику построения теста по заданной структуре. Метод автоматической генерации тестовых заданий базирующийся на продукционном формализме. Алгоритм реализации метода представлен на рисунке 3.2.2. Исходной информацией для построения теста является база знаний предметной области, представленная множеством формальных грамматик, описывающих множество правил вывода тестовых заданий. Структура теста задается указанием имен файлов, содержащих грамматики заданий, включаемых в тест и количества заданий каждого типа (по каждому из файлов). Модуль генерации теста (аксиомы) создает промежуточный файл, в который в соответствии с заданной структурой подставляются по какому-либо алгоритму конкретные грамматики тестовых заданий. Во избежание повторного использования номера примененных грамматик учитываются. На основании промежуточного файла вызываются обработчики соответствующих грамматик, которые формируют задание в привычном виде, подставляя по какому-либо алгоритму конкретные данные (текстовые, числовые, графические и т.д.).

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

Рисунок 3.2.2 - Алгоритм реализации метода автоматической генерации тестов, предложенный Сергушичевой и Швецовым

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

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

4. Разработка программных модулей

Разработка программных модулей в фреймворке Corona SDK на языке программирования lua представляет собой обычную разработку на объектно-ориентированном языке программирования и не очень сильно отличается от других языков. А вот фреймворк достаточно интересный.

Corona SDK - это кросс-платформенный движок для создания игр под iOS, Android и ПК. Он достаточно прост в освоении: «отлично» по паскалю - это достаточный багаж знаний для того, чтобы чувствовать себя вполне комфортно при работе с Corona SDK.

Интерфейс Corona SDK состоит из 2 окон: окно симулятора и окно консоли симулятора (Corona Simulator Output). В окне симулятора можно выбрать устройство и разрешение экрана, на котором будет производиться симуляция работы. Симуляция работы происходит достаточно быстро и практически не требует ресурсов компьютера, в отличии от полноценных эмуляторов устройств. Окно симулятора с запущенным примером программы из доступных в качестве обучающих представлено на рисунке 4.0.1.

Рисунок 4.0.1 - Окно симулятора Corona SDK

Во время работы симулятора в окно консоли симулятора поступают данные о состоянии программы: ошибки, состояние загрузки, команды мониторинга состояний (команда print в консоль). Окно консоли очень полезно для отладки и контроля правильности работы программы, главное пользоваться нужными метками в нужных местах. Окно консоли симулятора в момент работы программы-примера из документации короны, которая была показана на рисунке 4.0.1), представлено на рисунке 4.0.2.

Рисунок 4.0.1 - Окно консоли симулятора Corona SDK

Написание программного кода в Corona SDK происходит в сторонних программных средствах, например, блокнот, Notepad++, Sublime Text. Последняя имеет удобный для настройки интерфейс, подсветку синтаксиса, автоматическую подстановку слов и автоматическую расстановку скобок и точек с запятой, что определенно делает работу с Sublime Text очень удобной. Также в Sublime можно создавать проект и сохранять в профиль настройки проекта, список открытых окон и даже координаты курсора в момент последнего открытия.

4.1 Меню и навигация

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

Composer - это официальная библиотека создания и управления сценами (окнами) в Corona SDK. Эта библиотека предоставляет разработчикам простой способ создания и перехода между отдельными сценами [20].

Основным объектом библиотеки Composer является объект сцены. Это слушатель событий, который реагирует на определенные события и содержит уникальное свойство self.view, которое является ссылкой на группу отображения, связанную со сценой. Этот self.view - это то, где располагаются визуальные элементы, относящиеся к сцене.При помощи Composer сцена может быть создана, свернута (не отображается на экране, но существует в памяти), осуществлен переход к уже существующей сцене, загружена существующая сцена, но которой при этом нет в памяти устройства, удалена из памяти текущая сцена, удалены из памяти все скрытые сцены.

На рисунке 4.1.1 представлена схема работы меню.

Рисунок 4.1.1 - Схема работы меню

При запуске приложения вызывается файл main.lua, в котором инициализируются все используемые в проекте библиотеки, объявляются разрешения, которые нужно запросить у устройства (актуально для закрытых ос, таких как Android и iOs). Также в main устанавливается следующая вызываемая программой сцена:

display.setStatusBar( display.HiddenStatusBar )

display.setDefault("fillColor", 0);

local composer = require( "composer" )

composer.gotoScene( "menu" )

После вызова сцена menu.lua происходит её загрузка. Так как файл был вызван при помощи библиотеки Composer, то у неё есть строгая типизация оформления - цитата из официальной документации Corona SDK [20]:

local composer = require( "composer" )

local scene = composer.newScene()

-- Code outside of the scene event functions below will only be executed ONCE unless

-- the scene is removed entirely (not recycled) via "composer.removeScene()"

-- Scene event functions

-- create()

function scene:create( event )

local sceneGroup = self.view

-- Code here runs when the scene is first created but has not yet appeared on screen

end

-- show()

function scene:show( event )

local sceneGroup = self.view

local phase = event.phase

if ( phase == "will" ) then

-- Code here runs when the scene is still off screen (but is about to come on screen)

elseif ( phase == "did" ) then

-- Code here runs when the scene is entirely on screen

end

end

-- hide()

function scene:hide( event )

local sceneGroup = self.view

local phase = event.phase

if ( phase == "will" ) then

-- Code here runs when the scene is on screen (but is about to go off screen)

elseif ( phase == "did" ) then

-- Code here runs immediately after the scene goes entirely off screen

end

end

-- destroy()

function scene:destroy( event )

local sceneGroup = self.view

-- Code here runs prior to the removal of scene's view

end

-- Scene event function listeners

scene:addEventListener( "create", scene )

scene:addEventListener( "show", scene )

scene:addEventListener( "hide", scene )

scene:addEventListener( "destroy", scene )

return scene

Как видно, для каждого события, которое может произойти со сценой, как с объектом, предусмотрен свой шаблон поведения и listener, который слушает команды и передает Composer'y, который в свою очередь выполняет блок, который должен работать в данной ситуации.

После того, как мы из main.lua запустили menu.lua начал выполняться блок create, а за ним show. Так как мы не подразумеваем никаких хитрых манипуляций со сценами, то можем весь код просто писать в одном из этих блоков. Я предпочитаю использовать блок show, так как кажется логичным работать из блока, который выполняется, когда мы видим сцену.

Работа меню построена на базовых кнопках, которые состоят из простых форм - прямоугольников, в которых пишется текст:

local widget = require( "widget" )

local composer = require( "composer" )

local scene = composer.newScene()

local function PlayButtonEvent( event )

if ( "ended" == event.phase ) then

composer.gotoScene( "level" )

composer.removeScene( "menu" )

end

local function PlayButton1Event( event )

if ( "ended" == event.phase ) then

composer.gotoScene( "level1" )

composer.removeScene( "menu" )

end

end

local function AboutButtonEvent( event )

if ( "ended" == event.phase ) then

composer.gotoScene( "about" )

composer.removeScene( "menu" )

end

end

function scene:create( event )

local sceneGroup = self.view

local MenuText = display.newText( "Меню", display.contentCenterX, display.contentCenterY/5, "Blogger Sans-Medium", 80)

local playbutton = widget.newButton {

shape = 'Rect',

width = 500, height = 100,

x = display.contentCenterX, y = 750,

fillColor = { default={ 0.2 }, over={ 0.8 } },

labelColor = { default={ 1 }, over={ 1 } },

fontSize = 60,

font = "Blogger Sans-Medium",

label = "Играть",

onEvent = PlayButtonEvent

}

local playbutton1 = widget.newButton {

shape = 'Rect',

width = 500, height = 100,

x = display.contentCenterX, y = 750,

fillColor = { default={ 0.2 }, over={ 0.8 } },

labelColor = { default={ 1 }, over={ 1 } },

fontSize = 60,

font = "Blogger Sans-Medium",

label = "Учиться",

onEvent = PlayButton1Event

}

local aboutbutton = widget.newButton {

shape = 'Rect',

width = 500, height = 100,

x = display.contentCenterX, y = 900,

fillColor = { default={ 0.2 }, over={ 0.8 } },

labelColor = { default={ 1 }, over={ 1 } },

fontSize = 60,

font = "Blogger Sans-Medium",

label = "Помощь",

onEvent = AboutButtonEvent

}

sceneGroup:insert( playbutton )

sceneGroup:insert( playbutton1 )

sceneGroup:insert( aboutbutton )

sceneGroup:insert( MenuText )

end

function scene:show( event )

end

function scene:hide( event )

end

function scene:destroy( event )

end

scene:addEventListener( "create", scene )

scene:addEventListener( "show", scene )

scene:addEventListener( "hide", scene )

scene:addEventListener( "destroy", scene )

return scene

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

if ( "ended" == event.phase ) then

…

end.

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

4.2 Основная игровая сцена

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

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

В этой сцене ученику предлагается ввести код из букв в определенном порядке. Эти буквы генерируются автоматически из алфавита русских букв (за исключением самых редких, типа ё, ъ, ь, ы и так далее) и искомого слова. Эти буквы вносятся в массив из 16 знаков (2 строки по 8 букв) в случайном порядке. Каждому символу соответствует своя кнопка - после нажатия на эту кнопку символ вносится в электронный дисплей, а кнопка гаснет (становится невидимой и неактивной для нажатия).

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

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

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

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

5. Отладка и экспериментальное тестирование модулей

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

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

Все выявленные в ходе тестирования ошибки были обнаружены в коде, локализированы и исправлены. Большинство выявленных ошибок были алгоритмическими, то есть последовательность или результат выполнения группы операций не соответствовали спроектированным алгоритмам. Также присутствовали ошибки в интерфейсе, отображении графики, несостыковки графики на разных разрешениях экранов (при изменении соотношения сторон с 16:9 на 4:3 картинки перестали состыковываться).

6. Разработка технической документации

Игровая компьютерная среда дисциплины «Представление знаний в информационных системах» ориентирована на людей, желающих отточить навыки в решении задач по дисциплине ПЗиС и заодно весело провести время благодаря игровой форме подачи материала.

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

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

7. Проведение исследования

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

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

Итоговый тест в системе дистанционного образования представляет собой тестирующую систему, в которую внесены тестовые задания и варианты ответов. При генерации теста варианты ответа и порядок вопроса расставляются абсолютно случайно - таким образом уменьшается влияние других тестируемых на результат того, кто сейчас проходит тест. Тест включает в себя 30 вопросов, за каждый из которых дается разное количество баллов, чаще всего 1 балл за вопрос с 4 вариантами ответа. Не важно сколько баллов можно получить в итоге, но максимальное количество баллов - это 100% результат.

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

Также возьмем 20 человек из тех, кто ещё не проходил итоговый тест дисциплины ПЗиС и дадим им пользоваться игровой компьютерной средой в течении 7 дней. Время, которое тестируемые уделяли игровой среде никак не ограничивалось и не контролировалось.

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

Результаты теста представлены в таблице 7.1.

Таблица 7.1 - Результаты теста

Контрольная группа	Тестируемая группа
Идентификатор тестировщика	Результат, %	Идентификатор тестировщика	Результат, %
101	56	201	62
102	87	202	44
103	37	203	72
104	62	204	81
105	45	205	94
106	73	206	49
107	38	207	56
108	44	208	38
109	96	209	84
110	81	210	76
111	26	211	90
112	58	212	66
113	71	213	72
114	49	214	59
115	52	215	75
116	62	216	45
117	56	217	95
118	84	218	74
119	66	219	42
120	62	220	60

Среднее значение у контрольной группы - 60,25%, среднее значение у тестируемой группы - 66,7%. При этом минимальное значение у контрольной группы равно 26%, а у тестируемой - 38%; максимальное значение контрольной группы составило 96%, а у тестируемой - 95%.

То есть в целом использование игровой компьютерной среды оправдало ожидания - средний уровень знаний повысился. При этом значения оказались более сгруппированными: разница между минимумом и максимумом у тестируемой группы составила 57%, а у контрольной - 70%.

Если откинуть минимум и максимум и посмотреть только значения в середине интервалов, тогда получим следующие данные: тестируемая группа - 66,72%, а контрольная 60,167%. Разница примерно в 6.5% сохранилась. Это говорит нам об отсутствии влияния фактора минимума и максимума на результат тестирования.

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

Заключение

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

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