Friendly site visitor KC sends some all-too-kind words about Games Diner content, and asks an interesting question – that’s hard to answer, too, as the good questions always are.
“In your opinion, what aspects of a roleplaying system require special attention in order to avoid major conflicts?”
Hmm.
KC adds a bit more: “I know this is a broad question, and a lot of the answer requires knowing what the intent of the game engine is. Striving to find the balance between playability and realism is the most difficult part of a game, and I’m certain you are familiar with this. Which is why I ask the question.”
Tough one! There’s one that can’t be popped off during a commercial break. In fact, I’m very sorry to say, it’s been months since I received the question. It’s been one of those long, dry periods allowing little time for gaming fun, and about zero time for touching this site.
Yet I have long had, in the back of my head, whispers of actual rules to follow when hacking game systems, an oddball hobby that stretches back to revamping AD&D combat in its entirety, ages ago. I’ve been hearing those voices even more lately, as I’ve been playing with some (non-GURPS) original system stuff. No, nothing ready to reveal or even discuss just yet, but I have had to think more than ever about system design.
With apologies to KC for the ridiculousness slowness of the reply, I’ll take this chance to try putting the little voices’ mumblings into solid English. It’ll definitely be a first, disjointed take; I’ll try to organize the thoughts more in the future.
I won’t attempt to critique any commercial RPGs or the pro designers behind them. I’ll speak to the amateur, “armchair” designers that I can call my crowd. (That doesn’t just mean the hardcores who release free PDF systems, or pour copious amounts of text onto fan web sites; I include those who just make plenty of house rules for personal use, and/or hammer out such ideas in online forums.)
Here goes:
1) Know the goal: I think the main rule for designers is the very one KC mentions: know the intent or goal. It’s a pretty obvious step. Know what you want to build, then build it. Easier said than done, of course!
2) Go straight to the goal: Now that you know what you want, head straight from A to B. Sounds obvious, yes, but it’s surprising how often rules make unneeded diversion through or into C instead. Want to make small critters hard to hit in melee? Then just give a size-based TH mod, not the old Fantasy Folk oddball suggestion for extra PD. Want ST to offer decent lifting capabilities? Then just make it so (as GURPS 4e does), instead of saddling it with unsatisfactory lifting power and patching that via weird Extra Effort rules (a la 3e). And so on.
3) Unofficial is fine: Don’t be discouraged by “non-official” status. It doesn’t matter. Your home-brew may be just as good as the official stuff – in fact, commercial games (GURPS too!) are chock-packed with additions that, once upon a time, only existed as someone’s house rule.
4) Build and then unbuild: If you’ve got the time and energy, design the system that gives exactly what you want, without worrying that it’s overly complex. Now, what can you take away from it? What can you simplify? Starting with the “complete” system may be harder than designing a smaller system for simple, limited utility only, but you’ll often gain interesting insights, or pick up useful tools, in the process.
Meanwhile, the components of the “complete” system that you removed for simplicity remain in reserve, ready to be called into duty as advanced rules, special-case rules, and so on. Even if players don’t readily see it, below the surface your system is a big, unified whole.
So many games go the other route: develop only the minimum system that handles the narrow cases expected to occur in the game – and later, when more is needed, try to expand on the systems. That’s a very understandable approach, considering that developers (especially ones wanting to actually deliver product, especially commercial products) face very real limits on time and energy! But in practice, such later expansions of the game’s system too often take the form of a crazy quilt of mismatched rules patches.
5) Isolate to simulate: Or separate to evaluate, if you prefer. Related to 4), a cardinal rule for working on a simulation: Break up factors and look at each one in isolation. As an example, you can’t come up with spiffy physical performance simulations by mentally juggling power, mass, size, and so on in a big undifferentiated bundle. Look at what changes in each one alone means for a creature. If you do that well, simply putting the individual pieces back together will yield a simu-riffic result.
Restated: I like games that build their simulations and sub-systems from small, individual rules bits, fitted together like LEGO bricks as needed. If done right, those little bits will click together to game out complex situations. And if they don’t click together right… one or more of these little bits needs work. Fix ’em!
6) Watch those assumptions: Related to 4) and 5), watch out for needless assumptions. Is it necessary to assume human PCs, or standard gravity, or certain skills, etc.? An example: I’ve pointed out that GURPS‘ defense rules hands fighters a supernatural ability to predict whether an attack will hit or not, and then base defense decisions on that. To which some have replied, “Yes, but it makes sense that a skilled fighter can do that”. Maybe so – but the game makes no distinction for skill; it awards the same uncanny ability to a battle-scarred soldier and a zero-experience peacenik alike. A rule that assumes all combatants are hardened veterans is the sort of thing I want to get away from where possible.
(This item speaks to a personal like: universal rules that work pretty much anywhere, without patches. You set off after those by first jettisoning assumptions about where or to whom the rules will apply.)
7) Stress test: Got some rule you think is ready to go? Jump right to extreme cases to test it. If it involves physical performance, don’t hesitate to see what happens with creatures that are huge, tiny, super-strong, etc. If it involves some skill, check results for both the super-skilled and the hopeless default users. And so on.
In short: Try to break your rules! If one shatters, that’s fine; it just means it needs more work. Better that it break now on your coffee-stained, desktop “development lab” than later at the gaming table.
8) Playability, not perfection: Do no more design and tweaking than you need or want! Go for playability – whatever that means for you. When explaining imperfections in rules, remember that “because I say so” is an OK answer! As are “I don’t have time”, “I don’t think it’s important”, and “I don’t know how to do it”. Don’t feel every rule must be an unassailable gem of logic and realism.
Returning to the above GURPS example about questionable defense knowledge (e.g., “Those bullets are going to miss me; I don’t need to duck”), I’ve seen every tortured defense possible of its realism – all wildly unsuccessful, IMO. Forget the convoluted explanations; if someone points out problems with a rule but you still like the way it plays, just say, “My group doesn’t have a problem with it; we’re happy and will stick to it”. That’s all the reason you ever need to keep any rule!
Restated: I’m happy to forgive just about any rules “imperfection”, as long as the game is up-front and honest about it. Take the well-known mechanism of “level-based hit points” used in many games. For any sort of reasonable simulation of “damage” and “injury”, this approach makes for a pretty abysmal foundation. And so, if a game protests “Nuh-uh, these hit points are totally realistic!”, followed by some shaky reasoning, that game will earn my (modest) ill will.
But if a game admits “Yeah, we know the mechanism has issues, but it also has a certain wonky charm, and newcomers especially seem to enjoy it, and we’ve prepared a few simple patches to handle the worst problems that crop up”, my response will likely be… “All right. Fair enough. It’s not an approach I’d choose, but I get it. Now let’s play!”
9) Offer options: Tearing things apart and designing for detail will often leave you looking at a handful of decent ways to achieve your ends, each offering its own mix of complexity and detail. That’s good for one big reason: different gamers want different things, and have wildly different ideas of what’s “playable”. So if you’re designing for others, don’t throw out all options but your favorite; include options that others may prefer.
That includes keeping options for yourself, too. If you’re like me (and most gamers?), sometimes you want extra detail, sometimes you don’t. Having several options on hand means having a fuller toolbox.
(Most of the thoughts above are concerned with realism; 8) and 9) speak most directly to KC’s question about playability. And they’re not a spiffy clear answer. They boil down to “design and play what you want”. But hey, that is good advice, always!)
10) It’s only a game: Whatever your crazy idea, give it a shot, and forget the folks who say it can’t be done. When you try something ambitious, someone will always chide: “Why do all that? Why go through that trouble to get some fiddly component right? It’s only a game.”
My response to that is always: “Exactly! It’s only a game!” It’s not nuclear science. There’s nothing dangerous going on. Whatever you do, no one is going to get hurt. So go for it: Tinker, hack, obsess, detail, over-detail, scrap, rebuild, get it right, for whatever value of “right” works for you. While observers debate whether or not your fancy combat timing sub-system can or should be done, just jump in and do it.
And if you fail – well, you probably learned a few things or gained some new ideas in the process. Or, harking back to “know what you’re doing”, you now know what approaches failed and why, which may let you regroup and take a better shot.
There’s a weak start. Later it’d be good to have more thoughts that aren’t so blatantly obvious to everyone reading! Sorry!
For now, here are some additional thoughts on making good simulations.
Ingredients for good simulation
1) Right Components: What output (measurements or results) do you want to get out of the system? What inputs should go into it?
2) Right Engine: What’s the engine (formula or process) that converts inputs into output?
3) Right Numbers: Is the simulation good? To the extent possible, aim for “reality checked” (or otherwise valid) values for inputs and outputs.
Those vaguely correspond to the well-known Plan, Do, and Check, respectively. A few comments on the list:
Of these, 1) is often the bulk of the work. It’s where you break a system down to its components, ask what each should do (isolate), ask which are important (i.e., which are the ones you care about or can’t be safely ignored), and then ponder how to put them back together into the desired system.
1) is also a good place to clearly define what any given traits represent. If you can, be specific with your definitions. Looking back over GURPS issues that have confused players over the years (especially before 4e), the biggest culprits seem to have been confused definitions: vague explanations for what traits like Dodge, PD, or even ST represent; muddled connections among Speed and Move and Dodge; conflicting depictions of All-Out actions; and so on.
Robust compliance with 2) would be a good, solid engine. Weak compliance with 2) is at least getting directions right in your engine. (A very simple example: in rules for jumping, make sure that jumping performace goes up, not down, as strength goes up.)
Directions are usually obvious, but once in a while, rules do get things backward! (Example: A number of GURPS tweakers have suggested basing Basic Speed on ST. Sure, that has a sensible-sounding ring to it, and may even seem to work nicely for a range of humans of similar weights – but it can be 180° wrong where wee critters, dinosaurs, and even unusual people are concerned, yielding sluggish squirrels and hyper-speed brontosaurs. (See earlier advice about “stress testing”. Jump right to the extreme cases! If things break badly, these aren’t the rules you’re looking for.)
3) is where you’ll really want to try to break things, testing extreme inputs. Use real-life examples wherever you can: physical performance for a normal human can be guessed at or tested with some accuracy, and data exists for Olympic athletes and the like.
That’s it for now. It probably didn’t give you much insight, KC; you can blame me for not having much to say in the first place, and all of it unorganized at that.
There is a Part II.
