Theory: Non-Simulative Minis Game Rules

Occasionally I return to the idea of a story-driven, Dynasty Warriors-inspired minis game. Here’s an interesting way to think about the goal of that design:

RPGs fall, roughly, into two categories. In some, the rules are a simulation of the physics of the universe. FFG’s Warhammer 40K RPGs work this way; when a player rolls to hit, the target number is based on in-world factors like distance, visibility, and the characteristics of the weapon.

Other RPGs direct the rules toward the narrative rather than what’s happening in the fictional world. A lot of indie RPGs (without trying to get into a debate about what counts as an “indie” RPG) are of this school. Polaris’ rules, for example, are all about which player gets to decide what happens rather than whether her character can then carry out the decision.

Current minis games fall into the former category. The rules are designed to simulate the in-universe rules of the world. Admittedly those rules might be strange, because the world is a magitech kingdom or an alternate dimension, but they’re still meant as a simulation.

The proposed minis game takes a completely separate tack. The rules aren’t about simulating a character’s attacks. They’re about driving the narrative forward and wrestling for control over the story.

Theory: The Unsolved Problem of Ongoing-Release Games

Warmachine recently unveiled a new format: Champions, in which only certain pieces are legal. Champions is probably a great solution to some troubles Warmachine has been having. It also, however, points up an interesting design problem: how to keep games that have more and more content released manageable without resort to rotation.

By way of background: up until now every piece ever created for Warmachine was tournament-legal. It didn’t matter whether the piece’s rules just came out a month ago, or whether it was the first piece ever released for the game. Absolutely everything could be put on the table.

Over time that system has become less and less manageable for players. The sheer number of pieces and combinations has become overwhelming. Can your army handle a general like Morvahna, who can manipulate dice in her favor? What if she instead focuses on endlessly resurrecting her army? Deneghra can flatline your army’s stats for a turn; will you survive? Bradigus and the High Reclaimer both block line of sight, but in entirely different ways; can your army see through both? Saeryn’s army can’t be engaged in close combat for a turn, while Vlad can shut down most ranged attacks; you’ll probably want both options so you can always get through losing one. Sorcha will freeze you in place if you don’t have a way to become immune to ice attacks . . . .

The list goes on, but you can see the problem. It’s impossible for any one army to deal with all of these threats. As a result, players inevitably started to get into rock-paper-scissors matchups, wherein they didn’t have ice immunity or the ability to stop resurrection or whatever. Unsatisfying games invariably followed.

Magic: the Gathering had a similar problem of multiplying complexity, and answered it with rotation, a system in which older cards are excluded from tournaments as new cards come out. Rotation proved so effective at keeping complexity manageable that it’s become the accepted answer to the problem of “how do we keep releasing product for this game without rendering it incomprehensible.”

Warmachine will, I think, benefit from having a rotation; only needing to think about Saeryn without also needing an answer to Vlad will be a big help. Privateer Press’ form of rotation is even especially generous to players, since older pieces will rotate back in over time; Magic forces players into “eternal” formats when they want to use their old cards.

Nevertheless, I find I’m a bit disappointed. Rotation is a good solution, but it’s only one solution. I have to think that there are others, if we’re imaginative enough to find them.

The specific form of rotation Privateer Press has chosen demonstrates that there’s still thought to how it should be implemented. I’d still like, though, to push out the boundaries in this area. We know rotation is a good tool; now let’s put our energy into finding some equally good alternatives!

Three Days to Retirement: an Interesting Lesson

Just a quick note about something interesting that happened today . . . .

I asked a bunch of people if I should build Three Days to Retirement as more of a horror game, or as an exercise in challenging the player to stay focused while effectively playing a game about working a day job. I expected the answer to be “horror;” that’s a known genre, and frankly, do people really want to play a game about doing dreary things?

The answer turned out to be, overwhelmingly, “yes.” Horror was considered acceptable as something to tack on, but the real interest was entirely in the unusual concept, even if it’s not an obviously fun one.

Quite the lesson learned!

Theory: Following Up on Polishing

It struck me that the discussion on polishing the experience probably seemed to amount to “avoid downtime.” That’s a part of what I was talking about, but there’s a little more to it.

Games can slow down or stop for many reasons. Sometimes it’s because the mechanics require players to pause and wait for something to happen. It could also be because there’s a table that has to be consulted again and again, or a complex rule that needs to be looked up repeatedly. The physical processes of of the game might be the issue: fiddliness in the components can make the game drag, especially if it’s unproductive fiddliness–things getting knocked out of alignment or off the table that then need to be dealt with.

Take a broad view as you look for slowdowns. Anything that interrupts the game, or even brings down the tempo unintentionally, deserves your attention.

Theory : Polish the Experience

Years ago, as a school teacher, I found out that the easiest way to lose control of a classroom was to have a handout in the wrong place. The few seconds it took to walk across the room were enough for sotto voce conversations to spring up. Inevitably those turned into larger, longer, louder discussions, and trouble was in the air from then on out.

Playing a game is much the same way. As soon as friction appears in the play experience, players start to think about other things. Minds wander while someone looks up a rule. Phones come out as resources are counted. Shuffling cards becomes an excuse to watch a minute of the ballgame that’s on TV in the next room.

If you’re lucky, everyone comes back when the task is complete and the game is ready to resume. Relying on luck is dangerous, however. Like students who don’t enjoy a class, players who aren’t very invested in a game may never quite fully renew their attention, to the detriment of the group as a whole. They may just wander away and never come back!

It’s therefore vital to keep an eye out for rough edges that catch and delay your game’s progress. When does play stop? When do the players have to wait? Every time that happens they’ll spiral away from the game, like planets being spun off from a star. If they’re permitted to get too far away, they’ll leave your solar system entirely.

To the greatest extent possible, you want to remove those moments. Ideally you want to get rid of them entirely. Failing that, cover them over with something else happening.

As an example of the latter strategy, consider Dominion. Dominion involves a tremendous amount of shuffling. However, the next player can start her turn while the previous player’s routine end-of-turn shuffling is going on. The game therefore doesn’t have to stop; things are still happening, and everyone stays engaged.

Now imagine Dominion built a little differently–say, a player gets to make one final buy at the end of her turn and put that card on top of the deck. Now all shuffling has to be done before the next player can go. That game is significantly longer, and thus quite a bit more likely to lose people’s interest.

Polishing those little rough edges, sanding them down so that they don’t grab and slow the player experience, is a vital step in design. Eliminating rid of those problem moments will do a great deal to keep players involved in the game. Leave some time in your process for this work; it will pay dividends.

For the Curious

A project I just turned in for my MFA program. Three weeks of Javascript is both not nearly enough and far, far too much. 😉

http://phaser.magnet.tsoa.nyu.edu/tom/www/combineBlocks/

One major lesson I learned from this project: don’t get too caught up in solving technical problems, and neglect to design with pencil and paper. It’s much easier to solve design problems when they’re not wrapped up in the complexities of coding.

Theory: Everything I Needed to Know About Game Design, I Learned from Space Invaders

  • Start players out slow, then add more challenge.
  • Safe places create moments of respite; moving out of them then creates moments of excitement.
  • Simplify the player’s interaction with the game as much as possible.
  • Forgive enough player mistakes to let the player learn, but not so many that the game is trivial.
  • Keep the effects of your medium in mind. If, for example, your computer chips are going to move the aliens faster as they get blasted, you want to know that in advance if at all possible. 😉
  • Let the player do things that clearly provide progress, but make it hard to tell which action offers the most progress.
  • Related to the above, make it easy to be OK at the game, but as soon as the player reaches that point, let her see how much more there is to learn and do.
  • Cute, appealing monsters are easy to like.
  • Related to the above: art doesn’t need to be complicated or realistic to be cute and appealing.
  • Tune everything. Player movement, enemy movement, victory requirements, average game time, everything. If it can be expressed numerically, tune it precisely.
  • Don’t be ashamed to monetize a good product.

Theory: Maintain a Changelog

Long projects have a way of getting away from you. It’s hard to keep track of everything you’ve done, and it’s especially difficult to remember why you did it. Those times are the reason to keep a changelog.

You might have heard of a changelog in the context of programming. If you haven’t, it’s just a list of what you did for each version of your game/program/whatever. “Version 3–Reduced player chits from three to two, increased food to five units/player” is a perfectly good changelog entry.

Just doing that much will be a big help to your design. If nothing else, it will help you reverse course when something goes wrong (and I guarantee you, things will go wrong). A summary of what changed from version to version makes it easy to undo changes and get back to a version of the game that worked.

To get even more value out of your changelog, include a brief statement of why you did it. “Reduced player chits from three to two to avoid stalemates” is a short statement, but it allows you to reverse course selectively. If you’re still having a problem with stalemates, you can undo just the change that was meant to deal with them and try something else. If you’re happy with the stalemate situation but something else is wrong, you can roll back everything else.

Adding that extra detail to your changelog will also keep you from making stupid mistakes (of a sort, I will admit, I’ve made 😉 ). It’s very easy to forget which changes responded to which problems. You can very easily undo or modify a change that you need to keep, simply because you’ve forgotten what it was doing for you. Being able to quickly reference the changelog and say “wait, this thing that’s about to be altered is doing important work” can save a lot of time going down blind alleys.

For an example of a good changelog for a tabletop game, check out the one Mantic Games just put up for its Warpath rules. Most changes include a specific statement of why the change was made, so it’s clear which ones are safe to fiddle with and which ones aren’t.

(Disclaimer: I’m a backer for the current Warpath kickstarter, but only for about $20 to get a couple of specific models to use for other games. I don’t need more stretch goals met. ;))

Keeping this sort of changelog is the kind of thing that will take a few minutes each design/playtest session, and will save you hours of completely unnecessary design/playtest sessions. I can’t recommend it enough.

Link: GameMaker Humble Bundle

After Wednesday’s post it might seem weird that I’m linking to the GameMaker Humble Bundle. However, the product on offer here is different from Super Mario Maker in three key respects:

1. GameMaker is a proper engine, not just a level editor. Even if you start from the position that level editors are subject to limitations, GameMaker doesn’t suffer from them.

2. GameMaker is great for beginners. The strength of GameMaker is that it’s simple enough to learn quickly, while still being powerful enough that you can make some engaging stuff with it. I’ve heard of academic game design programs that use GameMaker as part of their introductory curriculum, and I can understand why it’s their choice. If you’re at an introductory stage, GameMaker is a good option.

3. The bundle includes source code. Although GameMaker is as accessible as a serious engine can be, it still involves programming–and that can be a real hurdle to clear. Having solid, working code to start from is a tremendous benefit to those new to programming, and easily makes the higher tiers of the bundle worthwhile.

I’ve only used GameMaker briefly, but I’ve been impressed with what I’ve seen. I think you’ll be more than satisfied with what you get for $12.