A Letter to Myself

Dear Me,

Elegance is good. A design that has all the rules it needs, and none that it doesn’t, plays well and is easier to learn. Creating something elegant is a valuable accomplishment, and is much to be desired.

Keep in mind, though, that not all solutions are found at the system level. Go is an incredible game. So too is chess, even though it has a bunch of pieces that work differently. Chess’ extra rules don’t make it inelegant; they provide much of its incredible, lasting appeal. Queens and knights and rooks all add play to a simple system, without needing to distort that system in order to create 8 x 8 go.

Give yourself permission to add on when you need to add on. Don’t undermine a system that works in the name of perfecting it; sometimes, the elegant system really does need one more rule.

All best,

You

Theory: Dependency in Cooperative Games

Cooperative games exist on a sliding scale based on how players interact with each other. Some feature high levels of dependency: players rely heavily on each other to carry out their respective tasks. Low-dependency games, on the other hand, allow players to progress independently. Recognizing where a design falls on the dependency spectrum is vital, because it has an enormous effect on the player experience.

In high-dependency games, player 1’s ability to perform in-game actions is gated by player 2’s choices. American football has many examples: the wide receiver simply cannot catch a ball the quarterback throws too inaccurately, and a running back stops at the line of scrimmage if the offensive linemen do not make a hole. Video game healers often fall into this category as well, unable to raise health bars when the rest of the team has gotten themselves killed.

High dependency means that if the rest of the team plays badly, or according to a different gameplan, player 1 cannot act. This makes players extremely aware of each other, and can create a very strong team experience. Clockwork moves that enable successive players to act at their best are both intrinsically satisfying and impressive to watch. When this kind of game is going well, the positive feedback is extremely strong.

On the other hand, when things get off the rails high dependency games turn nasty. Successful play is like an assembly line, and when widgets stop coming it’s easy to identify where the issue arose. The center snapped correctly, the quarterback threw accurately, and then the wide receiver was supposed to catch it and run—but that last step was missed. Since center and quarterback did things right, it must be the wide receiver’s fault. If the team is fractious, or team members enjoy the anonymity of online play, recrimination is apt to follow.

Low dependency play avoids turning player 2 into a gate for player 1. Pandemic’s Researcher can always cure diseases regardless of what the Medic is doing. Team Warmachine tournaments pair off members of opposing squads, such that teammates cannot help or hinder a game in progress.

It’s much easier to keep team dynamics positive in low dependency games. Everyone gets to do their thing, whether or not others are succeeding. Assuming “their thing” is fun, the game can be satisfying even if the rest of the group is having trouble.

Yet, low dependency makes it quite a bit more difficult to create a team dynamic in the first place. If everyone can act independently, it is easy to ignore one’s teammates. The game can devolve into loosely connected solo games, or the most skilled player dispensing with cooperation in an effort to carry the entire game.

Neither high nor low dependency is inherently better. Both dynamics provide value, and the weaknesses of each can be designed around. It is possible to shift between them, or to incorporate elements of both, adding just enough dependency to a game to keep a team together while providing independence to cool tensions.

The key for designers is to position their game on this spectrum consciously. Increasing dependency risks increasing toxicity; decreasing it can undermine cooperation. Knowing that, one can design around it.

Theory: Strawman Design

Sometimes you need a mechanic to do something. It doesn’t need to be a good mechanic, or at least that isn’t necessary yet. All you want is something that enables you to test another element of the design. In those cases, a strawman mechanic is what you’re looking for.

“Strawman” mechanics are an idea I got from Frank Lantz. They’re the dumbest, simplest things that do what you need done. Having strawmen in place makes it possible to test other aspects of the game; getting a high score may not be a great goal for your platformer, but it might be enough if you simply want to incentivize jumping so you can work out physics problems.

In addition, strawman mechanics provide a baseline against which other ideas can be judged. New mechanics have to work as well as, or preferably better than, the strawman. If they don’t, they don’t make the cut. This seemingly-trivial test will eliminate a lot of possibilities!

It’s often difficult to get all the aspects of a game right at once. You’ll find yourself needing to prop up one side of a game in order to work on the other. Let a strawman mechanic take that weight; it’ll keep your game in testing now, and help you choose a better system later.

Pathfinding Attacks

An odd concept, much in need of tuning but with the hint of a useful idea.

screen-shot-2016-10-24-at-9-55-21-pm

Players can choose from either of two weapons. Once pathfinds sensibly to the opponent. The other uses a random heuristic; it will get to the opponent eventually, but using a likely sub-optimal route that covers a lot more ground. Do you want to go for the throat, or control space?

The Joys of Version Control

Some advice I had occasion to give to first-year MFAs today, but that I’m confident is right for everyone: if you’re a digital designer, learn and use some kind of version control. Use it for everything. That includes your prototypes, your quick projects, everything, without exception. It substantially improves your ability to recover from failed experiments (and, thus, your comfort with necessary experimentation) even if you never have to recover from a drastic loss.

Link: Red Blob Games

Computers do all sorts of great things. Unfortunately, taking advantage of a computer’s unique capabilities–pathfinding, generating content mathematically, effortless line-of-sight evaluations, etc.–can involve getting through substantial technical barriers. If you’re being kept from your design goals by one of those walls, I strongly recommend taking a look at Red Blob Games.

Red Blob Games does two things that are very, very useful in providing code help. First, it has lots of examples. Second, and perhaps more importantly, it explains clearly how things work. The examples are all the more useful as a result, and it’s (relatively) easy to envision the changes needed to build the implementation you need for your particular project.

Some ideas hinge on a technical thing that must work. If your technical thing is on Red Blob Games’ pages, that’s a big head start. Give them a look.

Wargames Study: Little Wars

I suspect that many people have developed the essentials of H.G. Wells’ Little Wars on their own. At its core, one tries to knock over the other player’s toy soldiers with a projectile before they do the same to yours; I played a similar game with my father as a child, and I’m sure I’m not the only one. Committing simple rules to print, though, helps emphasize Wells’ central idea: “[t]hings should happen, and not be decided.”

We take it for granted that things are decided in games, usually by a system constructed for the purpose. Yet, there’s something remarkable about resting on “what happens” instead of “what the rules tell us happened.” It feels natural and immediate; the toy soldier is out of play because he was knocked over. How could it be otherwise?

It couldn’t. There’s no intermediate step to Little Wars combat, no opportunity for the excitement to dribble out of the resolution process. Our intuition tells us the soldier is lost, and instantly he is.

There are lots of other things to say about Little Wars. Charles Pratt accurately pointed out that its playful, toylike quality defuses the concern for precision that can make miniatures games fiddly; whether that trooper got knocked 1/16″ or 1/8″ to the left when he was tapped accidentally is irrelevant, because it’s the same challenge to hit him with a projectile either way. Little Wars is also a melding of dexterity and tactical play in a way that disappears from the strategy genre thereafter. It’s got as much in common with modern basketball and American football as it does with Warhammer.

Yet, I can’t get away from the sense of immediacy as the truly gripping element of Little Wars. “Things should happen, and not be decided.” How many games could follow that advice? How often could the system be refined, or cut away, to enable things to happen?