Other platform processes

In addition to the authoring and playing processes there are also processes to monitor or support students, to manage game runs, to populate the platform and game runs and to integrate the platform with other systems.

Monitoring and supporting students. A tutor may (i) inspect a student’s progress or (ii)

interfere in a running game as an NPC or an administrator (iii) may adjust a student’s progress. These sub-processes involve the Progress Manager or Shared Progress Man- ager (see section 3.2) to retrieve or adjust student’s progress.

A tutor may have two reasons to inspect progress: to inspect the performance of a student or to help a student out if he does not succeed to finish a specific task. To in- spect their performance he gets an overview of students per run, the tasks they have completed and assignment outcomes they have submitted. He may also generate his own overviews of specific game content properties, e.g., to inspect if certain resources are opened or questions are asked, or to inspect students’ paths through the game. To help a student out he can open the player environment showing the student’s progress to diagnose the problem. The same option allows him to interfere in a running game by sending an email as an NPC, e.g., in case a student’s performance is poor or better than average. Sending such an email might also trigger script that releases a next task. Such thresholds placed by a game developer may enable a tutor to guarantee a certain level of quality.

As a tutor can help out a student with substantive problems an administrator can help out in case of technical problems, e.g., if a door stays locked or certain resources do not become available due to bugs. An administrator has an overview of all students within specific runs and can open the player environment showing the progress of a specific student to diagnose the problem. Subsequently he can fix the problem by adjusting property values within the student’s progress. To adjust a property value he opens a similar dialogue as the one used to create a script action, which, after all, is meant to adjust a property value. If he saves the changed property value the Shared Progress Manager (see section 3.2) is used to send a p2p event to the student, which will result in a live update of the student’s progress so he can continue his game session.

Managing game runs. The run manager has an overview of all his runs and can perform

CRUD operations on them. Creating a run involves selecting a game from a list of all available games, giving the run a name and entering a start date and end date. It is important to stress that the game itself is not published but that the run just has a ref- erence to the game. This allows for adjustments of the game that are immediately available to students, e.g., in case of required bug fixes. It is even possible to let stu-

dents start with a part of a game while another part still is in development. The latter option has been used on various occasions.

Just like the administrator the run manager has the possibility to adjust property values within students’ progress during a run, but he may also initialize property values before a run. However, properties are not changed for one student but for all students in the run which allows for, e.g., assigning certain tasks to all students in the run at the same time. It also allows for configuring runs differently, e.g., in case of experiments where different runs should meet different experimental conditions. To adjust a property value the run manager uses a similar dialogue as the administrator (see above). If he saves the changed property value the Shared Progress Manager is used to send p2p events to all students in the run, which will result in a live update of students’ progress.

Populating the platform and game runs with users. The administrator has an overview

of all platform users and can perform CRUD operations on them. Creating a user in- volves assigning one or more platform roles to him, i.e., administrator, developer, run manager, tutor or student. Users can also be imported using an XML file containing predefined user data.

From his run overview the run manager can assign students to runs and game roles by selecting them directly or by importing them using an XML file containing predefined run user data. In the same overview he can also assign tutors to runs. He may also cre- ate teams of run users that have a shared progress for game components that allow user generated content such as the Resources and Google maps components. Students may extend the content of these components with their own resources and markers where extensions are stored in run team progress, which enables to see each other’s contributions to a same game component.

Integrating other systems. The platform offers SOAP (W3C, 2017) web services that

support the exchange of progress data with other applications that may adapt the play- er environment for a certain student. In an experiment, another application used webcam data analysis to derive a student’s mood and used the web services to trigger personalized game support depending on his mood (Bahreini et al., 2012). The web services allow for retrieving or setting state element property values of States compo- nents. If a property value has to be set the corresponding web service creates a proper- ty event for the student and invokes the Event Handler (see Figure 3.29) to handle it. Script conditions and actions then are used to adapt the game support depending on the set property value. Other web services support identity management to enable single sign-on.

In another experiment we integrated the Unity Web Player. A Unity game was shown embedded within the player environment by using a plugin element of the Navigation component. JavaScript functions were used to exchange data between the Unity game

and the EMERGO player environment, which resulted in adaptation of each other’s interfaces.