CriticalBotch Development

TravMUD and the Bartle Quotient

Sun, 06 Jul 2008 16:19:49 GMT

Anyone familiar with MUDs is probably familiar with the Bartle Quotient. The Bartle Quotient is a rating of 0-100% in each of four categories: Achiever, Explorer, Killer, Socializer.

Most people have a rating in all four categories but usually have one or two fairly high ones. What does the Bartle Quotient tell us about a player? It tells us what kind of activities the player will likely find enjoyable.

When building a game one should include content for all four categories.

Killers are the easiest to provide for: include meaningful combat and they're generally happy. That's a bit of an oversimplification but for our purposes it works.

Socializers generally want to build communities and friends; anything in the game designed to reinforce cooperation and people interacting with other people is a good thing to the Socializer.

Achievers like to see numbers go up. In most current games Achievers are the ones racking up the highest score, or getting the highest level fastest. Anything the Achiever can point to and say "look, I did this better than [x]!" is good.

Explorers enjoy, amazingly enough, exploring. Often this is literally expressed by going to places they don't know about and learning what they can. Sometimes it means learning more about the game itself and its systems.

Now that we have had a brief description of the four categories, let's explore how TravMUD will handle them.

First, Killers. TravMUD will include plenty of options for the combat oriented character. Combat will be fast paced and exciting. There will be some options for player vs player (PvP) but I am unsure exactly what level of PvP I wish to allow.

Next, Socializers. Within TravMUD players will be able to found Corporations. Usually these will be pure business ventures (a la Acme Mining Corp) but may have other purposes (John's Mercenaries, for example). These communities will be the primary resource of the socializer.

Third, Achievers. I plan to provide situations that will allow for unique (but not necessarily powerful) items to be born into the game. I may also include a list of achievements for each character (think Collections from Star Wars Galaxies) that can be viewed by others.

Last, Explorers. I won't lie to you; TravMUD is primarily designed with Explorers in mind. In the beginning there will be a limited number of known worlds (created by the builders). Beyond that, there will be randomly generated systems throughout the galaxy that people will have to discover, catalog, and so forth. One of the systems I am most looking forward to working on is the local fauna system. When a new world is generated so is a small list of creatures for that world. These will be very basic, randomly generated creatures based on the planet that was just generated. The first player to find a world may name it (within reason). Characters with the Animals skill of sufficient level may try to learn information about the local fauna, with the option (at a relatively high level of Animals) to upload the data to the Imperial DataNet - naming it in the process.

I think that TravMUD will appeal to explorers the most (as I said above), but I also feel that there will be plenty of content for the rest of the categories as well.

TravMUD

Sun, 06 Jul 2008 15:25:20 GMT

For anyone who is interested, TravMUD is coming along decently. It's very, very, very, very basic. Currently operational is the account and character system with some additional commands for debugging. I'm currently working on fleshing out the character generation system. Everything is in place it just needs to be linked up and fleshed out.

In any event, interested parties can check http://groups.google.com/group/travellermud-discuss. Anyone who wants to help is welcome; we can discuss the project's direction and end goals. Just hit me up on the pager or email me at dworkin.of.chaos@gmail.com. Experience with MUDs is a plus but not necessary.

Right now I primarily need people interested in development and design. Once I get a real working shell going with some test content I'll need playtesters as well.

Character Handling

Fri, 27 Jun 2008 18:06:17 GMT

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.

MUDs MUDs, who's got the MUDs?

Fri, 27 Jun 2008 17:53:23 GMT

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.

Alternative Advancment

Tue, 22 Apr 2008 07:54:14 GMT

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,440

8,000

45,255

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,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,600

6,400

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:

5 minutes

20 minutes

1 hour, 20 minutes

5 hours, 20 minutes

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.

AI - Rules Based Systems

Fri, 18 Apr 2008 15:28:33 GMT

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

Fri, 18 Apr 2008 06:16:49 GMT

Testing, testing. . . Hello World!