RubyMUD

RubyMUD was 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 was 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. Unfortunately, support and players appear to have withered and died.

Team

The team of Archons (administrators) was

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

Setting, Theme, and Focus

Setting

The setting of RubyMUD was 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 was that in RubyMUD, the players were to control the monsters, not the adventurers. More sapient monsters like Goblins and Ogres would be playable, while animals and more bestial monsters like slimes would 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 would include living quarters (still looking into the possibility of individual player housing), a mess hall, and a few other common areas. Beyond this would be some relatively safe wilds, your standard newbie areas and places to fish or prospect, and the farther out you go, the deeper you would delve into dangerous zones and threatening territory.

Theme

The theme of the MUD, then, was 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 would have probably been common. Though there was certainly no rule dictating what kind of attitude your character have, the general atmosphere was to be slightly lawless, and camaraderie would be mixed with a healthy dose of competition. In between hunts and treasure runs, the dungeon denizens were to no doubt fight and steal amongst themselves, and the more mischievous races could have been 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 was to be wholly encouraged.

Focus

The atmosphere RubyMUD hoped to create was 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 were a lot of other things planned, including crafting, animal taming, unique skills and abilities, and so on. To this end we planned 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 was that the more creative ways to play, the longer people can enjoy it, and the more breadth of gameplay there would have been beyond simply hacking up MOBs. However, while we wanted the players to be able to get creative both in their handling of MOBs/NPCs and PCs, we didn't want penalties that are too harsh or too many opportunities for overly-malicious griefing. The initial plan for this was that while PKing was to be largely open (to encourage tricks on other players and the possibility for retribution for those tricks), the penalty for dying would have been very minimal. Generally speaking we didn't want to punish players too much for getting into character as devious bastards. To this end we were going to implement 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 wouldn't necessarily have been "no PK", in order to allow for some mischief. But the guard force would have discouraged it, or at least encouraged players to be sneaky about it. On the whole we wanted a fun and accessible atmosphere where you can mess with other players, but one in which being messed with by others wouldn't instantly make you want to quit the MUD forever.

General Tenets of Construction

This section covered the basic foundation of how the MUD should have been approached by the Archons/Builders in order to form a coherent and cohesive product with as few balance issues as we could have managed.

Plan First

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

Don't Reinvent the Wheel

This was 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 would have to have been rebalanced to fit with the existing formulas and resources, or we would have been faced with two basic pools: the stuff balanced for our MUD, and the stuff balanced for CoffeeMUD. Obviously these things would not have played well together if they were set to different standards. Even if they weren't, every rebalance would have taken a lot of work to get just right. Therefore, the basic idea here was "if it isn't broken, don't fix it." We wanted to use the provided resources as much as we possibly can, rather than just reinventing them for the sake of reinventing them. If you created a new race, you should have based it on one of the premade races as a template. Use that as a standard. If you wanted to make a new monster, you should have found an existing monster that's roughly the level/challenge you wanted your new one to be and used it as an example to build off of. If you wanted to make a playable kobold, you SHOULDN'T have based it off the existing Kobolds (because they're fodder enemies!). Instead, you should have based it off of one of the playable races, ideally one of the quicker, weaker ones, and tried to keep it close to that standard. You could have even just taken existing monsters and retooled their fluff, changed their names and descriptions and behaviors, but kept their basic stats and abilities, or built off of them as templates. We had a lot of material already provided to us, and while we didn't want to put our own unique touch to this game, making everything from scratch would have not only take a lot of time, but provide so many countless balance issues that we'd have spent more time fixing numbers than actually working on existing problems. We would have just been making new ones for ourselves to solve.

Now obviously some things were necessary for this. We needed to make new races, we needed to reorganize and rebalance and redistribute the skills, abilities, and so on for them. But hopefully this would have been our biggest -- and one of our ONLY -- such overhaul projects. CoffeeMUD already provided dragons, dust storms, lightning bolts, crafting recipes, and on and on. Bottom line: Whenever possible, you should have used the provided, pre-balanced material, or built your new material off of it. This would have helped to keep the game's balance and prevent gamebreaking items, classes, monsters, etc. It also meant less work we would have been creating for ourselves.

Corollary: We Were Still Building Our Own Wagon

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

Keep the Focus

You should have always remembered that this game had a number of areas of focus that should have been kept in mind at all times. It should have been fun without breaking the rule system. It should have allowed player interaction but maintained a functionality beneath the socialization. It should have allowed trickery and even cutthroat behavior without completely destroying a character's progress and encouraging griefing. It should have allowed for emergent gameplay via abilities and skills without having to give players adminlike wizard powers. There needed to be a balance, but the focus should always have been on freedom, fun, and a variety of ways to interact with the environment and other players. All this really meant was we shouldn't institute features or areas or items that completely broke 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 was too common, and if it was too easy to get permanently crippled, and if it was too difficult to get severed limbs reattached, then you would have ended up with a lot of unhappy, limbless dungeon inhabitants hoping an Archon would come by and restore them to health before they hurled themselves off a cliff for the respawn.

Room Density

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

For social areas, room density should have been very low. You wanted very few individual rooms in a social area, like the home base. This way you would have drawn a lot of the players together. Having too many rooms in a social area would have meant too thin a distribution of players and they wouldn't have run into each other much, and when they did, you wouldn't have other players nearby as witnesses/spectators to whatever goes down. What fun would a social area have been if it seemed empty and desolate?
For combat areas, however, room density should have been very high. Area construction and overall mapping should certainly have allowed more common paths through, so that you wouldn't get totally lost, so that you could have found your way around, and so that you could have run into other players. But you would have wanted lots of different rooms in potential hunting and fighting zones, because unlike a traditional 3D MMORPG, each room essentially would have functioned 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 was very limited spacial accounting, if you entered a room that had monsters in it, it would have been assumed that all those monsters are now within attack range for you. This meant that if you were to have filled a room with as many monsters as you'd find in a WoW zone, everyone and everything entering would have been ripped to pieces in about half a second. Therefore you should have just remembered that every dangerous area should have been broken up into many rooms with generally low numbers of monsters each, because each group had to be fought at once. So while a social zone should have had only a few rooms to encourage everyone saw a lot of each other, dangerous areas should have had lots and lots of rooms filled with monsters and treasure so you could have fought your way through effectively. This didn't necessarily mean these areas would have been spatially "larger", because the rooms themselves may have been described as much smaller. It just meant it would have been more compartmentalized.

Content Planning

In this section Archons (and players) discussed and suggested focus for areas of the game and its gameplay.

Map and Areas

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

Races

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

Kobold
Goblin
Ogre

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

Classes

This was for planning and suggestions of character classes. Largely undiscussed as of then. Assumedly, many would have been based off of existing classes. However the list of classes was to have been cut severely down from the default, and many were to have been 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 wanted to hammer out. You could have done that here. This area was also used for outlining major decision on fundamental tenets of the gameplay, like how death is handled.

Law and Guards

Lawfulness didn't exist very widely in the dungeon, but some guards were to protect the monsters at the center in a verisimilitude of order. No guards in the game would have been invincible. Under the law system, certain classes may have been able to take the law into their own hands, including bounty hunter-like classes who could have apprehended and turned in wanted characters and players. At an extreme level (one we were likely to see in a dungeon) these jailer-classes could have also administered some punishment, ranging from beatings and torture to surgical amputation and chigury. The Law system may have also allowed for foreign powers. For instance, a clan of renegade gnolls could have lived 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 have been sent after you if you broke the laws of THEIR society. The guards here could have been even weaker, giving the player encouragement to have fought them off or escaped them, rather than just instantly dying/being arrested. Further, areas like this (with guards and enforcement) could have actually been captured by clans (guilds) of players and made to serve under them. You could have, for instance, controlled a small den of kobolds and had their forces at your disposal in that territory. Whether or not these would have been implemented of course is a decision yet to be made, and even then such an implementation would have been a long way off. This was little more than development bloat at the time.

Vote: Player Killing

The PLAYERKILL described how/whether players may kill each other. The default was OPTIONAL-4, but valid values included:

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 described what happens to a player when they die. Multiple entries may be included, and were separated by commas. The default was EXPERIENCE, but valid values included:

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 were actually exactly the same as above, for Player Death, and were incurred whenever you ran from combat. The default was NO PENALTY.

Vote: Playerbody Looting

The CORPSEGUARD string was used to determine who may have looted the corpses of dead players. The default was ALL. Other options were:

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 controlled various variables dealing with limb injury, bleeding, and amputation (limb severing through combat, not the surgical kind). Each variable was separated by a comma, and did not include the % character, even though the first four values were 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 toggled whether players would see the damage dealt to foes.

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

Vote: Class System

The CLASSSYSTEM described how/whether multi classing works. The default was 'SUB', but valid values included:

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 were all blindly hacking away at.

Quests by Weaver

4chan's /tg/: RubyQuest | JohnQuest | Mushroom Forest | WeaverQuest

Other notable creations: Orb of Infinite Psyche | Voltos | World Eater thread

Collab creations with TLE: Quest Fanfiction Generator | RubyMUD

Quests by The Littlest Emo

TGchan: Dong Quest | Hawksbury | NuLife | Designer Dong® | ByteQuest

Other notable creations: Metal Glen : The Flock Who Could Not Work Together | Space Station 13 Server

Collab creations with Weaver: Quest Fanfiction Generator | RubyMUD