Posts Tagged ‘bookkeeping’

One of the cardinal… guidelines… of game design is the K.I.S.S. mandate: Keep It Simple, Stupid.  Designers (and I count myself in this group, though I’m just an indie, and an artist by day) have a tendency to want to make intricate systems with many moving parts.  Part of the beauty of a good game is how well design elements mesh and make something more than the sum of their parts.  Tangentially, this is why emergent gameplay is so fascinating, but that’s an article for another time.  This tendency is an asset and a liability.

Like a precision watchmaker, I find joy in making initially disparate parts work together to make a great game, and like that watchmaker, sometimes most of my work will never be seen.  It’s like working in special effects in a movie; if you’re doing your job right as the FX guy, nobody knows because the effects are seamless.  (I almost went into movies; that is what my degree was geared for, Pixar-style, but I refuse to work in California.)  Like a good watch, a good game should present a simple function to its end user, and do an excellent job with this primary function.  Maybe there are bells and whistles under the hood that are there for further tinkering, maybe the function takes a lot of work behind the face, but in the end, a watch tells time.

A game provides… what?  A good play experience at the very least, hopefully with more depth as players dig into the strategies and implications of the design.  This exploration should come naturally, though.  Dropping an encyclopedia on a new player might be fine in some niches, but generally, the old Othello tagline “a minute to learn, a lifetime to master” is a pretty good rule of thumb.

Of course, each game will be different, and will appeal to different players, so this is more about culling extraneous design elements than it is about establishing a baseline for all games.  If a particular game design element just isn’t giving a lot of benefit for its cost, maybe it needs to be cut.

A couple of days ago, I posted a unit card for my Zomblobs! game.  This is a game that is meant to be a tabletop wargame, in the vein of BattleTech or WarMachine… just with blobs and some other quirks.  Here’s the card again for reference (and remember, it’s effectively boiling a whole page of data into a single card):

Zomblob Card Murmurer

As Andrew and Yeebo noted last time, it’s a busy little beastie.

There are three major mechanics in play here that drive the game engine:  Time, taken largely from my Tick Talk Time articleHeat, inspired in equal parts by BattleTech and Hordes and a simplification of what I wrote about in my Losing Control article, and the D6 Combat (no fancy single word keyword for this yet) based largely on the World of Warcraft Miniatures tabletop tactical game.  There’s nothing revolutionary here, like 4D space or psychometric controls, but that’s not really what I’m aiming for anyway.  This is a part of a bigger whole, ultimately, but it needs to function as a tabletop game as well.  Consequently, I’m dancing around a few self-imposed design constraints.

One, I want it to be easy to pick up, both for new players and veterans of Warhammer and the like.  Two, I want it to be a relatively small scale game, where every unit is important (think Final Fantasy Tactics rather than Warhammer).  Three, I want to explore the tactical implications of time.

It’s that third one that I hung a lot of hopes on.  Zomblobs! Tabletop isn’t a game where players take turns moving their whole army, like Warhammer or WarMachine.  It’s more like the WoW Minis game, where units move according to their own personal clock, and turns can wind up interwoven like the queue in Final Fantasy X.  (Again, I wrote more about this in the Tick Talk Time article.)

This, of necessity, means each unit needs a way to track their time.  Officially, these are the rules for Time (though I may rework the text for clarity as time goes on, this is the core of the design):

Every Action in the game costs Time.  Time is listed in the Costs section of each Action.

When an Action is used, the unit gains Time Points as noted in the Action Cost.  A unit can never have more than 6 Time Points.

Each unit will need to track its current Time.  A D6 die will work well for this.

A unit can only take its turn to move or use Actions if it has no Time Points.

If all units have Time Points, remove one Time Point from all units.  After this, any units that now have no Time Points may take their turn as normal, acting in Initiative order (highest initiative goes first, roll for ties), choosing to move and/or Act.

A unit’s turn incurs at least a single Time Point cost no matter what, even if they do nothing but pass their turn.

This should do what I want it to do, with teams interweaving their turns, units acting when they are ready instead of waiting for their laggard teammates.  This is also a mechanical theme; Feral units are fastest and will be able to act more frequently and move farther, while the Zomblobs are slow, plodding, powerful beasts, and the Aspirants are somewhere in between.  It might be a lot to think about and track, though.

…wandering off on a brief tangent again, Mark Rosewater has written a few times about tracking information in the Magic the Gathering game (though my Google-fu is weak today and I can’t find said articles, sadly).  The game has this Frankenstein’s Monster card with a weird mishmash of counters to show its state.  In recent years, they have tried to make counters only be +1/+1 or -1/-1, with a few exceptions like time counters.  This streamlined the game and made it easier to understand just what those little counters on the cards meant.  In effect, it means that the players have to track and parse fewer things to understand the game state.  The game has been “dumbed down”, perhaps, but it made it easier to play while still maintaining the bulk of the complexity and tactical depth that comes with those unit modification counters.

…back to the Time mechanic of Zomblobs, then, it’s one more thing to track in the game.  This, on top of Health (Hit Points, really, as Yeebo wrote eloquently about) and Heat (both of which will have a 12-unit span, making them trackable with a D12 like Time Points can be trackable with a D6).  Now, tracking three things per unit isn’t terrible when compared to some tabletop games, but it does mean fiddling around with pen and paper or dice.  I’m not inherently opposed to this, it’s expected in this sort of game, but I am keenly aware of the potential pain involved in tracking too much.  It seems like tracking Time isn’t quite as essential to the unit as Health or Heat (it’s not even part of the unit card), but at the same time, it’s pretty central to what I’m doing with the game’s combat tactics and pacing.  Time and Heat are both costs for each unit’s action, and they are fundamental to how units interact.

On the other hand, it’s entirely possible that the time system will be too much to handle for players who just want to take turns.  I think in the balance, the Time system adds enough tactical depth that it’s worth the cost of tracking it.  Maybe I’m wrong, but hopefully playtesting will give me a better idea of how well it’s received.

I hope to have a set of PDF files available here in a couple of weeks or so for printing by beta testers.  I’d greatly appreciate any help in testing this, especially by those of you who do have experience with other tabletop wargames.  I’ll make a big post on that when it’s ready, but I figured I’d mention it now.  In the meantime, does this make sense?  Any thoughts?

Thanks for the input!

Read Full Post »

I’ve been designing some miniatures I can get the Shapeways guys to print out eventually, ultimately for use in a pair of games I’m working on.  One is a six player (or three or two) elemental sort of chess, so I just need models, but the other is sort of a fantasy/BattleTech mashup, a tabletop tactical miniatures game almost in the vein of WarMachine.

I’m running into a design question, though that I’d like some input on.  I’m trying to find a good way to keep track of information for the combat units.  For those of you with experience with or interest in mini games like this, how do you like to keep track of unit status?  This might include things like hit points, status afflictions (morale, poisons, buff and debuffs, auras, that sort of thing), weapon loadout, special moves, or any of a number of other variables.

I’ve seen games like HeroClix and the World of Warcraft minis game try to encode at least some of this data on a rotating base under the figure.  This has always seemed like a gimmick to me, but it does reduce the number of things you have to keep track of on paper off the combat arena.  The models seem a bit flimsier for the mechanical base, though, so it’s definitely a tradeoff in terms of usability.  They also seem a bit more… “gamey” than the games that just use minis on bases that might have a more simulationist feel.

Other games like WarMachine and BattleTech offload the bookkeeping to papers.  This isn’t as easy to tell the status of things at a glance, but it does allow for much more detailed information and thus, potentially more game design elements and clearer design.

Warhammer does a little of both, in a way, letting unit count in a block of infantry be a visible tally of a combat group’s strength, but it also has a lot of data offloaded onto paper, especially for hero units and special gear or magical effects.

One of the strengths of the Magic: The Gathering card game is that they have tried to reduce the bookkeeping and memory issues over the years.  Once upon a time you might have to keep track of multiple different upkeeps, special effects and what different counters represented (is that a +0/+2, +1/+1 or +2/+0 counter?).  These days, they have tried to distill these issues and have the “board state” give as much information as possible.  It’s nice to have a lot of data out there in the gamespace rather than offloaded to paper, but some things just don’t code well in a small amount of space.  Reducing the number of things players have to remember also helps speed up the game and make it easier to learn, as well as easier to play.

My question then is about that data encoded in the figure bases, whether it’s HP, action arcs, facing, whatever.  Is that method actually helpful in real gameplay?  (This includes noting that it’s more of a hassle if you’re always picking up the models and twiddling with their bases, and on a non-grid gamespace, that’s kind of annoying.)  Is it better to have all bookkeeping off-model?

Which do you prefer playing with and why?  I have my opinions, but I also have relatively little experience with miniature tactical gaming.  I’d like to get a bit more information if possible.  Tangentially, how much bookkeeping is too much?

Thank you in advance!

(Perhaps this could be generously noted as a bit of game UI design.  Playability is a big component of whether a game sticks or not.)

Oh, and bonus question while we’re talking mini design.  Painted or nonpainted?  Shapeways can print in full color now, and it’s even cheaper than nonpainted models.  Painted models are more brittle, though, and don’t have as much detail, so again, it’s all about the tradeoffs.

Read Full Post »