Data Driven Software Architecture for Game- Based Learning Systems

Transcription

1 Data Driven Software Architecture for Game- Based Learning Systems Marco Antonio Gómez-Martín 1, Pedro Pablo Gómez-Martín 1, Pedro A. González-Calero 1 1 Group for Artificial Intelligence Applications Facultad de Informática de la Universidad Complutense de Madrid C/ Prof. José García Santesmases, s/n Madrid (España) {marcoa,pedrop}@fdi.ucm.es, pedro@sip.ucm.es Abstract Authoring demands in commercial videogames are increasing more and more, due to the creation necessity of first-class graphics, sound effects and music that each level requires. Behaviour and dynamism is, obviously, also needed, what involves a tight work between designers and programmers. On the other hand, educational videogames posses their own requirements, adding to all these authoring tasks the necessity to create the exercises or pedagogical missions which students must afford throughout their learning. In order to soften this situation, we proposed to merge a game level and an exercise. This idea groups both authoring aspects (recreational and educational) and lightens the whole work. Unfortunately, it also adds a new requirement: the content creator must be both a good game designer and a domain expert. In this paper we describe our proposal to solve this second problem, using a layered architecture that breaks this dependency. Keywords Educational videogame architecture, content authoring, exercise and game level integration 1 Introduction A key challenge to move forward the state of the art in game-based learning systems is to facilitate instructional content creation by the domain experts. Several decades of research on computer aided instruction have demonstrated that the expert has to be deeply involved in the content creation process, and that is why so many effort has been put into building authoring tools of all kind. However, using videogame technology to support computer aided instruction poses some new challenges on expert-friendly authoring tools, related to technical and cost issues. Content in videogames takes two different forms: multimedia and gameplay. 3D models of scenarios, objects and characters, 2D textures to dress the models, animations, music and sound effects collectively define the multimedia content of a videogame. Gameplay defines "what the player does". Gameplay designers build the dynamics of the game world by providing a detailed description of what the player can do and what the game has to do in response. As the size and quality of videogames increase to respond to growing player expectations, game development projects are also growing to involve several hundreds people working for an average time of three years, where content creation takes a good bite of the budget. It is easy to argue that serious games provide new opportunities for building engaging and motivating learning environments, although up to now not many empirical studies have been made to demonstrate it. However, given for granted that game-based learning outperforms other computer aided learning technologies in certain domains, it is hard to argue that based on those benefits we are going to get a budget increased by several orders of magnitude. In

2 user model domain and pedagogical knowledge Select concept to to teach Select Exercise Play the exercise Solution Analysis Feedback Virtual Environment Figure 1: Learning by doing in virtual environments. order to be of practical use, videogame technology applied to learning has to become costeffective compared to state of the art computer aided learning technologies. Regarding multimedia content creation, the solutions, which the videogame industry is already pursuing, are procedural content creation and end-user content creation. For example, for the game Spore Maxis is developing procedural animation methods that allow to build new characters and automatically apply predefined animations on them. End-user content creation is becoming more popular in industry, both as a way to promote gamer attachment to the game and to profit from a mass of content creation volunteers. Instructional content creation for game-based learning is a form of gameplay content creation. The instructional designer must provide a detailed description of what the student can do and what the system has to do in response. With current technology the instructional designer should work in pair with a gameplay designer or become one himself. In this paper we present a data driven software architecture for game-based learning systems that supports a clear separation between instructional and gameplay content creation. This architecture is the result of an ongoing effort on several game-based learning systems in the software engineering domain. The rest of the paper runs as follow: next section describes the goals of the architecture. Section 3 describes in detail all the modules in the architecture. Section 4 presents some evaluation, describing the game-base learning systems that use it. Finally, Section 5 presents some conclusions and ends the paper. 2 A New Layer on Data Driven Content Creation The pedagogical model that we support is that of learning-by-doing, as shown in Figure 1. Using knowledge about the student, the domain and teaching strategies, the system selects the next concept to teach to a given user as well as the exercise to be used. The student tries to solve the problem within the virtual environment where he gets feedback from the system as he proceeds. We proposed to join an exercise and a game level as a way to incorporate the learning-by-doing cycle into the game mechanics [Gomez-Martín et. al, 2004]. In this framework, the obvious solution to design exercises in virtual environments, inspired on the way videogames are created, is to build a different game map for every exercise.

3 Figure 2: Two level data driven process A map or level in a videogame is the way a game designer translates a design document into the game virtual environment. The map identifies a number of entities (game objects) to be loaded when the player enters this level. The designer may configure the behaviour of the entities through the particular set of parameters for every entity type or, if greater control is required, through scripts that build complex behaviours from simple ones. The identity, initial location and specialized behaviours for a given map are usually saved in XML files that serve as the data in data-driven game engines. Taking this approach to content creation in game-based learning environments implies that the domain expert has to play the role of a game designer building a map or collaborating with one in that task. Our proposal is to provide a new layer of data, separating the definition of the exercise from the definition of the actual map where that exercise will be executed. Using this approach, an exercise defines a situation that has to be executed in the environment, giving an initial state and possible end states along with particular events that should occur and what to do if certain events are identified. The same map may be used to execute different situations, and the same situations can be represented in a different way depending on the map they are being executed on. A simple example of this idea is a driving tutor where the student always drives through the same streets but different events occur depending on the exercise. This way, we pursue two main benefits: To minimize dependencies between people involved in the creation process, especially between the domain expert and the game designer. To minimize dependencies between domain specific knowledge and the rest of the system, so that: o The same knowledge may be used with different presentation strategies. Given that identifying a successful game play is a crucial point for every game-based application, it is important to minimize the cost of experimenting with different alternatives. o The same presentation can be used to teach different contents, also reducing development cost by allowing defining different exercises on the same map. Figure 2 schematized the process. Using different (and specialized) authoring tools, domain expert and game designer create both an exercises and a game level templates base, in an

4 independent way. In runtime, the application particularizes a level using the information of an exercise. This late binding requires a supporting software architecture that fills the gap between the taught domain and the game, passing educational events and the state defined in the exercise to the videogame environment primitives and vice versa. Next describes our proposal. 3 Two Level Data Driven Architecture The proposed architecture, as showed in Figure 3, is composed of the following sub-systems: Tutoring subsystem: This subsystem is in charge of the pedagogical decisions, communicating with the rest of the system through the Communication module that connects to the Logical view of the world. Modules in the tutoring subsystem decide what exercise to use for a given student and when and how give feedback during the interaction. Logical view of the world: This module provides a high level description of the state of the virtual environment including those aspects that are relevant to the tutoring subsystem. Entities: Dynamic objects in the virtual environment are represented as entities that serve to connect the representation of the object in the virtual environment with the specification of its behaviour. Application engine: This subsystem is responsible for executing the interaction with the user, providing graphics, sound and physics for the 3D virtual environment. Next subsections describe in detail every module. Figure 3: Two level data driven architecture

5 3.1 Tutoring subsystem This subsystem is the core of the Intelligent Tutoring System (ITS) and is in charge of the pedagogical decisions. It uses the classic ITS architecture first presented by [Wenger, 1987], though depending on the complexity of the system, it should be relaxed to a simpler structure or promoted to a more sophisticated one. The relevant aspects from the main architecture point of view are: The tutoring subsystem has access to the student profile that is selected when the application starts. The module has also access to the exercise. In fact, the ITS selects it according to the student knowledge. It has a communication module that is the only contact with the external world. Through this link, the tutoring subsystem gets information about the progress on the exercise resolution, and other student information. The ITS may alter the virtual environment accordingly, for example providing some explanation. The basic actions that this module may perform in the virtual environment are then translated by the logical view depending on the actual representation of the environment. 3.2 Logical view This module stores the high level state of the learning system, and it is responsible of its behaviour. Two main aspects are under the control of the logical view: World dynamics: There may be a part of the state of the world that is not dependent on the exercise being executed but is governed by some rules that always apply within that domain. For example, in a system that simulates the working of an engine there are certain rules that specify how the state of the engine evolves as inputs are received. The tutoring subsystem may want to access to that part of the state but will not change the rules of the world. Exercise dependent state: This is the part of the state in the virtual world whose dynamics are determined by the exercise being executed. It has to be manipulated from the tutoring subsystem, including the behaviour of other avatars in the map as well as the monitoring of the student actions and decisions on how to interact with him. When the tutoring subsystem loads a new exercise, it informs to this module that initializes the world dynamics and exercise dependent state accordingly with it. During the exercise resolution, the logical view receives the relevant events from the objects in the environment, and updates its state. It also receives actions form the communication module of the tutoring subsystem. Some of them will require performing operations in the virtual world. In that case, the module translates them in primitive operations to be sent to the entities in the module above. 3.3 Game objects This module is responsible for the behaviour of the dynamic objects in the virtual world. Using videogame terminology, these objects are called game objects or entities, and may be seen as self-contained pieces of logical interactive content [Llopis, 2005]. In our context, these entities may be grouped into three different categories: Objects that are not relevant to the learning goals: They are fully defined as entities and can be reused in different learning environments. Some examples are doors, switches and elevators.

6 Objects that represent the world state relevant to the learning goals: They are governed by exercise independent dynamics, and get automatically their behaviour from the logical view through some automatic updating mechanism. One example of these entities is the object which represents the engine that is simulated by the world dynamics in the logical view. Objects that have exercise dependent dynamics: These objects are not fully defined in the module but have just their low level behaviour represented within it. They provide a set of high level perceptors and effectors for the logical view to control them. Game objects are created by the application engine using the map file. This file contains the list of entities that form the virtual environment. In the creation process, the game objects get their initial state from the data store in the file and are reconfigured using the state of the logical view, which has previously set according the current exercise. 3.4 Application engine The last module of the architecture is in charge of the lower level tasks, and is similar to the so-called game engine of videogames. We locate here the graphics and physics engine, the module that is able to play music and sounds, the layer that gets the state of the input devices, and the network controller. The application engine is usually created using external libraries (also known as components-off-the-self or COTS). The application engine is able to load the map files and start the creation of the game objects. Entities will then use all these subsystems as desire. For example, some entities will use the graphics and physics engine while others will only use the sound engine. 4 Evaluation JV 2 M 1 JV 2 M 2 Figure 4: Two different applications using the proposed architecture The architecture described in the previous section has been used in several game-based learning applications, changing different pieces in the process. In particular, we have used it to develop two versions of JV 2 M and one version of ViRPlay. JV 2 M [Gomez-Martín et. al, 2006a; 2006b] is a tutoring system aimed at teaching how to compile Java into the language of the Java Virtual Machine [Lindholm, Yellin, 1999] and, at the same time, promotes a better understanding of the underlying mechanisms of objectoriented programming. We have developed two different versions of the system (see Figure 4) with crucial differences between them such us the game play.

7 On the other hand, VirPlay [Jiménez-Diaz et. al., 2005] is a tool to understand the interactions in Java programs by means of role-play simulations in a virtual 3D environment. The tool follows an approach that mixes software visualization with an active learning task, such as role-play. Application engine Prototype JV 2 M 1 JV 2 M 2 ViRPlay WildMagic + GLUT Nebula 1 Nebula 2 Nebula 1 Gameplay Graphic adventure Graphic adventure Action game Graphic adventure Educational content - JVM JVM Java interaction Map files Hard-coded bsp (Half-Life 1) XML bsp (Half-Life 1) Animated models md3 (Quake 3) mdl (Half-Life 1) n2 (Nebula 2) mdl (Half-Life 1) Table 1: Different instances of our architecture. All these applications together with a preliminary version of JV 2 M gave us these variations (see Table 1): Application engine: o Preliminary version of JV 2 M used WildMagic as graphics engine that render over OpenGL and used GLUT to get the input from the user. The graphics engine was extended to support Quake3 animated models to represents virtual characters. o First version of JV 2 M and ViRPlay used Nebula 1 as game engine. This game engine provides us with the graphics engine and user input management. Both applications use the Half-Life map file format to store the virtual environment information. Nebula 1 was completed with the support of the animated models of the same game to being able to represents avatars in the environment. o The application engine of the second version of JV 2 M was rewritten to use Nebula 2 as game engine. We also changed the way the maps are store from Half-Life files to XML, and the animated models, that are now saved using a proprietary format of Nebula 2. Gameplay: though the content of both versions of JV 2 M is the same (compiling Java to the Java Virtual Machine), the gameplay is radically different: o First version is clearly inspired by graphical adventures such us Grim Fandango and Escape from Monkey Island from LucasArts. The actions the students may perform over the environment are look, take, use and use with. o The last version recalls action games. Student carries a weapon and she has to get rid of enemies and get resources to finish the exercise. Content: the architecture has been used in two different educational contexts. While JV 2 M teaches the Java Virtual Machine internals and how to compile Java code to it, ViRPlay uses role-play simulations to explain how different Java objects interacts in a design pattern [Gamma et. al, 1995]

8 5 Conclusions Content authoring is one of the hardest and time consuming tasks when developing commercial videogames. Players are used to near film-quality games, which require more and more production time. When videogames are enriched with educational content, the creation work is increased with the necessity of exercises which probe that the student (gamer) is correctly learning the subject. A natural approach is to merge each game level with an exercise, in such a way that a learning episode is created at the same time that a level. Unfortunately, this also forces that the person who builds the level must know the taught domain. And the authoring tools must cover both educational and game requirements. Our proposal breaks this dependency with a two level data driven architecture. Domain experts create exercises in a game-independent way, and game designers create game level templates without concrete exercises in mind. Authoring tools are specialized in each aspect of the creation. When the educational game launches, both layers are procedurally joined in run-time, adapting the game level template in accordance with the exercise. To support this process, and let the system to adapt the student knowledge, different software modules are needed. The two layered data-driven model is in this way implemented using an architecture were educational and videogame aspects are enclosed in independent components, that are only in contact through an intermediate module that maps the high level (domain specific) actions in the virtual world primitives, and vice versa. Acknowledgement This work has been supported by the Spanish Committee of Education and Science project TIN C03-03 and it has been partially supported by the Comunidad de Madrid Education Council and Complutense University of Madrid (consolidated research group ). References E. Gamma, R. Helm, R. Johnson, J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Profesional, M. A. Gómez-Martín, P. P. Gómez-Martín, and P. A. González-Calero. Game-Driven Intelligent Tutoring Systems. Entertainment Computing (ICEC 2004), 3 rd International Conference, pp Eindhoven, The Netherlands, Springer, M. A. Gómez-Martín, P. P. Gómez-Martín, and P. A. González-Calero. Dynamic binding is the name of the game. Entertainment Computing (ICEC 2006), 5 th International Conference, pp Cambridge, UK. Springer, 2006a. M. A. Gómez-Martín, P. P. Gómez-Martín, P. Palmier-Campos, and P. A. González-Calero. Not yet another visualization tool: Learning compilers for fun. Proceedings del 8th International Symposium on Computers in Education, SIIE'06, pp León, Spain, 2006b. G. Jiménez-Díaz, M. Gómez-Albarrán, M. A. Gómez Martín and P. A. González-Calero. ViRPlay: Playing Roles to Understand Dynamic Behavior. 9th Workshop on Pedagogies and Tools for the Teaching and Learning of Object Oriented Concepts, at 19th European Conference on Object Oriented Programming, T. Lindholm and F. Yellin. The Java Virtual Machine Specification. 2 nd Edition. Addison-Wesley, Oxford, 1999 N. Llopis. Introduction to Game Development. Chapter: Game Architecture. Charles River Media, E. Wenger. Artificial Intelligence and Tutoring Systems: Computational and Cognitive Approaches to the Communication of Knowledge. Morgan Kaufman, 1987.