Theory: Take Notes

Careful note-taking is central to the design process. Overload is inevitable for a busy designer without a systematic approach to keeping thoughts and ideas organized. Even a designer working on a single project will run into trouble without some way to keep track of successful changes and failed experiments

Below are some guidelines I’ve found useful for note-taking. I hope you find them valuable as well.

1. Write everything down.

This might sound obvious, but things are often obvious because they’re important, and this is important. Don’t assume that you’ll remember anything. Any time you make any sort of progress on a design, write your thoughts down.

I didn’t understand how critical this would be until I started really pursuing design seriously. At that point it became clear that game design doesn’t always involve fretting over and polishing one game continuously. Sometimes that was because I had an idea that I wanted to follow up on right away; more often it was because I knew a concept might not pan out, and so I wanted to have another project “on deck.” Whatever the cause, I found that I was usually working on two or three games at once.

Nor do I have the impression that I’m unusual. If anything, I think I have fewer games in progress than many designers!

Working in parallel like this makes it hard to remember where a design is, what you’ve already tried, and what you meant to try next. This is especially true when a game has lain dormant for a while; coming back to it can feel like starting from scratch. If you don’t have good notes, starting from scratch is exactly what you’ll be doing!

Having a written record guarantees that improvements to a game don’t get lost. It’s incredibly frustrating to know that you solved a problem . . . if only you could remember how. Writing everything down guarantees that you never have to repeat your work.

2. Create a rulebook whenever you’re ready to stop.

Given that switching back and forth between projects is part of the job, it’s vital (a) to retain progress made on current game until it’s time to come back to it, and (b) to get up to speed on the next project as quickly as possible. Written notes help enormously with (a), but not so much with (b); figuring a game out from working notes is frustrating and increases the chance that you’ll miss something. It’s therefore extremely valuable to actually write out a rulebook before setting a project down, so that you can easily re-learn the latest and greatest version of the game when you’re ready to start working on it again.

Putting together a rulebook for a project recently saved me a lot of grief. I wanted to try out a change to Lines of Questioning—but LoQ has already undergone many changes, and I couldn’t remember off the top of my head exactly where the rules stood. This was my own game, and I didn’t know how to play! Without a rulebook I would either have had to reassemble the standard version from notes jotted on legal pads—with the concomitant risk of error—or redo the hours of work and many playtests necessary to hammer it out a second time.

Bjarne Stroustroup, creator of C++, says in his introductory programming textbook that properly documenting code isn’t just a kindness to other people who might read it. It’s also a kindness to yourself, since you may well be called on to maintain your code months or years later. The same principle holds true in game design. Document your designs with a rulebook; you’ll be grateful when you resume work on them.

3. Keep your records.

Sometimes it’s useful to be able to see, not just the current state of a design, but how it got there as well. Maybe you’ve decided that some changes aren’t right, and you want to revert a game to a previous version; maybe an idea that didn’t seem useful or important suddenly has new promise. Holding onto notes and old rulebooks ensures that you can turn back the clock.

The easiest way to keep these documents without your workspace (be it a physical desk or a computer desktop) becoming a mess is simply to organize by date. Admittedly, this isn’t much of an organizational method; knowing that a certain set of rules is from 8-11-15, or that some playtest notes are from 12-24-13, doesn’t tell you anything about what they contain. Something is better than nothing, though, and having a system begets putting things in the system. If you intend to store things by date you’re more likely to store them at all, and that’s the most important thing.

A more powerful, albeit more time consuming, method is to organize by topic. Notes on player powers go in one file; notes on mission cards go in a different one; board layout gets a third. If you’re willing to keep this system up, it provides easy, direct access to relevant information. Just make sure to have a comprehensive rulebook so that you don’t end up relearning (or, worse, teaching) from a slew of documents!

Maintaining old notes and rulebooks is the kind of task that seems like unnecessary drudgery until you really need to be able to refer back to them, at which point you’re happy you went to the trouble. Then you forget how relieved you were in that moment, and it goes back to feeling like drudgery. 😉 Try to hold onto the joy of having what you needed a the exact moment when you needed it, and resist the temptation just to recycle your old notes. Sooner or later you’ll be glad to have them.

Carved in stone

I’m always hesitant to say that someone else should work the way I do; there are lots of ways to be productive. Nevertheless, I feel confident in saying that anyone involved in game design who doesn’t have an eidetic memory will benefit from taking lots of notes, maintaining rulebooks for their designs, and holding on to their work documents. The time investment is significant, but the efficiency gains are tremendous.

Theory: Immersion through Options vs. Immersion through Process

There are two ways to make gameplay “feel” more thematic: by letting players do thematic things, and by having players do those things in thematic ways. Both of those approaches can work, but the former creates more room for design errors and balancing pitfalls. Achieving thematic play through a focus on how players carry out their tasks, rather than by letting them choose from the broadest possible array of options, is thus the safest course.

Many games seek to create immersion by matching play to theme. In fact, getting play and theme to line up is often considered central to having a compelling game. One need only compare the rave reviews given to the experience of playing a driving game with wheel and pedals to the critiques of board games with “pasted on” themes to see the great importance placed on theme coming out through action, and not just through art.

At Your Fingertips: Immersion Through Plentiful Options

Play and theme are frequently connected by seeking to give players all the options they would have if they were “really there.” Thus, in Starfleet Battles—a game of Star Trek space combat—players can use the transporter to move crew members . . . or to beam proximity mines near opposing ships. Shuttles can be sent out to act as fighter craft that harass the enemy vessel, or even to ram them. Whatever a person in the setting might be able to do, games like Starfleet Battles seek to let the player do. The hope is that the player will therefore feel herself an inhabitant of the fictional world.

Unfortunately, this approach has two major weaknesses. First, its limitations quickly become apparent. Shuttles in Starfleet Battles can’t (to my knowledge) have their engines tied into their parent ship’s engines, even though that’s something a starship captain who’s “really there” might want to do. Transporters can’t be used to reposition asteroids to act as navigational hazards, or to pluck out key pieces of opposing vessels, or for many of the infinite uses one might find for pinpoint matter relocation. It’s just not realistic to give the player every option, and before too long the player starts to notice these invisible walls.

Second, and more critically, the quest to make all the possibilities accessible to the player leads to severe design issues. Options might be so unrelated to each other as to need entirely different mechanisms to be satisfying: adding diplomacy to Starfleet Battles, for example, would mean more than just putting a “Talk” entry on the weapon charts. Bringing a wide range of strategies into a game’s ambit can quickly lead to the worst kind of feature-creep.

Even if whole new mechanics are not required, giving players additional choices still opens a can of worms. New capabilities imply a need for counter-capabilities, which may themselves require counter-counter-capabilities. If I could tie the shuttles into main power to get stronger phasers, my opponents would probably need access to better shields lest they get steamrolled by my Voltron-ship—and then I would need a way to break those shields when I don’t have a bunch of shuttles available. Complexity mounts as the options pile up.

By itself, complexity is generally something to be avoided. It’s particularly to be feared in this context, though, because game-breaking design problems lurk below its surface. Left unchecked, the profusion of choices and counter-choices leads to a game that is balanced (hopefully, anyway—it would be hard to tell) but nigh-impossible for anyone but the most invested players to come to grips with. Intimidating rulebooks are not conducive to attracting or retaining people!

Some miniatures games fall prey to this situation. Rules stack on rules: this faction gets to be invisible, so another faction gets tools to see through the invisibility, and then the first faction needs a new trick because invisibility isn’t reliable anymore. The see-through-invisibility faction can also see people hiding in underbrush, so now the “guerilla fighters” faction gets caught in the crossfire, and they need something new as well. By the time balance is restored the rules are a lot thicker!

Moreover, that’s not the worst possible outcome. Arguably a greater danger is the possibility that some choice won’t get its counter, or that the counter will prove too weak. Sooner or later players will notice, and when they do the game will devolve toward a dominant strategy. At that point the game will still be learnable, but it will no longer be worth learning!

Fighting games sometimes end up in that unfortunate situation. Street Fighter III: 3rd Strike is a lot of fun . . . but the things that were supposed to keep Yun’s Genei Jin super move in check didn’t work out. The entire game warped around the Genei Jin, such that much of 3rd Strike strategy boils down to landing or avoiding it. 3rd Strike is a tremendous entry in the pantheon of fighting games—more current games struggle to live up to its art, and that’s to say nothing of the gameplay—but among its astonishing wealth of options an overpowered one slipped through.

Giving players lots of capabilities is, therefore, a double-edged sword. It can contribute to immersion, making the player feel like she is “really there.” However, it can also highlight the options that aren’t available, and can lead to problems with complexity and balance. There are thus good reasons to think that a different approach to immersion might be more attractive.

Tending the Earth: Immersion Through Focus on Process

One such is to put emphasis, not on providing a wealth of choices, but on the nitty-gritty of each individual option. Rather than allowing shuttles to do 10 things (but not any of the 90 others one might want, and #8 is too good owing to a miscommunication with the playtesters), they might only do two—but executing each of those options is challenging and rewarding. Players thus feel that they’re “really there,” not because they can do anything they might choose, but because they get involved in carrying out the choices they make.

As an example, we might go back to flight simulators. Flight sims don’t really have very many options. Players can’t choose instead to drive a tank, or fight on foot, or resolve the issue diplomatically, or apply pressure through NGOs. Many don’t even have any sort of combat; the only thing players do is take off from one airfield, fly in a more-or-less straight line, and then land at another!

Yet, these games have enduring appeal—and that’s because they’re so good at capturing the process. A good flight sim makes the player feel like he’s the captain of the flight, living an entirely different life. Managing the plane is not easy, but doing it well feels great, and having to attend to all of the details maximizes the “you are there” feeling.

This approach to immersing a player in theme can be just as satisfying as providing lots of options. What’s more, it’s much safer from a design perspective. Since options are not proliferating, there’s less need to be concerned about layering of counters and counter-counters. It’s easier to recognize each possibility, to understand its full implications, and to ensure that it’s balanced within the game.

Furthermore, games taking this approach are often easier to learn. Actions have clear implications: do X to achieve Y, at which point you’re ready to do Z. That kind of stepwise process is much more intuitive than a slew of rock-paper-scissors relationships, many in number and some of them (all of them?) involving more than three possibilities.

This is not to say that games focusing on process necessarily have shorter rulebooks, or that they are easy to learn in an absolute sense. Falcon 4.0, a now-venerable flight sim, memorably came with a technical manual describing how to fly an F-16 in such depth that it served as the game’s packaging! By the time a player was ready to take on missions in Falcon 4.0, she was well on the way to actually being able to handle a real Fighting Falcon.

The point instead is that process is easier to learn than arbitrary counters and counter-counters. Falcon 4.0 was workable for those willing to invest the requisite time; a list of options as long as Falcon’s technical manual would have been completely unplayable. Given a length of rules, those rules will probably be easier to grasp if they’re about process than if they’re about alternatives.

As a recent example of how this approach works, let’s look at Agricola. Agricola is a highly-rated game about farming set in Middle Ages Europe. Players feed their families, and farming is the only way to do it; there’s no option to become a trader, or to resort to banditry.

That limitation might seem unthematic—why can’t I apprentice myself to the local builder, and raise beautiful cathedrals for a living?—but it leads to a much better design. First, the game is surprisingly easy to learn considering how much is going on. There’s worker placement and cards and resources and a mini-map for each farm, but the focus on process makes it all manageable. Whenever a player isn’t sure how to do something, he can just ask “well, what steps would I take if I really were a farmer?” The answer is usually very close to how it works in the game.

In addition, focusing on process allows Agricola to create variety in a way that avoids balance issues. One of the major strategies in Agricola can be summarized as “feed the family with grain products;” another is “feed the family with meat from farm animals.” So long as those macro-level options are kept balanced, it’s much easier to let players acquire grain or animals in lots of different ways suitable to middle ages townspeople. The limitations on the “grain strategy” and the “animal strategy” as a whole provide a safety valve and ensure that none of them will get too far out of whack.

Experience has demonstrated that this works surprisingly well. Agricola has lots of cards that give players unique advantages, but only one has received official errata for power reasons. While other cards have prompted discussion as to whether they’re overpowered, the checks and balances that control all strategies—competition for action spaces, in particular—has served to, at the very least, keep the issue open. Limiting players’ food options to grain, vegetables, and meat keeps the number of things to be balanced reasonable, and that contributes to the game’s excellent play-balance track record.

Diplomacy is another example of a game about process rather than options. It offers players very few choices: they can move their pieces to a small number of neighboring locations, and try to bump other pieces out. Most of the elements that have come to be associated with the empire-building genre—technological advancement, a wide variety of military units, resources that build up—are absent. In fact, there are so few possibilities for much of the game that Diplomacy has named openings and defined midgame positions, in the manner of chess.

Nevertheless, Diplomacy is a deep, fascinating game. Like Agricola, the how is interesting even though the what is not; there are a lot of situations that could lead to “A Marseilles -> Piedmont,” all of them different and all of them worthy of exploring.

Furthermore, Diplomacy’s paucity of options helps maintain the balance that has kept it worthy of tournament play for decades. There’s no unexpected combo that can take a game over on the third turn, and no technology that hard-counters Austria’s primary weapon. Simplicity ensures that the multiplayer dynamics Diplomacy relies upon for balance have room to work.

Immerse Yourself

There’s no one right way to achieve immersion—but there are ways that are more or less likely to cause problems in the long run. Providing lots of options, allowing players to try everything they might conceivably try if they were “really there,” is appealing but hard to do thoroughly and even harder to balance. Default instead to detailing the process of a smaller number of choices; the immersive effect can be just as powerful, and the design problems will be fewer.

In the Lab: Building With 3×5 Cards

Just as some examples of what building with 3×5 cards can do:

IMG_0324

A simple structure. Note that the slight differences in the shape of the cylinders allow them to stack just like solid blocks would. In addition, it’s possible to build high even with fairly shaky architecture.

IMG_0325

There’s no need, however, to be content with poor architectural design. This tower is quite stable; the cards are light, but everything is balanced and supported.

IMG_0330

It’s even possible to be a bit fancy while retaining structural strength. The bottom of this tower has fewer parts than the top, but there’s enough weight to keep it together. It survived for quite some time just sitting on the rug while I walked around.

A side benefit of building towers out of 3×5 card “blocks” is that they fall without making a tremendous racket or (assuming they’re used in a reasonable way) causing any damage. New parents playing Jenga will wake up a sleeping child when the game ends; card “blocks” fall with a sound like, well, rustling paper.

3×5 cards can also be written on to create marked blocks. That isn’t an option with when dealing with nice wood. 😉

Ultimately the neat thing about 3×5 cards isn’t that they’re ideal for any one purpose; it’s that they can be put to a multitude of uses–some of which don’t look very much like traditional applications of a card. Every time I need to prototype they’re the first tool I turn to, and they rarely prove unsuitable. I can’t say it enough: keep 3×5 cards handy. They’ll work more often than you think they will.

In the Lab Again

Administration relating to starting at NYU has taken up a lot of time recently, but yesterday and today I’ve finally been able to set some time aside to sit down and design. I’m glad of that, because I’ve had an idea I’m keen to try out.

This idea happens to involve blocks–lots of them, in various shapes. I don’t have blocks in my home, though, and I wasn’t excited about purchasing them just to test an idea that might not work. So, what to do?

The answer, as always, was: 3×5 cards.

It turns out that 3×5 cards keep their shape when folded, so long as one applies a bit of tape. Furthermore, they don’t have the natural curve that paper does. A 3×5 card folded into a box stays a box, with flat sides suitable for stacking.

I know I’ve said it before, but it bears repeating: don’t ever let a lack of prototyping materials stop you from pursuing a design. Prototyping doesn’t have to be complicated, and it certainly doesn’t have to be expensive. Dollar store supplies are plenty for a first run of a new concept.

Theory: Downtime As Encouragement

When designers try to bring out a theme through play, the focus is usually on the high-action moments. However, those moments are often fraught with danger and difficulty, with the result that the theme players experience is sometimes “you suck.” Ironically, it can therefore be useful to pack themes of empowerment into the quiet, calm situations. It’s when the game is at a low ebb that “you are powerful” is easiest to convey.

I noticed this dynamic for the first time when I played Warframe. Warframe casts the player as a futuristic super-space-ninja. My expectation was that, as a super-space-ninja, I would feel like an unstoppable warrior.

However, I’m strictly mediocre at action games. I therefore spent most of my time playing Warframe dying and respawning. It was a lot of fun, and even pretty ninja-y; I got to run on walls, sneak up on people, and generally behave like a shadowy infiltrator equipped with the best bow-and-dagger set around. I just didn’t feel as unstoppable, as remarkable, as I’d expected.

Yet, there was one time when I felt the super-ninja theme come through: back on my spaceship. Hiding in the void, watching alien vessels fly by without detecting me and flipping through my arsenal, I could imagine myself as not just a ninja-who-dies-a lot but as the super-space-ninja I aimed to be. In the safe zone, there was no evidence to the contrary.

Thus, an important thematic moment for Warframe was contained in what was, in essence, the menu system. By seeding the spaceship with little touches indicating power and competence–the enemy ships unwittingly passing me by, the consoles coming to life as I walked–the game’s designers let me in on the excitement of being skilled. Warframe draws on the lure of Real Ultimate Power, and on my spaceship I felt I had it.

Admittedly, this was thin gruel compared to being actually good at the game! There was no escaping the knowledge that outside the walled garden another round of ignominious ends awaited.

That’s probably as it should be, however, and on the way up the learning curve it was nice to have a place where I could get a little bit of the feeling that had drawn me to the game. I had come to be powerful, after all, and it was great that Warframe found a way to meet that desire when I couldn’t attain it otherwise. Warframe thus demonstrated to me that while some players may not have the skill to fully access a theme, it’s still possible to put the idea across in parts of the game where skill isn’t a factor. I’ll remember the lesson in games where the theme is about the player’s strength and power.

Theory: Complexity As an In-Game Resource

Managing complexity is usually viewed as an issue exclusively for designers. That’s not unreasonable; players do not, as a rule, have much ability to make a game more or less complicated. It’s possible, however, to envision ways to give them that ability–and there would be concrete benefits to doing so.

As an example of how this might work, consider word count on cards. I think it’s generally agreed that cards with more words on them are harder to parse, tend to involve more elaborate effects, and are more complicated than those with fewer. Designers are aware of this, and try to keep word count down where possible.

Unfortunately, that approach can only go so far. Looking from the designer’s perspective at cards as a group doesn’t address what will be in a certain deck, or which cards will appear in any particular game. Thus, designers have a further challenge: not only do they need to minimize word count overall, they must try to anticipate how the high- and low-word count cards will come up in play. It’s no use saying “90% of cards are very simple” if the remaining 10% are both extremely complex and enormously popular.

What’s more, different players have different tolerances for complexity. Experienced, highly invested players might find it easy to understand even the most difficult cards, while a parent playing with his or her six-year-old could easily wish for the simplest possible version of the game. It’s hard for a designer in the predictive, top-down position to make a game work for all of these players, even if the game is theoretically capable of accommodating them.

Why not, then, approach the problem from the other side? If word count becomes an explicit, player-facing part of the game, it becomes a lot easier to anticipate how much of it there will be. Word count might thus be limited to, say, 200 words per deck (or market, or tableau, or whatever the game has). Just as with any resource, players can decide how to spend it: a few really wordy cards mixed into a generally very simple environment, or a lot of one-step-above basic cards, or any other combination. The average level of complexity will be consistent no matter how players approach the game.

Of course, word count is a blunt instrument for measuring complexity–but there are other tools available. Each card could have the grade level of its text evaluated. (This isn’t as intensive a process as it sounds; Word has this kind of evaluation as a built-in feature.) The limit could then be based on the number of grade levels overall, or on the highest grade level permitted for any one card. Cards could alternatively be categorized based on the number of steps required by their text, or the number of action windows they implicate. An appropriate standard could be chosen for each game.

Handling complexity in this fashion also enables an opt-in approach that helps players customize their experience. Long-time players can push the limit up to allow for new strategies; parents can directly set the bar at the appropriate level for their kids.

Complexity doesn’t, then, need to be the province of designers alone, nor does it need to be unpredictable. There are techniques out there for measuring it objectively, and once measured it can be treated as a resource under player control, with maximums for individual components and/or for a game as a whole. Approaching complexity in this way could benefit designers, who might be able to say more confidently that they know what the play experience will be like, and has particular advantages for the players themselves, who would be able to tune an aspect of the game that is critically important to enjoyment.

Theory: Explain the Purpose of Options

So you’ve designed a game where it’s hard to transition from reading the rules to playing  intelligently. Maybe the player has options whose import–the “why” as distinct from the “what”–aren’t clear just from reading the rulebook, or perhaps the game is just too complicated for new players to be able to devote much thought to strategy. Everything is fine once someone is invested and has discovered the game’s tactical nuances, but the learning curve is more like a cliff. How can you help new players understand their choices, so that they don’t just quit in frustration?

There’s an often-overlooked solution: simply tell them.

GMT makes Fire in the Lake, its excellent-but-complex simulation of the Vietnam War, approachable using that exact method. Fire in the Lake has two big humps in its learning curve: first getting through the dense rulebook, and then understanding how the rules are applied on the tabletop to make progress toward winning. By being straightforward about what each maneuver is intended to accomplish, GMT gives players a tremendous boost over the second hurdle.

You see, there’s a lot for new players to take in when they start to learn Fire In the Lake: four factions, each with their own victory conditions and unique actions. It doesn’t get easier when one considers that each action has multiple parts. A US player, for example, can assault with her own troops in any of several locations (which costs no resources), then has the option of forcing her ally to attack (which does cost resources). How many pieces are removed by the assault depends on who’s attacking–the US or her ARVN ally, the terrain, and whether or not the US has established a base at that location. The US player also has three other actions she can take, plus three additional helper-actions which can’t all be combined with all of the main options. Her choices are also, by the way, contingent on the monsoon.

As you might imagine, it’s not easy to see the forest for the trees at the end of all this. After going carefully through the rulebook before my first game I was so busy juggling the technicalities in my head that I wasn’t sure how to fit my choices together into a strategy. Then I looked down at the player aid, and saw this:

"Why you would do this," helpfully spelled out.
It’s the first line that’s key.

Having the execution details of a patrol–the cost, where patrolling troops can move–was useful. The greatest value, though, came from that first line: “Purpose.” Here’s why you would do this; you’ll get the following out of it.

All of a sudden it was possible to make meaningful decisions. I had been getting ready to take actions “just to try them out,” accepting that the match would basically be an extended tutorial. Equipped with some basic information about what I could expect from each action, however, I was able to pursue a coherent strategy right away.

It’s worth pausing to reiterate that. A few lines on the player aid saved me from a four- to six-hour tutorial, and launched me right into the exciting part of the game. Those couple of sentences granted an enormous return in player engagement.

Fire in the Lake isn’t the only game that can benefit from explaining when and why certain moves are useful. Consider, for example, chess. The rules of chess are quite simple. Even small children can easily learn the game.

However, the strategic implications of the choices available are complex and often opaque. On his first turn a player can move a pawn, or jump with a knight. When is one better than the other? Why? If he should move a pawn, which one? How many spaces forward? I’ve never heard anyone say that they stopped playing chess because they couldn’t learn it, but I’ve heard people say that they just found it overwhelming.

Now imagine how much more accessible chess would be if every set came packaged with some basic information about what various moves accomplish. This opening brings the bishops and rooks forward to useful positions; that maneuver threatens the opponent’s pieces. Suddenly the player could to evaluate positions, at least in a simple way, and make informed choices. If he wanted to bring the bishops and rooks forward, he might try these moves; if he preferred to get his queen involved, he would at least have an example of what not to do.

Of course, that sort of information is readily available; there are any number of chess resources out there. Seeking them out, however, requires a level of investment that cannot be assumed of new players. When the problem is getting players engaged in the first instance, there’s no better solution than putting valuable help in the one document they’re most likely to read: the rulebook.

As always, this is not a tool suited to every game. Twilight Imperium 3rd Edition doesn’t need to expend energy telling people what the “Warfare” and “Production” roles are for. Netrunner can safely assume that everyone will understand the use of “purge all virus counters.”

When there’s a divide between a game’s rules and its strategy, however, a little explanation can go a long way. Helping players out with a brief statement of how each option might contribute to a strategy does a great deal to bridge the gap between reading the rulebook and having fun with a game. If nothing else, it avoids four- to six-hour tutorials!

Theory: Infinite-Size Units

One of the most interesting things in the Age of Sigmar rules, I feel, is allowing units of any size. Age of Sigmar makes that work by tossing balance aside as a design goal: hordes of troops (or, for that matter, hordes of gigantic firebreathing dragons on the wing) are OK because the opponent has bought into facing them. That leaves open, however, the question of what a balanced version of the idea would look like. How a game would have to work to allow players to take units of any size, and have it remain fair?

This is challenging in part because of the obvious arithmetic benefit to having lots of pieces (more weapons means more hitting), and in part because of the synergies inherent in most miniatures games. Such synergies exist because minis-game units generally exist in a rock-paper-scissors dynamic: tanks are vulnerable to tank hunters, tank hunters lose to massed infantry, etc. Having lots of one thing overloads the opponent’s ability to play the counter: the opponent probably has enough hunters for one tank, but if there are ten tanks the hunters can’t keep up.

So, we need a system that doesn’t directly reward having lots of troops arithmetically, and we also need to avoid RPS mechanics that might fall apart because no one could possibly have enough rocks to break an open-ended amount of scissors. Here’s my first pass:

Imagine a minis game where unit size determines, not mathematical power, but narrative role. Putting a single spearman on the table means that spearman is a mighty hero, the focal point of the story, capable of amazing things. A small number of spearmen (say, 5-10) is a disciplined unit meant to work as a team. Putting lots and lots of spearmen on the table makes them into a rabble, a horde, disorganized but threatening via sheer numbers.

All of these have the same overall power: a hero can mow down a rabble, and a rabble can swamp a hero. (Whether heroes should be mowing anyone down is a worthy question, but outside the scope of this exercise.) The challenge is that the different unit sizes access their power in very different ways. Heroes, for example, might be good at removing specific models (what chance does a member of a rabble have against such a terrible warrior?), but bad at exerting control over the battlefield as a whole. The rabble exerts lots of control (they’re everywhere!), but is weak until it can leverage that control to put lots of attacks on the hero at once.

All of that assumes, of course, that removing the opponent’s models is the goal. We could go even further, looking toward an asymmetric arrangement where the players win in different ways. Heroes accumulate victory points by performing remarkable acts of derring-do. Disciplined units earn points for keeping in formation and working together under pressure. The rabble gets rewards for shoving forward and taking over the board.

Now, the truth is that this might not work. So much of a minis game is in the math, and I haven’t even begun to consider what the math here would need to look like. Finding a way to handle combat where numbers are relevant but don’t directly add power is not trivial.

I still feel, however, that this is a worthy thought experiment. A miniatures game where numbers really don’t matter would be quite distinctive, a design that breaks new ground. There’s a lot to be said for pursuing that.

I need to start a tag for “projects for a 25th hour in the day” . . . .

Inquiring Minds Want to Know: Compilers

(Again, I’m out of town and this is being posted automatically; please forgive delayed responses!)

In the spirit of choosing the right tool for the job . . . .

For a while now I’ve used MonoDevelop for C#/Unity work, and Microsoft’s Visual Studio 2013 for C++. I’ll be frank in saying that I chose both more for their visibility than because of any specific feature they included; MonoDevelop is literally packaged with Unity, and Visual Studio is easily found when one goes looking for C++ compilers.

As time has gone on I’ve become curious about alternatives. My searches have led me to lots of options–but, interestingly, not much guidance as to how to choose between them. Various people online suggest using one compiler or another, but they rarely explain why one should prefer this over that..

Coders, what factors go into your choice of compiler? Do you have specific recommendations for the languages above, or for other languages?

Theory: Balancing for Whom?

(I’m on vacation this week; this post is going up automatically. I’ll respond to any comments when I get back!)

There’s a predicate issue we often skip right over when balancing a game: who will the balance affect? Who are the “players” that the game needs to treat fairly? The answer can dictate a great deal about a game’s design.

Certainly, most of the time the answer is obvious. The players are the ones sitting at the table, or in front of their computers. Game balance affects them, and they’re the ones we’re concerned about.

However, the people immediately making the decisions and pushing the components around aren’t the only possibilities. For example, consider the courtroom. Many people see game-like elements in a trial: there’s strategy, tactics, resources, winners and losers. However, the players aren’t just the lawyers. The clients are playing too–sometimes for life-changing (or even life-ending) stakes. The “game” of law needs to be balanced for these players who often have little opportunity to influence what’s going on.

That might seem an unsolvable problem–how can a game be made fair for players who can’t leverage their skill?–but the writers of the Federal Rules of Civil Procedure found partial answers thanks to some out-of-the-box thinking. In essence, they introduced co-op elements into the law, requiring attorneys to, for example, provide certain important information to the opposing party. When those co-op aspects of the law work well, they eliminate a number of “gotchas” and ensure that the clients have a chance to put on their case.

We might alternatively look toward spectators as potential players. Many games are explicitly designed for spectator appeal; basketball, for example, has on occasion changed its rules in part because the game was trending in a direction that was functional but boring. Thinking about balance in terms of the viewers might be more useful than thinking about it in terms of the people actually engaged in the sport, when those viewers generate multiple billions of dollars every year.

Game design is, to some extent, about creating an experience. It’s therefore sensible to ask “whose experiences?” Always ask that question; the answer might be surprising, and might push a design in fascinating directions.