RubyMUD

RubyMUD is the temporary WIP title for the second attempt at a MUD for the TGChan audience, established using the same basic platform as the original (CoffeeMUD), intended to be a longer-lasting project with a broader appeal. The main goal of this project is to provide an online game that allows for creative and emergent gameplay in a cooperative or lightheartedly competitive setting with a reliable underlying ruleset, and broad appeal for potential players.

Team

The current team of Archons (administrators) is

(this area intentionally left blank while archons are still being assigned)

Setting, Theme, and Focus

Setting

The setting of RubyMUD is your traditional medieval fantasy dungeon, a sprawling underground complex of both natural and constructed areas filled with all manner of monsters and demihuman beasts, scattered with traps and gold-bearing treasure chests. The difference is that in RubyMUD, the players control the monsters, not the adventurers. More sapient monsters like Goblins and Ogres will be playable, while animals and more bestial monsters like slimes will still serve a function as standard enemies and huntable resources. The layout of the dungeon, then, starts with a central 'safe' area in which the denizens can make their home. This will include living quarters (still looking into the possibility of individual player housing), a mess hall, and a few other common areas. Beyond this will be some relatively safe wilds, your standard newbie areas and places to fish or prospect, and the farther out you go, the deeper you will delve into dangerous zones and threatening territory.

Theme

The theme of the MUD, then, is that of several low-down dungeon dwellers trying to make a name for themselves, toughen up, and of course, hoard as much as they can. Infighting will probably be common. Though there's certainly no rule dictating what kind of attitude your character have, the general atmosphere will be slightly lawless, and comraderie will be mixed with a healthy dose of competition. In between hunts and treasure runs, the dungeon denizens will no doubt fight and steal amongst themselves, and the more mischievous races can be expected to play lots of tricks on their fellow underdwellers, while attempting to avoid retaliation from the less tricky, more brutish members. This kind of infighting and mischief is wholly encouraged.

Focus

The atmosphere RubyMUD hopes to create is an open, highly-social one that provides a lot of fun and allows for a lot of creativity without too much burden. Rather than just simple hack-and-slash abilities and combat, there are a lot of other things planned, including crafting, animal taming, unique skills and abilities, and so on. To this end we plan to implement a lot of spells, abilities and skills from the standard CoffeeMUD that allow for creative player action and emergent gameplay. Random examples include trapmaking, butchery (including of PCs), tattooing, manipulative spells, and so on. The line of thought here is that the more creative ways to play, the longer people can enjoy it, and the more breadth of gameplay there will be beyond simply hacking up MOBs. However, while we want the players to be able to get creative both in their handling of MOBs/NPCs and PCs, we don't want penalties that are too harsh or too many opportunities for overly-malicious griefing. The initial plan for this is that while PKing will be largely open (to encourage tricks on other players and the possibility for retribution for those tricks), the penalty for dying will be very minimal. Generally speaking we don't want to punish players too much for getting into character as devious bastards. To this end we are also implementing a few 'safe' zones at the very center of the dungeon with no PKing possible, and a guard force (not invincible) in some surrounding areas. Therefore even certain areas in the home base won't necessarily be "no PK", in order to allow for some mischief. But the guard force will discourage it, or at least encourage players to be sneaky about it. On the whole we want a fun and accessible atmosphere where you can mess with other players, but one in which being messed with by others won't instantly make you want to quit the MUD forever.

General Tenets of Construction

This section will cover the basic foundation of how the MUD should be approached by the Archons/Builders in order to form a coherent and cohesive product with as few balance issues as we can manage.

Plan First

See the Planning section below. It's important that everything added be first planned out and agreed upon before being thrown in. If every Archon were to simply build out from center, nothing would have any cohesion. At a thematic level, none of the areas would blend into each other, and there would be a complete disjoint in the descriptions and themes. On a technical level, you could get even simple things like arrows built by two separate Archons that are incompatible with the other's bows, simply because they were constructed without reference to each other. A total disjoint like this, obviously, should be avoided. To that end, everything from maps and NPCs to races and skills should be planned before being instituted. The planning section below should be used and edited to this end.

Don't Reinvent the Wheel

This is HUGELY important to the overarching design: CoffeeMUD provides a whole lot of content and template material. This has all been balanced to work with itself. Everything we touch will have to be rebalanced to fit with the existing formulas and resources, or we'll be faced with two basic pools: the stuff balanced for our MUD, and the stuff balanced for CoffeeMUD. Obviously these things will not play well together if they are set to different standards. Even if they're not, every rebalance will take a lot of work to get just right. Therefore, the basic idea here is "if it isn't broken, don't fix it." We want to use the provided resources as much as we possibly can, rather than just reinventing them for the sake of reinventing them. If you create a new race, base it on one of the premade races as a template. Use that as a standard. If you want to make a new monster, find an existing monster that's roughly the level/challenge you want your new one to be and use it as an example to build off of. If you want to make a playable kobold, DON'T base it off the existing Kobolds (because they're fodder enemies!). Instead, base it off of one of the playable races, ideally one of the quicker, weaker ones, and try to keep it close to that standard. You can even just take existing monsters and retool their fluff, change their names and descriptions and behaviors, but keep their basic stats and abilities, or build off of them as templates. We have a lot of material already provided to us, and while we do want to put our own unique touch to this game, making everything from scratch will not only take a lot of time, but provide so many countless balance issues that we'll spend more time fixing numbers than actually working on existing problems. We'll just be making new ones for ourselves to solve.

Now obviously some things are necessary for this. We'll need to make new races, we'll need to reorganize and rebalance and redistribute the skills, abilities, and so on for them. But hopefully this will be our biggest -- and one of our ONLY -- such overhaul projects. CoffeeMUD already provides dragons, dust storms, lightning bolts, crafting recipes, and on and on. Bottom line: Whenever possible, use the provided, pre-balanced material, or build your new material off of it. This will help to keep the game's balance and prevent gamebreaking items, classes, monsters, etc. It also means less work we'll be creating for ourselves.

Corollary: We're Still Building Our Own Wagon

To elaborate on this awkward metaphor, there is still plenty of tweaking and customization we will want to do that will be more necessary. In particular there are plenty of classes, spells, skills, and abilities we will probably want to take out. We're not just going to leave in every premade class and just call it a day. In part because many aren't thematically appropriate, and in part because many of them use things that just won't be functional in a dungeon environment. We expect to have some open-air areas (and equivalent, e.g. mist-filled waterfall caverns to substitute for rain, which has a function), so it's not as though all weather spells have to be taken out, for instance. But there are many areas of focus that will simply need to be trimmed or hacked out entirely.

Keep the Focus

Always remember that this game has a number of areas of focus that should be kept in mind at all times. It should be fun without breaking the rule system. It should allow player interaction but maintain a functionality beneath the socialization. It should allow trickery and even cutthroat behavior without completely destroying a character's progress and encouraging griefing. It should allow for emergent gameplay via abilities and skills without having to give players adminlike wizard powers. There needs to be a balance, but the focus should always be on freedom, fun, and a variety of ways to interact with the environment and other players. All this really means is we shouldn't institute features or areas or items that completely break any of these things, by means of, say, having a player get all their limbs chopped off by a single unlucky round of combat. Dismemberment can be fun. If it's too common, and if it's too easy to get permanently crippled, and if it's too difficult to get severed limbs reattached, then you'll end up with a lot of unhappy, limbless dungeon inhabitants hoping an Archon will come by and restore them to health before they hurl themselves off a cliff for the respawn.

Room Density

Room Density refers to the number of rooms per area, each area defined as having a different basic focus. Therefore the starting sort of 'safe' locale might be one area, a ferocious gnoll den might be another area, slime-infested crystal caves could be another, and so on. Think of each 'area' in the MUD as a traditional 'zone' in a 3D MMORPG.

• For social areas, room density should be very low. You want very few individual rooms in a social area, like the home base. This way you will draw a lot of the players together. Having too many rooms in a social area would mean too thin a distribution of players and they wouldn't run into each other much, and when they do, you won't have other players nearby as witnesses/spectators to whatever goes down. What fun is a social area if it seems empty and desolate?
• For combat areas, however, room density should be very high. Area construction and overall mapping should certainly allow more common paths through, so that you won't get totally lost, so that you can find your way around, and so that you can run into other players. But you'll want lots of different rooms in potential hunting and fighting zones, because unlike a traditional 3D MMORPG, each room essentially functions as its own encounter. In, say, World of Warcraft you could have a zone filled with monsters scattered about, and players could walk up to a group of monsters to start the encounter. But in a MUD, because there is very limited spacial accounting, if you enter a room that has monsters in it, it will be assumed that all those monsters are now within attack range for you. This means that if you were to fill a room with as many monsters as you'd find in a WoW zone, everyone and everything entering would be ripped to pieces in about half a second. Therefore just remember that every dangerous area should be broken up into many rooms with generally low numbers of monsters each, because each group has to be fought at once. So while a social zone should have only a few rooms to encourage everyone sees a lot of each other, dangerous areas should have lots and lots of rooms filled with monsters and treasure so you can fight your way through effectively. This doesn't necessarily mean these areas will be spatially "larger", because the rooms themselves may be described as much smaller. It just means it will be more compartmentalized.

Content Planning

In this section Archons (and players) can discuss and suggest focus for areas of the game and its gameplay.

Map and Areas

This will be for tentative planning maps, designed to give a basic overview of how the dungeon's layout should unfold. More detailed maps can also be added later. Areas can be discussed and suggested here as well, before actually being added to maps (in case you can't decide quite where to put them, or just have a general idea you'd like to suggest that can be worked into functionality later). Remember that nothing should actually be mapped into the game itself until it has reached a general consensus.

Races

This is for planning and suggestions on playable races. To begin, during the early testing phases, we should try to keep the number of playable races as low as possible. Every added race will bring with it a lot of work in terms of balancing and structuring, so even later on this should be capped at a reasonable level. There's no reason, for example, to have more races than players, or to add in races that don't make sense, or to add in races that are thematically appropriate but nobody is going to actually want to play. Non-traditional races that were invented by various Quests CAN be considered, but generally speaking, it should be a race that is appropriate to the game's dungeon setting. Voltos, for instance, would make no sense (and nobody would really want to play them either when they're basically just visually-different humans). Basic human nature suggests that many people are going to want to suggest races from their own quests, but the game's limitations also mean that most of them won't end up being added. Races that are appropriate and have popular support are much more likely to be added. The three starting 'test phase' races are:

• Kobold
• Goblin
• Ogre

This also rounds out the Fighter/Mage/Thief template of large brawny guys, small sneaky guys, and middle-sized smart guys, and so allows for broader balance testing. Unlike the default CoffeeMUD races will probably have a bit more in the way of distinctions beyond just stat differences, but we should be careful not to go overboard with turning the race's fluff into function. Allowing Nedynvor to fly, for instance, would give them a huge advantage in many ways right off the bat and would wreak havoc with game balance -- not to mention Nedynvor can't actually fly!

Classes

This is for planning and suggestions of character classes. Largely undiscussed as of yet. Assumedly, many will be based off of existing classes. However the list of classes will be cut severely down from the default, and many will be integrated, merged, or redistributed.

Feature Planning

In addition to filling the world with places to go and people to see, there are numerous decisions on rules and functions we'll want to hammer out. You can do that here. This area will also be used for outlining major decision on fundamental tenets of the gameplay, like how death is handled.

Law and Guards

Lawfulness doesn't exist very widely in the dungeon, but some guards will protect the monsters at the center in a verisimilitude of order. No guards in the game will be invincible. Under the law system, certain classes may be able to take the law into their own hands, including bounty hunter-like classes who can apprehend and turn in wanted characters and players. At an extreme level (one we're likely to see in a dungeon) these jailer-classes can also administer some punishment, ranging from beatings and torture to surgical amputation and chigury. The Law system may also allows for foreign powers. For instance, a clan of renegade gnolls could live on an uneasy truce with the player groups out in their own area of the cavern, but their own distinct system of guards and the like would be sent after you if you break the laws of THEIR society. The guards here can be even weaker, giving the player encouragement to fight them off or escape them, rather than just instantly dying/being arrested. Further, areas like this (with guards and enforcement) can actually be captured by clans (guilds) of players and made to serve under them. You could, for instance, control a small den of kobolds and have their forces at your disposal in that territory. Whether or not these will be implemented of course is a decision yet to be made, and even then such an implementation would be a long way off. This is little more than development bloat at the moment.

Vote: Player Killing

The PLAYERKILL describes how/whether players may kill each other. The default is OPTIONAL-4, but valid values include:

• ALWAYS Players may kill each other at will.
• ALWAYS-X Players may kill each other at will, but only if they are within X levels of each other.
• OPTIONAL Players must both have their PKILL option turned on in order to kill each other.
• OPTIONAL-X Players must both have their PKILL option turned on in order to kill each other, but must also be within X levels of each other.
• ONEWAY Same as OPTIONAL, but player can never turn PKILL off.
• ONEWAY-X Same as OPTIONAL-X, but player can never turn PKILL off.
• NEVER Players may never kill each other.

Vote: Player Death and Penalties

The PLAYERDEATH describes what happens to a player when they die. Multiple entries may be included, and are separated by commas. The default is EXPERIENCE, but valid values include:

• PURGE The player is erased from the system. THIS IS PERMADEATH.
• UNLEVEL X The player loses X levels of experience.
• LOSESKILL The player loses a random skill
• ASTRAL The player becomes an astral spirit. Normally resurrected by a resurrection spell cast by a PC or NPC.
• ASTRAL_RES As ASTRAL, but player can self-resurrect.
• EXPERIENCE The player loses 100 experience points per level
• OUT X The player goes safely unconscious for x ticks
• RECALL The player simply recalls to their death room (no body)
• (a number) The player loses a flat X experience points when they die.
• (expression) The players lost experience is calculated based on the give math expression, using + - * / (), and using @x1 to stand for the players level, and @x2 the killers level

Vote: Punishment for Fleeing Battle

The options here are actually exactly the same as above, for Player Death, and are incurred whenever you run from combat. The default is NO PENALTY.

Vote: Playerbody Looting

The CORPSEGUARD string is used to determine who may loot the corpses of dead players. The default is ALL. Other options are:

• ALL to allow anyone to loot player bodies
• SELFONLY will only allow the players to loot their own corpses
• PKONLY flag will allow the players, or other players with the playerkill flag turned on to loot.

Vote: Injury and Limb Severing

INJURYSYSTEM controls various variables dealing with limb injury, bleeding, and amputation (limb severing through combat, not the surgical kind). Each variable is separated by a comma, and does not include the % character, even though the first four values are percentages.

• The first variable is a % chance per hit of a limb being affected.
• The second is a % of hit points threshold before limbs start being affected.
• The third is % of hit points which must be done in a single blow to remove a limb before the limb is destroyed normally.
• The fourth is a % chance a limb is removed when it has been damaged 100%
• The fifth is multiplier that increases actual % limb damage done per hit. or has received a massive damage attack defined by the third variable.
• The sixth value is the MINIMUM player level that can lose limbs.
• The seventh value is the MINIMUM player level that can start bleeding
• The eighth value is the % of hp lost by a player in one blow to start bleeding.
• The ninth value is the % chance, on losing a limb, of bleeding.

The default value is 100,40,10,100,4,10,15,20,100.

Vote: Show Damage

SHOWDAMAGE toggles whether players will see the damage dealt to foes.

• YES Show damage in numbers, as well as words
• NO Only show words

Vote: Class System

The CLASSSYSTEM describes how/whether multi classing works. The default is 'SUB', but valid values include:

• SUB For subClassing, which only allows levels to be taken if the new class is also a subclass of the primary class.
• NO Disables all multi-classing, allowing users to pick from any of the player-selectable classes, but not to change.
• MULTI Allows the player to select from any of the user-selectable classes, and then to take levels in any other class at will.
• DISABLED Disables the class system algether. This is the same as including CLASSES in the DISABLE flag.

Special thanks to The Littlest Emo for setting up and hosting the MUD and helping out all the Archons to get their bearings and a basic understanding of the system they're all blindly hacking away at.