Extensions to xPST system to enable authoring tutors in 3D games

xPST systems has been extended to enable authoring of tutors in 3D games. Authoring in 3D games differs substantially from authoring tutors for traditional GUI software in terms of the inherent domain complexity involved, different types of feedback required and interactions generated by various entities apart from the student.

Enhanced xPST Architecture

3D Games Vs Traditional GUI Software or Websites

In a traditional GUI application or website, there are usually a set of controls (e.g. buttons, menus) that correspond one-to-one with a set of features. Some of these controls typically remain on screen while the user works. The two-part architecture typically consists of an application (e.g. Microsoft Word or Adobe Photoshop, or Amazon.com or Google.com) that has particular state while user-created content (e.g. a document, an image, or a query) is shaped by the user. A user's actions will typically evoke similar responses if done repetitively. In a game, on the other hand, a user's actions are frequently dependent on the context of other entities and the timecourse within the game. Rather than the user changing a file or query within an application that maintains a state, the gamer is focused on changing the application's state within the game state space. The states can be discretely defined, and they then act as the goalnodes: the user's goal is not to complete a textbox with a certain correct answer but rather to reach a specific state. The granularity at which these states needs to be defined depends on the author and the complexity of the task. The traditional GUI software and websites are typically a static system where all the events are triggered by the student (player). But 3D games are more like a dynamic system where interactions can happen between various entities in the game apart from the player and the events can be triggered by different entities in the game (e.g. by automated enemy players, or "constructive forces" in military terminology). The events generated are split into two categories: the events generated by the player and the events generated by other entities.

Unlike the traditional GUI software or websites, 3D games require the student to navigate through a simulated environment, the map, and sometimes communicate with the other entities in the game. This calls for the authoring system to provide tools to support tutoring on communication-based and location-based subtasks, e.g., "Identify yourself to the guard" or "Return to mission headquarters to give a report."

Extensions to xPST

In order to accommodate the differences between 3D games and traditional GUI software or websites, we have added the following extensions to the xPST architecture to facilitate easy authoring of ITSs in 3D games.

Actions by Non-Player Objects

Events can be triggered by non-player objects in 3D games. These events are modeled as hypothetical events by a Player-class object which is not the user.

For example Avatar1:request-answer is the goalnode corresponding to requesting an answer from the Avatar1 entity, where Avatar1 is the unique id of the entity and request-answer is the associated action. This approach is useful in tutoring on generic actions associated with any entity in the game, such as Tanker1:explode, Enemy1:attack. This is a more generic way of handling events compared to the previous xPST architecture in which the unique ID attribute always corresponds to the Player class object and was hence ignored while writing in the file. This is because the previous xPST architecture could support tutoring only on events generated by the Player.

Communication Events

Unlike the traditional GUI software or websites, many of the tasks in 3D games require the student to be able to communicate with other player entities in the game. We have extended xPST to support tutoring on communication events by using a special goalnode starttalk, to initiate the communication with other entities. The student will be able to choose the entity with which to communicate and the message to communicate. This approach facilitates tutoring on the protocol of communication and the message that is being communicated, a common training task in the military, where communication is frequently highly-structured.

Figure 1: Instantiation of starttalk goalnode along with the UI for the user to communicate with the other players.

If the student is supposed to choose Evacuate command for the task and if he chooses a different command, say, the Fire command, a JIT can be fired saying "You used Fire command on this occupant. That's not something you need to do right now." This multiple-choice user interface for tutoring on communication is designed to tutor on communication protocol and procedure: what to say and when and how to say it. Future research will evaluate its effectiveness within military scenarios.

Location Events

Location events facilitate tutoring on the navigational aspects of the player's performance. Unlike the traditional GUI software or websites, almost every task in a 3D game requires the player to move within the virtual environment. The author can use the entityid-enter goalnode to tutor on when the player enters a particular designated location in the game.

Figure 2: b1-enter goalnode is triggered when the player enters building1 (b1).

Torque Game Engine Advanced and TorqueScript

We have used Torque Game Engine Advanced (TGEA) as our simulation engine. It is a commercial off-the-shelf game engine from GarageGames. It provides various core functionalities required for game development like the rendering engine, physics engine, 3D graphs, collision detection etc. Instead of starting from the scratch, using an off-the-shelf game engine drastically reduces the game development time and helps the author concentrate more on the tutoring task.

TGEA supports scripting using TorqueScript. TorqueScript is similar in syntax to JavaScript and allows the developer to create modifications (mods) of the existing games. We have used TorqueScript to create the xPST Torque driver which contains two major modules, the Listener module and the Presentation module. The Listener module listens to the various events happening in the game and sends them to the xPST engine over the network. Then the xPST engine sends the appropriate tutoring feedback to the Listener module. This feedback is then presented to the user through the Presentation module.

The framework of the xPST driver can be leveraged to various other game engines by making the syntactical script changes required to be able to suit with that particular game engine. The Torque driver enables tutoring in 3D games created with Torque Game Engine.