Theory: Simulation and Puzzle Pure Co-Ops

It’s an article of faith that a great opponent makes a game more fun. A good pure co-op game, then, needs a good AI foe to challenge the players. Designing that opponent requires, first and foremost, deciding what kind of co-op you’re creating: a stand-in or a puzzle. Mashing elements from both types together leads to trouble.

A stand-in challenges the players by imitating a living opponent. It tries to do what a human would do in a given situation. In essence, it simulates the experience of having a human sitting across the table (or on the other side of the internet connection) playing against you.

A puzzle challenges the players by presenting a problem for them to solve. It is not concerned with doing as a real person would do; its only goal is to provide an interesting dilemma, and it acts in whatever way the designer thinks will best achieve that. Puzzles may (should?) have a theme, and they may be good simulations of that theme, but they aren’t trying to simulate an opposing player.

Which category a game falls into has a huge impact on what kind of AI is appropriate. Stand-in AIs need capacities that puzzle AIs don’t. A human will respond to his or her opponent’s actions; to feel “real,” the stand-in needs to be able to do the same. It has to be able to find out what the players are doing, determine what an appropriate response might be, and implement that response.

Puzzles, by contrast, don’t have to care what the players are doing. In fact, they don’t have to do any specific thing so long as they’re interesting. The central question is what the game needs, not how a person would behave, and the AI needs only those capabilities relevant to the game’s particular answer.

Either choice can lead to a great game. Pandemic and Forbidden Desert, for example, are both great puzzles. The diseases to cure in Pandemic and the sandstorm to dig through in Forbidden Desert don’t act like human opponents–but why would they? Diseases and sandstorms aren’t sapient, and it would be weird if they could respond to the players’ actions. Instead they operate in ways that are both thematic for the natural forces they represent and interesting in play. For puzzles, that’s the gold standard.

As an example of a great stand-in I always go back to the Reaper Bot and Zeus Bot for the original Quake. (Wow. I’ve been playing FPS games for a long time.) At a time when a lot of people were on dial-up and internet play with other humans was a lag-filled affair, the Reaper and Zeus Bots were striking for their ability to navigate without bumping into walls, good aim, and consistent connection. Many real players, fighting against 300-500ms pings, couldn’t offer those things. The bots out-humaned the humans!

Designers run into trouble, however, when they mix the two categories. One sees this a lot with “cheating” computer game AIs (which are usually intended for solo play rather than co-op, but the issues involved are comparable). They look like stand-ins but are actually puzzles, and as a result they often end up being unsatisfactory.

For example, players often express frustration with the AI in the Civilization series of games. Civ’s AI promises stand-ins; the player controls one civilization and the others are guided by an AI that has each civilization pursue its own ends–just like they would if humans were guiding them. The goal is to beat the other civilizations, eliminating or outscoring each as though they were separately controlled by human players. The AI-driven civilizations sometimes cooperate and sometimes attack each other, imitating what humans do. It looks like a stand-in, it quacks like a stand-in . . .

. . . but it’s not a stand-in, and at least anecdotally it ends up irking many players as a result. Civ’s AI doesn’t get much smarter as the difficulty level goes up; it just gets more and more resources, far outstripping what the human player receives. Those resources enable the AI to challenge a skilled player, but they undermine the simulation; no human can do the things a high-difficulty AI can do. Ultimately the game becomes a puzzle in which the player must find optimal moves that will allow him or her to keep up with the AIs’ lead in technology and production. Players choose a higher difficulty level looking for a simulation testing their diplomatic ability and battlefield tactics, instead find an optimization problem testing their command of the math behind the game, and walk away aggravated.

(To be fair, some players greatly enjoy the higher difficulty levels. However, they’re usually knowledgeable about the game, know they’re in for an optimization problem, and are specifically seeking that experience.)

Civilization demonstrates–-has in fact been demonstrating for years–-that a really tasty apple is not a substitute for an orange. When designing a pure co-op, follow in the mold of Pandemic, Forbidden Island, and Quake’s excellent bots by figuring out whether you need a puzzle or a stand-in and then delivering fully on that experience. Slipping elements of one into the other is apt to confuse the game’s message and frustrate players.

Something Completely Different: Making Competing Players Powerful – Rules

How can a two-player competitive game reinforce both players’ feelings of might and prowess, where the game is played synchronously in the real world?

There aren’t a lot of competitive games that are designed so that all of the players feel good at the same time. Usually it’s exactly the opposite: at any given moment someone is losing, knows it, and feels lousy. Miniatures games are no exception; since everything is (usually) right there on the table, it’s easy to see when you have taken greater losses than your opponent or are further away from an objective.

Since minis games weren’t helping me find rules germane to the issue, I ranged around a bit. Here’s what I came up with:

1. Players should “fail forward.”

This one comes from role-playing games. In essence, it says that failure should not mean that the player’s turn just ends in defeat. Instead, something interesting should happen.

Knowing a little role-playing game history might help clarify how this rule works in practice. (It’s also interesting in its own right.) Dungeons & Dragons, arguably the first major role-playing game as we’ve come to think of the term, was designed by wargamers. Those designers modeled D&D’s combat on the wargames they were familiar with: dice were used to model the uncertainties of combat, with a good result meaning you succeeded in hitting the target and a poor result meaning failure. This system is used even by game designers with military experience, so I assume that it’s at least a reasonable way to model people fighting.

Over time, however, problems revealed themselves. When playing a wargame, one normally controls many pieces. A single piece’s bad roll is just one part of a larger turn, so even when the dice go against you it’s still possible to have a satisfying turn overall. By contrast, in role-playing games the player usually controls a single character who makes a single roll in a turn. If that roll comes up snake eyes, that’s it–the turn ends on a down note.

Failing forward is one solution to that issue. (It also relates to other role-playing game design issues, to say nothing of the term’s use in self-help books and other arenas; I’m focusing on this particular application of the idea.) In essence, it says that failure should make things more interesting instead of just being a stopping point. The player doesn’t get what he or she wanted, but does get something else: plot advancement.

So, for example, in D&D (or at least, some versions of D&D) a player might try to swing a sword at a monster in order to slay it. If the player fails to slay the monster, that’s it; the player’s turn is over. By contrast, in a fail-forward model the player might fail to slay the monster–and be carried back to the monster’s lair. That means a whole new set of opportunities and options: maybe the player will have another go at fighting the monster, or sneak away, or find out that the monster’s lair is full of the monster’s artwork and the monster is actually a sentient being. Instead of the player’s turn just crashing to a halt with failure, the player is left with new possibilities to consider while waiting for his or her next chance to act.

Failing forward doesn’t mean failure is impossible or that players are choosing between a menu of good options. It just takes some of the sting out. The player missed the mark this time, but something interesting still happened and so the player can focus on that instead of stewing over the failure.

2. The game should involve building something the player can take pride in.

Agricola is a controversial game, which is surprising for a farming simulation with tried-and-true mechanics. A lot of people find the theme dull, or don’t like the “Euro” design sensibility wherein much of the game boils down to constructing an economic engine. I can’t say those criticisms are unfair–I’m not, I have to admit, all that interested in agriculture myself–but Agricola is nevertheless one of my favorite games. That’s for one simple reason: each and every time I play, I get a sense of accomplishment from building my little farm even if I lose.

I see the same dynamic play out in the Civilization series of video games, Minecraft, even building toys like lego. It’s fun to make something. Creating is enjoyable even if you lose, or even if the game is such that winning and losing aren’t meaningful concepts. Seeing something neat that’s new in the world, and being able to say “I did that,” is for many people compelling regardless of the context in which it occurs.

Building doesn’t have to be linear or unopposed; Civilization, Minecraft, and many other games involve building in an environment of challenge with the possibility of setbacks. Overcoming those obstacles can be another part of the fun, and can even give character to one’s result. The key is the sense of accomplishment; players need to be able to take pride in the results of their efforts, even if those efforts don’t result in winning.

That last sentence deserves a little more emphasis. It’s critical that the players end up with something they can take pride in. Agricola’s building is fun because your farm is a nice, productive spot even if it doesn’t earn the most points. Games where the building is just another way to keep score–where one can end the game with a useless half-constructed building, or a spaceship that could never fly–don’t provide this kind of satisfaction.

So what does all this mean?

I’ll be honest: I’m not quite sure yet how rules from role-playing games and a farming simulation apply to a miniatures wargame. However, I feel like these rules are already pushing in interesting directions. This game is supposed to play out a story, and failing forward involves plot advancement; doesn’t that suggest a very different kind of minis game? One where success is measured, not in the number of opposing units destroyed, but in telling a story? Where does that story come from? How does the building factor in? What are the players building? A thing? Character competence? The story themselves? How is the building handled so that players can enjoy the result even when they lose?

At the risk of being unfair, I’m going to leave those questions hanging for a little while: on Friday I’ll have the results for the latest round of Over the Next Dune’s playtesting.