Uncertainty in Games by Greg Costikyan - a review

Greg Costikyan's name came up often in Jon Peterson's The Elusive Shift. He was a prominent figure in the zine scene that formed around Dungeons & Dragons and the fledgling tabletop role-playing game community in the 1970s. A typical contribution of his to the discourse back then was Lord of the Dice, a satire on the role of randomness and rules in TTRPGs.

I was, therefore, very excited when @laurenmakegames on Twitter posted some books she was giving away, and I spotted Costikyan's name on one of them, Uncertainty in Games. I hadn't heard of this book before, but considering the name and the topic, which is dear to my heart - see my discussion of the Monty Hall problem, or the post where I formulated constructive alienation - asking for it was a no-brainer. Lauren was kind enough to send it to me, and it did make for great reading.

The book mostly focuses on video and board games, which he called "closed systems" in his early theoretical work. When tabletop role-playing games are mentioned, it's just Dungeons & Dragons, and only as an early example of potentially limitless games, and as an inspiration for massively multiplayer online games, like World of Warcraft. However, I think the framework he provides can be useful for TTRPGs, although that will have to wait for a future post.

His main argument, some caveats aside, is that the goal of games in culture is to be a safe space for confronting uncertainty, in a world where we usually attempt to reduce it as much as possible. What draws us to continue playing games is the existence of this uncertainty, and our ability to get better at addressing it. Once we accept this framework, a big question in the analysis and design of games is where their uncertainty comes from.

He goes on to analyze several games through their uncertainty, among them Super Mario Bros., The Curse of Monkey Island, Rock/Paper/Scissors, Chess, Poker, CityVille, and Civilization V. Using these games, he comes up with a list of sources of uncertainty, of which every game he cites makes use of one or two, sometimes more. I will try and formulate each as a question:

1. Performative uncertainty - can you use the controller to have Mario make that jump?
2. Solver's uncertainty - have you gathered enough witty retorts to defeat the sword master?
3. Player unpredictability - will this player put up scissors next after having done paper twice?
4. Randomness - will my phalanx defeat the enemy's chariot?
5. Analytic complexity - what is a good way to respond to the Queens' Gambit opening?
6. Hidden information - what hand did the player on my left draw?
7. Narrative anticipation - what is going to happen in the Governor's mansion?
8. Development anticipation - what new features are going to come in the next update?
9. Schedule uncertainty - can I return to the game in time to harvest my crops?
10. Uncertainty of perception - can I notice the hammer coming at me quickly enough to react?
11. Semiotic contingency - what meaning will the game have when I conclude this segment?

I think some of these are a bit of a stretch. "Narrative anticipation" seems more like a study of what kind of prior information the player has before some hidden information about the rest of the game is revealed, or maybe the results of resolving uncertainty from other sources, in the context of furthering a story. I'm also not sure that performative and perception uncertainty are really significantly separate. Semiotic contingency, which Costikyan gets from work by Thomas Malaby, doesn't really feature in any of the prior long-form analyses presented in this book, perhaps because of how few examples there are of games that actually make use of it.

The book ends with an insightful piece of advice: one way of creating a new game, or improving an existing one, is by focus on its sources of uncertainty: tuning the ones you have, adding or removing some, until the mix works for the experience or audience you're aiming for.

But I would like to jump back to an even more insightful comment made before the bulk of the book: that you should be careful using lessons from interface design in game design, and vice versa. The problem is that there are opposing goals at play: with interfaces to word processors, web browsers, spreadsheets, and other products, you want users to be certain of what happens, not uncertain. This constrains how well you can "gamify" productivity. It also goes in the opposite direction, in constraining how usable game interfaces can be made, without affecting the very uncertainty that you expect would draw people into your game and retain their interest.

An example from my experience is the existence of automaps in dungeon crawlers. Last year I spent a few months streaming playthroughs of the first two Eye of the Beholder games, first person dungeon crawlers based on the ruleset of AD&D 2nd Edition. I started by attempting to do so without automapping, as they were originally designed to be played, before getting extremely frustrated at a certain confusing point. I then restarted my gameplay using All-Seeing Eye, an extension which provides a few quality of life and outright game-editing capabilities, including automapping, which is all I used.

This did, in fact, make things easier, and I was able to beat both games. However, several of the puzzles in these games, and indeed, in the genre generally, hinge on the player's need to map by themselves, and on the uncertainty that comes from only being able to see what's right around the party of characters when making any individual decision. They become trivial to someone who can simply look at what's going on in the map and where the party is at all times. In retrospect, I'm certain that I've missed out on a lot of the experience, although on the other hand, perhaps I would have just given up due to this uncertainty and the difficulty involved in overcoming it, and never gotten any exposure to much of the content.

In total, I would recommend having a look at this short monograph, as uncertainty is a very interesting lens through which to analyze games. It's definitely staying on my shelf.

Character death in games

Yesterday, it finally happened. Having indulged in some constructive alienation to set up a framework for a dungeon combat challenge for the player characters, and furthermore, committing to a certain attitude by the enemies, I ran the game as it rolled, and one of the PCs died. Even in Dungeons & Dragons 5th Edition, it's possible to die in battle, and it happened. And it was a good death, for several reasons: it was a heroic and somewhat foolhardy press forward to engage the enemy without really waiting for backup, which fit well with the character; this somehow worked in previous iterations, but his luck ran out. The player also will have to take a break from gaming for a few months, so the out-of-game timing was good, as well. But still, it's sad for me when a character dies, and especially when that is connected to the player leaving the game, even if it's amicable.

I am reminded of a round of Betrayal at the House on the Hill I played at Who's Yer Con 2019. The game starts out with all the players cooperatively exploring a haunted house, which is generated using random tiles. Things go wrong, until one of the players moves beyond a point threshold, and becomes the betrayer. The game is paused while this player consults an entry in a book expressing the haunting, while the other players consult a corresponding explanation in the other book of how to defeat it. Play resumes, and it is now adversarial, until either the haunted player is defeated, or the other players are all killed or coopted, or whatever other end condition is achieved. In this particular instance of the game, I was the haunted one. And I slowly had to take out the other players. This was the last game of the night, so as I was taking people's characters out, they left to their hotel rooms, or to drive off. And it was really unpleasant for me to succeed at each juncture, and then to win the game. I felt like I was kicking people out of the game, rather than just challenging them inside its rules.

In a single-player video game, the situation is often very different. If you run into a challenge, and your character dies, you can just reload and try again. Even without saves or continues, even if you have to restart the game every time, you're ultimately able to confront the same challenge - or type of challenge, if it's procedurally generated - over and over again, until you tire of it, or until you overcome it. Death is a signal to you that you have failed, and an invitation to try again. In games made for the arcades, it is also a way to push you to spend more money. But I think games have moved more and more towards focusing on the specific challenge at hand. Instead of having to start games over, there are saves, or checkpoints; some games automatically restart you at the beginning of the latest challenge, allowing you to retry it over and over. Some games will adjust the difficulty of the challenge down, so that you are not stuck in one area due to missing out on a particular skill or capability. And of course, there are many games where death isn't really a possibility; it's just a matter of which of a variety of endings you get to when the game ends. I personally find a lot of the older games a bit frustrating these days, although certain retro and retro-style indie games have captured my interest.

So my experience with death in games leans towards the negative. I don't like getting characters killed, as a role-player, as a gamemaster, or as a board game player, and I find video game deaths frustrating when they require me to redo a lot of progress. But when thinking about gamemastering, game design, and theory, I'm trying to avoid just focusing on what I like. So let's discuss some parameters for lethality in role-playing games.

Many old school games were very lethal, or could be made to be. Original D&D did not provide characters with many hit points, or quick ways of replenishing them, monsters were deadly, as were traps and poisons, some of which would kill immediately. It was also very easy to build a new character - I recently played an OD&D game, and even with checking up on whatever houserules were in place, it took me about half an hour the first time, and would probably not take me more than ten minutes if I wanted to do so again with the same table. Another important aspect of early versions of D&D is that it expected adventures which did not really dig into character backgrounds and motivations. You crawled a dungeon with other players to look for treasure. The constant threat of death motivated you to be careful as you crawled, although combat did often happen, as did falling into pits. If your character survived, it might develop a larger narrative, especially if it ended up taking its funds to settle outside, but it could easily perish, and you would write up a short memorial and start again from scratch.

As I noted above, meanwhile, D&D 5E makes it very hard to die, or rather, makes it very easy for a PC to survive brushes with death. Your character gets to revive some of your hit points with an hour's rest, or all of your hit points on a night's rest. Once taken to zero hit points, a character needs to roll 10 or lower three times with a d20 (or two if one of the rolls was a 1) before rolling three 11s or above to die permanently. Moreover, a critical success (a 20) has the character at 1 hit point and ready to get back into the fray - or flee, likely the more prudent option, albeit made difficult by the system's punishing combat movement system. Correspondingly, character creation is a much more arduous task than in the original edition. It is usually recommended that the party and the DM take up the equivalent of a whole session to build characters together, to make sure that they mesh well and that their backgrounds can be tied into the plot properly. The adventures are expected to be long-term affairs, with meaningful participation of the characters at each step, so a character's death can really mess with the process. But other things can happen when you play: allies and enemies can win or fail, you can alienate former allies, befriend former enemies. Your character's choices can have a lot to do with how that changes.

I think this leads to a bigger discussion of what stakes you are playing for. The stakes can be the life of your character. But if the character is easy to generate and is expected to be easily killed, what are you losing when it dies? The string of successes you've had with it against a hostile world? Definitely not time out of the game. Meanwhile, if a character is difficult to create and adapt to the world at hand, you're not only losing all that starting investment, you are also probably losing a significant amount of participation with the game as you are taken out of it to restart this process. And if the game involved a lot of social relations with other parties to the game, both player and non-player characters, then all of that is lost, too. Meanwhile, you can lose some of these connections due to poor judgment or failures without killing the character. So your experience of the game with the other participants continues, even though you have suffered setbacks, setbacks that can be significant for you, if you have become invested in the world and the people in it. It can be a meaningful experience even if it is not lethal for your character individually.

That being said, if there is combat in the game, there is no greater proof of how important it is to do it well than the death of a party member, with all that entails. If there is a dungeon, death by trap is the best way to show that it is vital to tread carefully. If there is a despotic society you must navigate in, there is no better proof that you have to watch your actions very carefully than a summary execution.

And on that positive note, rest in peace, 2020.