Designing an Educational Game Creator

for Non-ProgrammersGoals

Process

Results

Future WorkThe backend engine handles all of the logic that runs the actual game created by the user. One central concept that drove our implementation of the game creator was that the game should be modeled as a deterministic finite state machine. States represent a player’s cur-rent progress through the game, while transitions represent accomplishments and events that drive the player towards an end goal. This design offered the most flexibility in potential game designs in conjunction with being presentable and relatively intuitive to teachers using our software to create games.

The appeal of the state machine design lies in the ability to create arbitrarily complex game logic through the combination of simple primitives, namely states and transitions. Furthermore, for teachers with minimal programming experience in select scripting lan-guages, we provide a means by which transitions can be completely customized. The backend engine executes scripts in order to determine the outcome of state transitions. These scripts can be generated automatically or coded by the teacher creating the game. See the “Results” section for an example.

Backend Engine

Teacher Interface User Interface

Frontend Engine

The frontend engine handles player interactions when running the game created by the game designer. When the player performs a particular action while playing the game, the frontend engine interprets this as an interaction and determines any relevant input information, passing that information along to the backend engine. In order to keep the backend engine completely oblivious to implementation specific details regarding inter-actions, the frontend engine first translates its input into a format that the backend engine understands. It has a number of different components which take specific interaction types and translates them to generic attribute maps that the backend engine can then utilize.

The frontend engine consists of a single main module and a hierarchy of interaction prompt types and interaction types. For example, a game which supports multiple choice questions would allow the player to speak to a character in the game, generating a Multi-pleChoicePrompt object carrying question and answer information. Her response would then be recorded in a MultipleChoiceAnswer object, which would be passed back to the backend engine in order to determine the next course of action based on her answer.

The teacher interface is designed to follow the model of flow-chart based design sys-tems. An example system is Lego Mindstorm, which is designed for non-programmers. This presentation medium allows the game designer to very easily understand the over-all progression that the game player will follow. The designer can use the interface as both their game editor, and their storyboard.

The flow-chart design system fits the interaction-response model on which the Backend Engine is built. This allows the designer to have a full understanding of the underlying design of the game, without having to handle the tough programming aspects.

The major control points that the game designer controls are transitions. These transi-tions are scriptable in Python -- but can be expanded to many other languages -- and allow the designer to have complete control over how the game moves from one state to the next. However, with the use of built-ins and community generated content, the designer can make all these choices without ever seeing a line of code.

The user interface is designed to be as modular as possible. This design choice was made to make fast-iteration development possible, as well as making it easy to switch to differ-ent platforms. One of the most important design goals was to make this accessible to as many students as possible. This means the user interface must support Mac/PC/Linux as well as machines where native code execution is not possible, such as a public machine in a library. This would require support for a user interface that could be run in the browser.

Development began with a text-based user interface. At the same time, we began research into possible game engines to use for graphics. The three main engines considered were: OGRE, Irrlicht, and Panda3D. We decided to begin with Irrlicht because of its easier learning curve. However, we designed the user interface module such that we could cre-ate another interface built with a different graphics engine.

The role of video games in education is a relatively new and unexplored field. Studies have suggested that effective use of interactive entertainment can significantly improve how a student absorbs material. Teachers, expe-rienced in interacting with students on a regular basis, are in the perfect position to design educational games.

However, the extensive programming experience typically required in vid-eo game development limits the degree to which most teachers can actually develop educational interactive software. Whether building a game from scratch or from an existing game engine, the developer needs significant familiarity with programming in order to implement a proper video game.

Game creators requiring no such experience exist, but none are geared spe-cifically toward educational games. In this project, we built an implemen-tation of a simple game creator designed to allow teachers with little to no programming experience to develop meaningful, educational games for their students.

• Use of a graphics engine to support graphical games• Intuitive, simple UI for teachers to use to create games• Pre-implemented transition scripts• Support for more scripting languages for transitions• Proof-of-concept game created with our game creator• Support for community generated content• More interaction types• Support for creation of web based games

A proof-of-concept screenshot of the teacher UI. A teacher creating a game using our software uses a simple drag-and-drop interface to design games of arbitrary complexity. The blocks and connections shown in the interface represent the un-derlying states and transitions that drive the game logic in the backend engine.

The backend engine supports customizable scripts that determine the outcome of state transitions based on interactions that the player has with the game. In this particular example, the Python script checks the player’s response to a free response question. By using regular expressions, it allows a great deal of flexibil-ity in the answers it will accept as correct. The script also determines the game’s textual response to the player’s answer.

import re

def state_transition_0(am, gm): if re.match(‘([tT]he )?[Dd]eclaration [Oo]f [Ii]ndependence’, am[‘free_response_answer’]): gm[‘response_text’] = “““Great answer! The Declaration of Independence is one of the most important documents in the creation of the United States.””” return 0 else: gm[‘response_text’] = “Nope, not quite. Why don’t you try again!” return 1

A screenshot from the game design interface in Neverwinter Nights 2. Games with its level of complexity tend to have intimidating interfaces.

A screenshot from Neverwinter Nights 2. Ideally, teachers would be able to create games of this complexity and detail.

Patrick Costello (patrickc@cs.stanford.edu) Dawson Zhou (zhoud@cs.stanford.edu)Advisor: Steve Cooper