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

There’s Play Everywhere

Apologies for the late update today. Some folks were blocking a major thoroughfare to run drag races.

While I can’t say I loved the inconvenience to the general public, it was a salutary reminder that games can pop up in unusual places, and at unexpected moments!

Please Forgive the Dust . . . .

It appears that some combination of WordPress updates and my experiments with an updated site have broken the sidebar, inhibiting site navigation. To make matters worse, the portfolio page isn’t linking correctly. Frustrating!

This week and the beginning of next are already slated for design work, but over the Thanksgiving weekend I should have a chance to get to work on this site’s overall structure. Stay tuned!

Slack: Here’s Why

I’ve occasionally inquired about Slack, a popular messaging system, to see what others felt its advantages were. Having used it fairly extensively at this point, I feel able to say that Slack has benefits–so long as it’s used in conjunction with other tools that address its shortcomings.

The major benefit to Slack over other communication systems (emails, etc.) is, as one of my colleagues at the Game Center has pointed out, its integration with other software. If you use Git for version control, GitHub can post directly to Slack when you commit code. Trello, commonly used as a production management tool (think of it like a feature-laden to-do list), will report to a Slack channel when tasks are created and completed.

Automating information flow like this has a lot of benefits. Most notably, it’s much easier to keep abreast of what’s happening in a group. You know what everyone’s working on, because messages appear and notifications are delivered as they make progress. Since the notices are sent automatically you get that information even when they’re busy and might forget to update the team themselves.

Unfortunately, while Slack is good as presenting information it’s extremely poor at retaining it. Messages scroll away quickly, and there’s no good method for sorting through them. It’s therefore vital to use external software to track bugs, maintain to-do lists, and the like; Slack doesn’t do persistent information.

Slack isn’t perfect. It is, however, free for smaller users, and its integration with useful tools does a lot for its appeal. Teams that need a centralized source of news–and that don’t mind storing anything that needs to stick around elsewhere–will find Slack a good fit.

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.

. . . and then there Was None

No time to write, that is! I’m afraid I’ve spent the last two days coding, discussing miniatures wargame design, tuning a thesis prototype, measuring control layouts for a refurbished arcade cabinet, and sleeping a little less than is recommended. 😉 Please forgive the non-update; I’ll hope to have something meatier for Friday!

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.