Building an Educational Adventure Game: Theory, Design, and Lessons.

Creation of complex educational software involves many different activities that include the use of appropriate educational pedagogy, development of resources, software creation and authoring. Some authors have argued that play is part of the learning process and that simulation and adventure games could be used as viable educational tools. This article presents a model for the development of an "edventure" (educational adventure game) game based on educational theory. It highlights the lessons learned in the development of Zadarh, a game developed to address misconceptions held by biology students. The intent is to present information that could foster discussion and a greater understanding of the processes involved in the construction of complex interactive learning tools.

Authors such as Quinn (1994) and Rieber (1996) have argued that play, and play associated with games, is an important construct of learning. Play, especially during early childhood, performs important roles in psychological, social, and intellectual development, and could be defined as a voluntary activity that is intrinsically motivating, involves some level of activity (often physical), and may possess make-believe qualities.

Two types of games (simulation and adventure) have been proposed as appropriate viable educational tools (Quinn, 1994, 1997; Roberts, 1976; Ju & Wagner, 1997; Amory, Naicker, Vincent, & Adams, 1999b). Skills required to play adventure games include logic, memory, visualisation, and problem solving (Quinn, 1994, 1997; Amory et at, 1999b). Games can affect cognitive functions and motivation (Rieber, 1996) and inherently stimulate curiosity (Thomas & Macredie, 1994) by including challenges and elements of fantasy (Malone 1980, 198l a,b), novelty, and complexity (Carroll, 1982; Malone, 1984; Malone & Lepper, 1987; Rivers, 1990). Neal (1990) argued that games promote goal formation and competition. Modem educational theories argue that developments of such skills are fundamental to all learning (Saljo, 1979; Schank & Cleary, 1995).

Simulation games, in preference to other game-types, are often used in educational environments as students can be focused on single goals, there is decreased competition between students, and such games allow students to explore or experiment at their own pace (Roberts, 1976). However, such simulation games are based on the concept that students need to engage in real-world activities and fail to acknowledge that play is part of our everyday lives; it is not the opposite of work as is leisure (Blanchard & Cheska, 1985), and appears to be a universally accepted mode of learning.

Games represent one way that learners can be immersed in constructivist microworlds. Here, users do not study a particular domain but become part of the scenario, thus stimulating interest and motivation. Microworlds differ from simulations in that they present the user with a simple domain that can be reshaped by the user to explore complex ideas (Rieber, 1996). Also, self-regulation is an important aspect of microworlds. Learners appear to be intrinsically motivated (Malone & Lepper, 1987), metacognitively active, behaviourally active and self-evaluating (Rieber, 1996) while playing games. Rieber believes games, rather than simulations, may provide a meaningful way to present microworlds to learners. Therefore, educational games could be viewed as instruments that promote the use of modem educational theories in the classroom.

Harrigan (1999) argued that dramatic theories, which provide practical techniques, could be incorporated into the design of educational software to heighten game play. He proposed that interactive teaching software should include effective movement (Laban, 1980) and actions that have a beginning, a middle, and an end (Stanislavski, 1981). Therefore, the addition of actors into virtual learning spaces could be used to provide additional motivation and drama, or could act as a learning tutor.

This article presents a model for the conceptualisation of educational games based on the initial work of Quinn (1994) that integrated modem theories of education. This model also attempts to address the relationship between theory and practice. The design and creation of an adventure game, Zadarh, is then explored and the lessons learned during this process presented. Finally, some user interface issues related to the design of the game are described. The objective of this article is therefore to describe the development of an edventure (an educational adventure game) to highlight theoretical, developmental, and practical issues. The article first explores game design (including the conceptualisation of the different levels) and then provides insights into resource development.

GAME DESIGN

Quinn (1994) described the development of games from a number of aspects that include system- versus user-centred design, models of instruction, element of fun, and the steps for instructional game design (based on the typical scenario used to design software). While this model was supported by educational theories, there is no implicit integration of theory and design. In an attempt to formalize the relationship between education theory, game design, play and development, we developed the Game Object Model (GOM) (Amory et al., 1999b). In this section the GOM is described, an overview of the game is provided and the use of GOM in the design of the game is discussed.

Game Object Model

GOM (Figure 1) attempts to create dialectic between pedagogical dimensions and game elements, and includes components (represented by rounded squares) that promote educational objectives (abstract) and those that allow for the realization of such objectives (concrete) contained within different spaces. Components accommodate either abstract or concrete interfaces (represented by circles: abstract, black; concrete, white). Components may either be freestanding or part of other components in which case they inherit all the parent interfaces. Inner components contain concrete interfaces while the outer ones are more abstract. Interfaces are also listed from the most to least important.

Therefore the game space component consists of four motivational interfaces (play, exploration, challenges, and engagement) and contains the inner visualisation space component. This visualization space component includes two domain spaces (game elements and problem components). The visualization space component contains the story line, critical thinking, discovery, goal formation, goal completion, competition, and practice interfaces. The elements component contains components and interfaces (fun, graphics, sound, and technology) that make up the story line, appearance, and playability of the game and are related to the discovery and goal formation interfaces of the visualisation space component and engagement of the game space component. The elements component includes the actor component that is specifically related to the engagement and story line interfaces and contains one abstract interface (drama) and two concrete (interaction and gestures) interfaces. The actor component therefore also inherits all the interfaces from its parent, the elements component.

The other interfaces of the visualisation space components (critical thinking, discovery, goal formation, goal completion, competition, and practice) are expressed by way of the manipulation, memory, logic, mathematics, and reflexes interfaces of the problem component. Pedagogical elements are therefore represented by abstract interfaces and game elements by concrete interfaces.

Game Description

Zadarh was designed to provide learning resources to address specific misconceptions held by biology students. A survey of senior secondary and junior tertiary level students identified Mendelian and molecular genetics, photosynthesis and respiration, human evolution, and 2D/3D visualization skills as difficult topics. Research was then undertaken to identify specific misconceptions related to each topic. The game consists of a number of levels, each associated with a single biological concept previously identified.

At the start of the game the player is informed that a scientist developing new viruses has been killed by one of his creations. The research laboratory has been evacuated and sealed to prevent the spread of the virus. The player, wearing a biohazard suit, is then invited to undertake a mission to find an anti-viral component that the scientist has hidden in the research laboratory. After accepting the mission the player needs to navigate through a 5 x 2 x 5 maze to reach a lift that is used to reach different levels of the game. In the level on human evolution the player solves a number of puzzles to eventually retrieve a vial of RNA. Successful completion of the next level, based on photosynthesis and respiration, provides the player with a supply of oxygen, a carbon dioxide cylinder used to extinguish a fire, and vials containing DNA bases. Basic understanding of Mendelian genetics is used in the next level where the player finds seeds that have been molecularly altered to contain the anti-viral DNA seque nce that is used in the final level to develop a vaccine.

The mouse was used for all navigation through, and interaction with the game. In each scene a player is able to walk forward or backwards, or is able to turn right or left. While investigating the game space the player finds objects, which can be collected, and solves puzzles to gain additional information or to progress to other game areas.

Use of the GOM

Conceptually, the creation of an educational game could be viewed from three perspectives: content domain identification (research-based), game resource creation, and software development (Figure 2). The design of the game was based on the idea that exploration and problem solving may overcome identified misconceptions. Therefore, puzzle conception and story development are closely related to research undertaken to identify learning problems and misconceptions (the domain identification phase).

Therefore, before any elements of the level were designed, sets of learning outcomes were described. This allowed for the identification of puzzles and hence the information needed to solve the puzzles. A single room was created for each identified misconception and thereby the goal formation interface, which is linked to the discovery interface, could be described for each room. All the information embedded in a room is directly related to the goal formation interface. Thereafter, a number of related puzzles were conceptualized for each room based on the information and learning outcomes, and incorporated at least two of the concrete problem interfaces (manipulation, memory, logic, mathematics, and reflexes). The goal completion interface was achieved through the solving of puzzles and allowed players to progress to a different part of the game or to discover new objects or information.

The look-and-feel of each room (graphics, sound, and technology interfaces) was only designed after the puzzles and information had been described and were used as a means to reinforce the core concepts. The interplay between concrete and abstract interfaces allowed easy identification and description of all the complex game elements and helped in game documentation, identification of appropriate technologies needed to be built into the game editor and player, and finally the production of a detailed story line with integrated puzzles. The model allowed careful matching of learning objectives with the different elements of the game and allowed careful planning of the different levels of the game and the incorporation of appropriate interactions. While the model served as a basis for the conceptualisation of the game levels (i.e., the specification phase of the Quinn Model), an action research approach was used to test each level and interface design. In the next section the game resource creation and softwar e development phases (Figure 2) are explored.

GAME RESOURCE DEVELOPMENT

The Game Page Editor and Playback engine were programmed concurrently with puzzle and story development. Game logic, images, effects, navigational areas and puzzles were integrated using the Game Page Editor to produce a game file for the Playback engine. This arrangement and interconnections of the different components (Figure 2) allowed educational concepts and research to influence the development of the game and provided a framework for the following discussion.

Tools

Three-dimensional graphics were created using 3D StudioMax (Kinetix) running under Microsoft NT version 4. Picture editing and additional graphical material was created using PhotoShop (Adobe). Game creation and playback software that runs under Windows 95, 98, or NT was developed using a Pascal programming tool (Delphi, Borland, Version 3).

Game Construction

Initially members of the development team were encouraged to play commercial games such as Myst, Rama, and Zork Nemisis to develop a sense of how commercial computer games designers handled various technical and design aspects. It was especially important that the graphic designers had a clear and holistic vision of a level before actually creating the computer resources. Only after the storyboard and puzzles had been decided on did the construction of a level using 3D Studio Max begin.

At each navigational point in a level the player is normally able to move in four directions (north, south, east, and west). Therefore, correct placement of objects in a room, camera angle, continuity between scenes, accurate texture mapping, and ease of navigation had to be carefully designed and constructed, as such elements can disrupt the visualization and programming of the game.

Object Placement

It was imperative that all objects be correctly scaled and placed in logical positions so as to create realistic worlds. A constant field of view (FOV) within a room was used in order to check that all objects would render correctly from different vantage points. Another lesson learned was not to have scenes in which pickup objects could be seen from different vantage points. For example, if two objects could either be visible, or absent, from four different camera angles, then the scene has to be rendered four times at each camera point (16 shots). While this is time consuming, it also created a real problem for the game programmer. A conscious effort should therefore be made to hide such interactive elements in a scene from the rest of the room. Elements such as screens and strategically positioned walls made such isolation possible.

The Camera

It was very important to keep the camera angle (height from ground and tilt) consistent throughout the game. As the camera represents the "eyes" of the player, the tilt and height from the floor of the camera should therefore represent eye level of the player. If this angle is not kept constant, then erratic tilting of the viewpoint disrupts the flow of movement forward through a room, or from one room to another. To ensure a consistent "eye level," the camera was placed about 1.7 m above the floor of each scene and tilted 40 downwards to simulate the slight down casting of the eyes when looking forward.

Scale

The first scene was rendered using a camera with a 50 mm lens. This lens caused distortion of the objects in the scene, making them appear slightly stretched. By switching to a 35 mm lens, the scene's perspective appeared normal or close to what the eye sees. Technical aspects such as this are important for conveying a sense of realism. Along with the camera FOV, the scale of objects needs to be in proportion to one another for the scene to appear convincing.

Texture Mapping

Realism of objects required well-designed surface materials and accurate mapping. The material assigned to an object gives it its surface characteristics such as colour, texture, shininess, and transparency. It was found that when tiling a material, that is repeating the bitmap to cover a larger surface area without stretching the material, its repetition should be unnoticeable in order for the surface to look as natural as possible and for the eye not to be distracted by the tiled surface. The only time a repetitive pattern succeeded was in creating a wallpaper effect such as in the library scene where the wall appears to be covered in an "evolution theme" wallpaper. At times, the use of tiled materials created false patterns. This was due to tonal variations at the edges of the bitmap resulting in sharp edges and lines, or when the bitmap contained a distinctive focal point. Touching up the bitmap in Adobe PhotoShop so that the tonal value of the bitmap matched on all four sides of the bitmap and its patte rn lined up when duplicated vertically and horizontally easily solved the first problem. As we created many of our own textures using a digital camera and/or Adobe PhotoShop, successful tiling of materials was an important issue in almost every scene.

In reality things get dirty in time due to wear and tear through use, or through the gathering of dust. If all the objects of the scene are totally spotless, the scene then looks unnatural and almost surreal. The problem with adding dirty patches to a material is that the dirty mark, however subtle, will form a distinct pattern when the material is tiled. We therefore tended to give only smaller objects in the scene, such as a computer monitor or telephone, which required less tiling (perhaps only one or two tiles), a "well-used" appearance. The irregular shape of these objects helped to hide any repetition of the dirty patches. For larger surface areas such as walls, floors, and tabletops very busy designs such as wooden slats, wallpapers, and rock textures were used and plain monochrome surfaces were avoided.

The 3D Max file size and rendering times increase each time an additional bitmap is assigned to an object. The bookshelf in the library scene comprised dozens of books, each drawn as separate objects and textured with different bitmaps. This resulted in extremely large files and very slow rendering times. To solve this problem, it is better to map a single texture map made up of many images on to all the books on a shelf.

Floor Plans and Image Generation

To help the game creation programmers each room was drawn to scale and each camera position identified numerically. Different sections of the room were each allocated a three-letter area code. Graphic files when rendered were labelled according to the scheme xxxyyd when xxx represented the area code, yy the camera position and d the direction. This scheme allowed all members of the team to easily identify different pictures and allowed the game programmer to develop logic whereby individual graphic files could be stored into single game files (see below). Each graphic was rendered in millions of colours at 540 by 405 pixels. Therefore each file occupied 640 KB of disk space. During the creation of the game files each image was reduced to 256 colour (214 KB) and stored in a temporary and final format. Therefore a minimum of 1.25 MB of disk space was required for the storage of each image. To allow for the storage of all the images and other resources the final game was assembled on a computer with an 8 GB SCS I hard drive.

Game Page Development

Specially created software, developed in Delphi, was used to add the hotspots and interactive logic to each game page that represents a single view in the game. While the addition of navigational area to the images was easy, development of a language that communicated with the game player was difficult and changed constantly as the development of the game engine progressed. Not wanting individual images to be accessible by players, a game file format was developed where all the different elements could be stored in a single file. Each of these game files contained all the images and game logic files related to a single area defined in the original floor plans. This file structure created problems when a single room contained many vantage points (individual files up to 250 MB in size). To overcome this problem large rooms were divided into different parts, each with their own area code. This method of creating game files was most successful as it allowed the page developer to program and test small parts of t he game and rapidly correct errors. However, the production of game pages was very time consuming and was often repetitive, resulting in errors in game logic.

Game Player

The game player is simple in concept but complex in design. As players navigate from page to page using the navigational hotspots, different images are displayed and associated game logic interpreted. The complex parts relate mostly to interaction with different objects that players can pick up and use in different pages to solve a problem or unlock a door. The game was developed to run on the student Local Area Network 200 Hz computers with 64 Mb RAM at 16-bit colour running Windows NT and used Microsoft's DirectX game technology. We chose 16-bit colour to remove the problem of palette swapping while displaying the different images.

All the effects (such as water and fire) and animations were built into the game engine. Puzzles, on the other hand were created as Dynamic Link Libraries. This allowed us to rapidly develop a stable game engine that can execute code stored externally to the engine. Such an approach also allowed greater complexity and different types of interactions to be introduced into play.

USER INTERFACE

It was not the intention to discuss issues of human-computer interaction, but rather to highlight three important elements related to the game interface. The interface has gone through three iterations. During student interaction with each design their ability to access the different components of the game was observed. This part of the article discusses the use of hotkeys (such as F1 for help), identification of user-interface components and navigational issues.

It was found that most of the students were very inexperienced computer users and therefore had little innate knowledge of standard Windows conventions. While experienced users were quickly able to find the help screens, novice users were unsuccessful. In the final interface design all subcomponents of the game were assessed early with a single mouse click through interactive buttons (Figure 3).

The students were unable to recognize standard iconic information (Amory, Mars, & Meyerowitz, 1999a). Therefore, each interface element needs to be clearly identified. In the final interface design a descriptive label appears in a small window at the bottom left of the screen as the mouse pointer moves over an interface element.

A player is able to view each navigational point in the game from four directions (north, south, east, and west). Arrow cursors were used to identify each direction that the player could navigate. For example, a forward arrow was used to indicate that the player could move forward. Inexperienced players found this convention difficult to follow and did not realize that by clicking when the left, forward, right, and back arrows were visible, that the view rotated 90[degrees] to the left, moved forward, rotated 90[degrees] to the right, or moved backwards respectively. To solve this problem a number of view transitions were built into the game: images were blended when moving forwards or backwards (i.e., the current and next view were mixed so that the current view blended into the new view), and when turning left or right the current view and new view were scrolled into view either from the right or left. This mechanism visualized the types of navigational movements and helped students to understand the direc t relationships between cursor shape, change between views, and movement through the virtual space. As this mechanism slowed the transition from one game point to the next, and therefore game play, a mechanism was provided to change the rate of transition from none to very smooth.

CONCLUSION

This article highlights the theoretical basis for the development of adventure games and describes some of the processes, problems, and solutions learned during the development of Zadarh. The GOM proved to be useful as it allowed educational philosophies to be closely allied with the development of the game and provided a framework for story and interactive puzzle creation. While the creations of game resources were demanding and complex, reporting of solutions to common problems could inform other developers and thus decrease the learning curve in developing such educational tools. This narrative of experiences could also foster greater understanding of the processes, problems, and solutions in the construction of complex interactive learning tools that support modem methods of educational practice.

Note

I wish to acknowledge research grants from the University of Natal Research Fund and National Research Foundation that made this research possible. I would also like to thank all of the students who have been involved in this project for their hard work and Jacky Vincent for her creative talents. Finally thanks to Patsy Clarke for her proof-reading skills.

References

Amory, A., Mars, M., & Meyerowitz, J. (1999a). Evaluation of efficacy of multimedia learning: Project development and strategies. South African Journal of Education, 19, 1-8.

Amory, A., Naicker, K., Vincent, J., & Adams, C. (1999b). The use of computer games as an educational tool: 1. Identification of appropriate game types and game elements. British Journal of Educational Technology, 30, 311-322.

Blanchard, J.S., & Cheska, A. (1985). The anthropology of sport: An introduction. MA: Bergin and Garvey.

Carroll, J.M. (1982). The adventure of getting to know a computer. IEEE Computer, 15, 49-58.

Harrigan, K.A. (1999). Applying theories used in drama to the design of educational multimedia. In B. Collis & R. Oliver (Eds.). Proceedings of ED-MEDIA 99, World conference on educational multimedia, hypermedia and telelcommunications, pp. 1314-1315. Seattle, Washington, USA, 19-24 June. Charlottesville, VA: Association for the Advancement of Computers in Education.

Ju, E., & Wagner, C. (1997). Personal computer adventure games: Their structure, principles and applicability for training. Data Base for Advances in Information Systems, 28, 78-92.

Laban, R. (1980). The mastery of movement. Plymouth, MA: Macdonald & Evans.

Malone, T.W. (1980). What makes things fun to learn? A study of intrinsically motivating computer games. Technical Report CIS-7. Palo Alto, CA: Xerox PARC.

Malone, T.W. (1981a). Toward a theory of intrinsically motivating instruction. Cognitive Science, 5, 333-369.

Malone, T.W. (198lb). What makes computer games fun? Byte, 6, 258-277.

Malone, T.W. (1984). Heuristics for designing enjoyable user interfaces: Lessons from computer games. In J.C Thomas & M.L. Schneider (Eds.) Human factors in computer systems, pp. 1-12. Norwood, NJ: Ablex.

Malone, T.W., & Lepper, M.R. (1987). Making learning fun: A taxonomy of intrinsic motivations for learning. In R.E. Snow & M.J. Farr (Eds.) Aptitude, learning and instruction III: Cognitive and affective process analysis, pp. 223-253, Hillsdale, NJ: Lawrence Erlbaum.

Neal, L. (1990). Implications of computer games for system design. In D. Diaper, D. Gilmore, G. Cockton, & B. Shackel (Eds.) Human-computer interaction. Proceedings of INTERACT '90, pp. 93-99. North Holland: Elsevier.

Quinn, C.N. (1994). Designing educational computer games. In K. Beattie, C. McNaught, & S. Wills, (Eds.) Interactive multimedia in university education: Designing for change in teaching and learning, pp. 45-57, Amsterdam: Elsevier.

Quinn, C.N. (1997). Engaging learning. ITForum Paper 18. [Online]. Available http://it.coe.uga/itforum/paperl8/paperl8.html

Rieber, L.P. (1996). Seriously considering play: Designing interactive learning. environments based on the blending of microworlds, simulations, and games. Educational Technology, Research and Development, 44, 43-58.

Rivers. R. (1990). The role of games and cognitive models in the understanding of complex dynamic systems. In D. Diaper, D. Gilmore, G. Cockton, & B. Shackel (Eds.) Human-computer interaction. Proceedings of INTERACT '90, pp. 87-92. North Holland: Elsevier.

Roberts, N. (1976). Simulation gaming: A critical review. (ERIC Document No. ED 137165)

Saljo, R. (1979). Learning in the learner 's perceptive. Some common-sense conceptions, Reports from the Institute of Education, University of Gothenburg.

Schank, R.C., & Cleary, C. (1995). Engines for education. Hillsdale, NJ: Lawrence Erlbaum.

Stanislavski, C. (1981). Creating a role. London: Methuen.

Thomas, P., & Macredie, R. (1994). Games and the design of human-computer interfaces. Educational Technology, 31, 134-142.