Building Gameplay

Building
Gameplay
Ben Garney
The Engine Company
@bengarney
bengarney.com
Tuesday, July 24, 12

Introduction

• Ben Garney (@bengarney)
• http://bengarney.com/
• Founder, The Engine Company
• Flash Architect, PushButton Labs
• Torque Technologies Director, GarageGames

Ask about audience - developer, interest in games, etc.

Agenda

• Motivation
• Surviving Development
• Simulation Techniques
• Conclusions & QA

Going to talk about different ways to build and think about games, with a speciﬁc focus on building blocks for making really good
gameplay

• Open source Flash game framework
• http://www.pushbuttonengine.com/
• For other open source libs, check out:
• http://github.com/bengarney
• http://github.com/PushButtonLabs

Some of my prior work, still out there, use it, it’s good!

Mobile Game Technology
http://theengine.co/

My new project, focused on mobile game technology.

What is
Gameplay?
What do we mean when we say gameplay? Of course the term can cover a wide variety of topics! But
I think there is a core set of development skills that give good experiences, and they can even
extend to non-game applications. (For instance, a car has a very intuitive interface - and it
embodies many of the properties of a good game).

“A game is a
series of
interesting
choices.”
- Sid Meier

Hopefully you know Sid Meier... he is personally responsible for a TON of great games, SimCity,
Pirates, Railroads, Civilization, and many more. He is smart about games.

Games stand on their own merits... This guy is operating this computer for some pretty darn good
reason, not because it’s intrinsically fun. Maybe he is calculating the census or he has an obsessive
compulsive disorder relating to buttons. Really this is the same reason we use Word or Excel or even
our web browsers. They are just a way to accomplish a task that we care about, like writing a memo
or doing our ﬁnances or logging into our banking website.

Games stand on their own merits, though. Through a variety of strategies (like responsiveness,
visual appeal, social/emotional appeal, or novelty/escapism) they make an activity fun in and of
itself. Typically this is accomplished via the gameplay.

Some games are simple and perfect in their gameplay... the original NES Mario, Tetris - these are
purist games.

... and others are byzantine. The behind-the-scenes doesn’t necessarily correlate with the
perceived complexity (compare a skating game’s gameplay system vs. chess).

BTW - this is the same game, displayed with tiles. Amazing the difference art can make! It’s still
byzantine. The satisfaction for people comes from wrestling with a huge complex system - like
having an ant farm. This game is Dwarf Fortress, written by Tarn Adams of Bay 12 Games

Game
making
is a
muscle.

If you want to get good at making games, the best thing to do is make a whole game. You will learn
a lot. And your next game will be even better. I have learned a ton from every single game project I
have taken on. Spend a week and make a game and you will be a better game maker.

Development
Risks
Of course, with practice you learn about ways you can fail! So let me talk a little bit about things
that kill game projects. I will focus primarily on internal factors, not external ones like what to do if
your company runs out of money...

Clients

• Can’t see vision.
• Aren’t willing to iterate.
• Lose sight of fun as goal.
Clients are a big factor, and they can be managed in part by showing them great gameplay. But they
also have risks...

Team

• Becomes frustrated.
• Loses track of priorities.
• Wants to over-innovate.
Managing the team is tough, and there are lots of things that can steer them astray.

Technology

• Becomes brittle.
• Is unreliable.
• Limits design and tweaking.
Tech is also a risk, although much less so now than a decade ago.

Gameplay

• Isn’t fun.
• Becomes unbalanced.
• Doesn’t match project goals.
And ultimately the game HAS TO BE FUN!

Development
Strategies
Games tend to follow one of four big development strategies: iteration, horizontal slice, vertical
slice, and reboot. There’s also a ﬁfth strategy, failure, which is what happens when the game
doesn’t turn out fun.

Iteration

Prototyping, sprints/agile, “knowing that you don’t know” - this approach involves building
something simple and rough, ﬁnishing it, playing it, and improving it... Repeat until it’s fun! This
works best for the most vital loops in a game, like the player’s movement, where you have to get a
lot of little details right to make a cohesive whole. It works less well for e.g. building out your
game’s content, where the cost of iterating can be prohibitive and it can be hard to iteratively arrive
at an overarching theme.

Horizontal Slice

Build out the WHOLE game, but in a very shallow way. For instance, for an RPG, build out simple
versions of all the major locations, and include all the major battles, but don’t build the whole battle
system + all items and NPCs. This is helpful in bigger projects to determine pacing and scope, and
it can also help show the vision to a publisher/client.

Vertical Slice

Build out one scene from the game in as complete detail as possible. For instance, consider a game
like Monster Hunter or Shadow of the Colossus (Wanda to Kyozo, Wanda & The Colossus). To sell its
unique vision and the intensity of the gameplay, it is necessary to fully experience one of its boss
battles. Once you have that taste, you don’t necessarily need to play the rest of the game to
understand it. So if you were pitching/demoing a title like that you would build a vertical slice.

Reboot

This is the most expensive option, but it can give good results. The classic example in western
games is Half Life; Valve spent several years building the game, but it wasn’t fun, so they ditched
their content and started over. Scary, but worth it. The result was a reinvention of the FPS, an
enduring franchise, and the seed that has built Valve into a billion dollar company.

Instant
State
Instantaneous state, really. This is the simplest kind of gameplay.

Instantaneous?

• Not based on previous state.
• Example: if(buttonDown) shineLaser();
• Simple, solid.

It doesn’t depend on what has happened before. For instance, a laser with a button on it. It is easy
to implement and modify.

Discrete

Let’s start with discrete state. Discrete meaning not continuous - that is, things like symbols,
boolean values, etc. that vary all at once, not in stages.

Truth Table

Button? Laser

T T

F F

A truth table is a way to model the behavior of a discrete system. In this case we are saying if the
button is down, the laser is on, and similarly, if the button is off, the laser is off.

Demo
“One Button”


Example

• Controlling a Car...
• if(brakePedal) brakeLightsOn();
• else brakeLightsOff();
• if(brakePedal) setAxleFriction(high);
• else setAxleFriction(low);

A car is a more complex example but it follows exactly the same approach. And when we write it in
the truth table we see that our rules as described here are ambiguous...

Truth Table
Gas Brake
Lights Brake Engine
Pedal? Pedal?
T T T T F
T F F F T

F T T T F

F F F F F

Here we see that there’s an interesting case to handle - what if both pedals are down? We can
choose various things depending on what ﬁts for the game. In our case we have braking take
priority.

Demo
“Two Button”


Why Bother?

• Uniform way of thinking about problems.
• Scales to be arbitrarily large.
• Very very simple!
• Mostly for booleans but generalizable to
other kinds of data...


Truth Table
Gas Brake
Lights Brake Engine
Pedal? Pedal?
T T on off reverse
T F off off high

F T on high off

F F off off off

We can also get a bit fancier and specify non-boolean outputs. (Of course in a strict truth table you
would represent this by outputting multiple bits of Brake or Engine.) Now we can have a more
nuanced behavior, within the same framework. And in the iterative environment of a game, this is
very very useful!

Continuous

OK, onto continuous state. This is for representing continuous numerical values, like weight or
health or speed.

Rob Penner’s easing functions. MANY ways to adjust behavior! And of course each one can be
tweaked in different ways.

Curves

• Highly controllable “feel.”
• Simple - value in, value out.
• Chainable.

http://hosted.zeh.com.br/mctween/animationtypes.html
These curve functions are very powerful. They are simple to work with, they can be combined
endlessly, and they give a huge amount of “ﬂavor” to whatever you apply them to.

Demo
“One Button With Tween”


Parametric State

• Full behavior set at beginning.
• Takes elapsed time into account.
• Simple and reliable.

Another big advantage to parametric equations is that they don’t have any variance. Once you set
up the start time you can evaluate it at any point from now until forever and know exactly what
you’ll get. Compare this with using a physics engine where it can be computationally very complex
to ﬁnd out the state at t+100seconds. This is nice because you can evaluate them cavalierly and not
have to worry about getting strange results.

x=sin(t) y=cos(t)

Parametric equations can control motion, for instance, making stuff move in a circle...

pos = -9.8t 2

They can also approximate gravity...

Parametric Rules For...

• Visual effects (particles)
• Platforms “on rails”
• Giving a “feel” to things.

And these are powerful building blocks for a variety of things - particles, platforms (SMW), and
kinematic dynamic objects.

Demo
Braid


Feedback
Loops

Now that we have some building blocks we can take the next step in complexity, which is to turn
them back on themselves and make a feedback loop.

Simulation

• v is state vector.
• f(x) is state function.
• v’ = f(v) to determine new state.
• Run at 30Hz and you have a simulation.

This glosses over several complexities - like temporal aliasing, numerical stability, and so on - if I
am doing well on time I have a slide a little later on these issues.

State Vector

• Written x = < state1, state2, state3 >
• Represents total state of the system.
• For our car example:
x = <brake?, gas?, light, brakes, engine>
x = <engine?, brakes?, gas, velocity, position>


State Function

• x’ = f(x)
• gas’ -= (engine? ? 0 : 1)
• velocity’ = (velocity + (engine? ? 1 : 0)) * 0.9
• position’ += velocity

Here are the update rules we would use.

Demo
Kerbal Space Program


Caveats

• Timestep
• Precision
• Stability
• Consistency

Of course there are some caveats - inconsistent timestep can introduce error, ﬂoating point
numbers have limited precision, numerical methods can be instable, and if you require identical
results every time it can be hard to keep things consistent.

Truth Table Feedback

Old New

T F

F T

Truth tables can be used in state functions, too. Really is just a way of writing out a function. Fits into
same model. Just run through the table once per tick. This sets us up perfectly to think about our next
topic... FSMs.

Finite
State
Machines

Let’s go back to 1986 and a classic game called Gradius...

... which was tough... and a classic game. It’s also a highly relevant example because it’s the ﬁrst
instance of a game using the Konami code, which is a great example for a state machine. The
Konami code was...

this sequence of inputs, and you entered it on the start screen to begin the game with all powerups
active (except for Speed Up, Double, and Laser). In the end maybe a hundred games, and even some
websites, support the code in one form or another today.

Up? Down? Down?
s1 s2 s3 s4
Up? Left?

IDLE s5
Else?
Right?

s6

OK! s9 s8 s7 Left?
A? B? Right?

Here is the state machine for the Konami code. (One link missing, s1->idle, due to limitations in
Keynote)

Finite State Machine

• Powerful way to drive complex game logic.
• Many variants:
• Hierarchical
• Finite/Inﬁnite
• Moore/Mealy

Moore - output driven by current state
Mealy - output driven by current transition

Else Else
StopLeft StopRight

Left Right? 250ms Right

100ms Left? Right? 100ms
Idle
StartLeft StartRight

Else


Demo
Super Mario World


This is an example of a complex FSM used to drive an AI character.

Conclusions


Functions Simulations

Truth Table State Vector
Parametric Numerical
Curves Finite State

Summary of various techniques we have learned, “functions” being basic things that can be
evaluated and “simulations” being things that are run iteratively to drive game state.

Takeaway

• Good gameplay code supports...
• Faster iterations
• + Painless changes
• + Happier team
• ... equals a fun, successful game.


Questions & Answers
• Thank you for listening!
• @bengarney, bengarney.com

Books: introduction to Adobe Edge, Web Design with Muse from Adobe, Android App Dev & Design:
Learn by Video

Building Gameplay

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Building Gameplay

Similar to Building Gameplay (20)

Recently uploaded

Recently uploaded (20)

Building Gameplay