Large-Scale System Design

by Linda Naughton ("Faraday")

Part I - Requirements

Getting Started

So, I'm staring at my SimpleMU window, looking at a staff job entry that says simply, "Implement Skills System". How the heck do I get started?

Taking a page from the software development textbooks, most folks seem to agree that the general process is:

• Requirements - What does the thing do?
  
• Design - How are we going to do it?
  
• Code - Do it.
  
• Test - Did we do it right?

Let's see what happens when we try to apply this process to softcode.

Requirements

First things first: What do we mean when we say a "Skills System"? We're talking about more than just a +check command that rolls some dice, right? Really what we mean is "Character Generation + Skills". After all, a character needs to get some skills before they can use them.

But even that's not good enough. A skills system usually doesn't stand alone. Other systems are going to use skills:

• Combat
  
• Space
  
• Language
  
• Economy (if haggling is coded somehow, or a coded gambling game)
  
• Mutter or Table Talk (if it hooks into perception scores)
  

Chargen opens up a whole other group of related systems:

• Request/Approval System
  
• +finger (shows some fields that might be set in chargen)
  
• +who (ditto)
  
• Census List
  
• Experience Points

The lists of related systems on your game will vary, but the bottom line is that the skills system has its hooks into a lot of different things. So it's important to consider the global view of how the system works with everything else.

Keeping all of these systems in the back of our mind, let's make a list of what the skills system has to do. In other words, the requirements or feature set. The list probably won't be 100% complete, but that's ok. We still need a place to start, and we can always add to it later.

Use Cases

One way to define a feature set is by considering "use cases". Who's going to use the system, and how are they going to use it?

Let's look at chargen first. Imagine a player brand new to the game. How are they going to make a character: from the moment they first log in until the moment they hit the IC grid, approved and ready to play?

Here's the use case for BSP:

1. Player creates a character from login screen.
   
2. Player enters chargen.
   
3. Player sets up stats, background and misc. data.
   
4. Player submits char for approval.
   
5. Staff reviews char.
   
6. Staff approves char or Staff rejects char.
   
7. If approved: Player enters RP.
   
8. If rejected: Player re-enters chargen, fixes whatever's broken, and the cycle begins again.

The use case for your game may be very different from this. Enforcing email registration or pre-approving character concepts before chargen puts a radically different spin on the whole flow. That's why it's important to figure out your use cases ahead of time.

Also, technically the use case doesn't end there. What does the player do once he hits the grid? How does he get a job? How does he get housing? How does his new boss/coworkers know that he's arrived? These are important questions to answer, but they're a bit beyond a skills/chargen so I'm not going to cover them here.

Now we need to think about the skills piece. How's that going to be used? I can think of a few cases:

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).

The other systems (Combat, Space, etc.) will have use cases also. These use cases will drive things that the skills system needs to do. For example: if you have a coded combat system, chances are you'll want to display a character's health/damage on their character sheet. This needs to be taken into account when designing the character sheet code.

Cost of Defects

By now you may be thinking: Geez, that's a lot of use cases! It'll take me forever to write all those down! Screw that - I just want to code!

An experienced coder might be able to get away with that. They'll often design things well enough that when they run into a problem ("Oh crap! I forgot about the mutter code!") they can adapt. They also instinctively know, in the back of their mind, various things they need to take into account. But if you're a relative novice, a problem like that could de-rail your entire system, causing days or weeks of re-work. Even an experienced coder is likely to introduce some bugs as they jam square pegs into round holes.

Various studies in the software industry (here's one) have shown that the cost of a defect (i.e. the amount of time and effort it takes you to fix it) goes up exponentially the further along you are in a project. The sooner you can find problems, the better off you'll be. It's a heck of a lot easier to change one line of text in a use case than to re-design a half-dozen coded commands because you forgot something.

Which brings me to another point... peer review. It's always a good idea to get someone else to look over your stuff. They will often catch something boneheaded that you missed. Examining MUSH code can be a nightmare, so I'm not sure I would inflict that on anyone. But you can certainly send out your use cases for other staff members to review. They might even form the basis of some of your help files.

So the moral of the story is this: Planning up front takes time, but believe me, it's time well spent. If you can save yourself 2 days of pain and suffering by spending 2 hours of up-front planning - wouldn't it be worth it?

Next section: Design