Game Systems as Engines

In a video I did recently, I talked a bit about these system-types that I originally posited in my book – the four “forms” of Toy, Puzzle, Contest and Game. This is not a breakdown of how I see things in the current state of game design, but rather a vision for what I think game design should be.

Before we go on – prescriptive definition warning. I use common words to refer to very specific things, so if you see the chart and think “what the hell is this guy talking about” – simply read below. I elaborate in detail about what I mean.

The main reason that this system is useful is because it gives game designers an abstract gameplay purpose to start with. It answers the question of “what should I be trying to do” at the most basic level.

This might sound arbitrary to some – I’ll address that quickly before going in more detail on this new chart.


It’s Abitrary!

Why are the systems Toy, Puzzle, Contest and Game, and not some other kinds of systems? What were these based on?

As far as I can tell, these are the four things that a person can be doing when interacting with a system. I suppose that my evidence for this would basically be inductive – I cannot “prove without a shadow of a doubt” that these are the systems, but I have observed it, and I continue to observe it. In other words, every example of play I can think of fits well into this system. Secondly, even if it is not “the true four ways” in some absolute sense, it is a very useful way to divide things up.

Of course, some existing systems use a combination of two or more of these types of interaction, but I have yet to find a fifth type of interaction that is unique from these.  If anyone can think of one, or argue that one of the types of interaction that I have listed here is not appropriate, or that two of the types of interaction I’ve listed as different are actually the same, please let me know.


Systems As Engines

Late last night, I figured that it might be helpful to see the four engine types laid out in this way:


Let me clarify these a bit, because some of these words might have connotations that I don’t mean, but they’re as close as I could get with the words I could find.

Toy – A Toy is any interactive system without a goal / problem to solve.  This is not meant to imply any kind of correlation with “childishness” or anything.  You can also call this a Bare Interactive System.  Many simulators fall into this category.

Play – I mean “play” as in the expression “to play with”, or “to mess with”.  This isn’t to say that this work is necessarily trivial, but rather that it’s exploratory.

Mapping – This is the result of the play I was talking about.  With play, we are finding edges, figuring out how a thing will respond.  Eventually we end up with some kind of mapping of how this thing works.  Interestingly, you could say that the object of a toy is to discover its rules.

HOW CAN WE USE THIS?  A good toy will have a vast amount of rules to discover.  Think Legos, or Minecraft, or a ball.


Puzzle – Don’t think about the normal colloquial (and very messy) “puzzle” word.  I simply mean anything with a goal / answer / problem.  So, a math problem counts as a puzzle.

Work – Work has a bad connotation, but think along the lines of a math problem when people say “show your work”.  Essentially, some effort and process towards uncovering the answer must be the input of a puzzle.  (Do not think that this means that solving a puzzle can’t be fun!)

Answer – This is the objective we were searching for.   Once the answer is found, the puzzle is no longer of value to us, because the search for the answer was where the value was.

HOW CAN WE USE THIS?  A good puzzle will have a difficult-to-find answer.  Obvious to most people, yes – but it’s still true.


Contest – Thankfully, this definition lines up pretty closely with the colloquial definition, so not much explanation needed here.

Test – Think “stress test”.  We are attempting to find the limits of something.  Note that this is unlike the wide, lateral exploration of “play”.  This is a vertical, straight test of one specific resource.

Measurement – Measurements are inherently relative and can have no meaning without something to measure up TO.  Therefore, all contests compare the measurement (result) to another result, and determine a winner and a loser.

HOW CAN WE USE THIS?  Good contests don’t have a low “cap” on that vertical skill possibility space.


Game – This is the most controversial word I use in my system.  Some prefer “decision-contest” and some have suggested “strategy game”.  Either way, the point is that this system, as I define it, is a “contest of decision-making”.  The concept is what’s important here.

Decide – The nature of a decision is very interesting and not trivial.  People have argued to me before that button-inputs in Guitar Hero are “decisions”.  I disagree with this characterization;  I think it would then follow that if you were walking and tripped, that you decided to trip.  “Why did you decide to trip”, only a jerk would ask, because obviously you did not decide this.  To help understand this aspect, perhaps think of decisions, in this context, as conscious decisions.

Games present choices that are ambiguous.  Ambiguous choices are choices that live somewhere between a guess and an answer.  A “guess” would be that you have 0% of the information you need to make a decision, like if I asked you whether I was thinking of the number 1 or 2 right now and you had to make that choice, based on no other information.  An answer would be if I asked you to decide which answer to the following problem is correct:

1+1 = ?

a). 2

b). 9999

The answer is “a”; there’s no ambiguity here, so this does not qualify as what I refer to as a decision.

Understanding – What we gain from a game is a holistic understanding of a set of rules and their ramifications, synergies, and connections.  This is not the same as what we gain from a toy, which is a list of rules.  Instead, this is an understanding of rule relationships, and how to manipulate the system to our benefit.  Obtaining new bits of understanding is of value to us, but once there’s no more understanding to gain, the game is dead.

HOW CAN WE USE THIS?  A game should have a very vast and deep set of rule relationships that we can explore for as long as possible.


Anyway, I hope this is helpful for people in understanding my work.  Let me know if anything doesn’t add up!

Minimalism Vs. Elegance

I’ve been called a “minimalist” before. Depending on the definition of the term you go by, I either am, or am not a minimalist. The reason that I don’t ever call myself a minimalist is because I think it has a connotation of “romanticizing the simple”, or some other kind of bias towards “simpleness”.

In actuality, my point of view is that things need to be as simple as they can be while still accomplishing their goals. This includes the possibility that they will actually end up being incredibly complex. There are some definitions/connotations of minimalism that this qualifies as, in which case, I’m not talking about that minimalism.

It’s also worth mentioning that when I refer to “simpleness”, I am of course only referring to inherent complexity, not emergent complexity. It’s a basic tenet of design that you want the largest possible ratio of emergent complexity to inherent complexity. So, if in one brush stroke, every idea in the universe could be expressed (a 1:infinity ratio), that would be theoretically optimal.

But that’s super-theoretical. In reality, sometimes we need great levels of inherent complexity to get our ideas across. I think that the rub I run into with people who are primarily digital gamers is simply a matter of what our standards are.


Standards: What Is Inherently Complex?

What we live with right now is the result of a 20+ year history of a technological and content-based arms race. Super Mario Bros. was a huge hit, so Super Mario Bros. 2 added more levels. Super Mario Bros 3. added more features. Super Mario World added even more features, and so on and so on forever.

With each generation of hardware, as the computing power/storage space increased, this had to be advertised proudly by the games. SNES games would brag about the filesize of the game, I recall. Backs of boxes, to this day, brag about stuff like “80 different levels, 200 spells, 30 hurricane kicks”, etc. At this point, it’s almost weird if a videogame doesn’t have a TON of content.

With technological spectacle front and center for so long, is it any surprise that we’d become a culture whose standards for “what is a lot of complexity” is a bit… warped?

In short, people classify me as a minimalist because their standards for complexity are based on a paradigm of mass content.


Games that are Too Simple

What people probably don’t realize is that I’ll happily reject a game that is too simple — it’s just that this rarely happens in digital games. It’s much less rare that it happens, however, in boardgames. Particularly, abstract 2-player boardgames.

For example, the boardgame Hive. It’s a hex-based 2-player game with no board, and little pieces themed with insects that try to surround the opponent’s Queen.

The boardgame Hive

The boardgame Hive

This game, in my view, is too simple. From what I’ve played of it, it seems too solvable, flat, and it also seems like the game becomes something like a “base-race” after only a few moves, with no way for the following player to catch up. There isn’t enough donkey space in Hive, it seems to me. There probably needs to be more complexity. (By the way:  I might be wrong about Hive; I’ve only played it a few times. The point is NOT about the game Hive, though, it’s about the fact that I will reject a game if I feel it’s too simple.)

Another example is a game that I helped Kickstart, which seemed pretty cool, called Rise! (these four-letter games, I tell you…). Rise is another abstract hex-based 2 player game. I have similar complaints with it, too. I just don’t think there’s enough complexity for there to be any really interesting emergence.




And while digital games tend to be way over-complicated, there are some recent attempts at what I might call “minimalist” games that I also am not crazy about.

Zaga-33, for instance. This is a “super-boiled down Rogue-like”. The screens are a very small grid (something like 12×12), and your only actions are attack and a few special spell-items you’ll find. It’s very, very tight – probably about as tight as it can possibly be. Again, I’m not really crazy about this game because there isn’t enough room for donkeyspace – for ambiguous, interesting, maybe-not-optimal-but-maybe-will-turn-out-to-be-a-kind-of-genius creative moves. I think Zaga-33 is actually too simple.





What I really want from games is, for whatever their goal is, they are elegant in achieving it. I think most videogames, due to the ease of adding complexity and more is more cultural demand for greater complexity, are almost always far too complex. So if you’re a videogame player primarily, I can see that you’d think that I was a minimalist.

On the other side of the coin, though, someone who only plays abstract 2-player games like those found at might think that I was some kind of foolish complexity glutton!

In reality, what I want is for games to be no more complex than they have to be to achieve what it is they’re trying to achieve, and what they’re trying to achieve should not be “super simplicity” (which I think might have been the goal in Zaga-33), and it should not be “super complexity” which I think is the goal in most videogames. 

I think that games can be judged by the interestingness of the decisions they present, and in order to create interesting decisions, you do need a certain level of inherent complexity. So, I think we should be seeking to find that level in the games we’re making.  It’s a very difficult thing to pinpoint, and varies from game to game. But let it be known that I am not a minimalist.


14 Points on Randomness

My last post, Game Placebo, got a lot of good feedback – more positive and constructive than usual, I’d say, which is nice. I also sent the article to DanC, who responded to me directly about it. He then wrote a G+ article about the topic of randomness, which led to a Lost Garden article. I feel happy to – at least partially – have been the inspiration for a Lost Garden article, being that that blog was my primary inspiration to begin writing about games almost a decade ago.

My position is that output randomness should not be a part of ideal game design. Right now I’ll try to break down my reasoning into discrete blocks that should help conversation about it.

Output randomness is randomness that affects a game after the player’s decision that decides the outcome. So, I decide to attack, and then there’s a dice roll to see if it worked or not. That’s output randomness. Input randomness, on the other hand, would be something like map generation or some face-up market cards that are available to all players. Although there can be improper implementations of input randomness that cause it to have similar problems as output randomness, input randomness is not what I’m talking about in this article.


The Points

I’ve put this in a list format.  Please read each point, and let me know which point does not work for you, and why (if any).


  • Point 1:  The act of coming to understand something is of value to human beings.  It is both enriching and entertaining to us, by our very nature.
  • Point 2: Games are valuable to human beings to the point that they allow us to understand them. If a game leads us smoothly to understand its lessons (accessibility / easy-to-learn), yet also has a very long, seemingly endless set of lessons to teach (depth / difficult-to-master), then that is a game that has great value to humans. Continue reading

Game Placebo

Homeopathy, for those who don’t know, is a form of alternative “medicine”.  It involves diluting an active medicinal ingredient into a solution so many times that there ends up being a mathematically near-zero chance of the solution containing even a single molecule of the active ingredient. Yet the United States spent 3.1 billion on homeopathic products in 2007, which can seem pretty strange to someone who understands what it really is.

Now, clearly homeopathy doesn’t “work” in the sense of having actual medicinal effects.  Homeopaths have tried to claim that it does by conjuring all sorts of bizarre theories, one of the most common being that “water has a memory” – it can “remember” the molecules that used to be in it, and somehow that memory has an effect. Whatever – pretty obviously nonsense but that’s not what concerns me here.

Delicious. It’s impossible for anyone to tell the difference between pure sugar pills and homeopathic drugs. That’s because they are the exact same thing.

What does interest me is the fact that homeopathy does work in the sense that people think it works. The placebo effect is very powerful (for some kinds of ailments, anyway), and having a “school of medicine” with practitioners all telling you that this sugar pill will stop your headache may alleviate the pain, since pain is understood to be a highly subjective sense that can be affected by the state of mind of a person.  The simple concept that “you’re being taken care of now, everything will be OK” may bring comfort to that person.  Here’s a really great Derren Brown video showing the great power of placebo. Continue reading

Instant Ambiguity Sauces

The practice of game design is one creating a functioning system that players can explore. I don’t mean explore as in “reveal areas of a map”, but explore as in push the frontiers of their understanding. Players explore a game through the action of decision-making. When you first start to play a game, you understand a certain amount, and that continues outward.

While you are learning (which is hopefully, forever – the best games aren’t solved in a lifetime), you are making decisions; decisions about things which you do not fully understand.  And actually, can you really even call something a decision if you do fully understand all the ins and outs of that system? If you already know the optimal move, there is no decision to make. You simply do the optimal thing.

Therefore, decisions – all decisions – really have to have some level of ambiguity (or uncertainty, if you prefer) to them. After a match is over, you can learn something about the system from those moves you made and start to form some rough guidelines for next time. This is what games are all about – it’s what makes them special from other forms of interactive systems.

However, not all ambiguity is equal.  There is ambiguity that is carefully crafted and a holistic, natural emergent quality of some systems… and there are some systems that really aren’t all that interesting on their own.  So we have quick-fix “sauces” that we can add to a system in a pinch.

The problem is, if you dump a can of sauce over a flavorless dish, you’re gonna taste nothing but sauce.


Instant Ambiguity

So let’s say we’re designing some kind of conquest game.  A big map, with lots of countries.  You and your opponent both have 10 little army men units, and we’re both trying to destroy the other forces.  Maybe you simply move your men into a zone to attack units in that zone, and maybe when you attack, you push the enemy forces back and they lose 1 troop.

It’s pretty clear to anyone following along with this example that we do not have enough for a functional game.  While it might seem as though we would, what we have now is easily solvable and will probably result in some kind of stalemate / draw.  So we need something.  Some kind of… sauce that will make this dry husk of a game go down smooth.

In videogames, that “something” has almost always been to place some totally unrelated obstacle between the player and agency itself.  Those things are always one or more of the following:  Execution, or Output Randomness, Labor, and/or Mass Content.  Afterwards, I’ll talk about the dangers of all of these.
Execution: In my above example, you could have a thing where players have to literally flick the bits with their finger into the opposing zones.  If they’re able to connect with an enemy piece and stay inside the territory, the enemy is killed.  If not, they are killed.  This is placing an execution requirement between you and agency.  That is to say, the decisions have become ambiguous because you simply don’t know if you’ll be able to do what it is you choose to do.

Since videogames are so heavily influenced by the need to always be fantasy simulators, and thus are generally terrified of being turn-based, putting execution requirements into them is very natural.  In fact, making a real time game – something about decisions, but that doesn’t have significant execution elements – is something difficult and must be really focused on on the part of the designer in order to work, otherwise execution can easily take over.


Output Randomness:  Output randomness is dice rolls, card draws, or random-number-generations that determine whether or not a player’s action succeeds or fails.  This is in contrast to input randomness, which is something like a randomly generated map or random spells that are available for all players or something.  This is generally expressed by “to-hit” mechanisms, “critical % chances”, as well as random item finds in something like Super Mario Kart.

This also comes very natural to videogame designers, being that Dungeons & Dragons – a fantasy simulator, through and through – was a huge inspiration for much of the roots of digital gaming.  A somewhat crappy, flat combat system can seem more interesting when there’s “to-hit” dice rolls (especially if you can increase them with lots of Labor!) and critical hits.


Labor:  Many – if not most single-player videogames of the past 15 years have been very, very heavy on forcing the player to perform hours upon hours of “busy-work”.  Grinding against hundreds of no-threat popcorn enemies, running down long corridors, fetch-quests, and collection schemes are just some of the ways that modern videogames stretch a system out, making it feel less like what they are:  an application where you press A to win.  Games with labor-sauce all over them need to have a great presentation and a massive hype train going, or else people will walk away.

In boardgames, the use of labor is less common (because it’s generally harder to hide), but there are examples of games where a lot of “fiddling” has to happen in between busy-work gameplay, to make it seem more like you’re doing something.  Breaking bills in Monopoly has always seemed like that to me.


Mass Content:  A lot of people are still under the impression that “a shit-ton of content” is something for a game to be proud of, not embarrassed by.  The idea that “more moving parts” is a good thing in a design or plan of any kind is a point of view that only exists in the world of videogame design.

But it’s not just these poor misguided “more is more” people who find a use in massive amounts of content.  Mass content, like the other sauces, can seem to make a totally dry, lifeless dish seem appealing.  Basically, it’s dependent on trying something for the first time – the element of “surprise”, if you will.  It helps even more if there’s a perpetual trickling of content into a system.  Magic: The Gathering was built with this in mind, as well as something like World of Warcraft.  One wonders how much play these systems would get with a small, tight amount of content.



What’s Wrong with A Little Sauce?

It’s not just that these things are completely expected to be in every new title released.  Worse than that is the fact that they’re almost seen by many in the videogame world as “the only way” to create ambiguity.  People don’t recognize the significance of utilizing these things.

For example, we were having a discussion recently here on my blog (in the comments), and I mentioned that if you were to make Starcraft turn-based, thus removing the execution element completely, you’d be left with a pretty boring, flat game (similar to, but not as bad as, my theoretical conquest game listed above).

A user by the name of Dasick wrote:

“But if you make SC turn based, it would loose a lot of SC flavour and tension. I think that to properly translate those elements into a turn-based board-game, you’d have to break out the dice.”

You’d have to, would you?  What he’s saying there is basically, if you don’t have execution, then you require output randomness.  In videogames, many believe that those are the only ways to create ambiguity.


The Dangers

“So what are the specific problems with these sauces?”, you might ask.  Well, I’ll tell you!

Execution:  execution has a way of swallowing up decision-making and creating needless barriers for players.  On one hand, in a game such as an RTS that involves both decision-making (what units to get, where to put them, when to expand) and execution (microing individual units, managing an economy, remembering to press the “build SCV” button every 30 seconds and I mean EVERY 30 seconds), the execution part can often take the lead.  I just wrote about this in my last article in detail.

But further, large execution requirements make it so that it’s much more difficult to get to a point of competence/understanding than it has to be.  One of the worst offenders are games like Street Fighter or Mortal Kombat, which intentionally make inputs difficult to do as a balance measure.  This is a ton of extra information and muscle memory that a player has to get down, just to take his normal actions!


Output Randomness:  I talked a lot about this issue in Episode 4 of the Game Design Theory Podcast.  Essentially, when you take an action in a game, and there is a dice roll to determine whether or not you’re successful, your agency is being reduced.  A system that has this is simply less efficient at giving you feedback for your agency.  When you win or lose an individual match, you can never be sure how much of a role you played, and how much of a role randomness played.

Further, it’s information that has nothing to do with the game itself.  Whether this die comes up 1 or 6 or anything in between has nothing to do with my skill, nothing to do with the game state and there’s nothing I can do to influence it.  It’s noise from outside the system and it can’t possibly be tied in well to the core mechanism of a game (which ideally, everything in a game should be tied into).


Labor:  I shouldn’t need to go on at length about this.  People don’t generally enjoy busy-work, no-brainers, etc.  It’s sort of the definition – the icon of boring.  Yes, you can achieve a sense of satisfaction for having done some busy-work – but you can achieve a sense of satisfaction for having done anything whether it’s interesting or not.  This is a blatant, callous waste of the player’s time and anyone who employs this in their game designs has my open contempt.


Mass Content:  Assuming both get the job done equally well, what’s better: a clock that has four moving parts or one that has 300 moving parts?  Elegance/efficiency is a pretty universally agreed upon “good quality” for things to have, and intentionally adding content to a system way beyond the point where it’s necessary flies in the face of that.  People need to start thinking of game designs as machines.  One faulty, out-of-balance or simply sub-par rule or bit of content can throw an otherwise working machine into disrepair.


The Solution Is Food, Not Sauce

Everyone must become vividly aware that this sauce-method is not the way that we should be operating.  You must never think that you’d ever “have” to break out the dice.  What you must not do is what most videogame developers (and some boardgame developers, mostly Americans) do, which is:

1.  Come up with a theme.

2.  Apply it to a generic gameplay model (FPS, 3rd person action, RTS) (for boardgames, usually Roll & Move or Area Control)

3.  Grease the wheels with one of the four above mentioned sauces

Instead, you need to make sure that your actual system, itself, is interesting.

Well shit, how do you do that?  That’s the hard part.  Game design is way, way harder than most people who have been operating under the sauce-method realize.  Like I said at the top of the article, it involves creating a system that can be understood, that is coherent, that can be learned, but is near-impossible to solve.  High levels of emergent complexity is the name of the game.  “Easy to learn, difficult to master” – this is a sign of elegance. 

As usual, there’s more to find in the world of boardgames than there is of videogames, but I’ll provide some examples from both.


Super Smash Bros. – Nintendo 64 revolutionary fighting game. Two major attack buttons, that are combined with the directions to make attacks in different directions.  There are a decent number of unique attacks, but they’re all intuitive and natural.  Everything in this game is tightly woven around the core mechanism of “positioning yourself and your opponent”.  Everything emerges out of that concept, cleanly and clearly (at least, with items OFF).


Go – 4,000 year old abstract strategy game. Has a 19×19 grid (somewhat large, but nothing compared to the grid in Starcraft or Civilization!), and black and white stones.  Incredibly simple rules that a, during play, expand out into one of the most complex game systems ever known to man. And it all comes out of a simple core mechanism: placing stones to capture territory.


Outwitters – An iOS wargame. Seven unit types, small grid (for videogames anyway), one resource type that’s used for both issuing commands and summoning units.  A fog of war system, which is hidden information, provides ambiguity, but it’s not random. Good players can learn to predict where their opponents will be.


All of the above systems start with a core mechanism and then tightly weave supporting mechanisms, balancing them together carefully to create a kick-ass curve of emergent complexity that is interesting, difficult, and ambiguous.  All without the use of any sauces.

Why aren’t these “sauce”?  Because they’re the meat & potatoes.  They are the game – the ambiguity and complexity and uncertainty all is coming directly from the system itself.  In go, the great emergent complexity of the board is where the ambiguity comes from.  In Outwitters, the hidden (although uncoverable) information of the fog of war does it.  In Smash Brothers, it’s the moment-to-moment prediction and reaction of a real-time decision that does it.  By the way – this is in contrast to raw execution, which is a matter of “can” rather than a matter of “should”.

This article isn’t a “how-to-design-games” article.  It’s more of a how not to design games article, but I just wanted to quickly give a nod to the way that games should be designed.  I can’t stand the idea that there’s anyone out there who’s still dumping crappy sauce all over a potential great game idea.

Related – I did a talk at NYU’s 2013 PRACTICE: Game Design in Detail conference where I detailed the matter of “sauces” versus “systems”. I also did a Q&A session afterwards. Watch it here: