Last Bastion: Getting There

Last Bastion‘s design process has been . . . involved. The game is currently on version 8.4; each new whole number represents a completely new prototype. Moreover, that does not include the very earliest concept-exploration prototypes over the summer.

Fortunately, there’s a light at the end of the tunnel. My major stakeholder was very pleased with how today’s test went, and I’m excited about the current direction. It’s interesting from a design perspective, and has a neat, wild magic feeling to it.

While it’s not yet ready for prime time, Last Bastion is getting there. Look for more news on it in the future.

Theory: Prototype Early

It’s been said before, but as I saw the evidence again today it bears repeating:

Get your game into a playable state as soon as possible, so that you can try it out. Eric Zimmerman suggests 20% of the way through a project as the deadline for having a playable prototype. If you go any deeper without being able to see how the game works in practice, you’re running a grave risk.

The World Chess Championship

I am bad at chess.

That’s something I admit with regret. Chess is a wonderful game, and I’d love to be good at it. As a competitive player, I’m drawn to its formal tournament structure; as a student of the history of games, I relish the idea of participating in one that that has lasted through so many years. Not having invested in chess is something I view as a failing.

My lack of chess knowledge, though, has done nothing to dim my enthusiasm for this year’s World Chess Championship. By all accounts–I don’t feel qualified to judge–it’s been a great one. Mr. Carlsen’s final victory has been detailed in the New York Times with just enough information to get a sense for what happened without overwhelming jargon; I’m sure there’s other good coverage, and I’d urge everyone to seek it out. Love it or hate it, chess is worthy of study–perhaps not least for the way such a slow-paced game can create such excitement.

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

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.