(See also Part II.)
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 2e 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 to 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 4e does), instead of saddling it with unsatisfactory lifting power and patching that via crooked 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: Design the system that gives exactly what you want, without concern for overcomplexity. Now, what can you take away from it, what can you simplify? That may be harder than building only for simple, limited utility, but you’ll often gain interesting insights, or pick up useful tools, in the process. And if you ever want to revisit the extra detail that you removed, it’s sitting on the bench, ready to go.
5) Isolate to simulate: A.k.a., separate to evaluate. 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 the creature. If you do that well, simply putting the individual pieces back together will yield a simu-riffic result.
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 online 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 rule makes no distinction for skill; it awards the same uncanny ability to the never-been-in-a-fight pacifist. Why should a rule assume that all combatants are hardened veterans?
(This one speaks to a personal fave: 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. Try to break your rule.
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 defense example, I’ve seen every tortured defense possible of its realism – all wildly unsuccessful. 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!
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, it 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? It’s only a game.” Exactly! It’s only a game; it’s not nuclear science, it’s not dangerous. While they’re debating whether or not it can/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, 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: GURPS tweakers often suggest basing Basic Speed on Strength. That may seem OK for a range of humans of similar weights, but can be 180° wrong where squirrels, brontosauruses, and even unusual people are concerned.
#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.
