# Goals, Anti-Goals and Multi-player Games

In this article I will try to address Keith Burgun‘s assertion that games should have a single goal and his analysis of certain kinds of goals as trivial or pathological. I will try to demonstrate that multi-player games either reduce to single player games or necessitate multiple goals, some of which are necessarily the sorts of goals which Burgun dismisses as trivial. I’ll try to make the case that such goals are useful ideas for game designers as well as being necessary components of non-trivial multi-player games.

(Note: I find Keith Burgun’s game design work very useful. If you are interested in game design and have the money, I suggest subscribing to his Patreon.)

# Notes on Burgun’s Analytical Frame

## The Forms

Keith Burgun is a game design philosopher focused on strategy games, which he calls simply games. He divides the world of interactive systems into four useful forms:

1. toys – an interactive system without goals. Discovery is the primary value of toys.
2. puzzle – bare interactive system plus a goal. Solving is the primary value of the puzzle.
3. contests – a toy plus a goal all meant to measure performance.
4. games – a toy, plus a goal, plus obfuscation of game state. The primary value is in synthesizing decision making heuristics to account for the obfuscation of the game state.

A good, brief, video introduction to the forms is available here. Burgun believes a good way to construct a game is to identify a core mechanism, which is a combination of a core action, a core purpose, and a goal. The action and purpose point together towards the goal. The goal, in turn, gives meaning to the actions the player can take and the states of the interactive system.

## On Goals

More should be said on goals, which appear in many of the above definitions. Burgun has a podcast which serves as a good long form explication of many of his ideas. There is an entire episode on goals here. The discussion of goals begins around the fifteen minute mark.

Here Burgun provides a related definition of games: contests of decision making. Goals are prominent in this discussion: the goal gives meaning to actions in the game state.

Burgun raises a critique of games which feature notions of second place. He groups such goals into a category of non-binary goals and gives us an example to clarify the discussion: goals of the form “get the highest score.”

His analysis of the poorness of this goal is that it seems to imply a few strange things:

1. The player always gets the highest score they are capable of because the universe is deterministic.
2. These goals imply that the game becomes vague after the previous high score is beaten, since the goal is met and yet the game continues.

The first applies to any interactive system at all, so isn’t a very powerful argument, as I understand it. Take a game with the rules of Tetris except that the board is initialized with a set of blocks already on the board. The player receives a deterministic sequence of blocks and must clear the already present blocks, at which point the game ends. This goal is not of the form “find the highest score” or “survive the longest” but the game’s outcome is already determined by the state of the universe at the beginning of the game. From this analysis we can conclude that if (1) constitutes a downside to the construction of a goal, it doesn’t apply uniquely to “high score” style goals.

(2) is more subtle. While it is true that in the form suggested, these rules leave the player without guidelines after the goal is met, I believe that in many cases a simple rephrasing of the goal in question resolves this problem. Take the goal:

G: Given the rules of Tetris, play for the highest score.

Since Tetris rewards you for clearing more lines at once and since Tetris ends when a block becomes fixed to the board but touches the top of the screen, we can rephrase this goal as:

G': Do not let the blocks reach the top of the screen.

This goal is augmented by secondary goals which enhance play: certain ways of moving away from the negative goal G' are more rewarding than others. Call this secondary goal g: clear lines in the largest groups possible. Call G' and goals like it “anti-goals.”

This terminology implies the definition.

If a goal is a particular game state towards which the player tries to move, an anti-goal is a particular state which the player is trying to avoid. Usually anti-goals are of the form “Do not allow X to occur” Where X is related to a (potentially open ended) goal.

Goals of the “high score” or “survive” variety are (or may be) anti-goals in disguise. Rephrased properly, they can be conceived of in anti-goal language. Of course there are good anti-goals and bad ones, just as there are good goals and bad goals. However, I would argue that the same criteria applies to both types of goals: a good (anti) goal is just one which gives meaning to the actions a person is presented with over an interactive system.

# Multi-Player Games and Anti-Goals

I believe anti-goals can be useful game design, even in the single player case. In another essay I may try to make the argument that anti-goals must be augmented with mechanics which tend to move the player towards the anti-goal against which players must do all the sorts of complex decision making which produces value for players.

However, there is a more direct way of demonstrating that anti-goals are unavoidable aspects of games, at least when games are multi-player. This argument also demonstrates that games with multiple goals are in a sense inevitable, at least in the case of multi-player games. First let me describe what I conceive of as a multi-player game.

multi-player game: A game where players interact via an interactive system in order to reach a goal which can only be attained by a single player.

The critical distinction I want to make is that a multi-player game is not just two or more people engaged in separate contests of decision making. If there are not actions mediating the interaction of players via the game state then what is really going on is many players are playing many distinct games. A true multi-player game must allow players to interact (via actions).

In a multi-player game, players are working towards a win state we can call G. However, in the context of the mechanics which allow interaction they are also playing against a (set of) anti-goals {A}, one for each player besides themselves. These goals are of the form “Prevent player X from reaching goal G“. Hence, anti-goals are critical ingredients to successful multi-player game design and are therefore useful ideas for game designers. Therefore, for a game to really be multi-player then there must be actions associated with each anti-goal {A}.

An argument we might make at this point is that if players are playing for {A} and not explicitly for G then our game is not well designed (for instance, it isn’t elegant or minimal). But I believe any multi-player game where a player can pursue G and not concern herself with {A}, even in the presence of game actions which allow interaction, is a set of single player games in disguise. If we follow our urge to make G the true goal for all players at the expense of {A} then we may as well remove the actions which intermediate between players and then we may as well be designing a single player game whose goal is G.

So, if we admit that multi-player games are worth designing, then we also admit that at least a family of anti-goals are worth considering. Note that we must explicitly design the actions which allow the pursuit of {A} in order to design the game. Ideally these will be related and work in accord with the actions which facilitate G but they cannot be identical to those mechanics without our game collapsing to the single player case. We must consider {A} actions as a separate (though ideally related) design space.

# Summary

I’ve tried to demonstrate that in multi-player games especially, anti-goals, which are goals of the for “Avoid some game state”, are necessary, distinct goal forms worth considering by game designers. The argument depends on demonstrating that a multi-player game must contain such anti-goals or collapse to a single player game played by multiple people but otherwise disconnected.

In a broader context, the idea here is to get a foot in the door for anti-goals as rules which can still do the work of a goal, which is to give meaning to choices and actions in an interactive system. An open question is whether such anti-goals are useful for single player games, whether they are useful but only in conjunction with game-terminating goals, or whether, though useful, we can always find a related normal goal which is superior from a design point of view. Hopefully, this essay provides a good jumping off point for those discussions.

# On Inform 7, Natural Language Programming and the Principle of Least Surprise

I’ve been pecking away at Inform 7 lately on account of its recently acquired Gnome front end. For those not in the know, Inform (and Inform 7) is a text adventure authoring language. I’ve always been interested in game programming but never had the time (or more likely the persistence of mind) to develop one of any sophistication myself. Usually in these cases one lowers the bar, and as far as interactive media goes, you can’t get much lower, complexity wise, than text adventures.

Writing a game in Inform amounts to describing the world and it’s rules in terms of a programming language provided by Inform. The system then collects the rules and descriptions and creates a game out of them. Time was, programming in Inform used to look like:

Constant Story "Hello World";
Include "Parser";
Include "VerbLib";
[ Initialise;
location = Living_Room;
"Hello World"; ];
Object Kitchen "Kitchen";
Object Front_Door "Front Door";
Object Living_Room "Living Room"
with
description "A comfortably furnished living room.",
n_to Kitchen,
s_to Front_Door,
has light;


Which is recognizably a programming language, if a bit strange and domain specific. These days, writing Inform looks like this: (from my little project):

"Frustrate" by "Vincent Toups"
Ticks is a number which varies.
Ticks is zero.
When play begins:
Now ticks is 1.

The Observation Room is a room. "The observation room cold and
surreal. Stars dot the floor underneath thick, leaded glass, cutting
across it with a barely perceptible tilt. This room seems to have been
adapted for storage, and is filled with all sorts of sub-stellar
detritus, sharp in the chill and out of place against the slowly
rotating sky. Even in the cold, the place smells of dust, old wood
finish, and mildew. [If ticks is less than two] As the sky cuts its
way across the milky way, the whole room seems to tilt.  You feel
dizzy.[else if ticks is less than four]The plane of the galaxy is
sinking out of range and the portal is filling with the void of
space. It feels like drowning.[else if ticks is greater than 7]The
galactic plane is filling the floor with a powdering of
stars.[else]The observation floor looks out across the void of space.
You avert your eyes from the floor.[end if]"

Every turn: Now ticks is ticks plus one.
Every turn: if ticks is 10:
decrease ticks by 10.



As you can see, the new Inform adopts a “natural language” approach to programming. As the Inform 7 website puts it

[The] Source language [is] modelled closely on a subset of English, and usually readable as such.

Also reproduced in the Inform 7 manual is the following quote from luminary Donald Knuth:

Programming is best regarded as the process of creating works of literature, which are meant to be read… so we ought to address them to people, not to machines. (Donald Knuth, “Literate Programming”, 1981)

Which better than anything else illustrates the desired goal of the new system: Humans are not machines! Machines should accommodate our modes of expression rather than forcing us to accommodate theirs! If it wasn’t for the unnaturalness of programming languages, the logic goes, many more people would program. The creation of interactive fiction means to be inclusive, so why not teach the machine to understand natural language?

This is a laudable goal. I really think the future is going to have a lot more programmers in it, and a primary task of language architects is to design programming languages which “regular” people find intuitive and useful. For successes in that arena see Python, or Smalltalk or even Basic. Perhaps these languages are not the pinnacle of intuitive programming environments but whatever that ultimate language is, I doubt seriously it will look much like Inform 7.

This is unfortunate, because reading Inform 7 is very pleasant, and the language is even charming from time to time. Unfortunately, it’s very difficult to program in1, and I say that as something of a programming language aficionado. It’s true that creating the basic skeleton of a text adventure is very easy, but even slightly non-trivial extensions to the language are difficult to intuitively get right. For instance, the game I am working on takes place on a gigantic, hollowed out natural satellite, spinning to provide artificial gravity. The game begins in a sort of observation bubble, where the floor is transparent and the stars are visible outside. Sometimes this observation window should be pointing into the plane of the Milky Way, but other times it should be pointing towards the void of space because the station’s axis of rotation is parallel to the plane of the galaxy. The description of the room should reflect these different possibilities.

Inform 7 operates on a turn based basis, so it seems like it should be simple enough to create this sort of time dependent behavior by keeping track of time but it was frustrating to figure out how to “tell” the Inform compiler what I wanted.

First I tried joint conditionals:

  When the player is in the Observation Room and
the turn is even, say: "The stars fill the floor."


But this resulted in an error message. Maybe the system doesn’t know about “evenness” so I tried:

  When the player is in the Observation Room and
the turn is greater than 3, say "The stars fill the floor."


(Figuring I could add more complex logic later).

Eventually I figured out the right syntax, which involved creating a variable and having a rule set its value each turn and a separate rule reset the value with the periodicity of the rotation of the ship, but the process was very frustrating. In Python the whole game might look, with the proper abstractions, like:


while not game.over():
game.describe_location(player.position);
if (player.position == 'The Observation Room' and
game.turn() % 10):
print "The stars fill the floor."


Which is not perhaps as “englishy” as the final working Inform code (posted near the beginning of this article) but is much more concise and obvious.

But that isn’t the reason the Python version is less frustrating to write. The reason is the Principle of Least Surprise, which states, roughly, that once you know the system, the least surprising way of doing things will work. The problem with Inform 7 is that “the system” appears to the observer to be “written English (perhaps more carefully constructed that usual)”. This produces in the coder a whole slew of assumptions about what sorts of statements will do what kind of things and as a consequence, you try a lot of things which, according to your mental model, inexplicably don’t work.

It took me an hour to figure out how to make what amounts to a special kind of clock and I had the benefit of knowing that underneath all that “natural English” was a (more or less) regular old (prolog flavored) programming environment. I can’t imagine the frustration a non-programmer would feel when they first decided to do something not directly supported or explained in the standard library or documentation.

That isn’t the only problem, either. Natural english is a domain specific language for communicating between intelligent things. It assumes that the recepient of the stream of tokens can easily resolve ambiguities, invert accidental negatives (pay attention, people do this all the time in speech) and tell the difference between important information and information it’s acceptable to leave ambiguous. Not only are computers presently incapable of this level of deduction/induction, but generally speaking we don’t want that behavior anyway: we are programming to get a computer to perform a very narrowly defined set of behaviors. The implication that Inform 7 will “understand you” in this context is doubly frustrating. And you don’t want it to “understand,” you want it to do exactly.

A lot of this could be ameliorated by a good piece of reference documentation, spelling out in exact detail the programmatic environment’s behavior. Unfortunately, the bundled documentation is a big tutorial which does a poor job of delineated between constructs in the language and elements of it. It all seems somewhat magical in the tutorial, in other words, and the intrepid reader, wishing to generalize on the rules of the system, is often confounded.

Nevertheless, I will probably keep using it. The environment is clean and pleasant, and the language, when you begin to feel out the classical language under the hood, is ok. And you can’t beat the built in features for text based games. I doubt that Inform 7, though, will seriously take off. Too many undeliverable promises.

1 This may make it the only “Read Only” programming language I can think of.

# Elaborations on “You Aren’t Gonna Need It”

The Cunningham & Cunningham Wiki is a wonderful place to get lost in, and it is so (chaotically) packed with useful programming lore that you are bound to come out of a dive a bit more enlightened about what it is programmers actually do.

One of my favorite pages is You Aren’t Gonna Need It from which I pull the following quotation:

Always implement things when you actually need them, never when you just foresee that you need them.

The justification for this is pretty straightforward: adding things you don’t need takes time and energy, plus generates more code, which means more potential bugs and cognitive load for future development. Since your job is to deliver software that actually does something which you presumably have at least a provisional understanding of, speculative development is an obvious waste of time.

To this basic justification I add only the following small elaboration: If you don’t need it now, you probably don’t understand it anyway. Anything you implement speculatively is very likely to be wrong as well as useless.

## Why Software Is Hard

There are a lot of reasons software engineering is hard. Probably the primary reason it is hard is that we do not yet have a complete understanding of why it is so hard in the first place. Richard P Gabriel, a software philosopher and progenitor of the Worse is Better meme observes, probably correctly, that one reason for this fundamental ignorance is that software engineering is a comparative tyro among engineering disciplines: it is both extremely young (beginning only in 1945, approximately) and subject to radical change. A developer in 1945 would find the contemporary development environment utterly alien and vice versa, a state of affairs not afflicting, for instance, stone masons, who have, arguably, thousands of years of more or less dependable tradition to inform their work.

With characteristic insight, Dr Gabriel also observes that software engineering is also difficult because it isn’t physically constrained1, which means that humans, the product of 3.5 billion years of evolution in a physical environment, but not a computational one, have very little experience upon which to rely as they build objects in the space of computable functions.

Suffer me a brief, digressive analogy: Hyper Rogue III is a game which takes place in a two-dimensional hyperbolic plane. One implication of such a space is that it is very unlikely that a wanderer will ever return to a particular position unless she almost exactly follows her own trail of bread crumbs. Exploring the space of computable functions is similarly dangerous to wanderers, except more so: we are not well equipped to even identify the hills, valleys, walls and contours of this space.

Hence my elaboration: the wanderer in the landscape of programming is very likely to lose his way. He has neither physical constraints nor well developed intuition to guide him. And despite the existence of tools like git, which promise us the ability to backtrack and refactor with some confidence, software inevitably ossifies as it grows.

Hence my elaboration: you don’t build things you don’t need because, if you don’t need them, you probably don’t really understand what they should be. If you don’t understand what they should be, you’ll probably wander off base as you build them, and you probably won’t even notice that you have wandered off until something concrete impinges upon that code. When that happens, you might find that refactoring to solve the problem you have now is prohibitively difficult, because that feature you thought you would need has subtly impinged on other parts of your code.

Explicit, concrete requirements are the closest thing you have to the physical constraints which make stone masonry a more reliable discipline than software engineering, and nothing but rote experience will ever give you the physical intuition that stone masons can rely on.

So don’t wander off: You Aren’t Gonna Need It anyway. At least until you do.

1: Well, the relationship between the physical constraints on software and the software is, at any rate, not entirely trivial or transparent.

# Watch as I Liveblog “Death of the Corpse Wizard” development.

I’ve always wanted to make videogames. I’ve been programming in one way or another for nearly half my life, so you’d think I would have created at least one so far, but usually my scope gets too big and I end grinding to a halt or getting distracted by something else. Today I’m trying something different. For the rest of the day I’ll be liveblogging, at this post, my development of a small game called Death of the Corpse Wizard. I’ll be using HTML5/Canvas, Javascript, an Oryx Tileset I bought, and a game design I thought of in the shower yesterday. Here is the inaugural image:

Hello World

Very briefly the game intends to be an “Arena Roguelike”.  Your character sits in the center of the screen and enemies approach from all sides.  If an enemy bumps into you, you lose one vitality.  If you bump into an enemy you take one vitality from it (most monsters have only one vitality).  You may also choose, on your turn, to use a vitality to build or reinforce a wall, which costs one vitality.   Monsters can attack walls and when the wall’s vitality is reduced to zero, it disappears.  The goal of the game is to survive as long as possible.

For now, those are the only rules.

### Update 11:30 am, Strasbourg Time

Tile Sheet Support

I’ve finished support for Tile Sheets and loaded the Oryx sheet.  Named a few tiles.

I’m working on the visual aspects first because they provide pleasing feedback.  I will now start the game engine.

161 LOC so far, not counting libraries.

### Update 12:53 pm, Strasbourg Time

Tweening

I’ve added the entities and systems required for drawing the player, set up the user controls, and implemented Tweening so that the player sprite moves smoothly.  Since this is now “playable”, I also uploaded the game here, so you can play it.

Some tidbits about the development process: I’m using Kran, an awesome, lightweight entity-component system which deserves more attention.  It is the same system I used to generate my clocks.

### 3:30 pm, Strasbourg Time

Timers, Spawners

I have added turn-based timer logic, spawners, and the ability to create walls.  Plus an HUD that shows the player’s vitality.

### 5:12 pm, Strasbourg Time

The game is now playable and you can even lose, sort of: monsters have AI and can attack you, you can kill them, and they can reduce your health to zero.

Monsters

### 6:04 pm, Strasbourg Time

Death Screen

Added a death screen and death condition!  It will probably be the start screen too, at some point.

### 6:53 pm, Strasbourg Time

Playable

Death of the Corpse Wizard is now entirely playable: it has a goal, challenged, and failure conditions.  I’m going to declare my first ever single-day Game Jam a success!

# What I learned from playing “Dark Souls” and “Kentucky Route Zero” in the same night.

Equus Oils

Crunch.

Because the world has not yet gone utterly mad, I had the chance, on my last vacation, to sit down and play video games with my friend Marlin and my brother. As a professional person living a semi-standard contemporary lifestyle, I don’t usually have time for dedicated gaming and so this hobby, which I enjoyed substantially at various stages of life when time was more easily spent, has fallen by the wayside.

In the same evening we played both Dark Souls and Kentucky Route Zero. I learned something about myself that night, and something about these weird things we call “video games.” Here is what I learned:

### VIDEO

“Kentucky Route Zero” and “Dark Souls” are radically different experiences. In the former, a disgustingly slick visual presentation delivers a series of significantly meaningless choices to the player as it explicates a mood, a setting and a story. The the latter game, just as much staggering expertise is devoted to the development of a perfectly balanced interactive system of punishment and reward. As a matter of course, “Dark Souls” furnishes its own fairly well developed and delivered mood and setting, but it is unmistakably the context for the play rather than the point of it.

“Kentucky Route Zero” is, undeniably, a fine piece of craft which is aware of itself and its cultural surroundings. And I have to admit, I found the experience engaging, particularly as a kind of spectacle. But “Kentucky Route Zero,” for all of its awareness of itself as a supposed “game,” seems mostly interested in undermining itself as an interactive experience. A great recipe for alienation is forcing a person to make choices which she knows do not matter, and “Kentucky Route Zero” seems pretty interested in this trick. Early in the game the player is forced to guess a password based on the fact that it is a “long poem, which really sums it all up.” They are prompted with a series of three choices of lines from three different poems and any series of choices works. The poems themselves are nice, and one does get a pathetic little frisson of pleasure at the prospect of mixing and matching them but in the end, the decisions don’t actually matter.

The entire game is a series of little, often very well conceived and executed vignettes in which the player’s choice doesn’t really matter. At the very best we can think of the game as a kind of psychological test which is never evaluated by anyone. This is thin gruel, and we might wonder why the creators of the game, who are clearly in possession of tremendous talent and skill, bothered with an interactive experience at all.

### GAMES

Let’s contrast this experience with “Dark Souls.” “Dark Souls” is the quintessential videogame, or at least the most quintessential game I’ve played recently. What do I mean by this? Well, “Dark Souls” is too a product of apparently profoundly skilled craftspeople, but where in “Kentucky Route Zero” the craft is devoted to style and narrative substance, “Dark Souls”‘s creators devoted most of their energy to the invisible, mechanical systematics of the game and to the job of communicating those systems to the player, clearly.

It has been for some time de rigueur for videogames (of which Final Fantasy VII or Metal Gear Solid are exemplars) to pack their narrative into “cutscenes,” which are just non-interactive, generally cinematic or intended as such, scenes in which story is advanced. “Dark Souls” has essentially none of these, recognizing them as fundamentally alien to a fundamentally interactive medium. Instead, “Dark Souls” thrusts you immediately into the business of moving your avatar through space. After a very brief interactive tutorial, the player finds herself contending with a series of interactions, diegetically presented as medieval combat, which require attentive reaction to an interlocking set of concerns.

The player has a weapon, a shield, health, and stamina. She generally faces similarly outfitted, sometimes oversized, versions of herself. Holding up one’s shield prevents one’s stamina from regenerating, as it does rather quickly, otherwise. Blocking a blow costs stamina, as does an attack or a dodge. If one’s stamina is drained she can neither attack effectively nor defend or dodge. On top of these actions, the game layers timing: it takes a moment to raise your shield, it takes varying amounts of time to strike, time which leaves you open to counter attack. It takes time for one’s stamina to regenerate, time during which the character is vulnerable. These systems, in and of themselves, are well designed but not particularly unusual for videogames.

What distinguishes “Dark Souls” is that it is not afraid to make the primary focus of the game these simple, balanced systems. It isn’t afraid to offer real reward and punishment for understanding them. The designers of the game were confident enough to sell the experience of “Dark Souls” as primarily the gameplay, rather than circumstantial narrative content. As such, “Dark Souls” can afford to apply a gentle touch to the subjects of setting and narrative. There is a latent story going on here, but, while we can enjoy it, and it may motivate us to play, the story is definitively not the game.1

### YOU DIED

Like the snooty intellectual I so obviously am, I have often bemoaned the boringness of videogame subject matter. Do we really need another game about big dudes hitting eachother with things until one of them dies? From this perspective I welcome the arrival of games like “Kentucky Route Zero,” as refreshing alternatives to mainstream game content.

However, “Dark Souls” reminds me that there is still enormous material to be mined the realm of mechanics, which are the elements of videogames as a medium which cannot be reproduced elsewhere. It is a definite problem that his material is being mined in a pretty boring, heteronormative context of dudes hitting dudes, but I can’t help but feel, at the end of the day, that “Dark Souls” is better at being what it is than “Kentucky Route Zero.”

### Footnotes

1: I’d like it if we could stop saying that “Dark Souls” is “hard.” “Dark Souls” is only “hard” because the relationship between the superficial and significant elements of the game, the progress the player makes in the world or plot vs the progress the player makes in her mastery of the mechanics, is misleading. The player experiences lots of progress in terms of her knowledge and ability to work the in-game systems, even when the false progress through the story or environments of the game is stalled.