# A Cloud Game-Based Educative Platform Architecture:
## 5 Cloud Game Monitor
### Data Management  
xAPI has been used with great success as an activity record mechanism in various educational tools in recent years [18; 57; 58], as well as incorporated from multiple Learning Management Systems (LMSs). Therefore, this standard is used as a tool to manage the recording of the activity of the participants. This way, it is possible to reuse existing LA techniques and integrating them to our CyberScratch project. Our LRS will be hosted in the cloud.  
Each xAPI statement represents an event that has taken place within our educational application. An xAPI statement is composed of three main elements:  
* _An actor_. An actor must have an associated account in the educational platform. From our perspective, there are three main actors available in our environment: the teachers, the players (the students) and the students' groups.
* _A verb_. Verbs are actions that are represented by URIs, such as access, init, ends, among others.
* _An object_. Within the definition of xAPI, it is the element of the framework on which falls the action (a game, a mission, a case, a flag, a reward...). It is also possible to add more information about the context of the events through an element called _Context_. If desired, we can add a specific element to add information about the result of the action. The process of designing sentences is performed with the next steps:  
1. Listing the relevant events to be recorded for the monitoring of the games. These events must allow lecturers to produce learning reports and, also adapt them and improve the experience of our players. The main registered events in CyberScratch are:  
* Start and ends of each session at the platform. It allows lecturers to determinate the time elapsed. It also allows detecting those students at risk.
* Start and ends of a game, each case and each mission at the platform. It allows lecturer to determinate the performance of the player and determinate the difficulty level of each challenge.
* Visualization of a story inside the platform. Lecturers can determine the appealing of the designed stories and the player comprehension of the story.
* Request of a clue. This event can allow to determine the complexity of the challenge for a player and the need of further support from the lecturer in order to succeed in the game.
* Artifact download by a player. This event and the next one are correlated with the resolution path of the challenge.
* Command issued by a player inside her/his console.
* Try of mission resolution and its corresponding result (failure or success).
* Creation/joined to a group at the game.
2. Creating a statement template for each event registered, which is detailed in the previous step. For each statement template the following guidelines have to be followed:  
* As defined above, each actor is correlated with an account.
* Verbs and objects are selected from xAPI Registry [59] and Serious Game xAPI Profile, as stated in [18]. They provide enough verbs and objects definitions that easily fit in our framework.
* Each statement contains a timestamp with the correct time zone.  
* The statement context should contain minimal information. This element is more focused on debugging information rather than educational information.
3. Correlating the existing variables in each template with existing variables in the application.  
Once xAPI templates are designed, the point where each statement is built, transmitted and identified. xAPI statements are constructed with the TinCanPython library [60] within the created Python framework. The statements are transmitted towards our cloud LRS.  
Once data management has been described, data privacy about our developments is performed next.