The Games That Designed Themselves

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.