This is a written-up, non-verbatim version of a guest lecture I gave for Playcrafting NYC’s 2015 8 week game design course.

Intro

I was super stoked when Pete asked me to talk about how I “find the fun” when I design games. One of the reasons I love this topic–and game design as a whole, really–is because finding the fun is an art. A really hard and slippery and amazing art. While you can methodically Skinner box people into hypno-engagement, fun is something that can’t really be made into an equation.

There’s two big things that come to mind that make fun so hard to nail down.

Different kinds of fun

The first is that there isn’t just one type of fun–there’s probably as many types of fun as there are games. There’s the fun you have when you execute clever tactics and totally destroy another player in Starcraft. There’s the dizzying, gleeful, mischievous fun you have when blowing stuff up in GTA. There’s the performative, social fun you have when you do terrible karaoke while playing Rock Band with your friends. There’s the exploratory, discovery- and surprise-oriented fun you have when you explain a cave in Minecraft. And so on and so forth.

Figuring out what “fun” is, and what types of fun exist, is something that game designers have been grappling with for ages. In 1958, Roger Callois set up a taxonomy of different types of play that speaks to different types of fun, including:

• Agon (competition)
• Alea (chance)
• Mimicry (role playing)
• Ilinx (vertigo)

This is just one set of taxonomies. In reality, there are about as many kinds of ways to experience fun as there are fun games. So everyone’s definition of what fun is–developers and players–is likely to be different.

Can’t fake the fun(k)

The other reason why creating fun is so difficult is because you can’t really force someone to have fun. It’s kind of like comedy: you can’t make people laugh if they don’t think that what you’re saying is funny, and you can always tell if they try to fake it. To create fun, you have to strike folks in exactly the right way, with the right combination of elements, to make the experience feel fun.

For that reason, it’s also hard to explain exactly why something is fun–kind of like how explaining a joke never really communicates the funniness of the joke. Describing the events of a fun interaction wouldn’t necessarily convey why it was fun. We often have evidence that people had fun–laughter, replaying, showing it to friends, trying to master it–but we don’t have a formula for exactly why.

The fact that fun can arise out of so many different contexts, and is often such a personal experience, makes it very difficult to define what fun is. But luckily, we don’t have to! We can make fun things without having a rock-solid definition of or equation for fun, much like how we can create jokes without having a scientific definition of what’s funny.

But if we don’t have an equation to find fun, that means it’s a much more delicate operation. In order to find fun, we must be attuned to fun. We have to:

• Closely observe other games and the world outside of games to discover potential new, interesting, fun mechanics, and
• Figure out how to make every single thing in the game push the player towards that fun experience.

So how do you find the fun?

Case study: Slam City Oracles

As a case study, I’m going to run you through the process I took for developing my most recent game, Slam City Oracles. Slam City Oracles was the game I made for my No Quarter 2014 commission. It’s a 2 player, cooperative, Grand Theft Auto meets Katamari meets riot grrrl slam-em-up, where you have two minutes to cause as much chaos in this city as possible.

You may be surprised to learn that a game that ended up looking like this…

… started like this.

Inspiration

Okay, so that’s not actually exactly where it started. For a long time, I had been interested in this idea of “riot grrrl game design.” I had grown up with riot grrrl, and had always loved the fact that its tenets were all about taking up space, being loud, and loving other women/prioritizing female friendships. The zines I read and the shows I went to changed my life for sure–I have many fond memories of jumping around and screaming along to lyrics at the top of my lungs, getting bruised and elbowed and dizzy and being totally into it.

But riot grrrl was mainly a musical movement, and I was a game designer, not a musician. So I started wondering: what would a riot grrrl game feel like? How could I make a game that felt like being in a crowd or a mosh pit at a show?

I got stuck on this sensation of being in a mosh pit–the vertigo, the spinning, the slamming, the bumping around–and kept turning it over in my head as a potential mechanic for my No Quarter game.

At the same time, I was also playing a lot of games (half for inspiration, half to procrastinate). I happened upon two games: Luftrausers and ROCKETSROCKETSROCKETS.

Although the goals and number of players in these games are different, they had exactly the sort of dizzying feeling I was so obsessed with.

I did what I usually do when I see a game I wish I’d made: I laid face-down on my bed for a while and fell into a deep depression and castigated myself for not being a better designer. So that was like an hour. After that pity party, I picked myself up, and thought: okay, so there’s obviously something compelling about making mechanics that support these sorts of dizzying aerial maneuvers. So what can I bring to the table? What if instead of diving or flying, like in these other games, you were slamming?

This is also around the time when I saw the music video for Turn Down For What:

I remember watching this music video about people dancing so hard they just totally destroy their apartment building, and being like: “This is it. I’m gonna make a game about dancing so hard you tear down a city.”

Process

So I had my great idea for a game. All I had to do was make it.

It was at that point that I built the absolute most simple prototype I could–the one you saw earlier.

It’s barely anything. It’s barely readable. Me and my partner sat down to mess with it. We remarked about how silly it was, how abstract it was, how little was in it… and kept messing around. We kept tossing each other up and giggling as we slammed down. We just kept playing.

When I realized that we hadn’t put this ridiculous, tiny pile of code down, I realized that I had something. It was the first nugget of what would be the game: this intense vertical motion, with this sort of bounce house/ball pit effect.

So the question was: where could I go from here? I had a nugget of the fun interaction, but even given the loosest definition of “game,” I barely had a game. How could I turn that tiny prototype into something that was actually really fun? How could I make sure every new addition spoke to the experience I was trying to convey?

This is where 99% of the work went, as I was consistently super duper totally wrong.

Example 1: I knew vertical motion was fun, but was it more fun to move horizontally (like bounding), or climb up vertically? I had assumed the former, and so I had designed the levels horizontally:

It turned out everyone loved going higher and higher, and saw horizontal movement as not super exciting, so I had to retool the levels to go vertically instead:

Example 2: I knew climbing motion was fun, but was it more fun to try and reach the top, or to get a lot of air and then do a really big slam at the bottom that would send a lot of stuff flying?

I assumed the latter, thinking it as a lovely way to feel like you’re jumping into a pile of leaves. But it turned out that folks tended to get frustrated if they slammed down past their platform, ending up on a lower one–even if that slam got them more points! So in reality, it was the former, so I designed a level where it was a lot harder to fall through the cracks.

Example 3: Ok, so if you get to smash shit up, how does it feel to smash shit up? I assumed folks would want to be careful and accurate with their slams, and would feel more satisfied if they managed to move a big heavy thing after a lot of buildup.

In reality, people responded a lot more to the game when the physics were faster and looser. Compare the following two images:

It’s the same game, but they sure feel different.

Example 4: Given that this was going to be a cooperative game, I decided to add moments for interaction between players, and mechanics for them to affect each other in-game. After all, when you’re dancing in a crowd at a show, it’s all about feeling your body be pushed around by other bodies. So I included a mechanic where you could throw the other player upward, which would get them higher than just slamming.

In reality, folks preferred to interact off-screen: sure, they would try to get to the same places together, and try to slam down on stuff at the same time, but that was all done by talking to each other. They were confused by the throwing mechanic–since the entire rest of the game was about slamming yourself down to bounce up–and were frustrated by trying to get it to work. Eventually, a playtester suggested I cut it, making it a one-button + joystick game that was immediately more readable, more playable, and more fun.

This kind of work continued on for quite a while, until it became the game that you see today.

It got a lot of nice press, which I include just so you have outside proof that other folks think this game is fun too:

So what lessons can we draw out of this process? What things did I do that helped me find the fun?

Finding the fun: overview

The first thing to notice is that there are two parts of the process:

• Coming up with a mechanic that feels fun on its own
• Finessing that mechanic so everything in the game works towards that fun experience

You really can’t have one without the other. A boring idea executed well typically isn’t that fun, and an interesting idea executed poorly often isn’t that fun either. Both are necessary.

So let’s start with the first part: attuning yourself to fun mechanics.

Attuning yourself to fun mechanics

A lot of game design writings focus on creating challenging systems, which is a totally legit kind of fun (agon!) but for now, I’d like to talk less about creating difficulty and holistic systems and more about creating fun that emerges out of the player encountering new, surprising, and joyous experiences.

Maybe the quickest shortcut to make a fun game is to clone a game that’s fun and that’s already been done. There’s plenty of that in the app store. But given that you’re here to learn about game design, you clearly have an interest in being original and in making unique and interesting things. So: if we’re not going to clone games, we have to start figuring out how we source inspiration.

In my experience, the best way to come up with interesting and fun mechanics is to be attuned to the world around you. It sounds corny and hippie-artsy, but it’s a great way to get inspiration. Sometimes the most mundane activities contain the seed for super weird or super cool or super compelling game mechanics that you never would have noticed otherwise.

And: notice I said “the world,” not just “other games!” As game designers, it’s always good to know what other games are doing, but it’s not necessarily enough. Why not take inspiration from art? music? design? gardening? petting a dog?

When I start making a game, I tend to mine mechanics from either sensations or daydreams. By sensations, I mean a feeling that I’ve had while doing a particular thing. By daydreams, I mean experiences that I’ve wanted to have but that I can’t in real life, due to a lack of skill, lack of mastery, or it being super not feasible in reality.

Sensations

Although a lot of inspiration for SCO came from other games, the core mechanic emerged out of a strong sense memory. I basically jumped around at punk shows like it was my job for a lot of my youth. The feeling of being there and doing that–the sense of being invincible, the physicality of slamming into other people, the goofiness, the adrenaline–was such an intense and compelling memory for me, and I figured it might be to other folks to.

So: how can you draw from sensations that are familiar or compelling or super weird and use them as the basis for a mechanic and a system?

Nina Freeman and her team make a lot of games that tap into the viserval feelings of being a young adult. How do you Do It is one example that I love that uses a memory like that and turns it into a mechanic.

The game was inspired by the designer’s experiences of growing up, playing with dolls, and wondering about sex. The entire mechanic is slamming these dolls together with the same goofy lack of grace that little kids have when they make Barbies kiss.

The clumsiness of the slamming, the arbitrariness of the scoring, and the goofy physics all work together to create a system and a mechanic that tap into those memories of being a young person figuring stuff out. It’s a super compelling game and one that taps into the awkwardness of growing up to create a totally unique and fun game mechanic.

Keita Takahashi, one of my personal heroes, has talked about the inspirations for game mechanics that he finds hidden in everyday life. He’s mentioned how Noby Noby Boy was inspired by him walking his dog and feeling the the lead go slack and then snap back.

For Katamari Damacy, he’s talked about gleaning inspiration from the simple joy that a kid feels while rolling a ball.

Notably, neither of these games are literal interpretations of these real life mechanics. Noby Noby Boy might have been inspired by dog leashes, but it’s not Dog Walker 2k16, nor is Katamari Damacy literally a ball-rolling simulation. But you can see the line from personal experience and sense memory to final product. These sensations informed the core idea of the experience that the player should feel while playing, with the system to support that emerging around it. They’re really effective examples of taking the feeling of something mundane or everyday and growing that feeling into an entirely new world and game mechanic.

Some prompts to ask yourself when you’re trying to brainstorm fun game mechanics:

• What’s the strongest, loveliest, funniest memory you have?

• How might you build a system that communicates that feeling?

Daydreams

So far we’ve talked about real-life experiences, observations, and sense memories. But we can also tap into the opposite end of the spectrum: the field of daydreams. What’s something you daydream about, or have always wanted to try, or have always wanted to do, but know you can’t master? What’s something that seems impossible or super illegal that also seems really fun? What tropes can you play with when you make a game?

This is the point at which I want to point out the huge difference between daydreams and realistic simulation. Although realistic simulation has appeal for a niche group of people, what I’m talking about here is much less about realism and much more about capturing what people think the essence of a situation or activity is.

A game design professor of mine, Nick Fortugno, uses the difference between Tony Hawk Ride and Tony Hawk Pro Skater as an example–hopefully I’ll do justice to his observations here.

• In Ride, you use a skateboard peripheral to simulate the riding of an actual skateboard in the game. It’s shaped just like a real skateboard (without wheels), and can detect all sorts of turning, leaning, hopping, and weight shifting.

• In the rest of the Tony Hawk franchise, you use a typical game controller, and the game is much less about actual physical movement and more about judging distances, pushing your luck, and mastering combos.

Notice a difference? In Ride, the focus is on performing a semi-realistic version of the activity of skateboarding. In Pro Skater, the focus is on making the player feel like they’re already as good as a real pro skater.

Ride totally flopped. It had super critical and commercial reception and almost risked canceling the rest of the Tony Hawk games (back in 2009). Meanwhile, Pro Skater games from around the same time got much better reviews. One guess as to why is because folks didn’t necessarily want the challenge of skateboarding (some folks do, and they’re typically real-life skateboarders). What folks really wanted out of the game was an experience they daydreamed about: the effortless feeling of being a professional skateboarder.

Guitar Hero is a great example of this. It doesn’t simulate playing a guitar–it simulates the feeling of being a rock star.

Keep Talking and Nobody Explodes is another exceptional example. It utilizes the tropes of bomb defusal that we see in action movies and allows the players an opportunity to feel like they have that same finesse and expertise.

Some more prompts to ask yourself when you’re trying to brainstorm fun game mechanics:

• What tropes or daydreams can you faciliate through your game’s system?

• How can a game simulate the feeling of being [something] without requiring real life skill or expertise?

Focusing the fun

Ok, so you have your mechanic–now what?

Keep your first prototype simple

You cut absolutely everything and build the tiniest thing possible first, that’s what.

This may sound unintuitive. You may think that the system in your head is the perfect way to make your game the most fun it can be. But remember the prototyping process I had with Slam City Oracles, and remember how many times I was wrong–even after I had found my first nugget of fun. Introducing too many factors at once would make it hard to know when I had added something unfun–the more things you have interacting in your game, the more breaking points you have. And giving into the desire to add stuff rarely works: it frequently means you’re just putting a bandaid on a not super fun experience. So, the best thing you can do with your sprawling idea for a game is to make the tiniest version of it first.

Think: what is the core experience of your game? Can you narrow it down to exactly one mechanic? Can you break that mechanic down even more to just one or two actions? How can you make that microcosm of your game fun?

Starting with the most core fun experience will make the stuff on top–the stuff that makes it complex or super-replayable or super beautiful–arise much more quickly and cleanly.

Remember this gif?

Did you know there’s stuff in this prototype that I should have cut?

Really, there is. If you watch towards the end of the gif, you can see P2 throw P1 up in the air. This was my initial way of giving the players a way to get height, before I created bouncy floors. However, that mechanic stuck around even after the bouncy floors came in.

The throwing mechanic confused everyone. When was it better to throw and when was it better to bounce? Wouldn’t you always want to throw since that’s going up, unlike the slam’s going down? When would you use which? And so on and so forth.

Given that it was in my first game, I kept it in all later prototypes, thinking it was a core part of the game. One day, a friend suggested I take it out–and it suddenly became clear that I didn’t need it. I cut it, and once the game became a one-button + one joystick game, those usability problems evaporated and the game became much more intuitive and much more fun as a result.

So, if you think your prototype is the simplest it can be, it probably isn’t.

Some questions to ask yourself during this process

• Does your first prototype express your core mechanic?

• Has that core mechanic been broken down as thoroughly as possible?

Playtest it constantly

With prototyping necessarily comes playtesting. It never really gets any less scary. I’ve been doing this for about eleven years and I want to throw up every time. But it’s always, always important for focusing in on the fun.

As the designer, it’s very unlikely that you’ll be correct about your guesses with regard to where people will have fun, so it’s very important to put the game in front of those folks, so you can see where the fun actually is.

Usually one of three things will happen:

• Maybe they play for ages and gush about how great it is. This happens, sometimes.

• Maybe they reveal that the interaction isn’t fun, so you have to go back to the drawing board and review your last addition or scrap the whole thing.

• Maybe they don’t find the fun in the same place that you thought they would, but they’re finding it in a totally new area of your game that you never would have thought of.

They’re all useful feedback. But you can’t know which path you’re on until you show people.

Like with prototyping, before a playtest, try to figure out what a successful playtest would look like for you. That might include testing hypotheses (“let’s see whether folks understand the game better without the throwing mechanic”) or simply seeing where people react to your game. For me, I know I’m hot on the trail of fun if at least two of the following happen:

• The player wants to show or share my game with a friend

• The player breaks out into laughter

• The player wants to play multiple times

If you’ve drilled down to the core fun and target your playtests, you can watch people play and see where they’re finding the fun (if they’re finding any at all).

For Slam City Oracles, I had playtested from the start, so I knew the intense vertical motion was fun–but there were at least 5-6 playgests over the 5-6 weeks that I developed the game in. Those playtests were how I discovered all those observations about horizontal vs vertical movement, about feeling bad when you fall to the bottom, about that dang throw mechanic. Watching people interact with those parts of my system helped me tweak the game and laser focus my development on what was actually fun, rather than my incorrect guess of what was fun.

So ask yourself:

• Can you frame each new prototype as answering one question or hypothesis?

Balancing

In games and software, it might take the same time to do the first 90% of programming and prototyping as it does to do the last 10% of balancing.

When I say balancing, I mean something different from polishing. Polishing has a connotation of smoothness and aesthetic completeness that’s not really what I’m talking about. Instead, I mean the tweaking that you do to make sure your game isn’t too hard, too easy, or totally inscrutable.

It’s useful to think about flow when you think about balancing. Flow is basically “the zone.” It’s how you feel when you’re totally immersed in an activity, when you feel energized and fully involved. It’s when you’re so enjoying what you’re doing that you look up and realize that hours have gone by.

As you can see in the above graphic (from Sean Baron’s Gamasutra article), a person’s skill and the difficulty of a task interact to result in different cognitive and emotional states.

• If the skill is too low and the task is too hard, you get anxiety.

• If the skill is too high and the task is too easy, you get boredom.

Where skill and difficulty are roughly proportinal, people enter these pleasant flow states.

Slam City Oracles’ vertical movement came from floors that were attached to springs, which allowed them to act kind of like a trampoline. It was a super easy technique to design around when there was just one floor… but then, when I started making the vertical levels, got REALLY FRUSTRATING.

• How do you make sure the players don’t get too far away from each other vertically (leading to camera zoom problems)?

• How do you make sure that a given platform doesn’t bounce a player too high or a player too low (gating)?

• How do you make sure that a platform behaves consistently and bounces the player the right amount when it has a bunch of items on it, as well as just a few items (different weights)?

I spent what felt like an infinite amount of time tweaking the spring values and masses of the different items to make sure the game felt good and correctly challenging, whether you were just starting a game, in the middle of a round, or racing towards the finish line. I think it made the difference between it being a fun toy people might mess with for 30s, and a game that people would pick up and play again and again.

So ask yourself:

• How can you tune everything in the game so it helps amp up the core mechanic at all times?

Conclusion

What I’ve laid out here isn’t so much a methodology as it is an attunement: a suggestion fo the things you should start to practice and pay attention to to make fun games.

It’s split between the generation of unusual, interesting ideas (your knowledge of other games and how to remix them; your own personal experiences and memories that are ripe for making stuff out of; tropes and daydreams you can create systems around), and the execution of those ideas (through prototyping, playtesting, and balancing).

All of us will have different senses of what makes something fun. That’s okay! That means you’re bound to make something that’s different from my definition of fun, which is what makes game design so exciting. Hopefully these experiences have given you some insight into techniques you can incorporate into your own practice to create the most fun experiences that you can.

---

Liked this post? Want to buy me a coffee so I can write more? Throw me a tip here.