Technical description - MobileGamingLabMobile/MGL GitHub Wiki
###3. Technical description of functionalities and structures ####3.1 Database The database is MongoDB (https://www.mongodb.org/) saving all the information and models needed for the application. The JSON format is used while saving the data. Below the database schemes and consider the name.id is automatically generated. ######user.profile
| name | profession | country | city | avatar |
|---|---|---|---|---|
| string | string | string | string |
######user.login
| password | registration | session_key | last | |
|---|---|---|---|---|
| string | string | date | string | date |
######user.games
| owned | subscribed |
|---|---|
| [game.id] | [game.id] |
######gameSession
| started | owner | players | groups | game |
|---|---|---|---|---|
| date | user.id | [playerInstance.id] | [group.id] | game.id |
######playerInstance
| user | availableQuests | finishedQuests | activeQuest |
|---|---|---|---|
| user.id | [quest.id] | [quest.id] | quest.id |
######comment
| user | game | rating | time | text |
|---|---|---|---|---|
| user.id | game.id | integer | date | string |
######game.metadata
| name | description | category | owner | published | publishedDate | comments | rating |
|---|---|---|---|---|---|---|---|
| string | string | [string] | user.id | boolean | date | [comment.id] | double |
######game.components
| quest | questCollections | scenes | plots | boundary | roles | objects | items | resources |
|---|---|---|---|---|---|---|---|---|
| [quest.id] | [questCollection.id] | [scene.id] | [plot.id] | double, double, double,double | [string] | [object.id] | [item.id] | [resource.id] |
######quest
| requirements | description | tasks | questEvent | started | finished | title | available |
|---|---|---|---|---|---|---|---|
| [trigger.id] | content.id | [interaction.id] | questEvent.id | boolean | boolean | string | boolean |
######questCollection
| quests | plot |
|---|---|
| [quest.id] | [quest.id] |
######scene
| questCollection | trigger | questEvent |
|---|---|---|
| [questCollection.id] | [trigger.id] | questEvent.id |
######questEvent
| sequence | title | actions |
|---|---|---|
| [content.id] | string | [action.id] |
######interaction
| trigger | actions |
|---|---|
| [trigger.id] | [action.id] |
######content
| name | url | type |
|---|---|---|
| string | string | “image” / “video” / “sound” / “text” |
######trigger
| conditions | triggered |
|---|---|
| [condition.id] | boolean |
######condition
| name | available | type |
|---|---|---|
| string | boolean | string |
######condition.timeCondition
| countdown | beforeTime | betweenTime | afterTime |
|---|---|---|---|
| double | date | [date, date] | date |
######condition.progressCondition
| started | finished | quest |
|---|---|---|
| boolean | boolean | quest.id |
######condition.locationCondition
| coord | minSpeed | minDistance | item | player | buffer |
|---|---|---|---|---|---|
| [double, double] | double | double | item.id | player.id | double |
######condition.objectCondition
| collected | activated | used | spent | amount | object | player |
|---|---|---|---|---|---|---|
| boolean | boolean | boolean | boolean | integer | object.id | player.id |
######condition.groupCondition
| formed | numberOfPlayers | groupID |
|---|---|---|
| boolean | integer | group.id |
######condition.inputCondition
| value | validated | performed |
|---|---|---|
| string | boolean | boolean |
######condition.playerCondition
| playerID | groupID | roleID | playsRole | roleAssigned | visible |
|---|---|---|---|---|---|
| player.id | group.id | string | boolean | boolean | boolean |
######condition.triggerCondition
| trigger | relation |
|---|---|
| [trigger.id] | string |
######action
| type | game |
|---|---|
| string | game.id |
######action.timeAction
| wait | countdown | startTime | stopTime |
|---|---|---|---|
| boolean | integer | boolean | boolean |
######action.progressAction
| start | unlock | finish | update | interaction | game |
|---|---|---|---|---|---|
| boolean | boolean | boolean | boolean | interaction.id | game.id |
######action.objectAction
| add | resource | decreaseResource | item | addItem | player | removeItem | placeItemOnMap |
|---|---|---|---|---|---|---|---|
| integer | resource.id | integer | item.id | boolean | player.id | boolean | boolean |
######action.groupAction
| group | showPlayers | setVisibility |
|---|---|---|
| group.id | [player.id] | boolean |
######object
| item | resource | player | properties |
|---|---|---|---|
| item.id | resource.id | player.id | properties.id |
######properties
| name | type | value |
|---|---|---|
| string | string | string |
######item
| name | position | icon | actions | buffer |
|---|---|---|---|---|
| string | GEOJSON | string | [action.id] | double |
######resource
| value | name | description |
|---|---|---|
| integer | string | string |
#####player
| position | buffer | resource | groups | properties | roleName | user |
|---|---|---|---|---|---|---|
| [double, double] | double | [resource.id] | [group.id] | properties.id | string | user.id |
######player.inventar
| enabled | slot |
|---|---|
| boolean | [item.id] |
######group
| member | properties |
|---|---|
| [player.id] | properties.id |
######group.inventar
| enabled | capacity |
|---|---|
| boolean | [item.id] |
####3.2 Community-Surface The community website is a one-pager realized with Angular.js. There are several templates: sign-up, log-in, profile, changeProfile, gameinfo, selectGame, help and game. The Framework Foundation5 is used to create a simple layout and a webpage easy to use. All games are listed in tables which are built with the plug-in datatables. This gives the advantage that it provides sort, search and paging functions. Furthermore the plug-in rateYo is used to enable the rating of the games. During the game a map is displayed and for this reason leaflet is integrated.
####3.3 Interfaces (RestAPI / Websockets) The communication between server and client is implemented using the REST communication pattern and websockets. The exchange objects are JSON object, since it is the easiest object to parse in a JavaScript environment. The API’s are split into four main areas:
Each of those API’s has a clear directive. The UserAPI deals mainly with user management functionalities, e.g. login / logout, signup and user profiles. The community API offers functions for commenting, exploring published games and playing the game. The editor API offers functions to create and edit various game components such as the quest, the tasks, as well as the trigger and actions. Last, the websocket API offers functions for the mobile client to interact with the game engine.
####3.4 Game structure The basis of each created game are quests which have to be solved to win the game. One quest at a time can be picked from a quest log which is then activated and can be solved. When a quest is finished also new quests can appear in the quest log. This makes it possible to build up a story line within a game.
A central role in the games plays a map. On this map little icons can be placed which mark specific locations where specific game actions are triggered. The idea was also that the own position and the positions of the other players are shown on the map. These positions are updated frequently so there will be moving icons on the map. Next to the real positions of the players also the motion of objects in the game world should be shown.
Another element of the game are items. All objects which are placed on the map are of this category. The player can store items in his inventar. These items can be activated by the player to execute a certain action. Simple values which need to be stored for the player, but can not start an interaction within the game, are also considered within the data model.
The picture shows an activity diagram which describes the core line of action of the games which could be build. The diagram does not mention: multiplayer aspects, other conditions beside the client values (like time,...), other events which could happen (Text, pictures, videos,... appear or resource values are changed and items are added lost).
The box in grey marks that this is a nice feature, but it is not considered in the database, yet.
######Multiplayer aspects
With the database schema it is possible that multiple players can play together or against each other. So they can try to solve the same quest or catch the other player (like mister x). With the schema it is also possible that the players can see each other on the map. An idea is also to create a chat possibility that the player can communicate easily with each other.
######Game state management
After the user has chosen to play a game a game session will be created, which will store general information about the started game. Those information are the host of the game and all the involved players of this particular game instance with their current game progress. It also has an unique id in order to manage the communication between clients and server in a way that the correct instance is called when the game engine evaluates the input given by a client.
While the “player” object created by the editor mainly describes the general properties and appearance of the player, the player instance uses the player object as a blueprint to create instances for each individual user that is involved in the game session. The most important parts of those instances are the links to the available and finished quest that are part of the game and the instantiation of the players inventar as well as assigned ressources like a score or currencies and alike.
######Game engine
The actions of the player (moving in the real world, activate items,...) need to be evaluated to check if the active quest is solved. This is done by the game engine which is located at the server. As that are multiplayer games the values of different players can influence the evaluation. For example it should be possible to compute the distance between the players using their GPS positions.
The architecture of the game engine is designed as a flow.
The architecture of the game engine is designed as a flow. The core process of the engine is shown on the left part of the picture. At the beginning there are the values which were send from the smartphone application of the player. These are tested if they fulfill one or more of the defined conditions. If a condition is fulfilled then all existing triggers are checked if they link to the fulfilled condition. The triggers which are found are then checked if all of their conditions are fulfilled. The same will be done with the interactions. All interactions where all their triggers triggered will then execute one or more actions.
The right part of the picture shows the connection of the game engine to other game elements. The status of the Conditions, Trigger and Interactions are stored in the “Session” object, which is part of the Progress Controller. The Progress Controller links to the “PlayerInstance” object, which stores the active quest. If all Triggers were triggered that are needed to finish that quest, the Progress Controller executes the related actions and sequences.
Conditions store values, which are compared against the incoming values. If the test succeed then the condition is fulfilled. For example a condition should be fulfilled when the player is near to a specific location. Then the GPS coordinates are compared with the coordinates of this location.
The trigger are a aggregation of multiple conditions. They describe a state in which all conditions need to be fulfilled. An example is that the player needs to be at a specific location (Condition 1) at a specific time (Condition 2).
For a better usability in the game editor there exist the “interaction” objects which aggregate multiple triggers. So states can be defined as a trigger and they can be used multiple times in different interactions. A specific state then only needs to be created one time.
If all trigger of an interaction have triggered (are fulfilled), then all actions, which are defined in that interaction, will be executed.