Разработка экскурсионно-развлекательной web-платформы KazanStreetGames (стр. 4 )

Рисунок 9

Для отображения заданий авторам квестов бывает необходимо загружать несколько картинок в описание уровней и подсказок. Для возможности хранения информации об изображениях (о именах файлов) созданы таблицы: level_img и prompting_img.

У каждого квеста может быть несколько авторов, которые могут его редактировать, информация об авторах отображается в таблице author_quest, которая объединяет сущности квест и пользователь.

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

Любой пользователь может проходить каждый квест как один раз, так и несколько. Информация о прохождении записывается в базы user_quest и user_level. Обе эти таблицы содержат поля is_begin и is_end для того, чтобы хранить информацию о том, начато ли прохождения квеста в целом и конкретного уровня в частности и закончено ли прохождение квеста или уровня. Данная информация необходима для возможности возобновления квеста на том же месте, где остановился пользователь, даже при смене устройства.

       Таблица user_quest ссылается на сущности quest и user, а таблица user_level на user_quest и level, так как ссылка на информацию о пользователе уже хранится в таблице user_quest, связь между таблицами отображена на рисунке 10.

       

Рисунок 10

       Таким образом полная схема базы данных без отображения полей имеет вид как на рисунке 11 (схема с отображением всех полей в приложении А):

Рисунок 11

Описание работы серверной части web-приложения.

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

Запрос приходит на Dispatcher Servlet, который является внутренним классом Spring и служит для распределения запросов по контроллерам. Контроллеры принимают параметры из запросов и вызывают методы сервисов, где располагается основная программная логика серверной части web-приложения. KazanStreetGames как приложение, написанное с использованием фреймворка Spring, использует внедрение зависимостей (Dependency Injection, DI) для связывания компонентов между собой, то есть при написании контроллера не приходится указывать конкретную версию реализации необходимого сервиса, фреймворк Spring делает это при старте приложения, нужно лишь указать интерфейс. В сервисы в свою очередь внедряются репозитории (слой DAO), в сервисах происходит валидация данных, их преобразование для отправки в базу, производятся вычисления. Вызванный сервисами слой DAO совершает непосредственную отправку запросов в базу данных. В приложении KazanStreetGames он реализован фреймворком Spring JPA, который позволяет создавать интерфейсы, наследуемые от JpaRepository, где названия методов формируются по определённым правилам, а реализация созданных интерфейсов производится Spring JPA. Ответ из базы в случае необходимости возвращается обратно по той же цепочке: DAO -> services -> controller ->view.

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

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

При нажатии на кнопку “Начать приключение” запрос попадает в GameController (метод inputKey). В запросе два основных параметра - это идентификатор квеста и значение самого входного ключа.

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

На рисунке 12 приведена краткая схема реализации обработки входного ключа, полный код класса GameController находится в приложении Б.Рисунок 12

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

Контроллер получает из текущей сессии значение входного ключа, которое было положено туда ранее и идентификатор квеста из URL запроса. Ключ  проверяется на валидность с помощью вызова метода сервиса InputKeyService: ключ должен существовать в сессии, ключ с таким же значением должен храниться в базе данных, ключ должен соответствовать квесту, который должен начаться, ключ назначен на текущего пользователя Далее квест проверяется на то, существует ли возможность пройти его в данное время, проверка осуществляется через сервис QuestService. Квеста доступен для прохождения, когда время окончания квеста ещё не прошло и время начала квеста уже наступило, или когда время проведения квеста не ограниченно автором, также не должно закончиться время окончания подтверждения участия. При прохождении проверок из двух предыдущих пунктов вызывается сервис работы с сущностью userQuest, где выполняется метод для создании новой записи. Далее происходит поиск первого уровня данного квеста через сервис LevelService и его данные отправляются на пользовательский интерфейс.

Рисунок 13

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

       При нажатии на кнопку “Подсказка” производится начисление штрафных очков, которые записываются в строку таблицы user_level, которая соответствует данному пользователю и данному уровню.

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

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

Рисунок 14

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

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

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

       Описанный алгоритм схематично изображён на рисунке 15.

Рисунок 15

Описание работы клиентской части web-приложения.

       Клиентская часть приложения KazanStreetGames представлена в виде jsp страниц с добавлением javaScript и CSS файлов. JavaScript-код выполняется в браузере на стороне пользователей, отправляя запросы на сервер для получения данных из базы или их сохранения.

       Код, написанный на javaScript использует фреймворк AngularJs. Данный фреймворк основан на шаблоне MVC. Модель (model) в AngularJS проецируется на представление (view) через HTML-шаблон (template). При изменении модели фреймворк обновляет необходимые точки связывания (binding points), после чего данные представления изменяются. [17]