On Game Design and Other Things

Musing: Chris Taylor's Call to Action

2007-06-28T21:13:00.000-07:00

A lot of people have thoughts and ideas about game design. For example, there's Chris Taylor, famous for the RTS Supreme Commander (and it's spiritual previous game, Total Annihilation. Famous mainly for being an also-ran to StarCraft ;) ).

He wrote an article about games. The crux of his article is that games are two hard. Games punish players and they should not do so.

In essence, he's putting forth a notion of design: that games should avoid punishments. That a game is "better" if it does not punish the player, if the player is easily allowed to progress through the game and see more stuff.

The fundamental flaw with his notion is this: it's not objective. It's subjective. It doesn't work as a credible theory of design because of this. His argument isn't that games that use strong Risks in the Challenge dimension are broken; it is merely that some people won't play them.

So?

A proper Theory of Game Design is not intended to say what the most people will play. Ultimately that is a subjective notion, one that changes over time based on what the population wants. An objective Theory of Game Design's purpose is to aid a game designer in being able to tell if a game is functional, as well as describe how functional it is.

My section on pathologies does not detail subjective problems. Something is pathological if it is objectively broken. There is some subjectivity to it, as the Situation Model does model a degree of subjectivity in its representation of the player's attributes. The Situation Model only goes so far as to allow the game designer to assign a generic value to a player's attributes in an area. A kind of, "You must have this much reason to pass this section."

Given that, is it possible to have a game who's Risk dimension is too great? For a particular player, and generalized over a number of players of similar mindset, yes.

As an example, the Risk for being on one's last life in World 8-4 of Super Mario Bros is enormous. Fail, and it's back to the beginning for you, where at best, you'll have to trek through 7 levels before getting back. As children, this risk was somewhat acceptable; children tend to have more time and tenacity on their hands. Plus, children get games when their parents are good and ready to give them to them.

Even so, Risk can be mitigated by another factor: how much fun it is to play. Super Mario Bros. game mechanics are rather enjoyable. While the early levels do get boring after a while, even a seasoned expert gets a thrill from some of the World 8 levels. If a game is fun enough, Risk can be averted.

However, there is one problem. While Chris summarized his position as wanting less Risk (using different terms, of course), that's not what his article actually described. The description of why he doesn't complete games did not deal with Risk; instead, it dealt with Challenge as a whole.

He says,

For one reason and another, I was never able to complete them because at some point while playing, I would hit a "blocker." (A blocker is a term that game designers use to call a part of the game that stops the player's forward progression because of a complex puzzle, or arbitrary twist in the game.) When I hit a blocker, I give it a couple of tries, decide that this seems like a great place to take a break for the night, and lo and behold, the game begins to collect dust and I never play it again. That's the story for most games on my shelf.

That is not an aversion to Risk; that is an indictment of the entire domain of Challenge.

Do videogames need Challenge in order to be videogames? No. The definition of videogames, as I present it, does not explicitly or implicitly require Challenge. It only requires interactivity and the intent to provide enjoyment.

However, do games, whether in videogame form or otherwise, need Challenge? Absolutely; Challenge is at the core of games.

Look at the difference between Chess and Tic-Tac-Toe. Why is Chess played at high skill levels, while Tic-Tac-Toe is considered a child's game? Because Chess provides a much greater degree of Challenge. Chess played against a tough opponent requires a great deal of Knowledge, Reason, and Comprehension in order to be successful. By contrast, Tic-Tac-Toe against the smartest player of the game in the world will always result in a tie.

In terms of non-videogame games, Challenge is ultimately all there is. Enjoyment is gained from little else; the base interactivity of non-videogame games tends to be moving pieces around a board. Table-top RPGs and high-end miniatures games with grand backstories can buck this trend, but for the most part, non-videogame games derive their enjoyment entirely from the Challenge that their mechanics generate.

In terms of gaming videogames, Challenge is still a very strong aspect. The Situation Model demands it. Though it models interactivity, because most of the dimensions of Challenge are based on factors in the Situation Model, Challenge is an important component of gaming videogames.

After all, what good is gaining Knowledge if the game does not confront you with a Situation in which that Knowledge is required? What good is Experience if the game does not test it? And the only way to test such things is by creating a Situation with Challenge in the appropriate dimensions.

It's like rats in a maze, really. It was discovered that rats running through a maze actually learned how to get around simply by being there. When they started putting food in various locations, the rats were able to find the food much faster than rats who were new to the maze. But nothing indicated to the researchers that the rats learned the maze until they started placing goals in it.

Only when something is Challenged are you certain that it is really there.

However, unlike most non-videogame games, videogame games can create enjoyment from non-Challenging features. The act of interaction, for example, can be enjoyable, as can the videogame's setting or other non-game factors. Even so, much enjoyment can be had by having the player surmount a Challenge.

The difficult, of course, is Pacing. That is, providing the right Challenge at the right place at the right time. As mentioned, some people like sharper pacing curves than others. Despite the fact that Myst sold many units, very few of those buyers actually liked the game. It had a very sharp pacing curve, one that was too sharp for many.

So, what Chris is asking game developers to do is lower the pacing curve. This begs a question though: is there a right pacing curve for a game? A single correct solution for a specific videogame?

No. Ultimately, everyone likes their pacing in a certain way. Some players get bored with games that are too easy. Other players get frustrated with games that get too hard too fast.

What Chris ultimately wants is for game developers to cater to the low-pacing crowd. That's his call, but it need not affect your decisions as a game developer. Higher-paced games are still valid and viable games, from an objective standpoint.

On a personal level, I can't really bring myself to care for the low-pacing crowd. It simply isn't that interesting of a task to design games for them. Their enjoyment tends to stem from the base interaction or other facets of the videogame's construction than from anything involving the game rules themselves.

This musing went kind of wide of its initial purpose, but maybe it's an interesting read none-the-less.

The Digital Game Canon: StarCraft

2007-04-05T13:10:00.000-07:00

StarCraft

Perhaps the most definitive RTS game, ever. Consistently considered one of the best games of its genre ever. Played as a professional sport in Korea.

Obviously, Blizzard was doing something right with that one.

Basically, this game is a testament to how to balance a game with multiple distinct sides. Chess and Go are "automatically" balanced because each side has the same pieces and takes the same actions (though some suggest that the first player in Chess has an automatic advantage). StarCraft, by contrast, deals with 3 distinct sides.

The beauty, design-wise, of StarCraft isn't just that it managed the feat of almost perfectly balancing 3 sides. The beauty is that it did so in such disparate ways; that each side is so very distinct from the other and yet still is balanced.

On the small scale, take the first two units that each side gets, for example. One ranged and one melee. However, ranged units (according to the game's mechanics) have an automatic advantage over melee units. By the very nature of how they attack, lots of ranged units can all be attacking a single target, whereas far fewer melee units can gang up on a single target. Therefore, it was designed, on an implementation level, to make the early-game melee units more powerful per cost than ranged units.

Because each side is so distinct, however, they went about it in three different ways. The Protoss Dragoon is powerful, but hideously expensive. For the cost of a Dragoon, you can get anywhere from 2 to 5 melee units (except for Protoss melee units). And sheer numbers makes this a forgone conclusion. And while a Dragoon can kill a Zealot one-on-one, a Dragoon costs a lot more than the Zealot, and it will take more damage per-cost than the Zealot did.

Terran Marines are relatively cheap, and the first Terran unit, and yet two Marines will be mercilessly slaughtered by a single Protoss Zealot. A single Marine cannot hope to survive against a pair of Zerg Zerglings. And a Marine will fall to a Terran Firebat (not quite equivalent in cost, since they require gas to produce, but close enough).

Zerg Hydralisks are often considered the most cost-efficient unit in the game. Even so, a single Firebat will destroy them. And don't even consider sending them one-on-one up against a Zealot (not exactly the same cost, but close enough). And 3 Zerglings will likewise own them.

But look at how each individual melee unit achieves its dominance. The Zealot, despite having it's hugely powerful Psi Blades (16-damage per strike), doesn't win due to its damage output. It attacks far too slow for that. It wins because it can sustain massive quantities of damage. The Dragoon doesn't win in a cost-analysis because it doesn't shoot fast enough to kill the Zealot before it meets out substantial damage. A pair of Marines may not even penetrate the shields of a Zealot before it has its way with them. And a Hyralisk likewise can't kill it fast enough.

The Zergling wins through sheer numbers and awesome damage-over-time output. For the cost of a Dragoon, you can get 5 Zerglings, which deals 25 damage per blow. A Dragoon can kill a Zergling in 2 shots, but that's still plenty of time to get in 50-75 damage. And there's still 4 Zerglings left. A Marine costs 2 Zerglings, and Marines, despite their high rate of fire, can't kill two Zerglings before they exhaust the meager 40 Hp of the Marine. And a Hyralisk costs 3 Zerglings (or 4, depending on how you count gas costs), and they can deal damage much faster than the Hydralisk.

The Firebat wins through its brutal damage output. Though it has the same damage as a Zealot per-attack, its refire rate is far superior. It doesn't have the toughness of a Zealot, but it's not exactly weak either. One-on-one, it's a tossup as to whether a Hydralisk would win, but the costs aren't equal; a Hydra costs 33% more than a Firebat. Two on one, and it's no contest. The Dragoon's cost means that you can get fully two (2.5 by some reckonings) Firebats, and that's enough to tear down the Dragoon's defenses and kill it. And a Marine's damage output can't possibly cope with the Firebat's output.

Each unit is balanced in a way that suggests an overall strategy. They are all balanced, all following the implementation rule, "Melee beats Ranged," but each does it using entirely different mechanics.

And yet, the balance in this case isn't absolute.

Zerglings rely on numbers to be brutally effective. With a line of Dragoons, one long enough so that the Zerglings can't get around it, a problem arises. Only 3-4 Zerglings can attack a single Dragoon, but if the Dragoon line has more Dragoons behind it, then numerous Dragoons can fire at a single Zergling. Even if the costs are kept equal, 4 Dragoons in a line are better than the 20 Zerglings they would go up against. Thus, Zerglings lose their advantage.

Except, Zerglings can be upgraded. With appropriate armor upgrades, a Zergling can require 3 (unupgraded) Dragoon blasts to kill. At the very least, this requires that the Protoss player upgrade the Dragoon's attack to achieve parity again. But Zerglings also have an Adrenal Gland upgrade. This, coupled with their full attack power upgrade, can allow them to more than double their damage output. Thus, one fully-upgraded Zergling becomes two unupgraded Zerglings. To fully counter the attack power upgrade, the Protoss player must upgrade both shields and armor. And nothing can be done to counter the Adrenal Gland upgrade, so the greater rate of attack is still available to the Zergling.

In the end, Zerglings can be made less effective by a Protoss player's actions. But that player must then devote time and resources to this upgrade, thus forcing the Protoss player to slow down.

So, in the early game, melee units are better than ranged units. With time, upgrades, and numbers, however, this changes. And thus, a playthrough of the game changes from moment to moment.

Single-unit tactics eventually become meaningless, because they are easily countered. However, remove 10 of those Zerglings in the Dragoon example and replace them with 3 Hyralisks, and everything goes badly for the Protoss player.

On a large scale, one can see that each side is balanced by it staking out a particular set of player strategies/ideologies. As long as each side remains ideologically distinct, and each side can reasonably exploit a weakness of another's ideology, then the game can maintain a semblance of balance.

The Zerg ideology, for example, is on cheap units and fast expansions. One weakness of this is that these cheap units are not always monetarily efficient compared to others. The Terrans, due to their ability to quickly repair anything they make, can be more efficient in terms of resources. At the higher levels of play, it is said that for a Zerg player to beat a Terran, he has to stay an expansion ahead of the Terran player. The Protoss ideology of quickly moving powerful forces for a strike (the infamous Protoss drops) easily can counters Zerg expansion, simply by quickly eradicating expansions. This forces the Zerg player to substantially defend any expansion, which makes attacking more difficult.

The take-home lesson for StarCraft is about perfecting game balance in entirely unique ways. It's about developing a good set of mechanics that allows for deep gameplay, yet using implementation to maintain balance between different sides in unique ways that exemplify the ideology of each side.

Game Design: Knowing the Unknowable

2007-04-02T16:32:00.000-07:00

Earlier I considered the question of what game design was. This was partially in regard to the Situation Model, but it also branched out more into the relationship between what the player sees (the set of possible inputs for a given Situation) and what the game designer creates (a list of rules and so forth that determines what a given Situation is and how the player can act therein).

The secret of game design, the purpose of having a coherent theory of game design in the first place is to answer the following question: how does a particular set of rules create a specific set of Situations that the designer would feel that a player considers interesting and potentially entertaining? That is, a full theory of game design answers the vital question of Chess. How do these seemingly simple rules create such a degree of complexity, depth, and challenge?

However, we may not want to use game design to create "complexity, depth, and challenge." We may want to do something else. Game design can be used to create other emotional reactions (fear, suspense, etc) or to do things we haven't really thought of yet. So a greater, more general formulation of the question is this:

Given a specific goal for a game's design, how do you create the appropriate elements to achieve this goal?

One problem with this question: it may not be answerable.

That being said, the Situation Model is a good tool for answering this question. Using it as a model, a game designer can test bits of gameplay (whether as a thought experiment or as a live prototype) and attempt to experience the game using particular bits of Knowledge and/or Experience. As a design tool, its most useful purpose is making sure that the decision making portion of the game is without pathologies, difficult to the specific degree the designer wants, and has the specific pacing and advancement that the game designer wants.

The Situation Model is a priori knowledge. That is, it is derived entirely from logic based on premises. You could derive the Situation Model before there were videogames, or even before there were games.

As we come to understand the decision making process, we can also see how certain aspects of game design work to create Situations. For example, the primary difference between Chess and Tic-Tac-Toe with regard to decision making depth is that Chess is, thus far, not solved. That is, we do not know the single path that leads to complete victory (or guaranteed stalemate). Tic-Tac-Toe is solved; there is a single best answer which, if taken by both parties, is guaranteed to lead to a tie game.

One of the principle differences is that Chess has a wealth of decisions available to the player from the start. Tic-Tac-Toe, even in its opening move, only really has three (corner, center, side). So, as an ad-hoc rule, one could say that the number of decisions available increases the depth of the game.

Of course, looking at other games can show that this only holds when those decisions are actually important. If some decisions are clearly wrong, then there are fewer actually viable decisions.

This kind of information is an example of a posteriori knowledge. That is, it requires evidence from the world to understand. It requires a degree of experimentation, rather than purely bound to logic.

Until we find an a priori mechanism that can directly answer the fundamental question of game design, until we have a way to know the unknowable, we are going to have to develop rules based on a posteriori knowledge. We're going to have to look at specific instances and develop a theory of how game design becomes what the player plays.

Articles in the "Design Details" section will explore this kind of a posteriori knowledge in an attempt to deduce some kind of theory of game design.

The Digital Game Canon: Riven

2007-03-26T00:18:00.000-07:00

Riven: The Sequel to Myst

I know; worst name on Earth. The people at Cyan probably just wanted to call it Riven, but realized that it would be throwing away all the credibility that the name "Myst" had.

The reason for selecting it is that it shows exactly what an adventure game is. It has incredibly clever puzzles, that are so intricately woven into the world that they don't actually feel like puzzles. Except when they do of course, but even then, they're not puzzles so much as elaborate security systems devised by people for reasons that are very apparent.

The beauty of Riven is that it tells you all of this with very little "dialog". It never once breaks kayfabe. Your character never talks, is never seen by you. This isn't even like Half-Life, where you are a particular person (Gordon Freeman) and you can see yourself in mirrors. You can literally imagine yourself there, and just about nothing is ever done that breaks the illusion.

Another thing in Riven's favor is how it gives you information. This game will exercise your Comprehension like no other. You have to learn numbers in the D'ni language. There is one device in the world (suitably in a classroom) that teaches you numbers, but it doesn't teach you it by showing an arabic numeral followed by a D'ni numeral (that would break kayfabe). It teaches you in a more abstract way that requires a certain degree of comprehension for the player to pick up on it. Furthermore, it doesn't teach you everything about D'ni numbers either; you learn 90% of what you need to solve a puzzle, and are expected to deduce the rest. The deduction requires some guess-and-check, but the answer should be fairly obvious for those with enough comprehension, or for those who take enough time to look at the number symbols. It really is a well-crafted puzzle, especially for someone like myself who actually knows a lot about number theory (numbers in non-base-10, etc).

The entire game delivers information visually and auditorially. It also, in true Myst-game fashion, delivers information through a number of journals. However, in most cases, these journals are far enough into the game to where you have already picked up the subtle clues to much of this already in the world that you have seen so far. This is part of the game's genius.

Another piece of genius that should be noted in an academic setting is that the game revolves around solving 2 puzzles. These are world-spanning puzzles that require accumulating vast quantities of information to even find out about them, let alone solve them. The nature of these puzzles should be discussed at length,

Now, the game does have some downsides, despite its genius. The game has one puzzle that is patently unfair. It is a basic Negative Knowledge Pathology. One of the two world-puzzles is broken in that entering the solution to the puzzle is basically impossible. Imagine having a puzzle where the solution is a 5-digit code. Simple enough: find the 5 digits and enter them in the right order, and the door opens. Now imagine that the keypad that you enter them into is not a regular 10-digit keypad, but in fact has 20 keys, where many of the keys are repeats. So there may be 4 copys of the number 5, etc. Except that the 5-digit code does not give you a way to differentiate between number copies, yet it requires that you hit a certain number 5 or a certain number 4 to enter the code correctly. That's what the pathology in this game is; you can absolutely know the code, the digits and the order of entry, but you may not know how to enter them correctly. And the number of viable entries is so vast that sitting there and entering them all would be very boring and utterly destroy the illusion of the game.

The take-home object lesson for this game is puzzle design and worldcraft. And, of course, how easy it is to create a negative knowledge pathology just because someone on your art staff though it would be funny to have a number of symbols look very similar to one another (you'd understand if you knew the puzzle).

The Digital Game Canon, Prologue

2007-03-25T22:53:00.000-07:00

Recently, Professor Henry Lowood of Stanford University suggested developing a videogame canon. Such a construct is analogous to the concept of the academic Western canon, which specifies a list of literature, and potentially art and so forth, that are considered significantly influential in Western culture.

I would like to do something similar with videogames. I deride the specifics of Professor Lowood's canon, primarily because of the specifics of game inclusion. From an academic standpoint, "Space War!" gives a player little real information about game design. Academically, Space War! is just not a useful teaching aid. That is not to say that it is a terrible game. But it doesn't show clearly and distinctly a specific tool in a game designers arsenal.

And to me, that is what a canon should do. It should list games that are useful as teaching tools. It should list games that have a clear and convincing object lesson associated with it that shows how a game designer can solve certain problems. And it should be the best example of that solution, not merely the first, which most of those games were.

So, what would I include? You'll find out in this new, ongoing series of articles. Each choice will be explained in detail, covering what needs to be taught in an academic setting (since that's the purpose of the list).

Musing: On PC Games vs. Console Games

2007-03-21T20:44:00.000-07:00

In one of my very first posts, I spent some time dealing with the question of videogame genres. Mainly, I said they were useless tools for the purpose of proffering a theory of design. And they are.

But, in a more formal way, what is a genre?

Well, a genre is really a framework. It lays the foundation, providing a number of basic rules for game mechanics.

Board games, in the traditional gaming sense, are a genre. The concept of them is that each player has one or more pieces that represent an entity's location in the game world (the board). And, via some mechanism, players move pieces around or add more or whatever. The framework in this case is player ownership of pieces and that locations on the board have some meaning.

Go and Chess are both board games, yet they are worlds apart. Even their game mechanics are very distinct, yet they both use the same underlying foundation of pieces on a board where the position of these pieces have some meaning.

Contrast Chess and Go with, say, Magic: The Gathering. These have virtually nothing in common besides the fact that they're all games. The genre of M:tG is predicated on cards that create rules, having a hand with cards that are inactive until "played", drawing more cards from a deck, and having cards in a discard pile of some form. This is the trading card game's genre.

So, genre's provide a framework for build game mechanics. Some game mechanics don't work, and others do. What makes a functioning genre is a set of strong mechanics that can be used for multiple disparate kinds of games. Being able to have game experiences as distinct as Go is from Chess.

Super Mario Bros. and Sonic the Hedgehog are both platformers. And yet they are as different from one another as Chess is to Go. Yes, they both involve getting past an obstacle course populated by difficult terrain and simple AI creatures that serve as dangerous obstacles. But they both go about it in entirely different ways.

That being said, above all, there are basically only 2 true genres, which I will call metagenres. These are Mechanics Heavy and Implementation Heavy.

For neither metagenre is the "light" portion of game design unimportant. However, the emphasis, the linchpin upon which the game will or will not work is the one that is "heavy".

The "classic" example of a Mechanics Heavy game is, well, NeverWinter Nights. It is literally built out of game mechanics from something that isn't a videogame: the 3rd edition of the Dungeons&Dragons table-top RPG.

NWN is Mechanics Heavy. It relies upon its game mechanics to create fun. If the D20 system were not interesting, if it did not create interesting choices for the player, then the game itself would not work no matter what else BioWare did to it.

Using a videogame classified as an RPG as a counter-example, we have, well, any Final Fantasy game. This game is very focused on Implementation. How much experience the player gets at a particular time. Which monsters the player faces, assuming the player has X abilities at that time. What matters in a FF game, what determines how good its gameplay is, depends greatly on exactly how the battles are put together. Which monsters are encountered when.

These issues matter in NWN, but not to nearly as great an extent. Likewise, the combat system of a FF game matters, but never to the degree that it does in NWN, if for no other reason than the fact that the system permeates every aspect of the game. Options open up for you if you have certain skills, or items or whatever.

It's funny. For reasons I haven't quite figured out, PC games tend to be Mechanics Heavy, while console games tend to be Implementation Heavy.

Just think about the great PC games. For the most part, they're Mechanics Heavy. The Sims, StarCraft, StarControl 2, Rome: Total War, pretty much every PC RPG, Civilization. Indeed, PCs have entire genres that are Mechanics Heavy: RTSs, Civ-style games, RPGs, etc.

Noticably absent from this list: FPS games. While mechanics do matter, particularly for their multiplayer aspects, the quality of the single player experience is derived from the implementation more than the mechanics. Why are they focused on PCs then? Controls. That's it. With dual-analog becoming more acceptable, you're seeing these games take the leap onto consoles.

Which is where they belong. Right alongside action/adventures, platformers, 3rd-person shooters, and the other host of console gaming genres of note.

How did this happen?

Well, part of it is somewhat historical. Consoles have been limited in what mechanics they could provide. First by the basic hardware resources (CPU power and memory), and later by what could be expressed by their controls. This forced console developers to focus their energies where they could: implementations. Mechanics had to be fairly simple, so it was the implementation, level design and so forth, that had to take to the fore.

By contrast, PCs have memory and performance available to them. What they had preventing them from exploring implementation was not hardware.

Another part of it is cultural. The PC gaming market has been ruled by, well, geeks. People who absolutely love minutiae and obsess over it. They are intrigued by interesting mechanics, and they do not like being told by some implementation (level design or whatever) that they cannot try something. Broad mechanics with fairly light implementations cater to these people. Not to mention, the first PC games were made by geeks for geeks.

By contrast, console gaming has lived a different life. Since the demise of Atari, console gaming has been focused largely in Asia, Japan in particular. There is a cultural emphasis on what would be considered focused experiences without the minutiae of clever game mechanics. You can see it with their non-gaming entertainment like anime and manga (particularly in the willingness to break with established canon if it serves the story), and the culture spills over into their gameplay. The mechanics are seen as a means to an end; a way to create the possibility of compelling gameplay.

So, there it is: the fundamental difference in PC games and Console games. One favors game mechanics, while the other favors game implementation.

Game Design: What are we Designing?

2007-03-12T13:33:00.000-07:00

Note: This is (probably) the only article where I will actually distinguish the term "game" from "videogame". Every other place will use these as synonyms, except when we are actually discussing the game-like character. In those cases, I will use specific language to distinguish them. Unless the context suggests otherwise, you can assume that the term "game" means "videogame".

More and more, we hear about things called "non-games." Things like The Sims, Second Life, Brain Age, etc. There are basically two definitions of non-games: videogames for people who aren't traditional gamers and videogames that aren't games. So, let's discuss what it is we're talking about.

First, let's define the term videogame. A videogame is an piece of software or hardware whose primary designed purpose is to elicit some form of enjoyment or entertainment. This separates videogame software from, say, Word or Photoshop. Plenty of artists have fun with Photoshop, but it's primary designed purpose is to empower the user with regard to editing images.

Now the phrase "primary designed purpose" is key. Why? Because Mario Paint is a videogame while Photoshop isn't. And this is not simply because Mario Paint came out on a console and Photoshop didn't. Eletroplankton is a videogame, despite the fact that it could be considered a strange combination of Photoshop and a sound synthesizer.

The reason Mario Paint is a game is because its user interface for editing images is designed for the purpose of making it fun, not useful. You can do things of value in Mario Paint, but the main purpose is to fool around, stamp out some nifty animation with Mario characters, and so forth. Maybe if you really get into it, you might try something serious, but its tools are really too simplified for that.

Microsoft Paint also has simplified tools. The primary difference there is that Paint's simplification is not designed so much for entertainment, but for ease of implementation. For just about every one of Paint's features, there is an equivalent Windows graphics API call. In short, Paint is really a thin user interface over the Windows graphics API.

Photoshop is designed to give the user powerful features for editing an image. This is its primary purpose. Whatever enjoyment comes out of using Photoshop is provided by the user's enjoyment of creating art, not the designed intent of the Photoshop developers. They merely provide what is useful towards the end of creating images.

So, a videogame is merely an electronic "device", hardware as in the earliest days of arcades, or software as in modern times, that is designed for the purpose of being entertaining.

However, that doesn't deal with the Game vs. Non-Game distinction.

Personally, the distinction between the two comes down to the traditional definition of the term "game".

What is a game? Well, a game is a set of rules for interacting with something and a set of objective conditions that determine when the game ends and who won, if anyone. This definition covers everything from Chess to Tic-Tac-Toe to Super Mario Bros. So, what doesn't it cover?

The Sims, for starters. SimCity as well. Will Wright famously and rightly states that these are not games; they're toys. A toy is something that has a set of rules for interacting. You can bounce a ball off of objects, but you cannot turn it inside out (well, you can, but it is a different object now) That is, a game is a toy that has explicit victory conditions.

Brain Age is a game. It is a game because it has an explicit score, and you know when you've won, because it tells you. Old-school arcade games that measure success by score are games. Competitive FPS's are games.

Note that the definitions of "game" and "videogame" are not related at all. There were games before videogames, and there are videogames that are not games. I use the term "videogame" as opposed to something that doesn't use the root word "game" simply because it's more widely know. I could say, "Interactive Entertainment" or something of that nature, but it's difficult to know how that is different from table-top Chess.

So what is the difference between a game videogame and a non-game videogame? Gaming videogames are about one thing: winning. The Interactive Loop is used to improve the player's skills and provide appropriate challenge. Mechanisms of design create interesting Situations for the player to overcome. And the design gives the player a way to tell how well they're doing and whether they "win". But even victory is secondary to the enjoyment gained from the Situation-to-Situation momentum of playing the game.

Non-gaming videogames use the Interactive Loop for some other purpose. Simulation-type videogames use the loop for the purpose of modeling a simulation, whether based on real principles or not. What matters in those videogames is how interesting the simulation is and that the rules of the simulation create interesting situations. These too have a degree of Pacing, though in their case, it is not always based on challenge; it depends on what the player chooses to try to achieve with the simulation. The quality of a simulation videogame is judged based on how interesting the situations that it naturally creates are, and how these situations flow one into the next, much like for gaming videogames.

There is a great deal of potential for finding other uses for the Interactive Loop. For example, Electroplankton uses the loop, not specifically to create a simulation, but to create audiovisual patterns. There is no victory; it is simply about the player creating an interesting audiovisual effect. Mario Paint does something similar, though in a more traditional way. Some videogames have even tried to deliver narrative content through the Interactive Loop, though with limited success.

Note that these are not hard-and-fast categories. Simulation-type videogames can have substantial elements of gaming properties, and vice versa. We will deal with this later as we look more in-depth at game design.

As for videogames for non-traditional gamers, the distinction matters, but not from a design point of view. Granted, videogames of this type tend to have slower pacing models and generally less complexity in terms of challenge and/or fewer dimensions of challenge. Their purpose tends to be introductory in nature, which is a reasonable goal.

Game Design: First Look

2007-03-08T12:32:00.000-08:00

The Situation Model of a game is player-centric. It describes how the player is playing through the game. It breaks the player's view of a game down into discreet situations, and depicts how the player flows from one situation to another. It treats the game itself as a black-box process (though one that the player can learn about), one that takes inputs and maps them to results that the player can process.

This is a very useful tool in the game designer's arsenal. However, it is not enough, because the game designer does not produce bare situations. The game designer produces a game design, which generates those situations.

We defined the term "game design" before, back here when we modified the original formulation of the Situation Model. We said that the game design is "the set of rules, the game's initial Situation, and potentially state information (about what has happened before, etc) that defines the mechanism for generating the Game Input to Result mapping for a Situation." This was from the perspective of the Situation Model.

From the perspective of the designer, however, things change. Under the Situation Model, which is focused on a single player, the opponent(s) in a multiplayer game would also go under the classification of "game design". This is easily explained; many people find playing online multiplayer games to be onerous because of the quality of opponents (griefers, droppers, etc). The quality of a multiplayer game is judged in part by the people who play it. Non-online multiplayer games tend to be seen as better, simply because people do not tend to behave inappropriately as they would online.

So it makes sense from a single player's perspective to group opponents under game design. However, the designer cannot. A game designer must treat the individual players altogether as part of the external world that needs to be served by the game's design.

Therefore, we will redefine game design slightly, from the perspective of the game designer. Game Design is:

The set of rules, the game's initial Situation, and potentially state information (about what has happened before, etc) that defines the mechanism for generating the Game Input to Result mapping for a Situation for any and all players playing the game.

We will divide game design into 2 distinct sections: Game Mechanics, and Game Implementation.

The Game Mechanics are the set of rules governing the behavior of objects in the game. In chess, the mechanics are simply the rules of turn-based movement, capturing pieces, moving pieces, and victory/loss conditions. As a more complex example, the game mechanics of Super Mario Bros are the ability to run on the ground, jumping and gravity, the fact that the player can hit objects from below to release items, how enemies can move, that a super mushroom makes Mario Super which has a number of attributes associated with it, etc.

The Game Implementation refers to the initial condition, the starting situation, as well as the specific application of mechanics to the particulars of the game itself. In the case of chess, all this refers to is the initial condition of the board and who goes first. In the case of Super Mario Bros, on the other hand, this refers to the specific design of each level down to the last brick, the behavior of each kind of enemy, the placement of enemy spawn locations, the fact that the game is broken up into 8 worlds made of 4 levels each, etc.

Some games emphasize one facet over another, and the character of the game can be derived from this. For example, most competitive multiplayer games are very heavily driven by game mechanics. Level design, which falls under implementation, is crucial as well, but poor mechanics can mean that there this an imbalance in the play that no level design can fix. Take StarCraft for example. Almost 10 years old, and it is still played as a professional sport in South Korea. This is due to its incredibly robust game mechanics. Level design is entirely secondary to the effectiveness of this game. Chess and Go are also very focused on mechanics, with very thin layers of implementation. This includes videogames like The Sims and SimCity; you get starting conditions and then you proceed to do as the mechanics allow.

Other games focus more on implementation than mechanics. Adventure games, for example, are much more about level design and layout than the specifics of the mechanics. RPGs need robust mechanics, but it is the specific use of these mechanics that most determines whether the game works well or not.

It is sometimes difficult to know where the line is between implementation and mechanics. Taking Civilization as an example, the existence of the tech tree is clearly a mechanic. The fact that all players have the same tree is a mechanic, as is the fact that each tech has a specific research cost. But are the particular technologies themselves part of the mechanics or the implementation? There is an argument to be made for both.

The distinction, in the hard-line sense, is generally best used in service to the game designer. From an analysis perspective, where exactly the implementation ends and mechanics begin is not very important, though it can be useful when talking about the game. For the designer who must then build the game, it can be very important, particularly with regard to how the game is built, playtested, and adjusted.

Testing the mechanics first for mechanics-heavy games is vital. As such, designing these games can involve folding some of what might be considered implementation into those mechanics. Whereas for implementation-heavy games, mechanics testing is, while useful, not always the best way to spend time. At which point, playtesting should be focused on the implementation.

BTW, this is why genres are important to many commercial designers. Not only does it give gamers an idea of what the game will be like, it gives designers a set (or partial set) of mechanics that the designer does not have to playtest to see if they work. Furthermore, with genres, designers already know how to use those mechanics to achieve certain effects, so the implementation is simpler.

AI is, in all cases, part of the implementation, however. AI is never a game mechanic; what the AI can do may be. This does not mean that game AI must be treated like another player. Most single-player games treat enemy AI as obstacles. In the case of platformers, they can even be used by clever players to get to locations that would be otherwise inaccessible.

However, AI can be treated as separate players. This is usually true for bot-type AI in multiplayer games, where bots fill in for humans. In such games, the AI lives at the very top of the implementation, and most of the rest of the implementation does not consider the presence of AI bots as being anything particularly special.

This is all just a lead-in to looking at exactly what game design is and how it relates to creating the Interactive Loop.

Pacing, the Foundation of Gaming

2007-03-07T22:09:00.000-08:00

So, we have this construct called Advancement, which refers to how the player moves from situation to situation through the game, gathering Knowledge and Experience, even if this requires replaying sections of it frequently. And we have this concept called Challenge, which is an intrinsic property of a particular situation.

Now, let's use some math, as an analogy. We have C(s), which represents the challenge C for a particular situation 's'. Technically, the challenge is represented in the 9-dimensional space defined in the article, but we will ignore that for the moment. And we have S(t) which represents advancement through time. The function of advancement returns a situation. So, we can have C(S(t)), which represents the challenge for a player at a particular point in time.

So, what is dC(S(t))/dt? For those who don't know Calculus, this means the rate of change of the function C(S(t)), or how C(S(t)) changes with time. If you were to graph C(S(t)), the rate of change at any time 't' would be the slope of the function at that time, not the point.

What does this rate of change represent? Well, because I'm getting sick of writing "rate of change", I'll name it: Pace.

What does it matter, and why does the title call it "the Foundation of Gaming?" Well, because it is.

Challenge is constantly in flux. The more you go through a particular level, the easier it gets. This is due to the accumulation of Knowledge and Experience, as depicted by Advancement. Advancement makes the game easier. Challenge, therefore, should increase as the player plays the game. The absolute challenge of a particular late-game situation should be far greater than that of an early game situation.

Pacing is about how you get there. It answers the very relevant question, "How much did the Challenge change between two Situations?"

Why does this question matter? Well, because challenge is a big part of what makes a game interesting. A game that lacks challenge does not give the player a sense of satisfaction upon playing it.

Here's the deal. Pacing, how challenge changes from situation to situation, is what defines the character of the game design. A game where challenge increases dramatically with player advancement is very difficult. However, it may not be considered enjoyably difficult. A game where challenge increases very little is easy, but not necessarily enjoyable.

A well-paced game is one in which the player, through advancement, learns something and integrates it cleverly in such a way as to meet the next challenge and surpass it.

Pacing can be controlled and varied over the course of the game. Boss encounters, for example, are really just substantial jumps in pacing. Suddenly changing the pacing can be refreshing for the player, particularly if it is a surprise. A nice change of... pace.

Pacing also strongly correlates to complexity. As the player progresses through a game, challenge increases need to use the complexity dimensions of challenge. The use of multiple facets of the game design, more clever use of previous knowledge, etc are all important in increasing challenge. So pacing increases often correlate with increases to complexity.

Videogaming is not the only artistic medium that has pacing. The pacing of a movie, for example, is about how the audience's tension changes with the progression of the narrative. Action sequences and dramatic moments are sudden changes of tension, so they represent times of higher pace than slower sections.

Most narrative formats have a similar construct. Narrative tends to build towards a designed climax, and how fast it builds to it is its pacing. Pacing is integral to these kinds of artistic media, and videogaming is no different, even when it doesn't have a narrative structure.

A key difference between videogame pacing and traditional narrative pacing. Note that pacing involves the function S(t), which we defined as Advancement. Further remember that Advancement is entirely determined by the player, not the game designer. Videogames, being interactive, have a component that other narrative media do not; the player has a very direct effect on pacing.

While a book reader can start a book over again, or put it down, or skip around, there's nothing an author can do about that, and therefore he/she does not write the book with that in mind. With games, there is something that a designer can do. While a designer cannot directly create pacing like those other media, a designer can take efforts to keep the pacing correct.

For example, several modern games actually make the game a bit easier if the player is having trouble in a certain spot. A more interesting (and, to my mind, better) way to change the pacing would be Wing Commander style: if you lose missions, the next missions you go on are different, and generally a bit easier. This more designed method allows the player to still Advance correctly through the game, but it may simply take longer.

Imagine a game where, if you demonstrate the repeated inability to pass some challenge, the game simply dumps you into a tutorial that walks you step-by-step through similar challenges. It doesn't ultimately let you pass the original one, but it gives slower-learning players the opportunity to advance through a section that the player is not ready for.

A brief note: outside of Challenge, Pacing is the one term whose definition I already had before even starting this design theory. What I found interesting is that I did not design this model to explain pacing; it simply fell out as I saw how challenge changes with advancement. Which strongly suggests that the Situation Model, if not the right answer, is at least pointing in the right direction.

Musing: Idolatry

2007-01-12T11:56:00.000-08:00

This is a new series of articles. These will not be about the basic theory of design that this blog is attempting to develop. Rather, instead these articles will be looking at how design is practiced in the real world. Or, in this case, mispracticed.

Idolatry. This word is bound to theological religious constructs, but it has applications in modern game design when properly understood. In order to coopt it, we must first understand it in context.

According to Christian Theology, Idolatry is a sin. It's even one of the Ten Commandments. Why is that? What is so bad about Idolatry?

In order to understand this, we have to understand a distinction between true Idolatry and merely having an idol that represents a religious icon. After all, if religious objects were truly outlawed in Christianity, virtually no denomination thereof would be Godly.

Idolatry is more than merely kneeling before an image of a religious figure. Idolatry is a misunderstanding of the use of said image. Idolatry happens when you worship the idol because it is an idol, not because of what the idol represents. That is, you worship the idol as God, rather than as a representation of God.

If a idol of Christ, for example, is destroyed, the non-Idolater may be upset at the loss of property, but there is little religious significance associated with the destruction of the idol. For the non-Idolater, the idol was simply a tool to help achieve a greater understanding of his faith and his God. A new tool may be needed or not, depending on how he feels about his faith.

For the Idolater, it literally means the death of God. The breaking of the idol leaves the Idolater in a metaphysical quandary: God has been killed.

So, Idolatry isn't merely about worshiping before an idol; it means that, in the mind of the practitioner, the idol takes on the physical body of that religion. In short, the Idolater has forgotten the purpose of the idol, and indeed, the religion itself. The Idolater has uses the idol thoughtlessly.

The Idolater has committed the synecdoche. The Idolater is mistaking the idol, the part, for the whole of his faith.

So, what does this have to do with videogames and game design?

Idolatry abounds in modern game design.

A game design element (from small things like health bars to larger constructs like levels, etc) exists for a specific purpose. In bad games, elements do not reinforce one another. In good games they do.

Idolatry in terms of game design means that the designer is using a game element because it is there rather than because it is the right element to fulfill that specific purpose. More often than not, Idolatry is committed by designers because previous games in the genre have used that element, therefore this one must.

The problem with idolatry in game design isn't always that the element doesn't fit. More often than not, it is simple laziness.

There are any number of game design elements out there. Solutions to game design problems can be made in innumerable ways. However, we keep reusing the same ones simply because it is easier than coming up with new ones. So idolatry creates this sense that the player has played the game before. The modern sense that games aren't changing or improving is likely due to the constant idolatry of modern game design.

Player expectations also play a role in idolatry. Game designers, under huge pressure from publishers to produce selling games, simply choose to regurgitate game design rather than come up with something that players may consider new simply because the player might not like it.

Idolatry can be genre-dependent. Modern RPGs are laden with idolatry. In virtually every RPG, armor and weapon upgrades are common. Why? Because every other RPG does it. Yes, the element serves a purpose (in theory. In practice, most RPGs make upgrading brain-dead simple instead of providing meaningful choices), but if the developer were thoughtful, another element could be used to serve that purpose (see Wild Arms: Alter Code F as an example). Why the incidental combat? Because every other RPG has it, and therefore it is necessary.

One very important note. When attempting to avoid idolatry in game design, it is very important to not forget basic design principles. Idolatry is not merely using elements from another game, or not using standard elements (health bars, etc). Idolatry is thoughtlessly using them. To not use them simply because they are common is simply idolatry but coming from the other direction. That's the problem with Ico: it attempts to avoid game conventions, but it does so at the expense of playability; they forgot what those conventions represent and did not provide a way to similarly convey that information in other ways.

To avoid idolatry, simply be thoughtful in your decisions. If a common element can help you achieve what you wish to achieve, use it knowing that you made that determination thoughtfully.

Progress, Regression, and Advancement

2007-01-12T11:42:00.000-08:00

The Situation model is built on the notion that the game experience involves both the player and the game. The player, as represented by attributes, and the game, as represented by the available inputs and outputs.

As such, when using the Situation Model to define other aspects of design, it is important to keep both the player and the game involved.

In this article, we will begin to discuss multiple Situations. That is, how Situations flow from one to another.

The Result of a Situation often presents the user with a new Situation. Progress is what happens when a Result generates a new Situation that the player feels is moving further through the game. Specifically, the player gets the impression that the game is moving towards the player's own goals, whatever those might be. Regression is what happens when a player feels that the Result generated a Situation that is farther from the players goal.

In essence, Progress is the player's desire, while Regression is what the player wishes to avoid. Progress is positive, Regress is negative.

Advancement is a different concept. As the player plays the game, Knowledge and Experience are accumulated. Whether the player is Progressing or Regressing, these two attributes are always increasing. A player can learn from falling into a pit and dying. A player can learn from leaping over the pit and continuing on his way.

The specific sequence of Situations that a player plays through is that player's Advancement through the game. Advancement is always positive, in the sense that the player is always accumulating Knowledge and Experience.

Advancement is a far more useful design concept than either Progress or Regression. By studying how a player may advance through a particular game design, the designer is able to gleem some insights into what Knowledge or Experience a player may have deduced. On paper, the designer can map out a particular sequence of Advancement and determine if the player is reasonably able to handle a particular Situation at any point along that sequence. The question of, "How many lives would it take a player to get past obstacle X" is a question of Advancement, not Progress or Regress.

Complexity, Risk, and Challenge (WTP 3)

2006-09-26T16:10:00.000-07:00

One of the powers of the Situation Model is to be able to accurately defined the concept of Challenge.

Really, it's fairly simple. First, let us divide the Situation into Domains, each named for the three actions that the player is capable of taking. So there is the Reason domain, the Ability domain, and the Comprehension domain.

But, before we can deal with Challenge itself, we need to define two other terms.

Let Risk be the relative potential for the player's actions in the Situation to produce negative consequences towards achieving the player's goal.

There are two degrees of Risk. One degree is the quality of the negative consequences. IE: how badly does it hurt the player to fail? The other degree is the quantity of the negative consequences. IE: how likely is the player to fail? How much of the Mapping Table is dedicated to paths that lead to failure rather than success? Or, put another way, how many Game Inputs are there that lead to success rather than failure?

Let us define the first degree to be Risk:Pain. The second degree will be Risk:Extent.

Risk, in either degree, is a fundamental quantity of a Situation. It is not affected by the player's skill set or body of accumulated wisdom. As such, it is not enough to be able to define what a Challenging Situation is. After all, what is hard when you first begin to play is not nearly as hard at the end.

Since the player's Reason, Ability, and Comprehension are all fixed by the Situation Model, only Knowledge and Experience can explain the changing nature of Challenge. So, now we introduce Complexity.

A Situation's Complexity is a descrition, for each domain as defined above, of the body of Knowledge and/or Experience needed to feed into the player's attributes to successfully deal with the Situation at hand. The more Knowledge and/or Experience, the greater the Complexity.

Complexity exists in each of the three domains, and it should be looked at separately for each.

Complexity in terms of Reason means that it requires pulling in disperate Knowledge in order to device a correct plan that will create the desired Result. The greater the body of Knowledge required to find a viable solution, the more Complex the task of using that Knowledge becomes.

However, reason has the honor of being the only domain fed by both Knowledge and Experience. So it gets a second pass. Reason must also estimate the likelihood of being able to execute the Player Input into Game Input, and the player's Experience informs this. However, greater Experience serves to decrease this form of Reason-based Complexity. Greater Experience means that the player is capable of doing more, providing more complex input, and doing so more accurately. Thus making more complex input easier for the player to achieve.

This also requires a degree of Risk analysis. The player must use the Knowledge of the Risks (which may not be complete, of course) to determine if the player's Experience is enough to be able to hit one of the correct solutions. Risk:Pain makes one wary of confronting the Situation at all (if the player has a choice), while Risk:Extent puts a stress on evaluating one's Experience for confonting the Situation.

Reason-based Complexity, therefore, has two degrees: Complexity:Reason:Knowledge and Complexity:Reason:Experience.

Ability-based Complexity is fed only by Experience. The decision of what to do has been made, and now it must be effected and transformed into Game Input. This Complexity represents the quantity of Experience one needs in order to properly manipulate the user interface to turn Player Input into Game Input. Or, in simpler terms, it represents how skilled a person must be at using the UI in order to command a particular Game Input. Thus, giving rise to Complexity:Ability.

Comprehension-based Complexity is fed only by prior Knowledge. Complexity in Comprehension means that it requires a large quantity of accumulated Knowledge to properly Comprehend a particular Result. The phrase "properly Comprehend", is intensionally nebulous.

Particularly of the Player Input that was used to produce this Result. From that, the player can actually reduce later Complexity (which we will discuss more later), by being able to apply previous victories in new Situations. Rather than later having to use Reason to cobble together some attempted solution, the player need only take an already proven solution and modify it for a new Situation. This proven solution, of course, is represented as Knowledge and/or Experience.

Which gives us Complexity:Comprehension.

So, what is Challenge? Well, quite simply, Challenge is any and all of these. A Situation is said to have a degree of Challenge when any of the 6 aforementioned degrees is involved to any significant extent.

Challenge therefore has 6 pimary degrees that a designer can theoretically adjust. Each of those degrees can be adjusted in a myriad of ways.

Risk of all forms provides the player with negative Results. The player does not (presumably) want negative results, so the player attempts to avoid them.

A high degree of Risk:Pain means that the player has a strong wish to avoid failure. It means that the player is going to be in a mental state of stress on the possibility of failure. Planning to avoid the pain is therefore very crucial; this degree plays towards the player's Reason and Comprehension, as well as Knowledge and Experience.

A high degree of Risk:Extent means that there are many pitfalls. The player must take extra care to provide the correct Game Input to select the right Result. This degree plays towards the player's Ability and Experience.

Complexity, of all forms, confounds the player. It makes the player's task harder by placing greater demands on the players attributes.

Complexity:Reason:Knowledge means that the player must use a great deal of accumulated Knowledge be successful in this Situation. Devising strategies is one example of this.

Complexity:Reason:Experience is all about stressing the player's accumulated skill at manipulating the user interface. The player must plan for his/her shortcomings if there are degrees of Experience that he/she is missing. The player may choose to play it safe rather than attempting a plan with a greater degree of Risk:Pain or Risk:Extent.

Complexity:Ability requires that the player be able to substantially manipulate the user interface. The player must have a great deal of prior experience in performing the actions that the player is being required to perform.

Complexity:Comprehension requires that the player gather large quantites of Knowledge from other Situations in order to be able to understand what is being presented by the game.

There are also 3 extra degrees of Challenge. And they are pretty obvious when you think about it. For a given Situation, there is a base "quantity" of Reason, Ability, and Comprehension that is required to be able to confront the Situation and/or learn from it. The more the Situation requires from the player in these domains, the more difficult the Situation (or later Situations in the case of Comprehension, due to lack of Knowledge and/or Experience) is. We will call these degrees of Challenge Difficulty:Reason, Difficulty:Ability, and Difficulty:Comprehension.

So, in total, there are 9 degrees of Challenge, each with a virtually infinite number of ways of being expressed to the player.

We will discuss how Challenge changes over the course of multiple Situations in later articles.

Rethinking Game Design

2006-09-20T23:59:00.000-07:00

The original formulation of the Situation Model specified that the list of possible Game Inputs to Results for a Situation was the totality of the game's Design.

That's not the case. That listing is called something, but I want the term Game Design to mean something else. And here's why.

Chess is a game (and, when played on a computerized system, a videogame). Basically, Chess the game is just a list of rules. The rules state what the game board is, what the pieces are called and what they can do (not necessarily the look of the pieces), a few special-case rules (castling and en-passant), and what the victory conditions are.

Nowhere in that is any mention of Situation.

Actually, that's a lie: there's one thing I forgot to mention. The rules of Chess state what the initial arrangement of the board is. Or, in our terms, what the initial Situation is.

That's it. The rules of Chess give you a starting Situation and tell you how other Situations resolve from there. In short, the game rules of Chess define how to derive the Game Input and Results.

The Situation model is focused on what a particular player experiences when playing through a game. The player doesn't experience the rules so much as the situation and what can result from them. Now, with Chess, if you don't know the game rules, you can't be expected to perform well; the Knowledge of the game's mechanics is the minimum set of Knowledge needed to play. Then again, that Knowledge is, effectively, Player Input (as well as an understanding of what your opponent can do against you), which as previously stated was vital to the player having any real ability to play the game.

As a player plays through games of Chess, certain facts start becoming evident; Knowledge is gained that is not immediately obvious from the basic rules of Chess. For example, the Queen ought to be the most powerful piece, for she can capture in 8 directions at any range. But her value is only potential value in the beginning of the game. You can move a pawn out of the way such as to be able to deploy your Queen significantly, but then you used a move to do that. Your opponent may counter this.

A Queen stuck in a corner can be far less useful than a Bishop in a more viable region of the play field. In fact, most pieces lose significant power along the edges of the board; that hard barrier cuts off movement possibilities and hamstrings how a piece can move.

These kinds of "emergent Knowledge", where you start to understand something about the game that the rules create, are vital towards effectively being able to play the game. They are a form of Knowledge, and as such, are a part of the Situation Model.

So, in effect, we have a set of game rules that define how the game gets played, but the player doesn't really see that. Instead, the player simply has what the player believes are the possible inputs. The player's understanding of the game comes from being able to determine the emergent Knowledge that the game produces. What are good strategies, etc. Indeed, the player may even ferrit out the game rules themselves, if they are not obvious from the player inputs.

The game rules don't say explicitly that "Queens in corners are bad" or that "Pieces can be pinned in place by other attacking pieces" or that "You can potentially protect a piece from an attack by a valuable piece by moving a piece so that it threatens the square that your piece resides in, thus promising the opponent that he/she will lose that valuable piece". However, each of these is fundamentally built into the rules of the game; they exist because certain rules create these specific effects.

What happens if the Chess board were wrap-around lengthwise? All kinds of things change from that. What if Knights couldn't hop over other pieces? Other things change because of that. And so forth.

So, what is a game's Design? Simple: it is the set of rules, the game's initial Situation, and potentially state information (about what has happened before, etc) that defines the mechanism for generating the Game Input to Result mapping for a Situation. The Game Design fully defines how Situations move from one to another, thus the Game Design is what make the Interactive Loop. Game Design is what the game designer creates; the rest (particular Situations, etc) is built implicitly based on the Game Design.

If that's Game Design, then what is the set of Game Input to Result mapping in a Situation? Well, to be technically accurate, the best way to model it in the Situation Model is to have the Game Input pass through the Game Design and then a Result is output. However, I find it useful to consider this to be a potentially enumerable mapping table rather than some black-box process. Therefore, we will simply call it the Game Input to Result Mapping Table.

Knowledge Pathologies 1 (WTP 2)

2006-09-12T11:39:00.000-07:00

Given our current model of game design, we now have a way to express certain disfunctions in games.

By disfunction, or pathology, I mean a place where the player's natural progression from one Situation to another is interrupted in a way that is either not called for by the game's design or could be considered significantly annoying to a player.

Given the Situation Model, we have an understanding that Knowledge is a fundamental part of the Interactive Loop. Indeed, it is Knowledge (and Experience) that makes this loop actually function, where each iteration builds upon the last. As such, when a pathology arises with regard to Knowledge, it can break the Interactive Loop.

Though the Situation Model is focused far more on the player than the game design, we will look at these pathologies from the point of view of the game designer; what the designer intends and/or expects.

In this article, I will examine pathologies surrounding Knowledge generation.

In the Comprehension phase of the Interactive Loop, the game's Result is processed by Comprehension, informed by prior Knowledge, to generate new Knowledge. A pathology can result in this phase from one of the following ways.

Vital information, information necessary for the player's later progression, may not be available. That is, the game's design did not actually provide a Result to the player that any form of Comprehension and prior Knowledge could transform into the appropriate Knowledge. This is more than a mere pathology: this is a clearly broken game.

Now, a game exhibiting this pathology isn't always technically unprogressable. If the game is progressible, what must happen is that the Reason phase needs to find a way to generate this Knowledge by taking a bold exploration of the known Player Inputs. In essence, in order to proceed, the player must try everything until something works. And the Knowledge of how to proceed is generated by inference; when progression occurs, the player understands that this was the correct answer.

A game example of this kind of pathology would be when a player is presented with a standard 10-key number pad and a locked door. The door is otherwise impassable, and the player knows that it requires an 8-digit password to proceed. The key piece of Knowledge that is missing is the password itself. If the game does not provide any Result where this password appears, then this pathology results. The player can proceed by trying all possible codes until one works.

Let us call this pathology Unfairness. I use this term because the game is not playing fair with the player; it has failed to provide certain Knowledge that it later expects the player to possess.

This pathology is often confused with a second Knowledge pathology. This one occurs when the game provides a Result that is intended by the designer to produce certain Knowledge, but for the player fails to do so. This can happen in one of two ways. In one way, it happens because the player simply isn't good enough at Comprehension to be able to follow the game's logical consequence from Result to Knowledge. The other is that the player doesn't have a certain piece of Knowledge to inform their Comprehension process in order to follow the logical consequence from Result to Knowledge.

The latter form is one of two things. It is either an expression of a prior Knowledge pathology, or the player has simply not yet encountered the Situation that is intended to provide the player with the specific Knowledge. So we will ignore this one for now, and focus on a lack of Comprehension.

This form of pathology is simply that the game expects too much out of this particular player. Perhaps the player is unsuited to playing this game. It is important to note, however, that it is easy to confused this pathology with Unfairness; in order for this one to apply, there must be some logical consequence that leads from Result to Knowledge. Even then, one might suggest that it is Unfair to expect too much in the way of Comprehension from a player; however, I consider it perfectly reasonable to have a game require a high degree of Comprehension from a player.

In general, a lack of Comprehension isn't really a pathology with the game; it's a problem with the player. The player is simply not suited to this particular game. Given the number-pad example, it could be the case that the 8-digit password was scattered and hidden about the game world, and the player simply didn't have the Comprehension to pick up on it.

To the player, there is no difference between these two forms of Unfairness. A wise player might use a FAQ to determine how the Knowledge was supposed to be deduced, and then judge whether the game was Unfair or if the player simply didn't have sufficient Comprehension to put it together. But, more often than not, the player will simply put it down to the game itself being the problem and leave it at that.

All of the above pathologies are what I call Negative Knowledge pathologies. This means they fundamentally arise from the player not actually Knowing something. But there is another kind of Comprehension Knowledge pathology that is equally, if not more, important: False Knowledge.

That is, the game provides a Result, and the Knowledge produced from Comprehending this result is inaccurate to what the game design actually is. The player has gained some Knowledge, but that False Knowledge will impede or degrade the player's progress.

The reasons that False Knowledge is often worse than Negative Knowledge are legion. First, it is much easier for the game designer to accidentally tell the player the wrong thing than it is to tell the player nothing about something. Second, it is often more difficult for the player to unlearn something than it was to learn it in the first place, particularly if the False Knowledge was bound in some way to real Knowledge. Third, a lack of Knowledge generally breeds failure; False Knowledge can more often perpetuate the cycle, breeding new False Knowledge from later iterations of the Interactive Loop.

False Knowledge can be very sneaky, and it can be very easy to create False Knowledge by accident. For example, if you have a game where performing an action will lead to a reward, but only rarely. And additionally, there is no other indication that the action will succeed or fail on a particular location without trying it, and there are huge numbers of places to try in the game. This is a strong setup for False Knowledge generation.

There is a very good chance that the player will learn that taking that action is totally meaningless. The player might try it in a few places, but since it is rare, it will more than likely fail in all cases. Thus, the player will learn that this action never does anything. This False Knowledge would become pathological if said action was later required in order to progress.

False Knowledge, much like Negative Knowledge, happens either from poor Comprehension, a Result that more reasonably leads to the False Knowledge than the real Knowledge, or from prior Knowledge that helps lead to the False Knowledge.

This kind of pathology is called Deception; the game is actively Deceiving the player, whether intentionally or not.

Deception is particularly dangerous because of the ease at which it can happen. A game designer must take special care when designing a game, so that False Knowledge is not readily generated. And the more the developer focuses on creating difficulty in the Comprehension stage of Situations, the more likely it is that False Knowledge will be generated.

Despite the dangers of Deception, it can often be corrected fairly easily. Given the above example, the most reasonable way to correct this is to make sure that the player encounters those places where the action will result in a positive outcome early on in the game. Or to outright tell the player and point the player in the direction of such a place where the action will work.

Now, if part of the difficulty (and potentially enjoyment) in the game is to actually discover this Knowledge on one's own, then the game still has the responsibility of providing appropriate clues as to the viability of this action. The action should have some realistic backing, such that it would seem viable just from the player's understanding of the workings of the real world. There can also be certain subtle indicators that one might want to try using the ability in certain locations.

There are a myriad number of ways of suggesting the viability of the action; the key thing to remember is that there should be something that lets the player know that it will work. And the most effective way is for the player to experience it working him/her self. All the game needs to do is hint the player to a location where it will work.

Theory of Design

2006-09-11T23:28:00.000-07:00

My current Theory of Design stands as the Situation Model. A more in-depth discussion of it is available here: , where it was first introduced.

This model is useful for classifying how well a game works and, as it is further analysed, as a means towards evaluating design elements.

What's the Point? (WTP 1)

2006-09-11T23:27:00.000-07:00

So, I've created a fairly interesting model of a game (the Situation Model), one that can be applied to games on virtually any scale. It can be applied to virtually any kind of game, and probably some things you don't think of as games.

(Let's assume you buy all of that, as I haven't actually proven or even demonstrated it yet)

Yay for me. So I can apply them to games. Big deal, right?

Scientific models aren't useful in and of themselves. Their usefulness is when they can actually predict something of value (or of potential value. Or even just something).

As such, the key to how truly valuable this model is will be in what it can actually tell us about a game. Can it explain why one game works and another one doesn't? Can it actually tell us what effective games and non-effective games are?

To me, the most important thing to get out of any Theory of Design is a way to objectively assess a game's design. To be able to say where a game is functional or not just by an examination of its structure. And, because functionality is person-specific, such a theory needs to be able to at least potentially address what kind of people will find a design functional and what kind won't.

That's part of the reason I'm not going to (yet) attempt to justify the theory by showing how it applies to actual games. Instead, I'm going to examine the theory itself, explain certain pathologies and functionalities that it indicates are possible, and then show that there are games that exhibit these pathologies and/or functionalities. I will, in essence, examine the theory in a vacuum and then show that it does predict certain things about games.

Maybe after that, I'll see about showing how well it applies to games in general.

The Situation Model

2006-09-11T15:19:00.000-07:00

The Situation Model is defined via the following diagram:

The diagram describes a game Situation, as defined in the provided link. The topmost region, colored in light blue, represents the player's accumulated Wisdom. The second region, in light green, defines the player's Attributes. The third region represents the player's mental workspace; what the player intends to communicate to the game*. The fourth region represents the game itself: the rules by which the game maps the Input the player actually provides to the particular Result that it offers.

A Situtation is a looping construct, in essence. It starts with the player becoming aware of a Situation, likely from a prior iteration of the loop. Then, the player uses Reason coupled with Knowledge and Experience to formulate a plan. This plan takes the form of a series of Inputs to the game that the player intends to send: the Player Input.

The player then attempts to deliver this Player Input to the game. The player invokes Ability, which is informed by Experience. This generates the Input that the game sees, the Game Input.

The game's Mapping Table is the set of all possible Game Inputs and their mapping to a game output. This Table need not be fully deterministic; randomness or chaos may enter into the outcome. So, via some means, the Game Input is mapped to the Result.

The player then processes the Result using Comprehension informed by Knowledge to generate new Knowledge and Experience. Not every situation will generate Knowledge or Experience, nor is there any guarentee as to whether the player actually understood all of the Knowledge or Experience that the game expected to deliver with a particular Result.

As a side note that will be important later on, the player's body of Knowledge includes some knowledge of what inputs the game can take at this time. However, this Knowledge may be incomplete or inaccurate.

Let the set I_g be the set of all valid Game Inputs. Let the set I_k be the set of inputs that the player has Knowledge of. There is no formal relationship between I_g and I_k, though it is usually a good idea if the there is some overlap between the two sets.

* The information in this region may be expanded upon later as the model is improved.

Situation Model Terms

2006-09-11T14:53:00.000-07:00

Situation: This is the particular set of Game Input that the game allows and the Results that the game will provide for those Inputs at the current state of the game. It involves the player confronting a particular state of the game and deciding how to interact with that state so as to produce a Result that the player considers favorable.

Player Accumulated Wisdom

A player, when approaching a Situation, brings with him/her the following accumulated attributes:

Knwoledge: This represents the accumulated information that the player has about the game up until this point. This represents, among other things, the player's understanding of the current Situation, the player's understanding of what Input the player may provide to the game, and the player's knowledge of what happened previously. Knowledge may be obtained through the application of Comprehension (and previous Knowledge) to the Result of a prior Situation. It may also be obtained from extra-game sources (online FAQ, hints from a friend, etc).

Experience: This represents the accumulated ability of the player to manipulate the game's user interface. Experience may be acquired through the application of Comprehension and Knowledge to the Result of a prior Situation. Experience may be acquired through other extra-game sources (playing a similar game with a similar user interface, etc).

Fundamental Player Attributes

The player, in addition to accumulated wisdom, brings with him/her certain fundamental attributes of that player. These attributes do not change from Situation to Situation; they represent basic constructs of the particular person playing the game. As part of the Situation Model, these attributes fully define a specific person playing the game. They also do not change over time.

Reason: This attribute is used to process Knowledge and Experience to produce the Player Input that the player wishes to use in a particular Situation.

Ability: This attribute represents the player's skills at manual dexterity. This attribute is used, when coupled with the player's accumulated Experience, to transform Player Input into Game Input.

Comprehension: This attribute represents the player's skill at understanding what he/she is being presented with. It is used to generate new Knowledge and Experience, but previous Knowledge informs this process as well.

Player's Mind

These constructs take place entirely within the player's mind.

Player Input: This is the specific sequence of commands that the player would like to tell the game in order to meet the Situation and achieve a Result. Player Input is generated by applying the player's Reason to the player's body of Knowledge and Experience. Player Input is then entered into the game by applying the player's Ability to the player's body of Experience.

The Game

Game Input: This is the valid input that the game receives from the player. The player uses his/her Ability, informed by Experience, and the player's Player Input to generate this information. The game outputs a Result based on this input and the specifics of its game design.

Result: This is the output from the game's processing of the Game Input. It is based on the Game Input and the game's design. It can be transformed into the player's Knowledge and Experience when the player's Comprehension is applied to the Result, informed by the player's current Knowledge.

Mapping Table: For a specific situation, the Mapping Table is the set of all possible mappings from Game Input to Results in this Situation. These mappings may not be 1:1, and there can be random or chaotic elements in the Design, such that it makes it difficult for the player to predict whether a particular Game Input will produce a particular Result.

Situation-Focused Model

2006-09-09T16:10:00.000-07:00

Forget everything you've read in previous Game Design discussions on this Blog; this superceeds them all.

Situation

When a player is playing a game, the player will be confronted with a Situation. A Situation is a moment of the player's playthrough of a game that allows the player to take action, or to take inaction.

When the player approaches any particular Situation in a game, the player brings with him any Knowledge and Experience that the player has acquired, either from prior Situations in the game or from external sources (previous games, life experiences, an online FAQ, etc).

Knowledge represents all information acquired by the player up to this point. Experience, alternatively, represents the player's ability to manipulate the user-interface to carry out the player's wishes. A player can have acquired all kinds of Knowledge about a game from reading a FAQ, but this is separate and distinct from being able to correctly interface with the game.

Situations may be of any scope. Being confronted by a creature in a game may be a situation. Confronting a level in that same game is also a situation. Situations may have sub-situations within them. The primary distinguishing factor that makes something a Situation is that the player must make a choice that bears some significance. If the player makes a wrong choice, then the player may not acquire some item, may not see a particular path, or may be killed off. Or maybe the player's avatar is put in some kind of peril.

Basically, a Situation happens when there is something at stake. Or when the player believes that something may be at stake.

An important part of the body of the player's Knowledge is the Knowledge of what the Situation is. What the player is being confronted with. Note that this may be different from what the Situation is to the game. The player may not have recognized some facet of the Situation. The player may also be considering things which are not important to the Situation. This will be covered in a later section.

Input

For any given Situation, the game may accept some number of Inputs. These are the instructions that the player uses to act upon the game. An Input need not be a single fundamental control (pressing up on a game pad); it may be a sequence of commands (press up, then left; press down-to-forward and Punch; etc).

The player's Knowledge plays a key role with regard to Inputs. The game, for a given Situation, provies a certain set of Inputs that we will call I_all. However, the player only has Knowledge of a set of Inputs called I_k. There is no formal relationship between the two sets. Usually, the player knows some subset of I_all, and that would be a requirement for the player being able to effectively manipulate the game. However, the player may not know that certain Inputs exist, or the player may believe that there are other Inputs besides the ones that the game provides.

A player's Experience is also important. Givne I_k, there is a subset of this I_e that the player has sufficient Experience to be able to perform correctly.

Reason and Ability

When confronted with a Situation, the player must decide what Input to enter. The player applies their Reason to their Knowledge and Experience; the result is the Input that the player wants to perform. Knowledge informs this process, both in terms of what the player expects to result from that Input as well as a weighing of other known factors. Experience informs this process primarily by the player selecting either Inputs that the player can perform, or knowing that there will be some uncertainty in the outcome and potentially planning for it.

Reason is not a body of information; it is a fundamental attribute of the person playing the game. It is the mechanism by which the player uses Knowledge and Experience to make a decision about which Input to use. The game itself has little-to-no influence upon the player's Reason. For the purposes of this model, we will assume that the player's Reason does not change over time.

Once the player has decided what Input to provide the game, the player must now attempt to provide this Input. This is governed by what the Input is, the Experience of the player, the game's set I_all (which determines if the Input is valid in this Situation), and the player's Ability. These factors influence whether the correctly provides the Input and what the game will do with that Input.

Ability, like Reason, will be considered a fundamental part of the player's skill set. It will not change over time.

Game Input is the Input that is actually provided to the game. This may differ slightly or substantially from the input that the player intended to provide, based on the player's Ability and accumulated Experience.

Result and Game Design

The game will process the Input that was given to it and produce a Result. This Result takes many forms, depending on the game.

The game decides what Result to give for a given Input based on its own internal rules; we will call these rules the game's Design. The game may have its own internal storage, such that it retains information for later. As such, not everything that changes in the game's state from a given Input will be provided directly to the player as a Result. It may be provided later, once other Input is given. However, unless some Result, either from this Situation or from a later one, actually uses this internal storage, then it is completely invisible to the player and therefore unimportant.

We will only consider that which goes in and that which goes out; what happens in the mean time is important only to the extent that it affects a result.

Comprehension

The game's Result is the total output of the game. However, the player may not fully understand what this total output is, much as the player may not be fully aware of what the possible Inputs are and so forth.

When the game provides a Result, the player must then apply their Knowledge to their ability to Comprehend. This process results in the possible acquisition of Knowledge and/or Experience. Among the Knowledge that may be acquired is the Knowledge of being confronted with a new Situation. Because Comprehension was involved, this new Knowledge may be imperfect; the game's Result may have intended to communicate some information, but that information may not have been properly Comprehended.

Much like Reason and Ability, Comprehension does not change with time. It is a fundamental skill of a particular player.

Interactive Loop

The Interactive Loop is the sequence of progression from one Situation to the next, where the Knowledge and Experience provided by one or more previous situations is required to get past a later Situation.

The Breaking of DAR/RAI Theory

2006-09-08T19:06:00.000-07:00

It's only fair to point out that the last main game design article, where I put forth the DAR/RAI theory, was composed, for the most part, as I typed. That is, I started writing an article looking at how DAR interacted with the player, and I wasn't entirely sure where it was going before I started typing.

This is par for the course for this blog, seing as how that's how DAR came to be. To be honest, when I started writing on game design, I had intended to put forth an entirely different theory of design, one based on GNS theory and other ideals from table-top role-playing game design. I thought they were nice theories, and they (when appropriately modified) do have some applicability to videogame design.

But then I thought up DAR. And RAI came out of that. Now, I have a whole bunch of ideas swimming around in my head that no modified GNS theory could touch, ideas and analyses that are useful to explaining why some games work and some don't. In essence, my modified GNS theory would have explained gaming from a top-down approach, while DAR theory operates from the lowest level of game design and scales up.

Because I thought up DAR and RAI basically on the fly, I'm still revising them fairly substantially. Take DAR, for example.

At first, it was designed to model both what the game presents and what the player does. The player's decision, the player's action, and the game's response. As I started on RAI theory, however, I realized that this was all wrong. It's actually the game's decision, and the game's available action(s). The game presents one or more DARs to the player, and the player uses Reason to select among them. In a particular DAR, the player uses Ability to act and receive the response. And, as a correction to the last article, the player uses comprehension (thus turning RAI into RAC; it sounds better to me) to take that response and turn it into knowledge.

I'm still somewhat concerned by one, seemingly glaring, omission in the DARRAC theory: the fact that Ability and Action have no third component. Knowledge feeds Reason, which leads to a Decision. And Response feeds Comprehension, leading to Knowledge. But Ability stands alone, fed only by the decision and never changes from one iteration of the same DAR to the next. There is no knowledge analog that represents the possibility for the player to improve in this domain.

In fact, I've really glossed over Action in discussions about the DAR model. This mostly stems from the fact that I'm fairly uncertain of it and its future. By all rights, making a decision and acting upon it are two separate things. Forming a plan and executing it. However, I don't really deal with it much. The Interactive Loop is based on decision and response; there just happens to be this middle section where you have to act on a decision in order to get the response.

The main problem is that the simple DAR model doesn't allow for the action to fail. See, you don't decide to fall into a pit in SMB; that certainly wouldn't be anything involving Reason. But it happens. It happens because you made an error in your actions; you jumped at the wrong time and couldn't get over the gap.

Then again, that last line can be reframed into a decision, rather than an action. The problem is that you decided to jump at the wrong time. And the knowledge of that failure would, when properly Comprehended, results in the player improving over time.

When phrased like that, it sounds like you don't need action. Yet action is clearly a part of game design. Any number of games have failed totally because of poor user interface. Given the above, just because you know when to jump doesn't mean you can do it all the time. That makes it seem like there is something between Decision and Response.

Not only that, I've come to realize that the DAR/RAC model is wrong more fundamentally. Elements are the wrong way to look at a game; it should be looked at from the perspective of a player playing the game. And a player doesn't get a DAR, a player is confronted with many DARs from which the player uses Reason to choose.

In short, I'm revamping DARRAC theory somewhat. The new model will become known as the Situation model, and will be forthcoming.

Navigating This Blog

2006-09-08T18:38:00.000-07:00

The best way, particularly if you're new, to catch up on this blog is as follows.

First, take a look at the introduction article. It will explain the topic and goal of this blog.

From there, you should start reading the commentaries on game design theories. These articles are found under the "Game Design" Category. These articles are cronologically arranged, first at the top, last at the bottom. They give a snapshot of my thinking in terms of these theories. Regardless of what alterations/improvements/abandonments that happen to theories after these posts are made, these particular blog entires will not change to protect the innocent/guilty/idiotic.

If you want to see my current theories on game design, the "Nomenclature" and "Theory" sections are for you. They will not justify how these theories were arrived at (that's what "Game Design" is for); they exist to explain the coherant theories of design. There will be one page under that category (entitled "Theory of Design") that will never be removed (if you want to link to my current theories, that's the page to link to). Other pages in this category can be added, removed, drastically modified, or whatever, as needed.

The main theory page will also have it's own category (the only article under that category) entitled, "Current Theory". It will link to the appropriate theory pages that are current.

Reviews of games, for the purpose of justifying game design or just because I think they're interesting design-wise, will be filed under the "Reviews" Category.

The Player, the DAR Model, and the Interactive Loop

2006-09-05T11:39:00.000-07:00

We now have a way to define the interaction between the player and the game: The DAR Model. The next step is to begin codifying how the player interacts with the DAR elements.

Let us visualize the DAR model as follows:

Decisions lead to actions, which lead to the response.

When the player makes a decision, that decision happens because of some information. The player applies their own reason to various knowledge that they have in order to arrive at a particular decision. Thus, the combination of knowledge and the player's reason combine to create the decision, as shown here:

Given a specific decision, the player must now carry out that decision; they must take action. Action is informed by the decision of course, but it is also informed by the player's ability to effectively communicate that decision to the game. You can know all you can about how to pass though a Mario level, but that doesn't mean that you can do it:

Only the game's design informs a response. For now, let us assume that this is a black box: the player does something, and a response happens. It is now upon the player to interpret this response.

The important question, and the one that is vital to understanding the interactive loop, is this: what is gained by this interpretation for the player? Simply put: knowledge. It could be, depending on the element in question, something as simple as updating the position of the other entities in the world, or it could be some valuable insight on what happens when two entities interact in some way.

Knowledge is an important reward for a reason that you may have already guessed. But first, let's diagram this:

What we have is a feedback loop. Knowledge both fuels the system and is its output. Note that the response need not be only knowledge; some elements can provide other responses. But knowledge is what makes this feedback loop work. In essence, the player started this element knowing some things (potentially nothing), applied his reason to them, took action, and discovered something.

Let us define the Interactive Loop element as a game element that provides significant knowledge that will be of value to how the player reasons later on, possibly to the point of being vital to the player's later success. The idea is that the significant knowledge feeds into either this same element again (as when one is playing a game like Asteroids or Defender) or into a new element that the player may or may not have encountered previously.

Even so, it is very important to note something about the diagram. The three red boxes represent things beyond the game designer's control. A game designer can determine what decisions are possible (and not possible), what actions are available, and what the response to these will be. A designer cannot determine what the player's reason is, what the player's ability is, and what they interpret from that response. As such, the game designer can never be 100% assurred that the player has received the appropriate knowledge that a particular response is intended to evoke, because the player may have misinterpreted that knowledge.

So, what do we have now? We have the DAR model, which represents what the game defines. Now, we have the RAI model, which respresents how the player interacts and responds to the game. And we have a cross-connecting piece between them, which is the player's knowledge, which can be built up over time from prior game elements to inform the player's decisions.

We'll talk more about the RAI model in future issues.

Revised DAR Theory

2006-09-05T11:21:00.000-07:00

DAR Theory: Interactions between the player and the non-player portions of the game can be defined as the following. The player makes a decision. The player then takes action on that decision by communicating it to the game. The player then receives a response from the game.

This is the Decision-Action-Response (DAR) Theory.

Element: An Element is a discreet DAR section of a game that involves a significant decision by the player and/or provides a significant, specific response by the game, whether positive or negative.

Game elements are hierarchical; an entire game is an element composed of many sub-elements, each of which can have sub-elements. This hierarchy continues until the loss of significance of the three parts of DAR. Analysing an insignificant DAR element into a game is pointless.

Notes

After spending some more time thinking about my initially proposed DAR theory (Decision-Action-Reward), I decided to make some small modifications to it.

The principle change is that we define DAR as Decision-Action-Response, thus preserving the term "Reward" for positive responses, and semantically allowing for negative or neutral responses to decisions and actions.

Game Pathologies

2006-09-01T17:46:00.000-07:00

A Pathology is a disfunction within a game. A Pathology happens when the game designer intended one effect to happen, but something else did that significantly changes the progression of the game.

Note that a true Pathology is one that is fundamental to the game, built into the game design. As such, under the Situation Model, a Pathology only ever arises from things born of either the Game Input or the Results of some prior input.

A Faux Pathology is not a true Pathology. Because analysing a game's design is virtually impossible without considering some player's involvement, it is possible for a player to consider something a Pathology that isn't. For example, it might simply be a puzzle that the player lacks sufficient Reason to solve, but feels to that player like there is a critical piece of Knowledge missing. The line between a Faux Pathology and a real Pathology is somewhat blury.

A Critical Pathology is a Pathology that causes the game to no longer be functional at all. A non-critical Pathology may allow the game to still be interesting or fullfill its goal; a Cricial Pathology does not. Note that the game can still be progressable, but the intent of the game design is drastically damaged if not destroyed. Typically, this happens in one of the following ways:

The game does not allow the player to progress, thus frustrating the player and eventually forcing the player to stop playing.

The game forces the player to engage in unreasonable activity in order to progress. The player may continue playing, but the player will lose a significant quantity of enjoyment for the game.

The game becomes incredibly easy for the player, thus stripping out all challenge from the game.

The player is forced to use external aids (online FAQs, asking someone, etc) in order to progress.

A Knowledge Pathology is a Pathology in a game based on the Knowledge domain of the Situation Model. The game's design provides certain expectations about the player's Knowledge base, for later Situations will test those expectations. A Pathology develops if the player's body of Knowledge differs significantly from what the game expects the player to have at that particular Situation.

There are two forms of this Pathology. A Negative Knowledge Pathology is merely when the game has not provided the player with a certain piece of Knowledge. Because the player's Comprehension is also a factor, it can inspire a Faux Pathology whereby the player simply lacks the comprehension necessary to deduce the Knowledge. The true form of the Pathology is when the game does not provide any Result that has some form of logical consequence that leads from that Result to Knowledge.

A slightly alternate form of this Pathology is when the game provides a result, but it requires a Game Input that the player is not likely to provide. This is often due to a Knowledge Pathology that has already occurred, however, and is rarely encountered in the absense of other errors.

The second form of Knowledge Pathology is the False Knowledge Pathology. False Knowledge happens as a true Pathology when the game expects the player to reason one thing, but given what the player knows, some other thing that is actually untrue seems more reasonable based on that Result. The Faux Pathology analog of this is when one's Comprehension is simply erronous, or otherwise different from what the game expects, and the player's logical deduction came to the wrong conclusion.

Decision Making, Rewards, and Elements

2006-08-27T11:47:00.000-07:00

The maker of the game SimCity, Will Wright, once endevoured to define games as a sequence of interesting decisions. While I don't fully agree with this definition, as I find it rather limitting along certain design dimensions, it does raise an important point in game design: making decisions.

Videogames are interactive; that's what separates them from other game media. As such, it is a vital component of videogame design to study and understand the player-to-game interaction.

In essence, it's really simple: the player makes a decision, communicates it to the game, and the game produces some result.

Let us call the first stage, the player making a decision, what it is: Decision Making. The second state we will call “Action.” The final stage we will call “Rewards.” So we can respecify the above as the player making a decision, acting on that decision, and receiving a reward.

Where this becomes really useful will be in my next article on the different modes of thought that go into these decisions and rewards. However, until then, there are a few minor points on this matter that need discussion.

The decision-action-reward (DAR) dynamic is a vital component of game design. Enjoyment of a game can come from any of the parts, or a combination or all of them: enjoyment of making the decision, enjoyment of carrying it out, or enjoyment of the rewards granted by it.

For example, if you're playing a puzzle game (not a Tetris-style puzzler, but a static puzzle game), figuring out the solution is part of the decision making process. Acting on that decision is often very simplistic, requiring little to no skill in doing so. The rewards of actually solving that puzzle is merely getting to solve another one that is, perhaps, more difficult or more interesting, though sometimes you are rewarded by learning more about the game system that will be tested in later puzzles. Most of such a game's enjoyment comes from solving the puzzle.

By contrast, a Tetris-style puzzle game provides some depth and enjoyment from action as well as decision making. The rewards are to continue the game and a metric for determining your level of skill compared to others or prior iterations from yourself.

Game design is, in effect, about creating a pleasing decision-action-reward loop that is self-reinforcing. That is, the enjoyment derived from executing one iteration of the loop makes the player want to execute another iteration. There are many tools in a game designer's toolkit to create the links between separate DAR elements, but we'll get to those later.

Let us define another piece of terminology: element. An element is a discreet DAR section of a game that involves a significant decision by the player and provides a significant, specific reward by the game.

An entire game is a single element, but so are sub-sections of a game. In a 2D Mario platformer, a level is an element, but so is a particular piece of a level that involves significant player decision making, acting, and provides a reward.

Looking at sections of a game's content ^[1] below a level of significance is ultimately futile; unless a basic motion of the character carries a particular significance in one of these ways, it is just not important. In a platformer, navigating a flat section with no enemies in it is not a significant piece of content.

So elements can be composed of other elements in a hierarchical relationship. Several elements are combined to make up other elements, and those elements are combined further to make up others, until at the last, all the elements are contained by the element defining the actual game itself.

The purpose of game design is, therefore, to come up with a sequence of elements that will reinforce one another, so as to keep the player entertained and keep the player playing. This sequence can be encountered in any order, whether pre-defined, player-defined, or some combination thereof. Indeed, deciding on how the combination of elements goes together is a vital part of game design.

1: I've been avoiding the term “gameplay,” and with very specific reasons. I'm attempting to take a holistic look at videogame design, one that does not seek to separate game design from graphics or create other dimensions of effort. A well-made game can use graphics as a reward (it is interaction, after all), just as it can use non-vocal sound to communicate real information.

I believe that the predilection among some of the “elite” or intellectuals in game design who attempt to speak of separating gameplay from other facets of videogame design are incorrect. That this separation is preventing them from using facets of non-“gameplay” as viable rewards as well as information feedback in decision making.

Why Genreless?

2006-08-26T17:26:00.000-07:00

In my introduction, I said that I would be discussing a genreless theory of design. Why genreless? Why is genre so bad?

Genre is a fine thing. In fact, genre, more than anything, informs game design. Each genre carries with it certain specific game design ideals that define that genre, and members of a genre are free to implement game design within this specific context.

There are two problems with genre. From an analyst perspective, genre is useless information. If you're analysing a game design, the dictates of its genre must be part of that analysis in order for it to be considered complete.

The other problem is that genre is fundamentally limitting to game designer freedom. Let's look at arcade game design pre-Donkey Kong.

You had a number of genres. Shooters (Defender, Galaga, etc), Pong-a-likes, and a few others.

Then, some nutball came up with the idea of a platformer, Donkey Kong, a game that looks very different from anything else in the time period. Your main character is a human (cartoon-ish though it may be). It involves maneuvering the character through a hazardous environment, often with few abilities to actually kill anything. That was heresy in those days, for the most part.

When it comes right down to it, if your first idea with a game is based on known genres, you have less of a chance to make a game that is unique.

Now, it is not a bad thing at all to follow the beaten path. Not only is it less likely to turn people off from playing it, it is more likely to actually work, because you actually know how the genre works. Also, you can make a genre entry stand out from the crowd by adding new gameplay, where it meshes well with the genre. Or you can correct flaws in other entries in the genre.

From an economic perspective (and there is nothing I hate more when dealing with game design than dealing with how well the game might sell), one needs to understand an unpleasant reality about the genre lifecycle. There's an article* on Lost Garden on the subject that gives it a decent treatment.

Even so, the basic fact is that the most innovative games tend to be seen as those of completely new genres. And it's hard to dispute that: Donkey Kong, the great grandfather of platformers, was a watershed moment in the evolution of videogames.

If you're going to profer a valid theory of design, like good scientific theories, they should actually predict something. They can't just tell you what works now; they have to tell you what will work tomorrow, and why a game to be invented 100 years from now will work.

* I don't like this article's inference that the lifecycle of a genre ends at niche/death status. I don't think there's nearly enough evidence to say this, with only ~30 years of history for videogaming. Especially since most of that history has driven the adoption of new genres by technology; it's hard to go back and play, let alone make, older-tech games, particularly when you have to compete against more advanced games. I think there's great potential for "genre mining"; that is, going back to some of those older genres, giving them an appropriate coat of paint, and making games using modern game design ideals with them. I believe that a genre can be reinvigorated after an appropriate length of time has past, much like the modern movie epic genre was reinvigorated by Braveheart.

On Game Design: What This Blog's About

2006-08-26T13:52:00.000-07:00

Videogames* are the newest form of artistic expression. They, much like cinema, are the convergence of numerous other arts. A good movie has to deal in the art of acting, cinematography, music, sound design, art design, writing, etc. A good game can need all of these, but it also has its own unique facet: interaction.

The big problem is simple: videogames are young. Once, in the earliest days of cinema, they actually tried to make movies look like filmed theater. After all, that's all they knew. It took decades for them to slowly work out rules of cinematography. And even now, they're still creating new ideas (bullet-time, overused though it may be, is a new, useful technique of cinematography) to create new sensations in audiences.

Nowadays, we have schools that teach the results of these experiments. We have schools for acting, artists, music composition. We know how to do these things competently, and we have rules for what works and what doesn't**.

What we don't know is game design. We have no formalized concept of game design. We don't really understand why certain things in games work, and we have few tools or guidelines to use in crafting works of videogaming art.

The greats of this emerging artform are, by and large, intuitive in nature. They have some understanding of design, but more often than not, they create their best works by intuition. The so-called game design schools teach genres and what games do now; they do not teach pure game design in-depth. Imagine an art school that only taught how to free-hand draw.

The primary purpose of this blog is to deal with issues of game design and game development. I intend to help formulate a coherant, genreless theory of game design, for the expressed purpose of allowing game designers to do their job better.

I will, also, be reviewing a number of games that I have enjoyed. These reviews will not be like normal reviews; I don't review games to tell you whether you should purchase it. These will take an indepth look at the very foundation of that game's design, dissecting the games design and rendering a verdict as to how well the game does and does not work.

Lastly, I will be posting reviews and other concepts as they relate to game development. Reviews of Open Source (or closed-source) tools, where appropriate. I may also spend some time mouthing off about programming subjects (since that's my field of expertise) and so forth, but those will be few and far between.

*On this blog, whenever I speak of the term "videogame", what I am referring to is any and all computerized applications that are primarily designed for the purpose of entertainment. I will likely go into detail a bit later as to exactly what this means, but for now, assume I'm talking about any and all console, handheld, cell-phone, and PC games that you are aware of.

**I am aware that the truly exceptional works often break these hard-and-fast rules. However, the creators of those works understand the rules and usually know why they're breaking them. And when it is appropriate to do so. The rules serve the function of informing the user what to and not to do.