Large-Scale System Design

by Linda Naughton ("Faraday")

Part II - Design

Last time we talked about the Requirements phase - defining what the system has to do. This time we're going to look at Design - figuring out how we're going to do it. I like to break this up into four pieces:

Details - How will the system work?
Interface - How will the player interact with the system?
Data - Where are we going to store our data?
Objects - What objects are we going to have?

Details
In all that talk about use cases and the feature set, we never actually figured out what skills system we're going to use. Obviously this is a pretty important detail. So important, in fact, that some may argue that it really should have been decided in the Requirements phase. I'm actually OK with that. Even engineers who do this for a living usually can't agree on exactly where Requirements ends and Design begins, so don't sweat it. As long as it gets decided somewhere, that's all that matters.

Skill System Details
Talking to Zarquon and Thor, I determined that they don't have a specific skills system in mind. So I pitched a few common ones to them:

• Count Successes (World of Darkness, Shadowrun 4)
  
• Percentile System (Top Secret SI, Millenium's End)
  
• D20 System (just about every game in the world now, it seems)
  
• FUDGE (Seen on a couple MUSHes, including Otherspace at one point)

Zarquon and Thor quickly decide on FUDGE. For those of you not familiar with the game, it's a generic system that uses a pretty simple mechanic. You can read all about it on the FUDGE web site (http://members.dsl-only.net/~bing/frp/fudge/fudge_toc.html). I had to do some reading to familiarize myself with the rules.

A word on legality: Obviously you want to consider copyright issues when using a published system. Usually you'll be OK, but you want to check to see if they have a published stance on such things. For FUDGE, the author allows you to use it freely so long as you include a disclaimer in the game.

FUDGE Sidebar
Here's a little summary of FUDGE.

Traits (skills and attributes) are rated from -3 to +3, with words corresponding to the levels (like Terrible or Superb). When you make a skill check, you roll 4 "Fudge Dice", which gives you a number from -4 to +4. You add that to your skill or attribute and get the final result (which they call the "Rolled Degree"). The degrees have the same names as the traits. Most tasks require only a Fair degree. Others will be easier or harder.

Example: Mary is trying to jump across a chasm. It's not that wide, so she only needs a Fair success (+0). Her jumping skill is Good (+1) and she rolls a -1. Adding the skill and roll together gives a rolled degree of Fair (+0). She succeeded, but barely. If it had been a wide chasm, with a difficulty level of Good, she would have failed.

A similar mechanic applies for opposed checks. Each player rolls, and you compare their rolled degrees.

Example: Jane and Joe are playing tug-of-war. There's no particular skill involved, so they both roll strength. Jane gets a rolled degree of Mediocre (-1) and Joe gets a rolled degree of Good (+1). Joe wins, with a relative degree of Great (+2) because he rolled 2 levels higher than Jane's roll.

Sometimes there are action modifiers that affect the roll. +1/-1 is normal, +2/-2 is a large modifier, and +3/-3 is an extreme modifier.

It's possible to roll better than Superb and worse than Terrible. Those rolls are generally labeled Superb+1, Superb+2, etc.

Being a generic system, FUDGE has flexible skills and attribute lists. At this point, I don't know exactly what skills and attributes we're going to need. That's not a big deal. I can code it up with a generic list and change it later once we decide.

There's only one problem with that. If there's a coded combat system, it needs to know what skills/attributes to use. Does the attack roll use Melee Weapons or does it use Swords? Is the dodging skill named Dodge or do we use Gymnastics? Since I'm only doing the Skills System right now, this isn't a problem. But we're going to have to work out the skills and attribute lists before we do any of the other systems.

A few other misc. notes about chargen in FUDGE: You get a certain number of points to spend on skills and attributes, but that's going to vary depending on what the skills and attributes are! We'll have to figure that out later. Also, FUDGE has a rule where you can alter the skill point cost depending on skill complexity. I really don't like that - it makes the system way too complicated when you're trying to spend skill points. So we're just going to use the same cost for everything. It might not be as realistic, but we want players to actually get through chargen in a reasonable amount of time!

FUDGE also has a concept of Gifts/Faults (similar to Merits/Flaws from World of Darkness), but after a quick discussion we decide we don't want to use these.

Back to the Details
Why did I just spend a dozen paragraphs summarizing FUDGE? You could have just read it yourself, right?

I personally find it very helpful to write down the details of the system I'm going to be implementing. It's one thing to read it in a rulebook. But when you summarize it in your own words, you get a better understanding. It makes you consider all the things you need to account for. It also gets you thinking, in the back of your mind, "How am I going to do that?"

Chargen Details
Anyway, the FUDGE sidebar covers the details of the skill system. Now let's look at Chargen. Back in the Requirements phase, I said that the player would need to set up "stats, background, and misc. data".

We've already talked about the stats, which we now know will include Skills and Attributes. Background is pretty self-explanatory. But what's this "misc. data"? Most of these came from the +finger use case. There are a bunch of fields in +finger that relate to a character's background and stuff. Chargen seemed like a logical place to set them. These fields include:

Full Name
Faction (civilian or military)
Home Colony
Ship
Position (Job)
Age
Rank
Callsign (for pilots)

There are also a few description-related fields I like to have. There's usually a command (like +profile) to view them, but mainly they just force you to think about your character a little. All of these can take data in any format you want. Since weight isn't used in any coded system, it doesn't matter whether you enter it as 160lbs or 40kg. You might do things differently if you actually had something coded for weight.

Height
Weight
Skin Color
Hair Color
Eye Color
Handedness (left/right/ambidex)

And last but not least - the MUSH basics:

Sex
Description

That's it for the details.

Interface

Now we need to consider how the player is going to interact with these systems. In a way, it's like we need to write the help files before we write the actual system.

Chargen Interface
For Chargen, most of the stuff will be set with a series of simple +commands. But we have to be careful not to bombard the player with too much information at once. For that reason, I like to break up Chargen into a series of rooms. Each room covers a different piece of Chargen.

I start by making a little map of Chargen:

Room 1: Overview + How to get help
Room 2: Physical Profile (height, weight, etc.)
Room 3: Demographics (all that +finger stuff)
Room 4: Skills and Attributes
Room 5: Background

Some games limit your travel, forcing you to sit in Chargen until you're approved. I prefer to let players roam around, so once they've submitted themselves for approval they can leave Chargen and return to the OOC area.

We don't want people going forward until they're done. The forward exits shouldn't let them through until they've set everything in the current room.

On the flip side, we do want people to be able to go back. If Jane gets all the way to the background room and realizes she set her age wrong, she needs to be able to go back and fix it. So we're going to have exits going backwards.

Within the Chargen rooms themselves, I envision a very simple set of +commands. +age sets your age, +rank sets your rank, etc. For skills and attributes, we could go with a direct-set command: +skill [skill]=[level] or raise/lower commands: +skill/raise [skill] and +skill/lower [skill]. The raise/lower commands are little easier to code, because you always know the value is changing by 1 level. It could be a nuisance to the player to have to do raise-raise-raise, but in FUDGE they normally won't be changing skills by more than a level or two. It should be OK.

What if someone wants a skill that's not on the list? Say they want to be an expert in Underwater Basketweaving. Without knowing what the actual skill list will be, it's hard to answer this question. It may just be a subskill of Art or something. So for now, I'm going to assume that there's a fixed list that they're stuck with, and picking something not on the list will be an error.

Considering Usability
I am mildly concerned about the length of the command +skill/raise. If the player is going to have to set a few dozen skills, it might be annoying to have to type that over and over again. But what are the alternatives?

I could abbreviate it: +sraise/+slower for skills and +araise/+alower for attributes. Shorter, but kinda clunky. It's not exactly intuitive.

Or I could split skills and attributes into different rooms, and have +raise/+lower commands in each room. That seems like a good idea.

But waitÉ what about experience points? We haven't really talked much about the XP system, but at some point players are going to need to improve their skills and attributes somehow.

I don't really like the idea of having separate rooms for "spend XP to improve attributes" and "spend XP to improve skills", so let's nix the separate rooms idea. In the end, I decide that +skill/raise isn't that bad.

Skills Interface
Now let's take a look at the interface for the skill system. In the last installment, we talked about our five use cases. I'll highlight them here again:

1. Player versus environment (Mary jumps across a chasm).
   
2. Player versus player (Mary punches Joe).
   
3. Staff versus player (NPC Guard shoots Joe. Poor Joe.).
   
4. Player versus staff (Joe's revenge: Joe shoots NPC Guard).
   
5. Indirect system usage (Mutter code uses perception score to determine eavesdropping).

If I were a player, how would I want to type this? For a simple roll, I just want:

If I want a modifier?

What if the difficulty level is something other than Fair? Well actually it doesn't really matter. You take that into account when you interpret the roll. If it spits out a rolled degree of Great, you figure out whether that's good enough for what you were trying to do.

I actually forgot a use case in my original requirements. What if NPC Guard is the one jumping across a chasm? We need to be able to specify his skill as a rating:

Putting all of this together, I get the following syntax (where modifier is optional):

That type of generic syntax may be a pain to code, but it's going to be a lot nicer for your players than a goofy set of +roll/attribute, +roll/skill, +roll/npc commands.

The output will be:

Now we need to consider the other use cases. Cases 2-4 are all variations of "opposed" skill checks. Much as I'd like to make the +roll system even more generic, there does come a point where it just becomes too complicated. So let's make this a separate command: +roll/opposed.

Standard opposed roll between two players:

What if Jane gets a bonus?

What if it's Jane versus an NPC?

Technically we don't need NPC Guard's name, but it makes the interface more consistent. Not only does this make it easier to code, it also makes it easier for the players to use.

Our syntax is similar to +roll:

The last use case is a special one. Here, nobody's typing anything. You've got one coded system talking to another coded system. The best way to do that is with a function. How about this one?

Hmm, won't work for NPCs. How about this instead?

That's pretty generic. It should work for all of our use cases. But now the combat system or table system is going to need to know how to extract a player's skill or attribute rating. We need another function:

Notice that all of these functions deal in plain numbers. That's because it's easier for the computer do deal with those. But eventually we're going to have to display something to the player, and they want to see a name. So we need another function:

This will work for both skill/attribute ratings and success levels, because they use the same rating scale. Just remember we need to account for ratings beyond +/- 3 (Superb+1, Superb+2, etc.)

Whew! That should about cover our interfaces. We're coming down the home stretch!

Data

It's important to decide where and how you're going to store your data. In particular, this is important when other systems need that data. For example: we talked about how the +finger system needs to get at the demographic data (rank, colony, etc.). Without knowing where that data is going to be stored, we can't code +finger.

There are two schools of thought on data storage: Minimize Attributes, or Minimize Complexity. If you're trying to minimize attributes, you may decide to store height/weight/age/etc. in a single attribute. For example:

Then, of course, you need functions to pick out the various pieces of data. On the other hand, if you're trying to minimize complexity, you'd give everything its own attribute:

It's easier to get the data, but you've got more attributes cluttering up your character. This normally won't be a problem unless you've got thousands of these things. Most servers have a pretty big attribute limit.

Skills and attributes are one case where you'll probably be better off storing things in the more complex fashion. I usually stick with a single SKILLS attribute and a single ATTRIBUTE attribute. The only thing to worry about here is whether your skill and attribute names have spaces in them. Think about these two examples:

Versus

In the second case, we needed to use pipes to separate the skills because we're allowing spaces in the names.

I tend to prefer space-separated lists. Most players can deal with slapping an underscore between Basket and Weaving, or smushing the names together like BasketWeaving. But it really doesn't matter, as long as you plan for it.

One other thing to note: Do you want the skill list to encompass ALL skills, even if the player doesn't have them, or just list the ones they have? Both ways have merit. It really depends on how many skills you have, and how you want your character sheet to be displayed. Also consider what happens if the character rolls a skill they don't have - does it default to 0, or do they get an error? In our system, you can't roll a skill you don't have, and the character sheet will only show the skills you do have. So our skills attribute will only store the ones you've got ratings in.

Objects

Last but not least, let's talk about objects. It's often been said that having extra attributes on objects in the master room is a cardinal sin - you should always have separate objects for commands and functions/data. I'm not sure that it matters anymore, in the days of gazillion-gigahertz processors, but it does help you to organize your code a little better. Your objects aren't as cluttered, and it's easier to find things.

So for the skill system, we're going to plan on two objects:

For chargen, I could put the code on the room itself, or on objects in the room. It really doesn't matter, but I prefer to put the code on objects in the room. So that will give us a few more objects:

Wait a secondÉ don't the skills and attribute commands for Chargen overlap with the Skills Commands for the skill system? In particular, what about experience point spending? Here's where I run into trouble. I haven't really done the use case for the XP system (bad Faraday!). Right now, I have two options: go back and do the use case for XP, or charge forward and hope I can reconcile the two systems later.

Deciding on the former, I go back and re-read FUDGE's rules on XP spending. I conclude that there's no way to make a single +skill/raise command that will work on both XP and Chargen. Also, it doesn't make any sense to allow +skill/lower once you're done with Chargen. So I convince myself that XP and Chargen really need to be treated separately.

But there still will be some overlap - both the XP and Chargen systems are going to need to modify skill ratings, check to make sure a skill is on the list, etc. Those common functions should go on the Skills Functions and Data object so they can be used in both places.

Now we've got a pretty coherent design, and we've answered a lot of questions about how the system is going to work. Next time, we'll put it all together and actually start coding.

Next section: Code