CriticalBotch Development

One of the challenges I find myself facing in developing my mud base is the question of character handling.

I'm not really looking at saving and loading, per se, but more of an overall grand architecture.

For example, I'm currently using a two-tier system of accounts and characters. Characters are tied to accounts, and accounts are tied to emails and passwords.

Pros: One stop shop for character management (a la BYOND's one key = multiple character set up on most BRPGs).
Centralized settings information.
Allows for account based achievements (unlocks, etc)

Cons: It's an extra step, and an extra level of complexity.
I'm not sure the above Pros are worth the extra headache.
People familiar with MU*s already could possibly be confused and turned off.

Currently, I favor the account system but that might change.

The other concern I have about an account based system is handling wizards/builders. I can go one of two ways: the account is a wizard account and the option exists to make a mortal character OR one character on the account is given the additional commands and access of a wizard; all other characters are mortals.

The former is convenient because I treat accounts very similarly to clients, and since I'm using Ebonshadow's MudBase suite as a foundation (ergo I'm using mb_Parser) such a system lends itself well. The downside is that the staff probably won't like having ALL their characters wizards unless they go through the hoops of specifying which ones aren't.

The latter is more traditional and it also allows more transparency in interactions between mortals and immortals. You don't have to wonder if [WIZ] Johnny is also [WIZ] Billy, who might also be [WIZ] Damien. [WIZ] Billy is [WIZ] Billy; any other characters that player might have are of no consequence in terms of this interaction.

I've dipped in and out of MudDev for a while, and let me tell ya; it's a ghost town :(

Which is a shame, because BYOND lends itself well to text based games. MU*s (Multi-User ) were the great granddaddy of online gaming and still have the potential of being some of the most creative game experiences out there.

Sadly, without the "bang, whiz, boom" of modern graphics, many new generations are simply passing MUDs by.

Alright, enough griping by an old man, on to the real reason of this post: Mud Development (the action, not the Guild).

Right now I'm working on building, from the ground up, a generic mud base. I'm borrowing a lot of the basic structure and core engine elements from Alathon's BMud set up. That is to say that I glance at how Alathon approached something and create my own interpretation. BMud looks great, but doesn't look like it'll be done any time soon :(

Ultimately I want this mud base to be robust enough to be usable for a variety of genres, from high fantasy to science fiction, and in-between. The actual MUD I want to make out of this will be based on the Traveller universe and I think there are many general elements of that universe that lend themselves to practically any project.

Traveller encompasses a large portion of a galaxy and is home to, depending on the time of the material, about 11,000 worlds, give or take. Naturally, that's a LOT to work with. I'm not foolish enough to be considering trying to tackle something like that. However, within this universe each world has a variety of metrics that help identify what the world is like. Things from the size of the world, it's atmosphere, hydrographics, population, tech level, etc. What I'm getting at is that if I build an engine that is scalable up to many worlds within the same universe, it will also handle just ONE world. Granted, there will be a lot of extra code not being used (space travel, trade routes, etc), but it would play out very easily on a micro scale while still being viable at the macro scale.

While taking a break from the RBS AI (they're like a child sometimes; trying, and occasionally talk back), I had a thought.

One of the things I like to see in games is an alternative to mindless grinding for experience to make your numbers go up. The whole game begins to revolve around grinding to get the experience to make the numbers higher to grind more experience to make the numbers higher to grind . . . you get the picture.

Anything that takes focus away from the grind and back to actual gameplay is a Good Thing™ to me.

One such system I've observed is used in EvE-Online (www.eve-online.com). It's a nice game if you enjoy space sims focused on fleet engagements, asteroid mining, and production. It's pretty cool game, and if you're interested, let me know and I'll shoot you a Wingman invite (free 14 days, +14 days to both of us if you stay).

In any event, their system is time based. They eliminate the variables of "hardcore" vs "causal" by making advancement take just as long regardless of online time.

A skill has a few different statistics:
a Primary attribute
a Secondary attribute
a Rank (difficulty)
a level (how high you've trained this skill)
SP (skill points, how many SP you've put in so far)
TSP (total skill points, how many SP are needed to the next level)

You generate a number of SP per minute equal to your Primary attribute plus 1/2 of your Secondary attribute. So, for example, if the skill's Primary was INTelligence and the Secondary was PERception, and you had INT at 5 and PER at 10, then you generate 10 SP a minute for that skill.

Now, a skill's TSP is based on the next level to be trained and it's rank. I'll save you the whole forumla but essentially it breaks down like this:

1. 250


2. 1,440


3. 8,000


4. 45,255


5. 256,000

The time invovled is simply the TSP divided by your SP per minute. In this case, level 1 (250 SP) will take 25 minutes (250/10). That's for a Rank 1 skill. The TSP is multiplied by the Rank, so higher ranks take longer to train.

They also keep adding skill points whether you're online or not.

The advantage to this system is that it levels the playing field for advancement. No longer do you fall drastically far behind your buddies because you have a job and a life outside of the game.

The downside is that there's also no point in putting in extended hours to "get that next level".

Logging in is encouraged by other means. Generating money (ISK, in EvE) is an active process, as is faction point gaining.

I've been thinking of bringing this kind of system to BYOND, but a little more straight forward and customizable.

Rather than use EvE's interesting but complex algorithm for determining sp/level, I will go with a more direct method.

There are three constant values, ExpBase, Exp, and ExpMod. The formula (at the moment), is ExpBase^(Level*Exp)*ExpMod, where Level is the current level of the skill being trained. As a default, the values of 2 (base), 1 (exp), and 100 (mod) will be used, resulting in a progression that looks like this:

1. 100


2. 200


3. 400


4. 800


5. 1,600

This provides a basic, exponential progression. Level 1, 2, and even 3 will be common, 4 will be uncommon, and 5 will be relatively rare.

You can tweak the curve by changing the Exp value. A base of 2, exp of 2, and mod of 100 would present the following progression:

1. 100


2. 400


3. 1,600


4. 6,400


5. 25,600

As you can see, the effect is minor at the lower levels, but much greater at higher levels. Decimal values are perfectly fine and likely required to get a proper progression for your game.

There's two parts to this, however. One is the progresssion, and remember that the above is for a Rank 1 skill. Ranks 2+ will increase those point totals. The points mean little without some measure of how difficult it is to achieve said numbers. That's the second part, generating the SP per minute of whoever/whatever has the skill. There will be defaults and hooks in the system to be overwritten, but ultimately you need to look at how long it takes to get from one level to the next. Too few SP per minute and people will get bored and frustrated. Too many and the first levels will be worthlessly easy to achieve. Finding a balance between SP per minute and the TSP for skills is vital and will have to be left up to the game developer.

The default will be a base of 2, an exp of 2, and a mod of 100. The default SP per minute will be 20, resulting in the following time line for skills levels:

1. 5 minutes


2. 20 minutes


3. 1 hour, 20 minutes


4. 5 hours, 20 minutes


5. 21 hours, 20 minutes

If you're looking for faster advancement, a standard tweak might be to change the default SP per minute to 100, which cuts training time by five. Level 1 takes a minute, level 5 takes 4 hours and 16 minutes.

I've been working on something that, if I work it correctly, could be a huge boon to rpgs and games in general.

If you've dabbled at all in game design outside of BYOND, you probably already know what the Rules Based System is (RBS, for short).

For those of you who haven't, here's a brief synopsis.

A RBS is made up of a knowledge base, a set of rules, and an inference engine.

Do what?

Ok, a knowledge base is simply a list of assertions, or things known about the environment. For example FIRE is HOT. This assertion tells the AI that fire is, indeed, hot. That's a fairly simple assertion and is the kind I am currently working with.

Rules tell our AI how to handle those assertions. They tend to work in simplified if->thens. For example, if x? is y? then do z?.

Rules do one of two things: add more assertions or fire of procedures. For an AI that doesn't like fire, a rule might look like IF x? is HOT then AVOID(x).

Nifty, no? Ok, moving on to the inference engine. This is the bad boy of the system. Up until now we've had, essentially, context free gramar. An inference engine goes through the knowledge base and decides what rules to fire based on the assertions in the knowledge base. I'm not completely done with the inference engine just yet, so I'll spare you details.

One nifty thing that you can do, just with the knowledge base, is deduction. What do I mean by deduction? Well, let's look at this example:

SPIKE is DOG
DOG is ANIMAL

Ok, that's a simple knowledge base, yes? Based on that, what can you deduce? Well, if SPIKE is a DOG, and DOGs are ANIMALs, then SPIKE is an ANIMAL, right?

Deduction goes through existing chunks of knowledge (called relationships) and performs matches along the lines of IF A = B and B = C then A = C. Rather, it pulls the third part of the relation (DOG from SPIKE is DOG), and then looks at the rest of the relations in the knowledge base and finds any whoes first part (SPIKE, from SPIKE is DOG) matches the third part already mentioned. In this case, the term DOG from SPIKE is DOG matches the term DOG from DOG is ANIMAL.

It then adds a relationship with the first relationship's first term (SPIKE), and the link and third term from the second relationship (is ANIMAL).

Now, our knowledgebase looks like this:

SPIKE is DOG
DOG is ANIMAL
SPIKE is ANIMAL


Nifty? Very.

Consider, for example, my test data:

FIRE creates LIGHT
FIRE creates HEAT
HEAT can KILL
LIGHT allows VISION
MORTAL desires HEAT
MORTAL desires LIGHT
MORTAL can DIE
HUMAN is MORTAL

Now we run the deduction. These relationships are added to the knowledge base:

FIRE can KILL
FIRE allows VISION
HUMANS desire HEAT
HUMANS desire LIGHT
HUMANS can DIE

Testing, testing. . . Hello World!