16 Formal Abstract Design Tools

In the Gamasutra article Formal Abstract Design Tools, Doug Church advocates for the creation of a set of design tools for making games. First, he mentions three aspects of games that are worth putting in our design toolbox:

• Player intention is defined as the ability of the player to devise and carry out their own plans and goals. We will come back to this later on in this text, but for now just realize that it can be important in many games to allow the player to form a plan of action.
• Perceivable consequence is defined in the reading as a clear reaction of the game to the player’s actions. Clarity is important here: if the game reacts but you don’t know how the game state has changed, then you may have difficulty linking your actions to the consequences of those actions. “Perceivable consequence” is known by a more common name: feedback.
• Story is the narrative thread of the game. Note that a game can contain two different types of story: the “embedded” story (created by the designer) and the “emergent” story (created by players). Emergent story happens, for example, when you tell your friends about a recent game you played and what happened to you during the play: “I had taken over all of Africa, but I just couldn’t keep the Blue player out of Zaire.” Embedded story is what we normally think of as the “narrative” of the game: “You are playing a brave knight venturing into the castle of an evil wizard.” Church’s point is that embedded story competes with intention and consequence — that is, the more the game is “on rails”, the less the player can affect the outcome. This statement is a clearer articulation of what Costikyan meant in “I Have No Words” when he said that games are not stories.

Here is an example of why player intention and perceivable consequence are important. Consider this situation: you are playing a first-person shooter game. You walk up to a wall that has a switch on it. You flip the switch. Nothing happens. Well, actually something did happen, but the game gives you no indication of what happened. Maybe a door somewhere else in the level opened. Maybe you just unleashed a bunch of monsters into the area, and you’ll run into them as soon as you exit the current room. Maybe there are a series of switches, and they all have to be in exactly the right pattern of on and off (or they have to be triggered in the right order) in order to open up the path to the level exit. But you have no way of knowing, and so you feel frustrated that you must now do a thorough search of everywhere you’ve already been… just to see if the switch did anything.

How could you fix this? Add better feedback. One way would be to provide a map to the player, and show them a location on the map when the switch was pulled. Or, show a brief cut scene that shows a door opening somewhere. I’m sure you can think of other methods as well.

On another subject, Church also included an interesting note at the end of the article about how he values beta testing, and half of his readers found the first two pages slow, so start at page 3 if you’re in that half. This would be an example of iteration in the design of this essay, of exactly the sort we talked about.

This note was likely partly in jest, but let’s take it at face value. There’s a slight problem with this fix: you don’t see the note until you’ve already read all of the way through the article, and it’s too late to do anything about it. If Church were to iterate on his design a second time, what would you suggest he do?

This chapter was adapted from Level 3 of Ian Schreiber’s Game Design Concepts course.