Designing an Educational Game Creator
Goals
for Non-Programmers
Results
Patrick Costello ([email protected])
Dawson Zhou ([email protected])
Advisor: Steve Cooper
Process
A screenshot from Neverwinter Nights 2. Ideally, teachers would be able
to create games of this complexity and detail.
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, experienced 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 video 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 specifically toward educational games. In this project, we built an implementation of a simple game creator designed to allow teachers with little to
no programming experience to develop meaningful, educational games for
their students.
Teacher Interface
User Interface
The teacher interface is designed to follow the model of flow-chart based design systems. An example system is Lego Mindstorm, which is designed for non-programmers.
This presentation medium allows the game designer to very easily understand the overall progression that the game player will follow. The designer can use the interface as
both their game editor, and their storyboard.
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 different 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.
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 transitions 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.
Backend Engine
The 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 current 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 languages, 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.
A screenshot from the game design interface in Neverwinter Nights 2.
Games with its level of complexity tend to have intimidating interfaces.
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 create another interface built with a different graphics engine.
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 underlying states and transitions that drive the game logic in the backend engine.
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
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 interactions, 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 MultipleChoicePrompt 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 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 flexibility in the answers it will accept as correct. The script also determines the game’s
textual response to the player’s answer.
Future Work
•
•
•
•
•
•
•
•
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