This document discusses game prototyping and evaluating Processing as a platform for it. It begins by defining play and games, explaining that play involves imaginary worlds separate from reality with their own rules and goals. Games similarly involve rule-based competition with varying outcomes. Game prototyping is useful for testing game mechanics before full development. The document then introduces Processing as a programming language and environment that can be used for rapid game prototyping due to its simplicity. An example game prototype created in Processing is presented to demonstrate its capabilities for this purpose.

1. Evaluating
Processing
as
a
Platform
for
Game
Prototyping
Daniel
Volk
28.03.2011

2. Agenda
• Part
I
–
Game
Prototyping
• What
is
a
Game?
• Why
Game
Prototyping?
• Part
II
–
Processing
• What
is
Processing?
• How
to
use
Processing?
• Part
III
–
Game
Prototype
• An
Example

3. Part
I
–
Game
Prototyping
• What
is
Play?
• [Play
is]
...
„a
free
ac8vity
standing
quite
consciously
outside
„ordinary“
life
as
being
„not
serious“,
but
at
the
same
Lme
absorbing
the
player
intensely
and
uMerly.
• It
is
an
acLvity
connected
with
no
material
interest,
and
no
profit
can
be
gained
by
it.
It
proceeds
within
its
own
proper
boundaries
of
8me
and
space
according
to
fixed
rules
and
in
an
orderly
manner.“
[Johan
Huizinga]
• The
Magic
Circle
• Game
Space
• Game
Time
(
)
...
primarily
true
for
games
...
the
real
world
the
ficLonal
game
world

4. Part
I
–
Game
Prototyping
• What
is
Play?
• Play
is
free
–
would
otherwise
loose
quality
as
diversion
• Play
is
separate
–
described
by
limits
of
space
and
Lme
• Play
is
uncertain
–
course
and
results
are
not
known
beforehand
• Play
is
unproduc8ve
–
creates
no
wealth
or
goods
• Play
is
governed
by
rules
–
a
new
legislaLon
is
established
• Play
is
make-­‐believe
–
it
creates
a
reality,
different
of
real
life
• Components
of
play
• Agon
(≈
compe88on)
• Alea
(≈
chance)
• Illinx
(≈
frenzy)
• Mimikry
(≈
masquerade)
[Roger
Caillois]

5. Part
I
–
Game
Prototyping
• What
is
a
Game?
• Games
can
be
the
origin
of
play.
• „Reduced
to
its
formal
essence,
a
game
is
an
ac8vity
among
two
or
more
independent
decision-­‐makers
seeking
to
achieve
their
objec8ves
in
some
limi8ng
context.
A
more
convenLonal
definiLon
would
say
that
a
game
is
a
context
with
rules
among
adversaries
trying
to
win
objecLves.“
[Clark
C.
Abt]
• „A
game
is
a
form
of
art
in
which
parLcipants,
termed
players,
make
decisions
in
order
to
manage
resources
through
game
tokens
in
pursuit
of
a
goal.“
[Greg
CosLkyan]

6. Part
I
–
Game
Prototyping
• What
is
a
Game?
• „Games
are
rule-­‐based“
• „Games
have
variying
endings,
with
different
numbers
assignable
to
a
specific
outcome“
• „The
different
potenLal
outcomes
of
the
games
are
assigned
different
values,
some
posiLve
and
some
negaLv“
• „The
player
exerts
effort
in
order
to
influence
the
outcome“
• „The
player
is
emo8onally
aLached
to
the
outcome
of
the
game“
• „The
same
game
(≈
rules)
can
be
played
with
or
without
real-­‐
world
consequences“
[Jesper
Juul]

7. Part
I
–
Game
Prototyping
player(s)
game
token(s)
game
space
game
8me
game
rules
ac8vity
game
goals
compe88on
decisions
1:0
outcome
challenge
aLachment
consequences

8. Part
I
–
Game
Prototyping
• Game
Rules
• DifferenLaLon
• (Game)world
rules
• Rules
define
the
boundaries
and
behaviour
of
the
world
containing
the
player
(or
his
avatar)
–
the
infrastructure
upon
which
the
game
exists
• Non-­‐digital
gameworld
rules
are
typically
defined
by
the
specs
of
the
real
world,
digital
games
need
to
be
defined
at
first
• Example
(non-­‐digital):
the
level
of
gravity
in
a
soccer
game
(g
=
9.81
m/s2)
• Example
(digital):
the
types
of
interacLons
possible
within
the
gameworld
• Gameplay
rules
• Rules
define
the
possibility
space
seman8cally
relevant
for
the
game
• Example
(non-­‐digital):
a
ball
that
crosses
the
goal
line
increases
the
score
• Example
(digital):
the
number
of
lives
a
jump‘n‘run
character
has
...
also
generic
mulLverses
like
SecondLife
implement
this
category
of
„game“
rules

9. Part
I
–
Game
Prototyping
• Game
Rules
• Basics
• Game
rules
give
games
structure
• Game
rules
need
to
be
unambiguous
and
repeatable
• Game
rules
need
to
be
fixed
and
binding
• Game
rules
need
to
be
balanced
• Understandings
• Game
rules
are
limita8ons
• Rules
define
obstacles
that
impose
challenges
to
the
player
• Example:
a
field
player
in
soccer
is
not
allowed
to
use
his
hands
• Game
rules
are
opportuni8es
• Rules
define
possible
ac8ons
that
offer
choices
to
the
player
• Example:
you
can
try
to
provoke
the
opposing
player
using
his
hands
...
e.g.
sensorimotor
challenges
in
soccer
(which
are
especially
interesLng,
since
conflict
is
involved)

10. Part
I
–
Game
Prototyping
• Game
Rules
• Levels
• Opera8onal
rules
• Are
visible
on
the
surface
(e.g.
in
form
of
a
rule-­‐set)
• Are
procedurally
formalized
by
instruc8ons/constraints
• Are
more
precise
(specific
for
one
game)
• Cons8tua8ve
rules
• Lie
hidden
underneath
the
surface
• Are
descrip8vely
formalized
by
a
finite
state
machine
• Are
more
abstract
(specific
for
a
class
of
games)
• Implicit
rules
• Are
surrounding
rules
that
are
defined
by
the
player
community
• Are
typically
unwriLen
and
ojen
conveyed
outside
the
game

11. Part
I
–
Game
Prototyping
• Game
Rules
• General
approaches
• Games
of
Emergence
• The
gameplay
challenges
emerge
in
parallel
from
a
set
of
simple
(first-­‐
order),
interacLng
rules
(which
generates
a
wide
decision
tree)
• Is
typically
build
around
a
strong
simulaLve
core
• Games
of
Progression
• Gameplay
challenges
are
constructed
serially,
by
way
of
special
case
(second-­‐order)
rules
(which
generates
a
narrow
decision
tree)
• Is
typically
build
upon
a
strong
narraLve
backbone
• Gameplay
• The
player
is
challenged
by
obstacles
while
working
towards
the
goals
(and
their
rewards);
to
overcome
the
obstacles
he
makes
choices
about
the
right
acLons,
interacts
with
the
game
accordingly
and
in
doing
so
he
unfolds
the
gameplay
...follows
the
principle
of
„easy
to
learn,
difficult
to
master“

12. Part
I
–
Game
Prototyping
• What
is
a
Videogame?
• „A
videogame
is
a
game
which
we
play
thanks
to
an
audiovisual
apparatus
and
which
can
be
based
on
a
story“
[Nicolas
Esposito]
(
)
...
although
true
for
classic
games
...
a
ficLonal
virtual
world
the
ficLonal
game
world
the
Magic
Circle
Remember
the
(Game)world
rules?
Remember
the
Gameplay
rules?
the
real
world
can
be
an
abstracLon
of

13. Part
I
–
Game
Prototyping
• Interac8vity
• „Just
as
the
schwerpunkt
of
computers
is
processing,
so
too
the
schwerpunkt
of
all
sojware
is
interac8vity
–
and
this
goes
double
for
games.“
• InteracLvity
is
„a
cyclic
process
in
which
two
ac8ve
agents
alternaLvely
(and
metaphorically)
listen,
think,
and
speak.“
[Chris
Crawford]
Think
Think
Speak
Speak
Listen
Listen
Human-­‐Computer-­‐
Interac8on
barrier
...is
a
higher-­‐level
concept
compared
to
interac8on!

14. Part
I
–
Game
Prototyping
• High
interac8vity
• High-­‐quality
listening
• How
wide
is
the
range
of
(inter)ac8on
op8ons
offered
to
the
player?
• High-­‐quality
thinking
• How
complex
is
the
set
of
algorithms
(process
intensity)
executed
by
the
game
in
response
to
the
players
input?
• High-­‐quality
speaking
• How
strong
is
the
expressiveness
(the
more
sophisLcated
the
answer,
the
beMer
–
representaLon
is
secondary)
of
the
game‘s
reacLon?
• Core
Game
Mechanic
• Every
game
is
designed
around
a
main
ac8vity
(cf.
„Jump‘n‘Run“)
• This
acLvity
is
very
sensi8ve
to
interac8on
deficiencies
• It
primarily
defines
the
level
of
interac8vity
...in
a
way
similar
to
the
concept
of
entropy
(cf.
informaLon
theory)

15. Part
I
–
Game
Prototyping
• Reasons
for
prototyping
• Game
rules
are
best
defined
using
boLom-­‐up
strategies
(quite
ojen
interesLng
features
are
discovered
just
on
the
fly)
• The
same
holds
true
for
game
interac8vity
(direct
result
of
rules)
• This
is
especially
true
for
games
of
emergence
(restricLng
to
first-­‐
order
rules
means
provoking
second-­‐order
design
challenges)
• Game
balance
is
best
achieved
by
playing
and
refining
the
game
• The
same
holds
true
for
game
interac8on
(fine-­‐tuning
using
a
running
prototype
is
especially
important
for
core
mechanics)
• This
all
assumes
creaLng
a
playable
prototype
fastest
possible

16. Part
I
–
Game
Prototyping
• A
model
for
itera8ve
game
development
• Phases
• Concept
• Goal:
generate
ideas
• Tool:
gameplay
sketching
• Pre-­‐Produc8on
• Goal:
concreLze
ideas
• Tool:
gameplay
prototyping
• Produc8on
• Goal:
implement/refine
ideas
• Tool:
evoluLonary
development
• QA
• Goal:
evaluate/
refine
ideas
• Tool:
evoluLonary
development
• Origin
• USC
InteracLve
Media
Division
(2003)
[Tracy
Fullerton]

17. Part
I
–
Game
Prototyping
• The
spiral
model
of
soXware
development
[Barry
Boehm]
Exchange
width
by
depth
• Reduce
design
opLons
• Increase
prototype
scope

18. Part
I
–
Game
Prototyping
• Prototype
categories
(contentual
disLncLon)
• Game
design
focus
• The
prototype
is
built
around
a
game
design
issue
• Technology
focus
• The
prototype
is
build
around
a
technical
issue
• Prototype
categories
(goal
disLncLon)
• Generate
ideas
(sketching)
• A
sketch
is
used
to
explore
the
design
space,
rise
ques8ons
about
various
opLons
and
propose
specific
selecLons
• ConcreLze/
Refine
ideas
(prototyping)
• A
prototype
is
used
to
refine
a
concrete
design
choice,
answer
quesLons
that
arose
while
trying
out
opLons
and
test
selecLons
that
have
been
made

19. Part
I
–
Game
Prototyping
• Prototype
categories
(structural
disLncLon)
• Horizontal
prototype
• Realizes
just
specific
levels
of
the
system
desired
and
concentrates
on
singular
aspects
that
need
evaluaLon
(e.g.
the
GUI)
• VerLcal
prototype
• Realizes
a
properly
func8onal
itera8on
of
the
system
desired
that
cuts
through
all
levels
of
the
system
but
limits
funcLonality
considerably
(e.g.
the
first
game
level)
• Prototype
categories
(life
cycle
disLncLon)
• Throw-­‐away
prototype
• The
prototype
is
just
built
to
demonstrate
a
specific
aspect
or
to
answer
a
concrete
ques8on
that
arose
while
development
• Pilot
system
• The
prototype
represents
a
preliminary
version
of
the
aspired
product
and
is
base
for
further
development
iteraLons

20. Part
I
–
Game
Prototyping
• Technical
Requirements
• A
good
prototyping
environment
• facilitates
a
shallow
learning
curve
• allows
for
fast
itera8ons
• provides
verLcal
scalability
(at
least
to
a
certain
degree)
• This
is
typically
accomplished,
if
the
environment
• sets
the
right
focus
(animaLon/
simulaLon/
media)
• contains
examples
and
snippets
• provides
reusable
components
• offers
a
supporLng
framework
• Is
sourrounded
by
helpful
tools

21. Agenda
• Part
I
–
Game
Prototyping
• What
is
a
Game?
• Why
Game
Prototyping?
• Part
II
–
Processing
• What
is
Processing?
• How
to
use
Processing?
• Part
III
–
Game
Prototype
• An
Example

22. Part
II
–
Processing
„Processing
is
an
open
source
programming
language
and
environment
for
people
who
want
to
create
images,
anima8ons,
and
interac8ons“
[www.processing.org]

23. Part
II
–
Processing
• Some
examples...

24. Part
II
–
Processing
• The
Programming
Language
• Built
on
top
of
Java
• Is
strictly
typed
• Has
classes
and
inheritance
• The
mandatory
Hello
World
example:
• println("Hello World!");
• Supports
three
modes
of
programming
• Basic
(just
one
method
body)
• Con8nuous
(setup()
and
looped
draw()
as
core)
• Java
(well,
it‘s
just
naLve
Java...
J)
• Can
be
exported
(compiled)
to
different
languages!

25. Part
II
–
Processing
• The
Programming
Environment
• Processing
Development
Environment
(PDE)
is
bundled
(Pro-­‐users
can
also
replace
it
by
Eclipse)
• Provides
basic
funcLonality
and
is
easy
to
use
• Contains
examples
and
snippets
• Exports
Applets
and
applicaLons
• Contains
a
basic
set
of
supporLng
tools
• Can
be
extended
by
external
tools
(provides
an
extension
mechanism)

26. Part
II
–
Processing
• The
Programming
Interface
• Is
focused
on
Data
Visualiza8on
• Can
do
2D
and
3D
(both
can
be
done
HW-­‐accelerated!)
• Contains
a
bunch
of
globally-­‐accessible
funcLons
for
doing
standard
work
(very
flat
API)
• The
real
Hello
World
example:
• textFont(loadFont("Dialog-16.vlw"), 16);
• text("Hello World!", 10, 20);
• Some
addiLonal
libraries
included
(Audio,
Video,
Network,
...)
• Lots
of
external
libraries
available
(Hardware,
SimulaLon,
...)
(provides
an
extension
interface)

27. Part
II
–
Processing
• Program
and
Control
Structures
• The
same
as
in
Java
• Data
Types
• Nearly
the
same
as
in
Java
(e.g.,
color,
...)
• AddiLonal
helper
methods
for
handling
(e.g.,
Strings,
Arrays,
...)
• Math
• Operators
are
the
same
as
in
Java
• Methods
for
CalculaLon
(ceil(),
dist(),
constrain(),
norm(),
...)
• Methods
for
Trigonometry
(sin(),
cos(),
degrees(),
radians(),
...)
• Methods
for
Random
Sampling
(random(),
noise(),
...)
• PVector
as
datatype
for
two-­‐
or
three-­‐dimensional
vectors

28. Part
II
–
Processing
• Input
• Mouse
(e.g.,
mousePressed(),
mouseReleased(),
...)
• Keyboard
(e.g.,
keyPressed(),
keyReleased(),
...)
• File
(e.g.,
loadBytes(),
loadString(),
...)
• Output
• Text/
Image
(e.g.,
println(),
saveFrame(),
...)
• File
(e.g.,
saveStream(),
saveBytes(),
saveString(),
...)
• Environmental
Control
• Controls
for
seqngs
(e.g.,
size(),
cursor(),
pushStyle(),
...)
• Controls
for
main
loop
(e.g.,
frameRate(),
noLoop(),
redraw(),
...)

29. Part
II
–
Processing
• Basic
2D
Drawing
• 2D
PrimiLves
(e.g.,
point(),
line(),
ellipse(),
rect(),
...)
• Curves
(e.g.,
arc(),
curve(),
bezier(),
...)
• AMributes
(e.g.,
fill(),
stroke(),
smooth(),
color(),
...)
• PShape
as
datatype
for
handling
SVG
shapes
• Basic
3D
Drawing
• 3D
PrimiLves
(e.g.,
sphere(),
box(),
...)
• Lights
(e.g.,
ambientLight(),
pointLight(),
spotLight(),
...)
• Materials
(e.g.,
ambient(),
emissive(),
shininess(),
specular(),
...)
• Camera
(e.g.,
camera(),
frustum(),
ortho(),
...)

30. Part
II
–
Processing
• Advanced
2D/
3D
Drawing
• Vertex
Handling
(e.g.,
beginShape(),
vertex(),
texture(),
...)
• TransformaLons
(e.g.,
pushMatrix(),
translate(),
rotate(),
...)
• Images
• Handling
(e.g.,
image(),
imageMode(),
Lnt(),
...)
• Pixel
Handling
(e.g.,
loadPixels(),
filter(),
blend(),
...)
• PImage
as
datatype
for
handling
GIF,
JPG,
TGA
and
PNG
images
• PGraphics
as
datatype
for
the
main
rendering
context
• Typography
• Handling
(e.g.,
loadFont(),
textFont(),
text(),
...)
• AMributes
(e.g.,
textMode(),
textSize(),
textAlign(),
...)
• PFont
as
datatype
for
pixel-­‐based
VLW
fonts

31. Agenda
• Part
I
–
Game
Prototyping
• What
is
a
Game?
• Why
Game
Prototyping?
• Part
II
–
Processing
• What
is
Processing?
• How
to
use
Processing?
• Part
III
–
Game
Prototype
• An
Example

32. Part
III
–
Game
Prototype
• Core
Game
Mechanics
• Avoid
geqng
hit
by
incoming
objects
• TaMer
objects
by
using
effector
• Opera8onal
Rules
• Avatar
health
is
restricted
(obstacle)
• Different
objects
with
different
behaviour
(choice)
• Effectors
are
restricted
in
some
way
(obstacle/
choice)
• Different
effectors
are
available
(choice)
• Movement
of
avatar
is
restricted
to
screen
(obstacle)
• Player
tries
to
survive
as
long
as
possible
(main
goal)
• Player
tries
to
survive
certain
amount
of
Lme
(intermediate
goal);
is
then
offered
new
effector
opLons
(reward)
• Interac8on
• Player
controls
avatar
by
keyboard-­‐mouse-­‐combinaLon
(→
game
Lme)
(→
game
space)
(→
game
category)

33. Part
III
–
Game
Prototype
• Prototype
I
–
„Birth
of
an
avatar“
• Type:
• Horizontal
throw-­‐away
(technology)
• Focus:
• InteracLon
with
player
avatar
• Goals:
• Show
simple
avatar
representaLon
• Move
avatar
using
keyboard
(a,w,s,d)-­‐keys
• Evalua8on
• OK:
• Indirect
steering
works
beMer
• Playing
with
inerLa
feels
good
-­‐>
use
acceleraLon/
space
theme?
• NOK:
• Movement
needs
to
be
restricted
to
screen
• Velocity
needs
to
be
restricted
to
reasonable
limit
• MulLple-­‐key
movement
doesn‘t
work
properly
yet

34. Part
III
–
Game
Prototype
• Prototype
II
–
„Aiming
at
bad
objects“
• Type:
• Horizontal
throw-­‐away
(technology)
• Focus:
• InteracLon
with
player
avatar
• Goals:
• Show
simple
avatar
and
effector
representaLon
• Aim
effector
using
mouse
• Evalua8on
• OK:
• Approach
will
do
• Using
translaLons
works
well
• NOK:
• Loosing
mouse
focus
interrupts
experience
• Crosshairs
mouse
cursor
would
improve
game
feeling

35. Part
III
–
Game
Prototype
• Prototype
III
–
„Ready
for
take
off“
• Type:
• Horizontal
pilot
(technology)
• Focus:
• InteracLon
with
player
avatar
• Goals:
• Combine
Prototype
I
and
II
• Remedy
current
NOKs/
Do
simple
code
refactorings
• Evalua8on
• OK:
• Approach
will
do
• Movement
restricLon
should
be
part
of
gameplay
• NOK:
• Loosing
mouse
focus
interrupts
experience

36. Part
III
–
Game
Prototype
• Prototype
IV
–
„Emissions
all
around“
• Type:
• Horizontal
throw-­‐away
(technology)
• Focus:
• InteracLon
with
player
avatar
• Goals:
• Show
representaLon
of
effector
emissions
• Provide
basic
emission
behavior
• Launch
emissions
using
mouse
• Evalua8on
• OK:
• Approach
will
do
• NOK:
• Emissions
discharge
it
too
staLc
(add
random
factor)
• Emissions
lifeLme
is
too
staLc
(add
random
factor)

37. Part
III
–
Game
Prototype
• Prototype
V
–
„Avatar,
trigger-­‐happy“
• Type:
• Horizontal
pilot
(technology)
• Focus:
• InteracLon
with
player
avatar
• Goals:
• Combine
Prototype
III
and
IV
• Remedy
current
NOKs/
Do
simple
code
refactorings
• Evalua8on
• OK:
• Approach
will
do
• Implemented
emiMer
might
work
best
as
short
distance
type
• NOK:
• Emission
rate
shouldn‘t
depend
on
framerate
• Emission
should
be
restricted
to
lej
mouse
buMon

38. Part
III
–
Game
Prototype
• Prototype
VI
–
„Bad
objects
on
the
move“
• Type:
• Horizontal
throw-­‐away
(technology)
• Focus:
• InteracLon
with
game
objects
• Goals:
• Show
representaLon
of
bad
objects
• Provide
basic
bad-­‐object
behavior
(hunLng
mouse)
• Evalua8on
• OK:
• Approach
will
do
• NOK:
• IniLal
direcLon
of
bad
objects
has
to
be
set
• Bad
Objects
need
to
be
different
-­‐>
classes
of
objects?

39. Part
III
–
Game
Prototype
• Prototype
VII
–
„The
(make
believe)
witch
hunt“
• Type:
• VerLcal
pilot
(game
design/
technology)
• Focus:
• InteracLon
with
player
avatar/
InteracLon
with
game
objects
• Goals:
• Combine
Prototype
V
and
VI
• Remedy
current
NOKs/
Do
simple
code
refactorings
• Colorize
game
world
• Evalua8on
• OK:
• Approach
will
do
• NOK:
• Swarm-­‐behavior
is
too
predictable
yet
• Annoying
flickering
-­‐>
double
buffering
enabled?
• Input-­‐handling
should
be
centralized

40. Part
III
–
Game
Prototype
• Prototype
VIII
–
„Hit
´em“
• Type:
• Horizontal
throw-­‐away
(technology)
• Focus:
• InteracLon
with
game
objects
• Goals:
• Provide
basic
object-­‐to-­‐object
collision-­‐detecLon
• Provide
simple
collision-­‐handling
• Evalua8on
• OK:
• Approach
will
do
• NOK:
• Number
of
collision
checks
probably
need
to
be
restricted
• Style
of
collision-­‐handling
needs
to
be
improved

41. Part
III
–
Game
Prototype
• Prototype
IX
–
„The
(serious)
witch
hunt
“
• Type:
• VerLcal
pilot
(game
design/
technology)
• Focus:
• InteracLon
with
player
avatar/
InteracLon
with
game
objects
• Goals:
• Combine
Prototype
VII
and
VIII
• Remedy
current
NOKs/
Do
simple
code
refactorings
• Add
simple
gameplay
behavior
• Evalua8on
• OK:
• Approach
will
do
• NOK:
• Add
visual
feedback
when
hiqng
bad
objects
• Add
player
health
and
points

42. Part
III
–
Game
Prototype
• Prototype
X
–
„A
delicate
liMle
gameplay
plant“
• Type:
• VerLcal
pilot
(game
design)
• Focus:
• Gameplay
Improvements
• Goals:
• Remedy
current
NOKs/
Do
simple
code
refactorings
• Enrich
gameplay
behavior/
Add
game
states
• Evalua8on
• OK:
• Approach
will
do
• NOK:
• Add
audio
component
to
the
game
• Add
different
bad
object
types

43. Part
I
–
Game
Prototyping
• Technical
Evalua8on
• A
good
prototyping
environment
• facilitates
a
shallow
learning
curve
• allows
for
fast
itera8ons
• provides
verLcal
scalability
(at
least
to
a
certain
degree)
• This
is
typically
accomplished,
if
the
environment
• sets
the
right
focus
(animaLon/
simulaLon/
media)
• contains
examples
and
snippets
• provides
reusable
components
• offers
a
supporLng
framework
• Is
sourrounded
by
helpful
tools