HANGRY

DRAGON HANGRY DEER ALGO- FOUR

DROP HIPSTERS PONG RHYTHM SHADOW SUBWOLFER BIFURCAT

AN R&D PROCESS FOR PROTOTYPING CASUAL GAMES

DESIGNING FOR FAILURE

SCOTT JON SIEGEL, NUMBERLESS.NET
@NUMBERLESS

Hey everyone. Thank you so much for coming. I'm Scott Jon Siegel. And this is a talk about the design of games, but it's also a talk about the design of development.
 @NUMBERLESS

6 SHIPPED

2 CANCELED

3 PROTOTYPES SHELVED
MONSTER GOPHER DRAGON
MACHINE IT TAPPERS

I've been working in the casual space as a game designer for the last 9 years. During that time I've seen a lot of different development processes in place. I've designed
and worked on games that have seen massive success, games that haven't, and games that never shipped. You learn a lot from being a part of success, but I've come to
find that you learn a lot more being intimately involved in failure.
 @NUMBERLESS

EMBRACE FAILURE

Perhaps the most important thing I've learned is that failure is unavoidable. But the trick to game development (maybe to any creative process) is to anticipate and plan
for failure, and create the opportunity to learn from it, and try again.
 @NUMBERLESS

Sucking at something is the first

step to being sorta good at
something.

FAILURE-FOCUSED
GAME DESIGN

Learning from failure is actually a facet of many of my favorite games. Games create a space in which failure is not just permitted, but often a part of the mastery process.
In games like Super Hexagon, Flappy Bird, or even AAA titles like the Dark Souls series, proficiency builds from successive failures. You gotta suck at something a lot
before you can begin to get kind of good at it.
 @NUMBERLESS

"BEST"
PRACTICES
"Just copy what they do
and do it until we have their numbers."

But I don't think many game companies today are designed to allow for failure or even learn from it. And my time in the casual, free-to-play game industry has shown me
that fear of failure often leads to a risk-averse strategy -- a notion that playing it safe means just doing the things other people have already done.

And my concern is that this leads to casual game companies that are not built to try new things, and therefore never learn new lessons. The industry as a whole relies so
much on what's established, what's proven, "best practices", that we're perpetually running the risk of stagnancy.
 @NUMBERLESS

THE SUNK COST FALLACY

KC GREEN

And I've watched companies spend years developing something "safe" only to have it ultimately underperform, failing to pull audiences away from the multitude of
similar games in the app store.

What's more, this fear of failure leads companies to double-down on struggling development: Aggressive staffing, mid-production design pivots, pulling resources from
other projects, pushing release to the next quarter: All ways of throwing more and more money and time at a problem, all in the name of avoiding failure.
 @NUMBERLESS

SURVIVORSHIP BIAS THE ICEBERG PROBLEM

And all because we're an industry that focuses on what worked, and not enough on what didn't, or what it took to get to a thing that worked.

But the story of success is always a story about failure. Folks just tend to only read the last chapter. Here are some examples.
 KING: THINKING WITH PORTALS

@NUMBERLESS

We all know King made a name for themselves with Candy Crush Saga in 2012. But before they were King they were King.com, a games portal with a whole bunch of
casual games, and a strong community whose gameplay metrics would help King determine which of their games to further develop and move to other platforms. Of
these titles, Candy Crush was the third to move to Facebook, and the first to make its way to mobile. And now Mario Lopez hosts a Candy Crush TV show.
 @NUMBERLESS

ROVIO: GOT IT IN 52

Back in 2009, Rovio made their mark in casual games with Angry Birds. But Rovio also shipped 51 other games before Angry Birds, and would've risked bankruptcy had
the game not succeeded.
 @NUMBERLESS

POPCAP: FAILURE IS AN OPTION

That same year, Popcap shipped the massively successful Plants vs. Zombies, the original of which is STILL a top paid game on the iOS app store

But leadership at PopCap didn't expect Plants vs. Zombies to be successful. It was too strange and unlike other things for them to believe it could capture a large-
enough audience.

Regardless, they gave its small team the time and space they needed to develop it, and ship it, knowing that the company would remain afloat even if the weird, risky
thing they tried didn't pan out. Even if PVZ had been DOA, PopCap would have moved on smoothly, no worse for wear.
 @NUMBERLESS

FAILURE
HAPPENS

In all three of these cases of success, failure plays a critical role. Success sometimes means getting it right on the 52nd try. Or trying lots of low-risk things before
committing more resources to a bigger thing. And success sometimes means creating the stability to try something weird, and assuring that failure leads to learnings,
rather than crisis.
 1. a symptom of
trying things

2. a learning
experience

3. a prerequisite for
success

This is a talk about prototyping for casual games. But it's also a talk about redefining what failure and success mean, and how building and nurturing a culture of
prototyping can allow companies to fail *successfully* and create the best path for future success.

After all, failure is what happens when we try things. And a fear of failure means an aversion to trying new things.
 @NUMBERLESS

4F
Failing Fast to Find the Fun

(CREDIT TO MITCH ZAMARA FOR THE NAME. THANKS MITCH!)

4F is a system for trying things, and allowing for them to not work out. 4F is all about Failing Fast to Find the Fun.

And it's a loopy process. We gather ideas, create plans to rapidly prototype mechanics and concepts, test the prototypes, and then either iterate, or shelve it and go back
to the drawing board. Sometimes we move things into pre-production, but that's not what 4F is about.
 kokotoni on Flickr @NUMBERLESS

MAKE LOOPS
NOT ESCALATORS

In fact, we need to get it out of our heads that game development is a linear process, an escalator leading to an inevitable shipped product. When in fact it should be a
series of circles, and at any point in the process there needs to be consideration for whether it's time to loop back. Moving forward should never be the assumption.
Because that escalator? It doesn't always lead somewhere good.
 @NUMBERLESS

MONSTER DRAGON
MACHINE GOPHER IT TAPPERS

POPLABS
‣ 1.5 years
‣ 2-person team
‣ 4 prototypes
‣ avg. 2-3 weeks to first playables
‣ 1 soft-launch

This process is inspired primarily by my time working in the PopLabs prototyping group at Popcap. Working with a single engineer, we developed four different
prototypes, iterating, testing, and deciding for ourselves when it was time to walk away from each and move on to the next thing. The fourth of these prototypes tested
extraordinarily well, was further developed by a team of 10, and soft-launched in Canada. Though ultimately not successful, I learned a lot from all of our prototypes, and
the lab as a whole.
 @NUMBERLESS

ENGINEER

DESIGNER ‣ small teams

‣ self-managed
‣ equal say
‣ honest communication

Like my experience in PopLabs, 4F is based around creative partnerships -- a designer and an engineer in close collaboration, tackling problems together.

I view this as a true, equal partnership. The engineer is not there simply to execute some designer's grand vision. The work produced is a synthesis of both the creative
and technical. And like any relationship, communication, trust, and mutual respect are critical.

You might need a slightly larger team, depending on what you're building. But keeping the team small is important, to ensure everyone has a voice in the process while
still maintaining cohesion, and moving quickly.
 @NUMBERLESS

"Flex-off" by Faebelina
faebelina.deviantart.com

Every time a 4F team loops together, they become better at the process, and their working relationship improves. Like any team, the more experience they have working
together, the stronger their output. And 4F can give teams a lot of experience in a short amount of time.
 @NUMBERLESS

THE BOX

4F should never kick off with a single idea. It's not "we're going to build this thing." It's "we're going to try a lot of things". And all of those things come from the box.

The box is a critical part in the exploration of game concepts. It limits the dependency on any one idea, and allows those involved to constantly chew on the other ideas
in the backs of their minds.
 @NUMBERLESS

THERE ARE ALWAYS MORE THINGS TO TRY

The Box encourages a playful approach to ideation that doesn't put too much pressure on any one thing to be The Thing. Keeping the box filled allows you to more easily
put down things that aren't working. Because lots of stuff won't work.
 @NUMBERLESS

SOME THINGS TAKE TIME TO PERCOLATE

!
MIXED METAPHOR ALERT

It's also an admission that some ideas aren't fully cooked, and need time to percolate before they're ready to come out of the box.
 @NUMBERLESS

When I think about the concept of the box, I think of Pixar, and how in a single lunch meeting back in 1994, the so-called "brain trust" of Pixar generated the rough ideas
that would become the studio's next four films.
 @NUMBERLESS

The concepts they came up with came from varying approaches. Rendering humans in CG was still a technical challenge, so A Bug's Life was planned as a story without
human characters. The secret lives of toys worked well as a kid-friendly concept for Toy Story, so Monster's Inc. was about the secret lives of the monsters under your
bed. Finding Nemo came from Andrew Stanton's sympathy for the fish in his dentist's aquarium, and Wall-E started with just the character -- the idea of a sad robot left
alone on a planet, performing the same menial tasks for centuries.
 @NUMBERLESS

IDEAS COME FROM EVERYWHERE

In the same way, what's in the box aren't complete prototypes, or even fully-formed ideas. They're pieces of interaction, or questions, or clever solutions to constraints
and limitations.

A certain toy in children's play area at Ikea. The iPhone's "slide to unlock" interaction. Leaping across rooftops in Saints Row IV. The idea of a casual metroidvania,
bussing your own table at restaurants, rock climbing, goats, tinder.

The box is there to constantly tickle your brain, and the ideas are there to be played with, twisted around, mashed together. Eventually, you'll begin to figure out a path to
something playable, and potentially fun.
 @NUMBERLESS

THE PLAN
4F
Failing Fast to Find the Fun

At that point, you have to determine exactly what you're building, and how you're going to build it.

The goal for any prototype is to prove a concept or hypothesis. Usually: that doing <x> is fun. But the proof will not come from those familiar with the original idea. That
proof has to come from actual players who have no idea what you're trying to do, or the thinking behind what's in front of them.
 @NUMBERLESS

WHO IS YOUR PROTOTYPE FOR?

?

The problem with most prototyping I've seen in casual games is that the prototypes are built for the developers themselves, and sharing those prototypes with anyone
other than their creators involves a lot of pre-explanation and caveats. And criticism of the prototype can often be responded with "we can clarify that with a tutorial" or "I
probably didn't explain it well" or "yeah but the visuals would make that feel a lot more satisfying."

A key part of this process is that you're not building prototypes for yourselves. You're building them for an actual audience. And you want the feedback to focus as much
as possible on the things you're actually trying to test, rather than the rough edges.
 @NUMBERLESS

THE USABLE PROTOTYPE

This means that your prototype needs to stand on its own. The entirety of what players are evaluating has to be contained within the game itself. So when I say a
prototype needs to be playable, I also mean that it needs to be usable.

A usable prototype for a casual game is one that you can hand it to an uninitiated player, watch them figure out how to play without needing to explain anything, and
witness their honest and immediate reactions to the experience. This means that some aspects we tend to think of as polish, need to be included for the sake of usability.
 @NUMBERLESS

USABILITY IN MOTION

CODE BY DECKY COSS

These are two versions of a prototype that mixes video poker with match-3 mechanics. Both versions are functionally identical, but the one on the left is lacking a
cascade effect when cards are removed from the board, making it unclear what happened to the selected cards, and where the new cards and coming from.

The cascade animation is critical to the player's understanding of how their interaction affects the environment. If they don't understand how the game works, they can't
possibly evaluate whether it's fun.
 @NUMBERLESS

At the same time, it's still important to turn the prototype around quickly, and get it front of players as soon as possible. This means cutting corners as much as you can
while still having a presentable, usable facade. So whenever possible, avoid building totally new things. Repurpose existing code. Grab art from the internet. And if you're
part of a larger game company, borrow what you need from other studios.
 @NUMBERLESS

One prototype we built at Popcap was made almost entirely of assets from the facebook game Pet Society. Borrowing these assets from EA's Playfish studio allowed us
to build the prototype quickly, and without needing to task an artist with generating hundreds of items.
 @NUMBERLESS

PLAYTESTING & FEEDBACK

Once your prototype is built, it's time to have people play it, to watch them play it, and collect copious amounts of feedback on their play experience. This is maybe the
hardest part of the process, and it'll require being confident, thick-skinned and tight-lipped.
 @NUMBERLESS

THE FARTHER YOU

GO, THE MORE
HONEST THE
FEEDBACK

I'm a shy kid, and it's hard for me to put the things I made in front of people. But sticking to feedback close to home means you're only going to get feedback from the
people too close to you and the game to fairly evaluate it.

The closer someone is to you and the project, the more that bias will affect their evaluation. The most honest feedback you can receive is from people who don't know
you, and who are reacting solely to the game in front of them.
 @NUMBERLESS

‣ encourage thinking out loud

‣ observe what they're doing, and
how they're reacting
‣ don't speak
‣ they don't need your reasons
‣ so please stop explaining
‣ don't tell them, because it hurts (the
quality of their feedback)

That said, take advantage of any opportunity you have to actually watch someone playing your game. Ask them to narrate their play experience, to say what they're
thinking. See how they react to moments of the game. Notice what they like, what confuses them.

And during all of this, DON'T SPEAK. Don't explain, don't get defensive. Just observe. The more you say, the more you color their experience.
 @NUMBERLESS

USERTESTING.COM

For playtesting outside of your social sphere, I strongly recommend usertesting.com. Usertesting lets you upload builds of your games and expose them to targeted demographics,
complete with surveys and recorded footage of their gameplay.

Usertesting was an invaluable tool for collecting external feedback on many of our prototypes. It also makes it easy to create time-stamped notes, and compile video snippets into
highlight reels (which is great if you ever need to pitch the game to executives).
 @NUMBERLESS

EVALUATING FEEDBACK

‣ What's working?
‣ What isn't working?
‣ What could we iterate on?
‣ Do we keep going, or try something new?

All the feedback you receive needs to be collected, categorized, and considered. Compare all the external feedback to your internal notes. And ask yourselves the
following questions.

1) What's working?

2) What not?

3) What could we iterate on?

and most importantly:

4) Do we keep going, or try something new?

 @NUMBERLESS

And here we arrive at a critical part of the process: the decision whether to iterate on what you have, or put it down and go back to the box.
 @NUMBERLESS

STOP

There is always a chance that after one iteration you'll quickly determine that the concept doesn't pan out, and the decision to put it down will be easy. Most likely,
however, it'll be hard to make that kind of call.
 @NUMBERLESS

STOP

"...but, what if we tried this?"

Most of the time, you'll think "Well, okay, but what if we tried *this*?
 @NUMBERLESS

WE CAN'T STOP NOW!

WE'VE ALREADY SPENT
SO MUCH TIME ON
THIS!

And here again is where the sunk cost fallacy rears its ugly head. Iteration on any concept takes time. And walking away from something you've invested in always feels
like admitting defeat, wasting work.
 @NUMBERLESS

DON'T FORGET
ABOUT THE BOX
(HOW COULD YOU? IT'S FULL OF PUPPIES!)

But this is why we have the box. Part of the decision to shelve or iterate is about whether you and the team still feel passionate and confident about what you're building,
or whether there is something in the Box that is tempting you, or some open question on another design that you think you know how to test.
 @NUMBERLESS

WHY SHOULD I SHELVE THIS?

‣ It's not working
‣ Too costly to iterate
‣ Fatigue
‣ Something new worth trying

Sometimes you'll shelve something because you know it's not working. Sometimes you'll shelve because exploring how to make it work is costly and not worth the time.
Sometimes you'll shelve something simply because something else caught your attention, and there's momentum and excitement behind that something new.
 @NUMBERLESS

ERIK RYDEMAN
@IAMDOBOROG

And chasing something new can sometimes be incredibly fruitful. My friend Erik Rydeman spent his first year as an indie dev building an ambitious tactical strategy
game. He then switched gears to collaborate with game designer Dana Nelson on a cooperative mobile title.

But during a break in development Erik wanted to try something he'd been toying with in his brain.
 2 WEEKS TO PROTOTYPE
4 MONTHS TO EARLY ACCESS RELEASE

So he took two weeks to build a prototype of Clone Drone in the Danger Zone. A year later, the game's now in early access, and has proven extremely popular with
twitch and youtube streamers. Clone Drone's success quickly turned it into a full-time project for Erik, and has allowed him to hire a second engineer. All because he had
an idea he wanted to try out, had a quick, low-risk path to trying it, and wasn't afraid to put down what he was working on.
 @NUMBERLESS

Because the things he put down are still there, on the shelf, ready to be picked up again when the time is right.
 @NUMBERLESS

‣ proudly displaying prototypes, rather than

HANGRY burying them
HANGRY FOUR
HIPSTERS SHADOW
‣ anything on a shelf is easily picked up again

‣ everything on the shelf is there as reference

DEER DRAGON ALGO-
PONG DROP RHYTHM

FOURTRON SUBWOLFER BIFURCAT

THE SHELF
And this is the reason it's called a shelf. Projects on the shelf aren't dead and buried; they're displayed proudly as a record of progress and accomplishment. They're
easily returned to. And they exist as reference material, for both you and your peers.
 @NUMBERLESS

FAILURE IS YOUR KPI

HANGRY
DRAGON HANGRY DEER ALGO- FOUR
DROP HIPSTERS PONG RHYTHM SHADOW SUBWOLFER BIFURCAT

MY BEAUTIFUL FAIL BABIES

The metric for prototyping success is not how many projects you get greenlit, or ship; it's the number of things you've tried. A major part of 4F is celebrating everything
you put down. It's a mark of experience, and a moment of excitement as you pick up something else.
 @NUMBERLESS

4F MAKES GAME DEVELOPERS

BETTER AT GAME DEVELOPMENT
‣ build mastery of design and development
‣ strengthen teams through rapid development experience
‣ encourage critical honesty when giving and receiving feedback
‣ foster company culture of creativity and innovation
‣ avoid stagnation and stay ahead of the curve

The 4F process isn't just about exploring new ideas. It's about building development mastery; creating team cohesion before teams ever enter production; fostering
healthier relationships to critical feedback, and motivating teams to think different. In other words, 4F makes game developers better at game development.
 @NUMBERLESS

WHAT DOES 4F NEED TO SUCCEED?

▸ insulation from executive oversight.
▸ no penalties for failure (it's always
okay to put something down).

▸ no quarterly goals around

greenlighting or shipping.

▸ limited visibility to stakeholders.

But in order for 4F to work, it has to be held apart from the expectations of production-focused teams and processes.

Nothing being prototyped should be expected to go into full development, or ship. Investing in R&D means investing in something separate from normal development
expectations and pressures. The more pressure you put on every prototype to work, the more teams will feel a sunk cost in everything they try, and the more likely they
are to fool themselves (and others) into thinking something's working, even when it's not, for the sake of moving it forward in order to hit some quarterly goal.
 @NUMBERLESS

MAINTAIN
AUTONOMY
▸ be self-managing
▸ keep each other honest
▸ shelve things before
anyone has to ask you
to

But this also means teams need to operate semi-autonomously, and maintain a practice of regular critical feedback to help keep each other honest. The studio as a
whole needs to demonstrate that it is capable of autonomy. And if you wait for someone higher up to tell you how to manage your time, you lose that autonomy.
 @NUMBERLESS

I make games
for everyone.

I work in casual games because I like telling people that I make games for everyone. More than any other part of our industry, casual games have the potential to reach
the widest audiences, to touch the most people. And they accomplish this by offering simplicity, approachability. They defy the prior games literacy that so many console
and AAA games require as a prerequisite to enjoyment. When you make a casual game, you are making something that anyone can play, and everyone can enjoy.
 @NUMBERLESS

to make better
games,
we need to make
games better

We owe it to our players, to everyone, to keep finding new and delightful ways to play. This is our design challenge, but it's also our process challenge.

To make better games, we need to get better at making them.

And I hope you'll help me do just that. For our players. For our industry. And for each other.
 THANK YOU!
<3
THANK YOU!
<3

SCOTT JON SIEGEL, NUMBERLESS.NET

@NUMBERLESS

Thank you!