How to Focus your Game and Give Players More of What They Want

We’re excited about the new platform we’re developing called InstantAction. We believe it will be an exciting new medium for indies to publish to. But no matter what platform a game resides on or what new technology exists, the same bread and butter principles still guide all good design. Having a cool platform with the opportunities and features that platform affords is not a shortcut to good design. And a part of good design is focusing your game to give players a satisfying experience. This post describes a technique to help bring focus to your design to give players more of what they want and less of what they don’t. This is one technique and not the last word on the matter, but try it and see if it’s useful to you.

This kid is definitely NOT getting more of what he wants!
Focus your design to give players more of what they want by supporting your core fun.

You have a vision for what your game should be, but you can’t see it with a hundred percent clarity yet. Sometimes it feels like you’re a jazz musician trying out different riffs and going with what seems cool. In the end, as long as the behavior of the game works — that is, it’s fun — the process of how you got there doesn’t matter. Or does it?

In later stages of game design it takes structure to produce a well balanced design, unlike abstract painting where you dabble and feel your way through the entire process. Game design is in good part a methodology. That methodology taken to its extreme removes the creative element from design. But used in good measure, design benefits from structural techniques. The following is a simple design focusing technique that I employ. In addition to using it, I’ve helped several developers with it to help them focus their designs too. It is another tool for the designer’s arsenal. Let’s begin!

The Asset List Mentality

Game designers are also often coders, where thought tends towards the linear, logical, and textual. Those are effective for writing code, but not for designing games. Code lives in a world of absolutes, where x has a specific value, and y performs a specific function. But game design lives in a world of relatives, where relationships between elements are as important as the details of the element itself.

Take a Bomberman style game for example. To a coder, the game may look like a list of features, which are technical requirements to be met:

  • Player movement
  • Player bombing
  • Wall breaking
  • Enemy destruction
  • Enemy avoiding
  • Powerups
  • Level exit

This view is wholly suitable for a coder’s purposes. But this linear, logical, textual, non-relative listing of game elements leaves much to be desired in the way of showing relationships between elements and each’s relative importance. There is a better way.

The above is a visual chart of the same information. It is NOT a flowchart. It is a listing of all the main game features arranged per their relationships. It is not a perfect representation or a technical diagram — it is a rough approximation of both what is considered a main game feature or not, and of how they are related. There will be an arrangement that makes the most sense for your game and you will know when it is right. It may not make perfect logical sense in its arrangement, but a placement will intuitively feel right.

An Apple with One Core

The very first question you must answer is this: what is your core? What is the game really about? What’s the central idea? Where’s the BEEF?

In a Bomberman style game as above, the core of the game is blowing shit up; making things go boom; explosions. That’s what you do more than anything, that’s what’s fun about the game, that’s what the game is all about. So draw your core in the center and put a big circle around it. Everything else in your design should relate to this core. Everything should point back to and support this core.

If your core is spread across an array of smaller things, you don’t have a core. If your core is actually across two things because you’re brilliantly combining two disparate elements, you don’t have a core. The earth has one core, an apple has one core, a core is a core because it’s one thing. Your core, what your game is all about, should be one thing. It can even be an abstract idea, like “creating fear,” but it should be one thing. You want a sharply focused, well supported core. For Bomberman that core is bombing.

Once you have your core drawn, arrange the remaining main game features as they relate to one another and make sense. Again there is no science here, it will just feel right when you get the placement right.

Is THAT the Punchline?

Now that you have your visual chart drawn and know what your design is centered on, ask yourself this: is what the core of the game is also what is most fun about the game? Is what you DO the most of in the game also what you WANT to do the most of? Was there some emergent fun that spontaneously happened that is more fun than the focus you built your design around? Be honest with these answers, and have people test your game. You may have to build out a prototype to effectively answer these questions. Game design is part experimentation, and what turns out to be fun isn’t always what your design is already focused on. Focus on what’s organically fun instead of what you have to force to be fun and you’ll generally build a better game.

Core Support

Now that you’ve got your visual chart with a firm core and with the core also being what’s most fun about the game, the next question you have to answer is this: are you supporting your core?

First, dream up ways to support the core. Note in the Bomberman example that player placement of bombs on the screen has the most consequences: invoking player movement (to get out of the way of the explosion), potentially busting a wall (leading to prizes or the exit), or potentially busting an enemy (the best reward of all). The design COULD have had all the support on player movement: walls could have broken as you walked into them, enemies died after you get a powerup from a wall piece ala Pac Man and walk into them. But doing those wouldn’t have supported what’s centrally fun about the game, which is bombin’ stuff.

In Pac Man, what’s fun about the game is eating pellets. Chomp chomp! So they made some extra cool pellets that gave you a special ability. That’s support. Then they made the special ability be that the ghosts were suddenly traveling pellets themselves! That’s brilliant support.

If I had a second button for a Bomberman style game, I would use it for a second way to throw a bomb, not a run button, and not a third thing entirely, like a gun. A run button would support player movement, which is not the game’s focus of bombing. A gun would be a separate thing entirely, relating only to enemy destruction, giving no focus to the design. A second button for a bomb could be shooting it until it hits a wall and stops. That would add depth to the game and continue to sharpen the focus of bombing stuff. The game title is after all “Bomberman” and not “MovingAndBombingMan“.

Think of other ways to support your core. For Bomberman this could mean more classes of bombs, like EMP bombs that freeze only robot class enemies, but whose explosion doesn’t hurt you. Or more ways to place a bomb, like holding down the bomb button to toss it over a wall instead of just placing it in front of you. In the art direction department, the explosions had better be pretty sweet looking. If an enemy or two looks a little off it will be forgiven; bombing stuff is the focus so that’s what has to be done right.

So think of different creative ways to support your core. Then think of things to support the most fun things of those things and so on. This is the fun part of game design. Brainstorm creatively. Be flexible with your design. Build it out and make it as detailed or summarized as you want. Play with it and have fun.

Trimming Fat

Now that you’ve built out a branching list of potential features, it’s time to cut back to pare the design down to something elegant, sleek, focused, and most importantly to indie developers, do-able. Plus, a design with too many elements is like a dish with too many ingredients; it becomes harder to balance with each additional feature and often comes out as either overwhelming to the palette, obnoxiously over-ambitious, or spread too thin. In addition, the point of brainstorming was in knowing that only the best of ideas would survive the editing process, and that editing time is now.

There are many reasons a feature gets cut. You may have to prototype some features to be able to definitively weigh the strength of them. Other times what features are axed may depend on budget (physics, for example, which adds greatly to development and testing costs but often doesn’t add compelling value to the game compared to faked physics). Don’t be too married to any one feature and be ready to be ruthless. If it’s not pulling its weight, or it’s not supporting the core enough, or worse yet it’s diverging the core or is orphaned on your visual chart, consider cutting it.

Helping and Hurting the Player

As you edit the design, cutting and adding features, keep in mind which elements help or hurt the player for balance. For example, if your core is bombing stuff, then effective game helpers help you bomb stuff: barrels that explode and cause chain reactions, power ups focused on increasing your bombing power rather than making you walk faster, walls that randomly crumble on their own thereby revealing potential treasure or the way out. Balance helping and hurting elements to make the game neither too easy and trivial nor too difficult and punishing. If there are parts of the game that players struggle with, try adding helping elements before you cut it. That additional support may be just what that feature needs.

Weaving Game Elements

As you look at your diagram, consider how elements call back to one another. Ideally you want your design elements to be tied to one another and refer back to one another as much as possible like a spiderweb or tapestry, rather than having any orphan game elements or many disparate game elements that don’t make sense in the same juxtaposition because they’re isolated and not tied together.

Another Example

As a final example and to show the process from start to finish, here’s what the visual diagram looks like for my own title Shelled:

First, find the focus. Firing shells is clearly the focus of the game. As it happens, that’s also what’s most fun about the game, an ideal match of focus with what’s fun.

Now, support the focus. Firing has lots of support — shooting always results in something cool happening (either hitting/killing an enemy or making a big dent in the ground, both positive feedback); you can shoot multiple ways (nukes, sliding shell, etc); and you can shoot gold to collect it. The core is well supported, giving players more of what they want — more of what’s the most fun.

Now, support what’s supporting the core: enemies can be AI or humans via internet games; the terrain can be destroyed peckishly or massively; and the multiple weapons have different unique shell art, particle effects, and terrain impacts.

Now to trim the fat. We did that in the pre-alpha (aka “pretty awful”) version. Examples of cuts include turtle pilots / foot soldiers (which didn’t support the core), tank upgrades like shields and spikes (which didn’t support the core), and turn based play (which made you wait longer between shots, thereby not supporting the core).

Now consider what helps and hurts the player. Water slows the player down, for example, while there’s no turbo booster in the environment to balance that out and speed the player up. The only positive outcome of flight, aside from position change, is picking up a golden shell. So flight has more hurting it than helping it. Note to self for next version.

Consider which elements are woven together. Flight is indeed orphaned from firing and relates to it only in that both are primary actions that the player can perform. You cannot actually fire while flying — the game prevents that. So they are not woven together very skillfully. Again, note to self for next time. Flight always felt like it diverged the core game, but you needed some defensive options, and needed a way to get out of a non-fun deep pit (ET anyone?). So it was a necessary evil, but it needs better relation to the core game.

Charting to focus your design is a disarmingly simple technique yet can yield impressive results. If nothing else it forces you to abstract and consider your design, looking at it in a way you are not natively used to. By questioning and poking at your design, you will make a better game. And though we are very excited about this upcoming platform and opportunity for indies, some things in the industry never change and good design is timeless.

Joshua Dallman, GG

  • Joe

    Great article.

    I thought about this all the time when I was developing Joystick Johnny. Except what you call the core, I called the concept. I see it as a very imprecise thing, though. Like a black hole — you can’t see it, it’s hard to pin down exactly, but you know it’s there because of the influence it exerts on everything around it.

  • Brian

    Good read. It’s easy to see how the graphing technique can be useful for analyzing game design. Do you have any further reading references for game design analysis? Did you come up with this technique yourself, or does it come from somewhere else? Any info appreciated.

  • Gaiiden

    Awesome. I linked to it in our resources section over at GDNet. Also got your other post on pitching games there too. Looking forward to more!

  • Michael Walbridge

    I recently reviewed a game in beta that should be done soon, and the ideas and the system were revolutionary, in my eyes.

    Then I played it; it was like something made up by Marx or contemporary French philosopher–good on paper and capturing something we’re looking for, but nothing with substance.

    Here’s to better games being released by you and by us.


  • David Burchanowski

    Interesting. I’ve never really thought of game mechanics in terms of core/non-core terms before, likely partially due to the game review and advertising industries’ near total focus on “features”, which are often not really related to each other at all. I’ll have to keep this sort of thing in mind for the future, could come in handy.

  • Leon Lubking

    great article, very helpful indeed!

    Coincedentally i bumped into this while designing the concepts of a new game. Using this technique to re-evaluate some of my ideas was a boon, especially this early on. I’l be keeping this in mind now whenever i dream up another impossible feature ;)

    Keep up the good work!

  • Jonathan

    I think i have something for your flight issue. I am only looking at it conceptually as I haven’t played your game (yet) but I think I understand its premise. In your shoes, I would consider a shell that shot a translocator… a one way teleporter to where the shell lands.

    1. It keeps focus… you are still just shooting a special purpose round
    2. The power could be tweaked simply by controlling the speed of fire and the distance it goes… what if it takes you long enough to transport that against a skilled opponent it is risky because they get a free shot or two while you are firing the translocator.

    Also, thanks for the write up. You have really got me to thinking about atmospheric focus as a supporting element instead of a core.

  • Explosives Automation

    In a Bomberman style game as above, the core of the game is blowing shit up; making things go boom; explosions. That’s what you do more than anything, that’s what’s fun about the game, that’s what the game is all about