Transcript Experiential Learning and Micro-Worlds for Business and

Software Game Design
Issues
Peter L. Jackson
School of O.R. and I.E.
Cornell University
What makes for a good
game?
•
•
•
•
•
•
Fast, fun, and understandable
Pleasing to the eye and to the touch
Competitive: nontrivial but not impossible
Social: stimulates interaction
Relevant: connects with the real world
Skill-building: not pure chance or autoplay
Overview
• Evolution of game software elements: a
personal history
• Examples from 7 games
•
•
•
•
Towards a data-driven game interface
Network game architecture
Game software design recommendations
Game design recommendations
The Mfg. Operations Game
Menu buttons
Text-based screen
Large font
List-limited inputs
The Distribution Game
Menu
Simple score
Few inputs
Graphical
analysis
Animated
pictorial
state of
system
Button control
Multi-purpose
screen sections
The Transportation Game
Multiple cascaded
screens
Drag and drop
interaction
Process Optimization
Menu buttons replace menus
Multi-purpose
screen sections
High impact
art
Diverse inputs
with pictorial
clues
Graphical
analysis
Quick help text line
The M.F.D. Pull Game
Animated pictorial state of system
Multi-purpose
screen sections
Message line
Quick help
text line
Centralized control panel
Situations Flavor the Game
The
Manufacturing
Operations Game
The M.F.D. Pull
Game
Commercial Game Screen:
“Deadlock”
Iconic menu
buttons
Pseudo 3-D
view with
high impact
animated art
Multiple
screen
sections
The M.F.D. THRUPUT Game
Pseudo 3-D
view with
high impact
animated art
Quick help
text line
Multi-purpose
screen sections
Centralized
control and
dialog panel
Query
control
dialog
Graphical
analysis from
database
query
Menu button
panel
The M.F.D. Thruput Game
Cyclical game
sequence control
The Engineering Factory
Large font
status row
Multipurpose
screen
sections
Variable
size
Menu
button
panel
Quick help
text line
High
impact art
section
Variable
size
Centralized
control and
dialog area
The Engineering Factory
Graphical
analysis from
database
query:
networks
and multilevel axes
Drill-down
list for
query
control
Multipurpose
screen
sections
Centralized
dialog panel
Situations Flavor the Game
Rich text
format
document
view;
document
stored in
database
3-D
rotational
view
Towards a Data-Driven
Game Interface
• Game components are becoming
standard
• Programming and layout is repetitive
• Data are coming from relational databases
• Put component descriptions in database too
• Databases provide both data and
instructions on how to display data
• Graphs, lists, tree lists, dialogs, control
panels, rich text documents, images
• Result: game interface is more generic
Towards a Data-Driven
Game Interface
Tables and
queries define
complex charts
Tables
define
dialogs
Queries
define
multi-level
indices
Network Game Architecture
Server
Game database
executes game
Map database
describes game
Clients
Clients
interact
with game
database
Game Software Design
Recommendations
• Use multi-purpose screen sections
• Reserve a section for a centralized
control panel (even if it blocks view)
• Make next steps obvious: eg. cycle
• Use high impact art
•
•
•
•
Illustrate situations
Animate resource states
Customize buttons
(Hire an artist)
• Don’t try to be funny: play it straight
Game Software Design
Recommendations (cont’d)
• Represent state of system pictorially
• Animate resource state changes
• Show history in graphical form
• Display status in large font
• (for instructor to see)
• Plan for different screen resolutions
• Use iconic menu buttons rather than
menus
• Add tool help text (balloons or text line)
Game Design
Recommendations
• Identify a small number of decision
variables in a repetitive decision problem
• Prefer low-level decision to high-level
• eg. Next city to visit rather than which TSP
algorithm to use
• Flavor the game with situations
• Break monotony of repetitive problem
• Illustrate complex problems but treat them as
exceptions
• Keep scoring (and tradeoffs) simple
For More Information
• Web page
• http:///www.orie.cornell.edu/~jackson
• E-mail:
• [email protected]