building gameplay

Building Gameplay

Ben GarneyThe 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.

http://bengarney.com

http://bengarney.com

Agenda

• Motivation

• Surviving Development

• Simulation Techniques

• Conclusions & QA

Tuesday, July 24, 12Going to talk about different ways to build and think about games, with a specific 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!

http://www.pushbuttonengine.com

http://www.pushbuttonengine.com

http://github.com/bengarney

http://github.com/bengarney

http://github.com/PushButtonLabs

http://github.com/PushButtonLabs

Mobile Game Technologyhttp://theengine.co/


My new project, focused on mobile game technology.

http://theengine.co

http://theengine.co

http://theengine.co

http://theengine.co

What isGameplay?


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 finances 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.

DevelopmentRisks


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 fifth 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, finishing 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.

InstantState


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 TableGas

Pedal?Brake Pedal? Lights Brake Engine

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 fits 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 TableGas

Pedal?Brake Pedal? Lights Brake Engine

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.htmlThese curve functions are very powerful. They are simple to work with, they can be combined endlessly, and they give a huge amount of “flavor” 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 find 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.8t2


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.

DemoBraid


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.

DemoKerbal Space Program


Caveats

• Timestep

• Precision

• Stability

• Consistency


Of course there are some caveats - inconsistent timestep can introduce error, floating 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

MachinesTuesday, July 24, 12


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 first 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.

IDLE

s1 s2 s3 s4

s5

s6

s7s8s9OK!

Up?

Up? Down? Down?

Left?

Right?

Left?Right?B?A?

Else?


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/Infinite

• Moore/Mealy


Moore - output driven by current stateMealy - output driven by current transition

Left

IdleStartRight

Right

StartLeft

StopLeft StopRight

Right?Left?

Right?

Else

ElseElse

250ms

100ms100ms


DemoSuper Mario World



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

Conclusions


Functions Simulations

Truth TableParametric

Curves

State VectorNumericalFinite 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

Technology

ifyour company runs

billion dollar company

gamelike monster hunter

sell itsunique vision

give good results

battlesystem

development riskstuesday

state machine