The Digital Game Canon: Riven

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

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

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?

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

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

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.