TL;DR: A perhaps too brief look at games from the lens of player uncertainty – how uncertainty affects players and how we might categorize it different types. A design theory book on an advanced topic, but lacking some meat.

Quote from the Publisher: “In this concise and entertaining book, Costikyan, an award-winning game designer, argues that games require uncertainty to hold our interest, and that the struggle to master uncertainty is central to their appeal. Game designers, he suggests, can harness the idea of uncertainty to guide their work.” (Source)

Uncertainty in Games attempts to take a single topic – “uncertainty” – and explore its role and meaning in game design. Costikyan, the author, is a fairly acclaimed designer – his essay “I Have No Mouth and I Must Design” (PDF) is a key reading for anyone looking at the history and evolution of the field of game design. In addition, the book was published as part of the Playful Thinking series from MIT Press (like Art of Failure, another excellent book). All together Uncertainty in Games seemed to represent a text that’s both practical and theoretical, with a dense deep dive into a singular topic. However, I felt the book ultimately fell short of that promise.

The book is an analysis and catalogue of ways games create uncertainty in players, and why that is important to games. The end result is essentially giving designers a new lens (uncertainty) from which to look at and evaluate their games.

The introductory chapters (only a few pages each) simply devotes itself to defining uncertainty and wrestling with various definitions of “game” or “play”, having a kind of dialogue with some of the more famous philosophers like Callois) in this field. This is the most academic part of the book in terms of tone and content, but still easy enough to follow along as someone not entirely familiar with the source references. “Games thrive on uncertainty, whereas other interactive entities do their best to minimize it” (p. 15).

Chapter 4 starts really getting into the meat of the topic by doing an analysis of various types of games – digital and analog from very different genres – and looking at what role uncertainty plays in each. Chapter 5 follows up by taking this exploration of uncertainty and categorizing them into specific roles.

This reads strangely as though the chapters are in the wrong order – most authors would define and categorize the theory and then use examples to support it. The result is the same though.

Below are the different forms of uncertainty the Costikyan identifies:

performative uncertainty, such as in games of skill like Tetris

solvers uncertainty, as in uncertainty in the challenge of puzzle-solving. The author favors puzzle-games like Lemmings where the puzzles develop emergently from the game’s mechanics over authored/contextual puzzles like in point-n-click games.

unpredictability of opposing players, such as in Rock, Paper, Scissors or any given multiplayer game, or even in singleplayer games with robust enemy AI to simulate another player

uncertainty due to analytical complexity, such as Chess, or Dwarf Fortress, or any game where the sheer amount of systems and their interconnectivity is beyond the ability of a player to fully grasp

uncertainty due to randomness, such as in roguelikes or the roll of a die. One interesting callout here is that while a single throw of dice is extremely dependent on randomness, games that use many throws tends to temper that randomness with strategic choices, where the ultimate outcome of the game is largely relies on player skill

uncertainty due to hidden information, such as Poker where you do not know the other player’s cards. This kind of uncertainty tends to encourage exploration and testing of the system.

uncertainty of perception, such as in a Hidden Picture game, but also applied to games like Guitar Hero. There seems to be a heavy overlap between this type and performative uncertainty.

narrative anticipation, especially in games where players can upset the balance and allow an underdog to win at the last moment. This is as opposed to a game like Monopoly where you know the winner fairly early on and it takes a long time to actually resolve the game.

uncertainty of schedule, a fairly new type popularized by FarmVille, where the player cannot be entirely certain of their own schedule in returning to the game at important intervals

development anticipation, where players look forward to updates, patches, and post-release content

Uncertainty in Games fails to identify any kind of uncertainty we haven’t fully explored in games. Where do we go from here? What avenues have we yet to open up? With the exception of a nod at social games (the references to CityVille already unfortunately feeling outdated), there seem to be no new innovations in the way developers use uncertainty. The last chapter that covers games lacking uncertainty or the problem of excess uncertainty is too short to really dig into exception, contradictions, or problems arising from the gameplay element.

My writing marks up many of the pages with questions, often pointing out seeming contradictions or statements that didn’t seem quite supported by my own experience or the rest of the text. For example, the authors says that endless games like World of Warcraft have uncertainty not in the outcome, but in the path the player takes. And yet he follows along saying puzzles are not games because they have no uncertainty – if you know X then you can derive Y. But I don’t see why even a simple jigsaw puzzle can’t have uncertainty in the path in the player takes, in which piece they solve next, in how the final picture is assembled. In fact, Costikyan seems to contract himself when he covers “solvers uncertainty” (p. 25) in puzzles.

I am summarizing here, possibly unfairly, but this represents one of the many instances where I wanted to argue with the text and some of the grand statements made within it. I definitely had to resist the urge to nitpick the content in favor of focusing on the broader concepts.

I could not help but constantly compare the way Costikyan treats uncertainty to how Koster focuses on patterns in his book A Theory of Fun For Game Design. For Costikyan, uncertainty seems to be the key element in the design of a good game. For Koster, good game experiences come from experimenting with the game’s systems until they fully understand it (pattern matching), at which point the game because unfun. This period of play when the player is trying to understand the pattern – but doesn’t – is essential the period of uncertainty. These aren’t contradictory concepts but rather felt like two sides of the same coin.

However, Costikyan never really talks about a game once it’s been mastered, or the difference between the first time playing a game and repeated playthroughs of games intended to be played once. I think that’s due to a (my perception) focus on analog games for good examples of uncertainty, or games that rely on algorithmic complexity (Dwarf Fortress). A game like Uncharted also has uncertainty – especially narrative uncertainty – but after completing it, that uncertainty largely vanishes.

For a real deep dive into the topic, I’d expect the author to explore this situation and others that challenge or complicate the concept of uncertainty. Fairly or unfairly, I can’t help but compare this book to the other one I’ve read in the same series – Art of Failure by Jesper Juul. While I critiqued that one for being a bit meandering, it was extremely comprehensives, looking at the single topic from as many angle as possible. Ultimately that’s what’s missing from Uncertainty in Games and why it feels like it doesn’t go far enough.

The book itself is a quick read – 114 pages, plentiful references, and not bogged down in complicated terminology nor does it feel dry like a textbook. While I think the content does require at least some experience in game design (as a student studying the field or developer practicing in it), I found it very easy to follow along. I would recommend the book if the topic specifically interests you but don’t expect to come away with anything particularly ground-breaking.

Book: Morphology of the FolktaleAuthor: Vladimir Propp, Russian academic on folkloreYear: 1928 original, first print in English in 1958. My edition was from 2003.

Summary: This is not a book about games, but rather a systems-focused approach to dissecting folktales. Dense but delicious substance for deep systems designers who love narrative, but if that doesn’t describe you then do yourself a favor and skip this reading.

I picked up Morphology of the Folktale after seeing it mentioned in the book Quests by Jeff Howard as a very methodical approach to breaking down narratives into functional parts. I had a few fellow designers who are comfortable with more academic work recommend it to me as well.

The book is pretty short, just 117 pages plus a very useful reference table at the end. However, it’s translated from Russian, originally written in 1928, and was definitely written for an audience of fellow academics of folklore and literature. All those elements combine to create a fairly dense read with a rigorous, academic, dry, analytical tone. However, I found it easy to follow along and the academic references didn’t hinder comprehension (you don’t need to know the references in order to understand the topic).

Morphology of the Folktale is the author’s attempt to decompose fairy tales into their most basic components – a series of functions strung together in a particular predetermined order. While some tales may skip certain functions, the order (almost) always remains the same. A function for Propp is an event or verb – “an absence takes place” or “a warning is given”. Who gives that warning and who receives it doesn’t matter to Propp in this breakdown – the villain could be a dragon or a witch, the hero a peasant or a bird. It’s the action that determines the tale.

Each of these functions are given a specific annotation until a tale can be written like so:

A notation like β refers to a function – in this case it means an absence takes place. β² refers specifically to the death of parents, a variation on the absence that is common in tales, while β³ refers to the variant in which younger members of a family or household absent themselves (by going out). Each letter and number then has its own significance and allows us to read the ‘form’ of the tale without the details.

At the start of the book, Propp outlines why he feels the need to break fairy tales into components: all the current classification structures are inadequate, arbitrary, or overlap. They rely on themes or motifs but fail to define them thoroughly. The author claims we need to understand these tales at this abstract, formal, grammar level if we wish to start comparing tales across cultures. This should all sound familiar to game designers, as we wrestle with inconsistent terminology and difficulty classifying games by outdated genre definitions.

I really liked this book, but I liked it for its dry, formal analysis of literature that others may find lacking. Algorithmic approaches to storytelling and breaking down a tale into a specific formula fascinates me and horrifies many others. If you find yourself in the second camp I recommend skipping this book. If the mathematically annotation I quoted earlier doesn’t scare you off and you find the rest of the subject interesting, I highly recommend it. However, having a good understanding of the Hero’s Journey would be helpful as there’s a lot of crossover between the two books. For fun, I recommend checking out this PhD thesis that maps Propp’s morphology to the Harry Potter series.

I definitely think it’s worth reading if you are a systems designer with narrative tendencies, or interested in systems design and how that relates to story structure. If anything, it’s refreshing to see a highly formal structure emerge from an art (fairy tales) we’re all very familiar with.

Book: Quests: Design, Theory, and History in Games and NarrativesAuthor: Jeff Howard, academic and professor of game designYear: 2008

Summary: Not recommended, unless you’re looking specifically for a lesson plan centered around classic Western quest narratives. Even then I think the book is unfortunately outdated.

It’s not much of a secret that my favorite subject is the intersection between game design and narrative design, and back in the day I studied medieval literature, so I was definitely looking forward to reading Quests. On the surface it purports to be a text for game designers looking to add more meaning to their quest design, for academics to better understand how quests translate to games, and for students to practice design lessons. Unfortunately, I felt it failed at all three.

The book is printed large like a textbook, but only clocks in at 230 pages. The structure starts off with an introduction to the topic and several chapters covering the main elements that make up a quest: spaces, challenges, objects, and characters. Each chapter is further divided in half between theory – the underlying concepts from both game design and literary studies – and practice – which takes the form of very specific technical tutorials for implementing that portion of the quest in the Aurora engine from Neverwinter Nights.

Generally I think the book’s structure is solid and the division between theory and practice allowed me to skim the technical aspects, which I didn’t need, and focus on the theoretical ones. While the Aurora engine is old now and there’s better game development tools available to students for prototyping quests, I thought the lesson plan was fairly solid as a first game design project. However, it falls a bit short of challenging students to create meaningful quest content (it’s intended purpose) – instead I’d say it’s more of a technical introduction to building a quest with a checklist of game design elements.

From the theory half of the book, Quests‘s main thesis appears to be that quests are a structure in literature and an activity in games, and that we can learn from a cross-pollination of literary and game studies to make more meaningful quests in our games. The author backs this up fairly solidly with a dissection of the quest archetype in Gawain the Green Knight (among others) and comparing its structure to common quests in games such as Ultima and World of Warcraft. A quest involves goals, the collection of certain magical items, NPCs that represent quest givers, monsters or tasks that provide challenge, and a healthy dose of symbolism.

Unfortunately I felt the book was a failure. Its lessons on game design were very basic, more appropriate for a student audience than practicing designers. His explanations of quests in a literary sense did not provide much practical insight.

I believe the biggest flaw with Quests is that the book was untimely. A large portion of the introduction is devoted to defending against a ludology vs. narratology debate in academia, which in 2016 feels like beating a dead horse. The academic nature of the book leads to a lot of quotes and references to other academics, pitting their words against one another (particularly in the introduction) without much-needed context. I felt like much of the theory portions of Quests was spent arguing in defense of its thesis from a hypothetical reader than actually

(As an aside: the ludology versus narratology debate essentially boiled down to whether we can and should study games for their unique game-like properties (ludology) or use tools of analysis from other media, primarily film and literature (narratology).)

From a game design standpoint, there was really nothing new I could take away. The author’s definition of quests narrowed down the possible content to a focus on a handful of medieval fantasy role-playing games with western cultural traditions – like Ultima – excluding Japanese role-playing games with obvious quest narratives or games from other genres (Call of Duty is certainly structured like a quest). The author is also quick to dismiss Diablo and other action-oriented RPGs from this limited view, giving readers even less opportunity to apply any insights widely.

I can’t really recommend the book for anyone – not academics, game designers, nor students. I think the topic – quest design – is still really relevant to game designers, but probably needs to be written from a much more practical point of view, and one that incorporates the wider palette of games that involve quest narratives.

Last week Emily Short hosted a pseudo game jam called #BringOutYourDead to encourage developers to share unfinished and abandoned work, and talk about what happened. This gave me a great chance to look back at the games I’ve worked on and. with hindsight, ask myself what went wrong. It ended up being a really good design exercise.

Most of my abandoned work exists in the form of text – when I get an interesting idea, I explore it in writing with mini custom game design documents. I’ve decided to skip those (since there’s so many) and go straight to the games where I’ve done some form of development. Some of these only exist as images and not in any playable form.

This is a long post. Below is a list of the games (in order of completeness) if you want to skip around.

Book: The Design of Everyday ThingsAuthor: Don NormanYear: 1988. There’s a revised and expanded edition for 2013 that I recommend over the original if you have access to it, but this review is for the original text.

Summary: A must read for anyone who designs things – whether they are objects or games – for people to use. Very readable and no prior experience necessary.

It almost feels silly to review The Design of Everyday Things considering its reputation. I think most game developers that are somewhat serious about reading about their craft already have a copy. It’s certainly the one book that I find game designers recommend the most when asking about a book to read – despite not being about game design.

The Design of Everyday Things is a foundational text on usability and user centered design. It looks at everyday objects – telephones, doors, watches, radios, cars, teapots, remotes – and presents examples of good and poor design. The author delivers important lessons on how to design with users in mind to make their experience of using that object smooth by contrasting them with pages and pages of anecdotes of objects that frustrate and confuse its users. If you get nothing else from the book, you will at least gain a sense of horror about how poorly the world around us is designed.

If you’ve ever fumbled with a door, pushing when you should have pulled or vice versa, or pushing on the hinge instead of where the door swings, or pushing when you were supposed to slide it… then you will find the anecdotes in the book cathartic to read. And while the anecdotes are the easiest thing to recall, each are paired with concepts from usability: affordance, constraints, memory, feedback (a concept all gamedevs should be familiar with!), and so on.

There’s two sections of the book I want to call out as being particularly informative for me. The first is the stress on human error as an inevitable thing, as all humans will eventually error no matter how well a system is designed or how much experience they have with it. A designer’s role, then, should be to design controls to eliminate error as much as possible (for example, a water tap that you could never turn hot enough to scald yourself). When that’s not possible, you should design it so the error is reversible or limits damage as much as possible (for example, the recycling bin application on your computer, or autosave features). Of course, applying this to games, think about elements where it’s easy for players to make mistakes, like at an RPG vendor, and methods games have implemented to limit user error, such as the ability to buyback items you recently sold in WoW. Norman points out that in these situations just a confirmation prompt alone is not enough to prevent human error: if the error is still possible, you should design safeguards for that event.

The other section I found particularly enlightening focused on human memory. The author splits up memory between memory in the head (our minds), memory in the world (cues, post-its, event calendars, reminders, instructions), and memory associated with cultural standards (how to drive a car doesn’t change much between cars, so you only need to learn it once). There are flaws with relying on any given type of memory for users of your design, so the author advocates whenever possible to design so that those users do not need to use their memory – the design is intuitive as is. Recall switching between different games and trying to remember what controls go with what move. Luckily, there are standards that most games follow – left analog stick controls camera, right stick controls movement. But I’m sure most people remember playing a game where the controls seemed to break the rules and you had a lot of trouble not throwing a grenade at your feet (*cough* Call of Duty *cough*).

A lot of the content in this book crosses over into other books I’ve read regarding design. A whole section on how the brain works, with a focus on patterns, may remind you of Koster’s similar emphasis on patterns in A Theory of Fun for Game Design. I’d say a good portion of the principles in Universal Principles of Design are cribbed from this book – constraints, accessibility, chunking, affordance, and so on. Since this is such an important book, you’re likely familiar with some of its concepts already.

There’s two editions of the book out. I read the copy from 1988 and found it was fine, but if you were born in the 90s or later (and don’t remember what it was like to reprogram a VCR or use call-waiting system or a mechanical projector) I recommend picking up the newer one. It replaces a lot of the examples with more contemporary ones and I hear it’s still worth rereading if you’re only experience is with the original.

In case it’s not clear yet, I highly recommend the book for everyone. Its lessons are timeless, even if it’s examples aren’t. It’s written in an easy, approachable manner that makes it suitable for anyone interested in the topic, whether they are experts or hobbyists or students.