by Richard Egan

I’ve always been wary of writing an article on “how to design a variant”. Most of all, I doubt my own credentials, but I also know only too well how the motives and goals of one variant designer can be very different from those of another. The standard game itself represents a compromise between historical accuracy (where is Montenegro?) and simplicity (a special rule for the Kiel canal), which it is hard to imagine another designer settling on independently. The readiness of variant designers to “improve” on the basic game, with the likes of Milan Diplomacy and Abstraction, confirm this. 

Given that “Calhamer’s compromise” is the foundation of every single variant designed, it strikes me as most unlikely that any two writers will concur on how to go about producing any agreed scenario. Thus we have several versions of a worldwide variant (Mercator, World Domination, World Diplomacy), two or three Tolkien-based designs (Middle Earth, Downfall, Third Age) and so on. Most of those I’ve already named have at least two or three marks, representing different interpretations of the original design. 

Recently, Lee A. Kendter Jr., in his zine Get Them Dots Now published a couple of articles on “What Makes A Good Variant” and “What Is Chrome”. It speaks volumes that I found myself disagreeing with much of what even such an eminent authority on variants had to say: for example, his suggestion that a designer should avoid names like “Gulf of Siam”, preferring instead “Siam Gulf”, not only differs from the example of the standard game, which I like to take as a reference point in all my own variants, but can also compromise the atmosphere of a game. If the Gulf of Lyons is called the Gulf of Lyons, I feel it should be so called on a DIPLOMACY map – I’ve never seen or heard it referred to as the “Lyons Gulf”. 

Others obviously feel differently, but I confess my regard for a variant has occasionally been undermined by what I regard as contrived names – and I know I wasn’t the only one to laugh at a province called “Iguana Town” on a medieval English variant called “The Men Who Would Be King” (or some such). My own habit is to spend some time with a couple of large atlases looking for alternative names for a difficult province, rather than invent one. 

Whilst this might hardly seem an overly important point, it nevertheless demonstrates is that there is not necessarily a lot of consensus on what makes a good design: if even the names of the provinces can be a subject for disagreement, what hope is there for the rules themselves? 

I, for example, prefer to “design by default” : I try to avoid repeating the rules of the standard game where they are unchanged by the variant. Where I leave something unsaid, I expect the players or GM to refer back to that enduring phrase featured at the start of nearly every variant, along the lines of “the rules of the basic game apply except where noted below”. 

Recently, I received an enquiry from a GM running one of my variants. It is a design that uses units other than Armies and Fleets, and also includes a rule which allows players to choose, in the first turn, whether to start “with an Army or a Fleet” in each of their home supply centres. I was surprised when the GM asked if this meant players could also choose to start with one of the other types of unit; to me, the answer was clearly “no”, and yet he felt that, since the rules did not specifically say to the contrary, it should be allowed. 

My philosophy has usually been to keep rules to what I regard as a ‘manageable minimum’: not only do I expect points to be lost in a mass of conditions and repetitions, but also there is a danger of boring the reader out of his interest in the game. Keeping them as simple as can be consistent with eliminating loopholes and ambiguities is one of my priorities. But if the example above is anything to go by, this is not everyone’s idea of what makes a good set of rules. 

And even then, I’ve broken my own guidelines: I am currently running a variant called “Africa”, again one of my own designs, but which is so complex that, even as a five-player game, it takes about as long to adjudicate as two or three standard DIPLOMACY games. Some people would say that such a design was unwieldy, but such people would clearly not buy AVALON HILL games – there are no hard and fast rules on either complexity or chrome, and I receive more requests to open a waiting list for another “Africa” game than anything else. With complexity and chrome, it seems, it’s yet another case of different strokes for different blokes. 

Having thus established that it’s never more than one man’s preference that decides what is a good variant, it’s time I made some attempt to fulfill my original brief (issued by Rich Jackson, who will by now be wondering when I’m going to get around to the set of guidelines he requested on “designing a variant”). For there are common points worth bearing in mind when putting a design together, and I shall endeavour to highlight some of them below: 

1. OBJECTIVE 

Before you start, give some thought to whether or not your idea is likely to make a good variant, how many players you expect it to support, and what sort of variant you want it to be. How important is accuracy? Do you want a complex variant or a simple one? 

2. CONSISTENCY 

Strive for consistency when preparing the rules: avoid getting bogged down in chrome in one area whilst leaving another under-developed. If you achieve historical or literary accuracy with one part, but ignore it elsewhere, players will soon question why. Better to be simple or complex throughout (example writing Saruman’s Crows into a Tolkien variant whilst leaving out the Ring). 

3. PLAIN ENGLISH 

When you come to writing the rules, try to write them as simply and plainly as possible. Rules are “technical writing”, and should be presented with a minimum of effect. 

4. AMBIGUITIES 

This is what it’s all about. Quite distinct from the matter of rules written in a confusing fashion (see above) is the matter of rules that conflict with each other or are open to different interpretations. Above all, avoid these. All rules should be thoroughly checked for this before publication. Approach them with the attitude of a player looking for loopholes he can exploit. 

5. PROVINCE NAMES 

If the variant needs a map (and most do), take trouble over the likely three-letter abbreviations of the names you give the provinces. Ideally they should all be different, though some prominent designs instead feature a list of abbreviations which all players are expected to use. Alternatively, label the map with the abbreviations and publish a list of the full names elsewhere – this is by far the simplest way to avoid any confusion. However, you must still take care to check you haven’t duplicated any abbreviations. 

6. BORDERS 

If the variant needs a map, take care that borders are draw so as to leave no doubt about which provinces neighbour each other. For example, borders should never form an “X”, which makes it ambiguous whether or not all four provinces adjoin each other – UNLESS the rules provide for this. 

7. STRUCTURE  

Try to present the rules in an orderly fashion, split into sections if possible or necessary, to facilitate understanding and quick reference. Ideally, every point should be given a distinct number or code, or named, so that if a query is raised, a player or GM can point to “Rule Xll.a” or “The Moses Crossing Rule”. 

8. NAMES  

Any designer worth his salt should take the trouble to check that he isn’t naming the variant after one already in existence. For preference, ask the UKVB Custodian – or better still, send a draft copy of the rules. The UKVB can, on request, proof-read rules to check for ambiguities and loopholes for you (see above). 

9. INFORMATION

Always include the designers name and a date when the variant was published or written : the latter is most important in the event of confusion over which mark number came first (especially given the thoroughly infuriating and deplorable habit of the NAVB in issuing ARDA numbers without reference to chronology). 

10. VARIANT BANK IT! 

Once finished, ensure that you send a copy to your friendly UKVB Custodian. 

This article was first published in Moonlighting No.7 (Feb 1990)