Patreon Post: Gods and Magicians

This article originally appeared in the now-defunct online magazine Imaginary Realities. It talks about MUD administration, and draws on my experience working with Armageddon MUD, the world of Zalanthas. For those who don’t know what a MUD is, it’s a text-based roleplaying game. Here’s the wikipedia article on MUDs.

One of the sad truths of the mud world is that there are never enough coders. Builders aplenty, brimming with fresh idealism and plans for entire zones, appear (and sometimes disappear) at the drop of a hat. But coders are the unicorns of the mudding world, seldom glimpsed and ardently pursued. We are lucky enough to have three dedicated coders on Armageddon MUD: Morgenes, Tenebrius and Tiernan, as well as a few other staff members willing and able to wade through the bugs file and tinker with things upon occasion. How, then, does an administrator keep these rare beasts happy? The following four steps may help.

1) Communicate: When asking for new code, try to let the coders know exactly what is desired. For example, instead of ‘Let’s make archery more complicated,” a staff member might propose “Let’s put a range on archery, so the farther away the target is, the harder it is to shoot it.” A full description of the the idea, perhaps including examples, such as fake logs showing what the idea will look like when being used, helps make sure the originator of the idea and the coder are on the same track as far as things like syntax and usage are concerned.

The same holds true for bugs. Describing how it’s supposed to work as well to how it’s working right now helps clarify ideas. Coders want to know if the bug is REALLY a bug, or something being reported because it doesn’t work as the reporter feels it should.

With bugs, give the coders as much information as possible, including how to reproduce the bug. Examples by way of logs are great, and if they include some form of error message (or message that they’re getting that shows it’s an error), it often allows the coder to track down what section of the code needs to be worked on.

Make sure people aren’t bumping into each other. On Armageddon, we’ve got a coder’s board, where people post changes as they make them. This alerts fellow team members to what they’re doing and is also helpful if unexpected bugs crop up, enabling people to track exactly what got changed and when. Two people should not be working on the same idea at once unless they know it, and can divvy up the work accordingly.

2) Have a purpose: Will it get used? Is it something players are asking for? This one is a matter of ego, but we’re all human and we all do have egos. Seeing their work getting used, regularly and as envisioned, is a reward beyond any thanks or congratulations other staff members can give a coder. Track player requests, through entries in the bugs/ideas/typos files as well as emails to the account and posts on the general discussion board in order to convince a coder that the players want, and will use, something.

Generally, with new ideas figure out how they are moving towards some goal. A piece of code like a new skill is going to sound more interesting if it fits into some overall purpose, such as a master plan of non-combat related skills for the economy than it would if it is just a random idea. You are also going to end up getting more out of the idea if it is part of a greater whole.

Make it innovative. Some coders like to be trail breakers, to feel that they’re not just playing catch-up with another mud, but are creating ideas and concepts new to the mud community. Some ideas get requested to ‘balance’ things out between groups: guilds, or races, or mount speed. When a coder starts to feel like the code they’re doing that day only works to nullify a change made last week, then they’re going to start wondering what they will be asked to implement tomorrow.

3) Share the work: Do as much of the grunt work as you can for the coders, including helping thoroughly test, providing help files and documentation, and fleshing things out. In testing, give coders information about what is not working and how to recreate the result. Be precise about what needs to be changed: not ‘the plague of locusts spell needs to do more damage’, but ‘it needs to do about twice the damage it is now.’ When something requires a new help file or modification of an existing help file, do not expect the coder to do it, but supply it yourself. If it is something that requires building, provide the items. Teamwork of this kind, when it is working well, is terrific, and will often produce amazingly cool results.

4) Appreciate: Good coders can never be praised sufficiently. We try to make sure that players know who is responsible for new and interesting changes, by posting information about them in the news as well as in our weekly update, which is a mailing our players can subscribe to, which provides information about changes, staff and world news, upcoming recommended playing times, etc. When players write in with compliments or feedback on a code change, make sure that the note gets passed along to the person , as well as that the coder knows how cool or slick you think the ideas they have implemented are as well.

There is a tendency sometimes to regard coders as resources that spit out code at request. But the fact of the matter is that treating coders in that way will frustrate both sides, leading coders to become discouraged and unmotivated to implement new ideas and builders to feel that their coding needs are not being met. These four points may help avoid such frustration.

This article originally appeared in the April 2001 issue of Imaginary Realities.
© 2002 Cat Rambo. All rights reserved.

This essay originally appeared in the February 2001 issue of Imaginary Realities. The crafting system in Armageddon is something we worked towards for a long time. The implementation may not have been the most efficient (I still, vividly, remember making hundreds of arrow objects so we could have them with every possible color combination of fletching) but getting it into the game was a huge source of satisfaction.

One of the desires expressed at the very first Armageddon player-staff meeting I ever attended was a yen to move away from “a hack and slash economy,” where players made their income by selling the gear off NPCs (and the occasional PC) that they had killed. How, one immortal noted, could the world be realistic when there was no coded reflection of the material underpinnings of it? How to create this economic reflection was a question that remained in the air for several years, and it was not until discussion of implementing crafting code came up that such a move seemed possible.

We laid the groundwork for crafting by first creating ways to get the raw materials. I reviewed what was produced from skinning the various creatures in the game, both to make sure that players could skin most corpses and to ensure that what was being produced was reasonable. We implemented skinning difficulty: some things, such as pelts, are harder to extract from a corpse, as opposed to cuts of meat. Beyond that, we added a forage command, allowing players to find rocks and wood. Later, this was expanded to add other arguments: artifacts, salt, and roots. Forageable objects differ according to the sector type of the room and in order to make this reflect geographical differences, we added some more sector types, such as thornlands, salt flats, and ruins. Salt can only be foraged in the salt flats, for example, and roots are only available in fertile land (hard to find on a desert planet).

Once the ability to gather raw materials was in place, a couple of initial crafting skills were implemented: basket weaving and tanning. Basket weaving, admittedly, started out as a bit of a joke, but it served its purpose: to allow us to discover flaws. Both skills necessitated the creation of the objects to be crafted: a series of baskets for basket weaving, and tanned versions of various pelts and hides. With each, I tried to make sure there were incentives to use the skill: tanning a hide made it both more valuable as well as sometimes adding wear flags, while baskets included some objects that were wearable on the back or otherwise handy. I included the ability to craft an object, a numut vine sash, that had vanished from the game when the city of its origin was destroyed, and this in turn led me to wander through the database to find other objects that could be recycled and used for the code. As part of this effort, I ended up adding a component crafting skill for the magic users in the game in order to use a series of objects left over from an immortal project that had never been fully finished.

Although some objects could be recycled in this fashion, many others had to be made for the crafting code as we began to implement additional skills, including bow making, knife making, cooking, dyeing, leather working, bandage making, etc. Occasionally, obsessiveness got the better of me: after creating four different types of arrowheads, I decided that people should be able to make striped fletching for their arrows, so they could, if they wished, make arrows using their clan or House colors. This required me making some 300 or so arrow objects in a madcap building session that left me not wanting to ever type the word “arrow” again. Here, planning out the entire effort in detail ahead of time and having used a different structure for coding the items would have paid off, instead of having added bit by bit as I went along. For example, I found myself regretting the variety of gems one could forage in the game when I ended up making multiple bone dagger items, each with a different gemstone in the hilt. Having the entire structure sketched out ahead of time, rather than adding in skills as they occurred, might have been helpful, although some of the skills came from player suggestions after they’d been exposed to the new code.

As the skills began to be more fleshed out, we started making them available to the players. Cooking was a skill everyone got, while others were fitted into the skill trees (Armageddon has a branching system) where appropriate, with merchants ending up the vast beneficiaries overall, going from a possible 13 skills to 38. Some additional skills grew out of the effort, such as analyze, which allows a player to determine an item.s component parts, and armor repair.

At the same time, we added a secondary guild system, which allowed players to flesh out their backgrounds further, by adding a few skills, usually crafting. The secondary guilds were not the same as the regular guilds but intended to reflect life experiences or talents, including stone worker, bard, house servant, guard and mercenary, and I enjoyed putting the packages together in a way that made sense, such as giving the house servants pilot, flower arranging, and a high cooking skill or the mercenaries ride, knife-making and an increase in their ability to hold their liquor.

Inevitable questions and problems arose. On Armageddon, skilled merchants can often identify the style of an item via the value command, if it came from a specific region or culture, and in order to accommodate this, I made the crafting of some items dependent on materials available to only those groups. Shopkeepers began to be glutted with some items (nothing is sadder than a Kadian merchant laden with nothing but spiral-carved green marble incense burners), but this allowed us to check and adjust item prices by monitoring the shops to see what items were appearing at what costs.

For example, since wood is more expensive in Allanak than in the Northlands, some players were cashing in wildly by making and selling wooden spears to House Salarr, which I hadn’t realized would happen till I noticed them selling for 300 sid (Armageddon uses obsidian for its coinage) in the shops.

The experiment still continues and new items, many contributed by players, are added every few weeks. Currently, there are some 3000+ possibilities, crafting wise, coded, and there are still gaps. When I initially did the dyes, for example, I left out the color orange, which means that I keep getting inquiries about implementing variations with that color from the players. The fact that it would require writing up another 300 or so objects has stopped me so far, however. But the players are using the code right and left, and some are actually supporting their characters with it. Though there is still a limited market for incense burners.