It's almost impossible to imagine the game
Ape Out without an ape.

And yet, that's exactly how it started life.

According to designer Gabe Cuzzillo, this
was supposed to be a time-looping stealth

game where you'd use push and grab
mechanics to slink along walls.

But if there were going to be guards in the
game, then naturally you should be able to

use those same mechanics on them, leading
to gameplay that has you holding guards hostage

and chucking them at walls.

This turned out to be the most interesting
part of the game: and so Gabe decided to wildly

change direction and actually build the game
around this core concept.

He removed everything that didn't need to
be there, like stealth and time-loops.

And did whatever he could to emphasise this
idea - most notably, by swapping the bald

guy for a rampaging, 300-pound gorilla.

This is an example of a game design methodology
called "Follow the Fun".

It’s the deceptively simple idea that designers
should ignore their plans and preconceived

ideas - and instead look to the game itself
to find out where the development should lead.

So take the microscopic tactics gem, Into
the Breach.

This game started life as a pretty standard
Advance Wars-style game, where enemies chose

attacks at random and hid their intentions
until their turn.

But one foe in the game would show you exactly
what they were about to do on their turn,

by highlighting the tile they were going to
attack.

The developers at Subset realised that this
was the single most enjoyable part, and so

decided to focus the rest of the game almost
exclusively on these telegraphed attacks.

And this actually helped dictate the rest
of the design decisions that the studio had

to make.

Because, if you know what the enemies are
going to do, can't you just move your own

units out of their attack zone?

Alright, maybe the game is actually about
protecting static buildings.

And so now it's about pushing the enemies
around so their attacks will miss.

But actually, you could use this to trick
the enemies into killing each other.

You can probably see why the designers who
use this method often say that their game,

to some extent, designed itself.

Here's Sam Coster from Crashlands-developer
Butterscotch Shenanigans.

SAM COSTER: "We like to think about this process
as the game discovering itself over time.

Because as iterators, rather than designers,
it's our job to simply play the game, listen

to it, feel it, and kind of feel out what
it seems to want to become - and just follow

the trails of what's fun."

Now, the idea of a game designing itself is
surely rather exciting for those looking to

make the next big hit.

But, it's not like amazing game ideas just
appear from the ether.

So, where do they come from?

Well, let's look at the origins of the rhythm-based
roguelike Crypt of the Necrodancer.

Designer Ryan Clark wanted to see if he could
put Spelunky's quick-fire decision making

into a more traditional turn-based dungeon
crawler.

So he made a quick prototype of a roguelike
where you only have a second to make your

next turn.

When he played it, Ryan realised that it had
an almost rhythmic-like quality - and it became

obvious that the game should be set to music.

Or perhaps we should take a look at the iconic
mid-air movement of Rocket League.

When Psyonix was working on the game's predecessor,
Supersonic Acrobatic Rocket-Powered Battle-Cars

- they've learned a lot about marketing since
then.

Uh, they had built a game about battling cars,
but wanted to add a speed boost mechanic.

So the devs simply applied a physics force
to the back of the car.

In testing, they discovered that players could
use that force in mid-air to rocket about

the arena.

That wasn't the plan, but the developers realised
that this actually added enormous depth and

a whole extra dimension to the game - so they
kept it.

The studio says “we developed this mechanic
almost by accident”.

In fact, there's a whole history of games
where bugs, glitches, and accidents in the

development process were turned into features.

For example, Hideki Kamiya found a bug in
Onimusha: Warlords that let you juggle enemies

in the air by repeatedly slashing them.

It was fixed in Onimusha, but Kamiya developed
it further, and turned it into the premiere

game mechanic of Devil May Cry.

The point being, this process involves taking
some initial idea - however loose, fuzzy,

or unoriginal it might be - and actually building
a working prototype.

And it's here - during the process of coding
and playing - that new ideas can spring up.

And so it's up to the designer to be open
and attentive to what the game is saying.

To realise what's interesting, and be willing
to explore those aspects… even if they don't

totally align with what you originally had
in mind.

That's how Gunpoint went from being about
a robot in space who drops fridges on people,

to being a puzzle game about a spy who re-wires
buildings.

That re-wire mechanic was just one possible
idea for a hacking mini-game in a side-scrolling

Deus Ex-inspired game.

But as soon as designer Tom Francis started
prototyping it, the game that would eventually

become Gunpoint started to emerge.

Here's Tom:

TOM FRANCIS: “It just immediately became
obvious that this should become a puzzle game.

That was just a puzzle mechanic.

And so Gunpoint just kind of told me what
it wanted to be.

It just wanted to be a puzzle game, just obviously.

And I just rolled with that, I just expanded
the hacking mechanic to a crazy extent.

I built the whole game around it."

So this process generally causes the most
significant changes towards the beginning

of a game’s development - which is the point
that Sam Coster describes the game as a white

hot ball of malleable magma.

But it can still be used as development goes
on, and the game starts to form and settle

into rock.

Like, for content generation: Jonathan Blow
has said that the puzzles in Braid were simply

a showcase of the unexpected consequences
of his time-travelling game engine.

Blow says "I had a curator role, cleaning
up the answers and presenting them in such

a way that they could be enjoyed by the game’s
players.”

More on that in this video.

Or, it can be used for listening to player
feedback.

When Chris Hecker made SpyParty, players found
all sorts of exploits and unintended ways

to play the game.

Instead of fixing these “bugs”, Chris
leaned into them and made them an official

part of the game - pushing the experience
towards being more about

mind-games and psychological tricks.

And it can simply be used to help guide the
general development of a game.

Here's Subnautica designer Charlie Cleveland:

CHARLIE CLEVELAND: "You kind of think you
know where you're going.

You have some place on the horizon.

And there's many paths and you don't know
how to get there.

But if you listen to the game it will tell
you where it wants to go."

That's how his studio made a horror game,
without that ever being the intention at the

start of the project.

Now obviously, this sort of design process
can make it very difficult to predict how

long a game will take to make.

This is one reason why the methodology is
more popular in the world of indies - rather

than the fiercely regimented world of blockbuster
game production.

Like, when Tom Francis made his second game,
Heat Signature, he hoped that the fuzzy idea

of “you go inside spaceships” would magically
lead to good stuff - just like had happened

with Gunpoint.

But… it just didn't. 
At least, not for a very long time.

In truth, Tom realised that he had to make
a butt-load of stuff in order to find out

what made the game interesting, which lead
to a protracted development where he made

a ship generation system, artificial intelligence,
a combat system, a whole galaxy map with an

economy, and so on.

It took Tom years to to figure out that the
on-ship combat was the most interesting bit.

And so that's why it’s worth remembering
that the real phrase is actually a bit longer

than just "Follow the Fun".

I traced the coinage of the phrase back to
this guy - Marc LeBlanc.

He’s a designer who worked on Thief and
System Shock, and an educator who helped come

up with ideas like the MDA framework.

When he coined this phrase, he actually started
it with a well-known idiom from the world

of design and entrepreneurship: "fail fast".

That’s the process of throwing something
together as quickly as possible, to see what

works and what doesn't.

It doesn't matter if you fail, because you
didn't waste much time - but that so-called

"failure" will tell you so much about what
direction the next attempt should take.

So, perhaps there are some concrete techniques
for speeding up the iteration process?

Well, one is something all GMTK viewers will
be familiar with: Game Jams.

Those frantic game creation marathons where
you have to try and make a game in, perhaps,

a single weekend.

Arvi Teikari, who dreamt up the award-winning
puzzler Baba is You at a Game Jam, speaks

to the power of these events:

ARVI TEIKARI: "The whole idea
is you can take a prototype that you have

in your head and try to make something around
it.

if it doesn't work, that's fine.

you can toss it away after the game jam. you
are not committed to the idea for longer than

the game jam takes".

Another technique is to use tools that suit
rapid prototyping, like Game Maker and Godot.

Or perhaps paper prototypes, LEGO, or the
PS4 game-creation suite Dreams.

If you've already made most of the game and
just want to generate content, you can develop

some custom level creation tools to speed
up the creative process - and get more people

on board to help.

So, for Mario Galaxy 2, Nintendo made simple
level creation tools to encourage everyone

on the team to think up unique mechanics.

And to quickly focus on design and mechanics,
you can use placeholder art, music, and plot.

When Klei made the very first game jam prototype
of Don't Starve, the hero of the game was

actually represented by…

Link, from Zelda.

And finally, it can actually help to have
something

about the game that absolutely cannot change.

Sunni Pavolic from thatgamecompany says the
studio used a very iterative methodology when

making Journey, but always with the idea that
this game would explore the theme of love.

This gave everyone on the team a singular
direction to follow, and helped narrow the

range of possible ideas that they might discover
and develop.

So if there’s one thing I’d want you to
take away from this video: it’s to stop

waiting for the perfect game idea to come
along.

It’s easy to look at something like Ape Out, 
Crypt of the Necrodancer,

or Crashlands and assume that
these games were designed in a flash of insight

- which seamlessly transitioned into the final
game.

And so if you can’t come up with an idea
as good as these ones - why bother trying?

But as I’ve shown in this video, nothing
could be further from the truth.

In reality, the thing that ties all of these
developers together is that they got started

and they built something.

And it was only then - as the designers tried
new ideas, played their prototypes, and even

created bugs - that the games we know today
started to form.

They’re great designers not because they
came up with amazing ideas - but because they

knew how to listen to the game, knew which
avenues to follow, knew how to fail fast and

fail often, and knew how to coalesce these
disparate ideas into something coherent.

So if you watch Game Maker’s Toolkit and
think you might like to make a game - don’t

wait for the perfect idea.

Build something.

And then you can listen to the game, follow
the fun - and you might just discover that

the game, in some small way, designs itself.