In it, he not only analyzes a variety games to determine their complexity class, but he also arrives at a few metatheorems that are generically applicable for all game design. In other words, “include these features and your game gains fun.”
When I said that narrative was not a game mechanic, but rather a form of feedback, I was getting at the core point that chunks of story are generally doled out as a reward for accomplishing a particular task. And games fundamentally, are about completing tasks — reaching for goals, be they self-imposed (as in all the forms of free-form play or paideia, as Caillois put it in Man, Play and Games) or authorially imposed (or ludus). They are about problem-solving in the sense that hey are about cognitively mastering models of varying complexity.
Some replies used the word “content” to describe the role that narrative plays. But I wouldn’t use the word content to describe varying feedback.
In other words, perverse as it may sound, I wouldn’t generally call chunks of story “game content.” But I would sometimes, and I’ll even offer up a game design here that does so.
From Twitter and the hilarious HULKGAMECRIT.
HULKGAMECRIT: @raphkoster @ibogost @larsiusprime HULK WONDER WHAT FFEDBACK WOULD LOOK LIKE IF HYBRID GAME DESIGN & WRITER WERE TAKE CONTROL OF NARRATIVE!
You have a system. Let’s say it’s a system where you can throw darts. And you have to open your bar in one week.
Throwing darts might have a bad interface. The dartboard might be too small or too big or poorly lit. Darts may be a perfectly nice idea, but the implementation of it needs tuning.
At this point, you have a feature, but not fun. It’s gonna take you four days to make it fun.
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.
