An atomic theory of fun game design

This is the original essay in which I worked out the basics of my game grammar approach. It later became a GDC talk. This essay was written in 2004, and the genesis of it was working through issues with the crafting system in Everquest II with Rod Humble. This essay no longer represents my current understanding of game grammar, but it’s a decent start.

This essay has never been publicly posted (it was originally posted only to a private game developer forum, on June 26th of 2004), but I thought I should make it available both for historical interest and also for the sake of clarifying some of the things that I now take for granted when I discuss game design here on the blog. I can’t expect everyone to have read everything I have ever written, of course, and in this case it’s even worse since some of the material was only delivered at conferences. So many of the responses to the article on narrative were clearly from folks unaware of some of this work that it felt like the right time to post it up.

Since this was written, I have met fellow travelers — boy, was I pissed when Dan Cook’s “Chemistry” article came out a few years later, and had such nicer diagrams! I also found Ben Cousins’ work on “ludemes” later, a term I gladly stole. And I think this served as some inspiration to folks like Stéphane Bura and Joris Dormans who have pushed this in fresh directions I would never have pursued. There have been grammarian get-togethers, Project Horseshoe whitepapers, and more. I even have a pile of blog posts that fit under the “game grammar” tag here on this site for those who are curious about more.

Lately, I’ve been spending a lot of time thinking about the nature of fun. I’ve reduced it down to a cognitive challenge, the notion that fun is the feeling you get when you are exercising your brain by solving a cognitive puzzle. Sometimes the puzzle is provided by a computer, sometimes by another player, but either way, your brain is basically trying to perceive a pattern; victory usually comes from identifying the pattern, then correctly executing on some action that the pattern does not account for. For further thoughts on this and its implications for game design as an art form, I refer you to my presentation “A Theory of Fun.”

This suggests that there are probably ways to break down or otherwise analyze what makes a given puzzle or challenge fun. Now, challenges or puzzles come in a very wide array of forms—spatio-temporal challenges like Tetris, and physical dexterity ones like soccer. What do all of these have in common?

Building a subgame atom
The following algorithm came about from attempting to map the basic features of MMOG combat systems onto MMOG tradeskills, which are usually regarded as not having met a sufficiently high bar of fun. Interestingly, MMO combat itself is often not regarded as having reached that bar either, and yet it succeeds in keeping players captivated for many months on end, when correctly executed.

A successful MMO probably needs to have many individual subgames (of which combat may be one) in order to be successful, and for maximum impact, each of them needs to fulfill all of the following requirements. In fact the atom needs to have certain known “system inputs” and “system outputs” so that it can be hooked together to build game “molecules” if you like.

We typically refer to each atom as being “a game system” in game design, but part of the point of this essay is to show that this definition is to a degree recursive. Once you have knitted together several atoms into a molecule, the molecule as a whole must also meet all the criteria for what makes an atom fun. When looking at a piece of interactive entertainment, it is made out of at least one atom, and possibly many molecules, as in the case of MMOGs. In the end, what we refer to as “scope of a game” is really measure of how many atoms it has.

Taking the MMOG combat example
I’ve selected hack ‘n’ slash MMO combat for my example, because it is a well-established mechanic that has undergone twenty years of refinement; it is a multiplayer mechanic, which brings in additional wrinkles for cooperative games that would otherwise be absent from the model; it can be performed either against computer opponents or other players; and it is typically not a full game in itself, but is one system among several in the MMO, thus demonstrating the recursive and connective qualities of game atoms.

When you break down what makes MMOG combat entertaining, there turn out to be a surprising number of required elements:

• Preparation is required. In most cases, this may be as simple as healing up before entering the encounter. At its best, there is an opportunity here for hooking the combat system into the larger network of subgames via the need for non-combat roles. At a minimum, different forms of preparation should be viable, in order to provide different tactical choices.
• Important point: preparation cannot be allowed to overwhelm skill. In fact, in a game that is a pure test of skill, you may not have variable preparation. It’s worth noting that when this is the case, advanced players will often come to the challenge less prepared on purpose, such as playing DDR backwards, handicapping yourself in chess, or playing Diablo in hardcore mode.
• A sense of place is required. Physical location affects tactics during the encounter, and affects the strategy of which locations to have encounters in. In other words, locations affect risk and reward.
• Important point: it’s easy to have locations that turn out not to matter, in which case this becomes merely tedious. When they do matter, however, they add immensely.
• A solid core mechanic. This is in the nature of a puzzle to solve—it’s a ruleset into which content can be poured, that is intrinsically interesting. Effectively, this core mechanic may be an entire atom in itself.
• Important point: Note that by itself, it is probably interesting only for a limited amount of time.
• A range of challenges. This is content; each enemy provides a unique puzzle. Combinations of enemies then provide additional puzzle types as well.
• Important point: whenever you reach the point where fighting the new enemy can be done using the same tactics as the previous enemy, you have not actually added a new challenge to the game. This is where players find repetition.
• A range of abilities required to solve the encounter. We design our encounters such that it takes teamwork to resolve them, via formally preventing any given character from having all the abilities required. Even in single-player games, however, the player who relies on a single ability usually ends up unable to compete at higher levels.
• Important point: Usually this starts out not being present at the lowest challenge encounters, and rises in necessity as you reach more complex encounters.
• Skill in using the abilities is required. Bad choices lead to failure in the encounter. This skill can be of any sort, really: resource management during the encounter, failures in timing, failures in physical dexterity, failures to monitor all the variables that are in motion.
• Important point: This says nothing about the level of preparation in advance of the fight, which leaves out the issue of skill entirely. It should be possible for a skilled and a non-skilled player to have radically different experiences, all other things being the same. Otherwise, players will rightfully say that they could automate the fight.
• A variable feedback system should be in place. The result of the encounter should not be completely predictable. Ideally, greater skill in completing the encounter should lead to better rewards, but some degree of variability in the reward is important to maintain interest and minimize “farming.”
• Important point: you’re playing with fire here, and if it makes you nervous, this is the only optional item on the list. Merely randomized drops is not sufficient, and it’s incredibly easy to alienate players with long waits for what they want. The feedback should be such that it is always worthwhile, but perhaps not to you—or there should be a system whereby the feedback you get (e.g., the loot) is perhaps tailored to the way that the encounter was resolved. The reward should always be contextual to what the challenge was.
• The Mastery Problem must be dealt with. The system cannot permit high level players to derive maximum benefit from less challenging encounters, or you get bottomfeeding. This has the detrimental effect of also closing lower level players out from access to the content.
• Important point: the only effective way to do this is to forcibly make the lower level content no longer appeal to (or even be usable by!) higher level players.
• Failure has a cost. Loss of the given encounter or challenge ejects you completely from the atom, and pops you out of the stack. Next time you attempt the challenge, you are assumed to come into it from scratch.
• Important point: next time you come back, you may be differently prepared. The challenge you faced does not necessarily need to be reset to its original state, as “wear it down” is a viable approach to a given challenge. This leaves open the question of penalties for failure that extend beyond the individual challenge.

Building an atom diagram
All of these things can be applied to any game system, but it requires approaching the issue theoretically. A simple list gives you this breakdown of required elements:

• Preparation is required.
• A sense of place is required.
• A solid core mechanic.
• A range of challenges.
• A range of abilities required to solve the challenges.
• Skill in using the abilities is required.
• A variable feedback system should be in place.
• The Mastery Problem must be dealt with.
• Failure has a cost.

You can, using this atomic method, consider games as directed graphs of game atoms. A given atom looks like this:

In this diagram, you will notice that the abilities and skills are balanced—that is because otherwise, you get the Mastery Problem. The core itself then becomes a loop of repeatedly testing these abilities and skills against those of the challenge. It is worth pointing out that this entire core mechanic may well be composed of multiple atoms itself.

In terms of ludological theory, since atoms “stack,” popping off the top of the stack effectively takes you out of the “magic circle” of privileged space.

You can then diagram games using this method, and see what the relationships are between game systems. Each input and output onto an atom can be linked to the input or output on another atom, and atoms can be nested within one another.

It’s beyond the scope of this little essay to try diagramming an MMO, but even checkers provides an illustrative example.

1. The preparation step is generally skipped, since this is a two-player game. However, a typical form of prep would be to handicap one side or the other.
2. The place is a fixed board, though interesting variant boards have been constructed using the exact same ruleset (CheckersFour being one such).
3.  The core mechanic of “checkers” is “capture all pieces.”
4.  The range of challenges lies in different possible opponents. In that sense, you can consider checkers to be a “simple game” in that it is not a multi-stage experience. Most board games are not, but something like a puzzle game, which swaps out the space and perhaps the preparation on every level, certainly is.
5.  The range of abilities to solve this is very limited. You have pieces on the board. You can move them. You can jump with them.
6.  The skill lies in choosing which piece to move with. This part is in fact another game atom, because each move is a problem to solve itself: move, or jump?
7.  The variable feedback of winning the overall game of checkers is entirely driven by your emotional response and that of your opponent.
8.  The overall game of checkers does not attempt to solve the mastery problem via formal mechanics. If you come up against a toddler, you will win. This will make for a dull game for both of you. Because of this, we customarily avoid this sort of match-up.
9.  Failure to capture all the pieces results in loss. Next game, you have to start over from scratch, without any of the captures you achieved last game. All record of achievement is lost. Note that layering on something like a rating system or rankings or win-loss records actually nests the entire game of checkers as an atom within the “climb the ranking ladder” game.

Now, nested within the game of checkers is another atom, that of moving a piece and attempting a capture.

1. The preparation step is actually that of the previous moves.
2.  The place is the specific tactical situation created by the previous moves.
3.  The core mechanic is “capture a piece.”
4.  The challenge lies in the risk of capture of multiple of your pieces.
5.  Your range of abilities involve moving one piece diagonally. Depending on the game situation, that may be a king capture or a regular checker capture, and it might include multiple jumps.
6.  There is no skill required in this atom. This is an indicator that you cannot nest another atom within this one. It is a fundamental atomic unit of checkers.
7. The variable feedback for success is interesting. There’s the direct success of capturing one piece, there’s extreme success of capturing multiple pieces via a chain of jumps, there’s the orthogonal success of failing to capture a piece but instead creating a king, and there’s the Pyrrhic victory of sacrificing a piece in order to create a better landscape in the next iteration of the atom. This variety is what makes checkers an interesting game. Removing one of these dynamics would make the game significantly poorer.
8.  Since there is no skill involved in the game of moving a single piece, there is no mastery problem.
9.  Failure ejects from the atom, and next turn you start on a new landscape that is worse off than the one you just left (because your opponent gets to move).

Practical applications
All the above sounds very theoretical and useless. What happens when you walk through a crafting system using this? Let’s look at what we do with tradeskills in most MMOs.

• Preparation is required. Ever since the days of Ultima Online, we’ve relied on “getting the right pieces” to provide the fun in crafting. So we’ve done well on the “preparation is required” aspect of things as far as crafting goes. BUT: Preparation in itself ideally follows all of these rules recursively (eg, we should regard the harvesting mechanic as needing to follow all of these rules in and of itself). By and large, we have not done that. We also have usually failed to take full advantage of the “preparation should be able to take multiple forms” part of this—we have by and large gone with static ingredients for static results.
• A sense of place is required. This is highly underexploited in crafting systems today. Different locales providing different advantages and disadvantages to crafting was explored a bit in Star Wars Galaxies, but has not been addressed much by and large.
• A solid core mechanic. By and large, we’ve relied on simple combination. That’s not an interesting ruleset in and of itself—it shifts all the burden of fun onto the preparation. We need a mechanic that “fights back” as AIs do in combat. This is the core of the issue with crafting. It is currently on the order of moving a single checker piece, as opposed to playing checkers.
• A range of challenges. This is, simply put, the range of possible craftables. However, it’s worth noting that since the solid core mechanic is missing, the range of challenges is not generally significantly interesting. The different items (as “opponents”) do not have different abilities or skill to use against you except for perhaps a variable failure rate.
• A range of abilities required to solve the encounter. This is usually true to a degree, but currently, most crafting systems do not require interdependence between players at the actual crafting step. Instead, they put all of that in the resource gathering step. The abilities needed are part of the preparatory step, since there’s no explicit use of ability during crafting itself. Requiring multiple individuals working together to create something has best been expressed by pizza-making in Sims Online, and has hardly been used anywhere else.
• Skill in using the abilities is required. This is missing altogether in most cases. There’s a minor amount of gambling in SWG’s crafting system, but that’s about it. Lacking a core, there’s no way to use abilities. A good core mechanic is going to provide scope for use of abilities, and for skillful application of those abilities.
• A variable feedback system should be in place.  In most cases, we do not do this. Currently, success almost always gives you exactly what you want. This means that crafting an item is actually simpler than moving a checker piece, which has multiple possible outcomes.
• The Mastery Problem must be dealt with. This problem crushes most online game crafting systems, as high level crafters completely block the market to lower levels players.
• Failure has a cost. This, we usually do.

In the end…
A game diagram can be regarded as fractal. When you diagram your game, each possible skill choice will be an atom, and systems will be built out of linked and nested atoms. From far away, the whole game looks like one atom, one where the failure and success cases are both “game over.”

If you have an atom that has a skill choice within it, and there’s no atom nested within it, you’re not done designing. If you have an atom that doesn’t hit all nine elements, that atom probably won’t be a fun game system, and needs to be redesigned.

Is this an algorithm for fun? No, but it’s a useful tool for checking on the absence of fun, in that you can identify systems that fail to meet all the criteria. As such, it may prove useful in terms of game critique. Simply check each system against this list:

• Do you have to prepare before taking on the challenge?
• Does the preparatory step pass this list as well?
• Can you prepare in different ways and still succeed?
• Does the environment in which the challenge takes place affect the challenge?
• Are there solid rules defined for the challenge you undertake?
• Can the one ruleset support multiple types of challenges?
• Can the player bring multiple abilities to bear on the challenge?
• At high levels of difficulty, does the player have to bring multiple abilities to bear on the challenge?
• Is there skill involved in using an ability? (If not, is this a fundamental “move” in the game?)
• Are there multiple success states to overcoming the challenge? (In other words, success should not have a single guaranteed result).
• Do advanced players not get a benefit from tackling easy challenges?
• Does failing at the challenge at the very least make you have to try again?

If any of the above answers is “no,” then the game system is probably worth re-addressing.