> mudreading.com

Articles and News for the MUD Community

Rae on ArmageddonMUD Videocast Episode 1

21 days ago by Raesanos regarding Community

I recorded a videocast where I talk about ArmageddonMUD. Sanvean of Armageddon has been doing these for awhile and I decided to give it a shot. In this episode (assuming I’m going to do more) I talk about setting up new staff members for the game and an interesting character I played years ago.

Is there anyone else in the MUD community doing these? I’d love to see videos like this about other games!

It is split up into 3 YouTube videos and is about 22 minutes long:

Part 1/3
Part 2/3
Part 3/3

And there is a discussion of the videocast going on here:

Armageddon community discussion on the videocast

Comment

Easy Supply and Demand

43 days ago by Raesanos regarding Game Design

A realistic economy is a goal of many MUDs. Many of the benefits of a realistic economy can be created with very little work.

Here is a simple supply and demand system. Every time a player buys an item, increase its cost. Every time a player sells an item, decrease its cost.

Voila. Supply and demand. The system works well to make high-demand items expensive and extremely common items cheap. There are just a few tweaks that would keep things working.

Tweak the settings for how much the cost is effected by each purchase or sale. You can’t assign the “right” values deterministically. It depends on your playerbase’s size and behavior, and will change over time.

Consider having the prices normalize gradually over time. That way a surge of unusual activity will be offset sooner, and items that are bought but not sold (such as consumables) will not simply increase in price forever.

Consider a minimum and maximum price. EG, do not allow an item’s cost to change to 50% less or more than its original cost. This is a good approximation of other factors not considered in the system and helps catch flukes before they cause a problem.

To expand on the system a little, keep a multiplier for object types and materials, if you have them. Start at 1. Each time a player buys or sells an item, increase or decrease the multiplier (by a small fraction). Have the multiplier effect all objects of that type or material. Now, if silver longswords are in demand, the price of silver broadswords will increase as well.

To expand on the system even more, keep these set of values separate for each city, region, or whatever granularity is appropriate for your game. Then travelling to a region where an item is more rare will yield a better payoff.

Comment [3]

Hiring for MUDs

69 days ago by Raesanos regarding Administration

I’ve noticed that for the last person we hired for Armageddon and for the last person we hired at work, the process was nearly identical. In both cases it was for a developer position. Our process is to say that we are hiring, receive applications with a certain type of information, choose some people to come in for interviews, have interviews that ask the same questions, then send a few offers.

What are the differences, though? That is the part that I find interesting.

Supply and Demand

In the software world, startups and new, exciting companies usually get a lot of attention from job-seekers. There is the chance to learn new and exciting technologies, having a fully stocked soda fridge and expresso machine, and of course the possibility of stock options making you a quick fortune.

In the MUD world, new MUDs are the ones that have to try their damnedest to bring on new staff. MUD forums are always full of posts about the need for coders or builders for a fresh MUD. Why is this?

First, new MUDs have a low success rate. As a hobby, it is very possible that not enough volunteers will be rounded up. Even if the game gets off the ground, its very hard to reach the critical mass where you have enough players for the playerbase to not just disappear during a lull. For MUD administration talent, its a risky move to invest in such a MUD, and many talented folks are more interested in starting their own project.

Most MUDs that are already established hire from within. Players of a MUD are usually very interested in joining the staff of their favorite MUD, so the game staff can remain sufficient even with a fairly high churn.

What can we learn from this? If you are starting a new MUD, be ready to hire through networking rather than forum posts. However, you should take some lessons from the software industry. Make your MUD an appealing place to work. For coders, advertise what cool new technologies you employ. For builders, make sure you have some unique features that are of interest. The competition is fierce, so make sure you answer the question: “Why is it more fun to work on this MUD?”

For established MUDs: Be picky. You probably have a boatload of players who want to help out. Look at the entire pool of potential staff and take the time to really get to know people and their qualifications. We used to hire by invitation, but hiring by an application process has let us consider highly qualified potential staff that had been flying under our radar in the past.

Celebrity Founders

Every heard of Pownce? It is a Twitter like site. Why do I know about it? Only because one of the original founders was known for his involvement in Digg. The world of software entrepreneurship has celebrities. Companies started by such a person get a lot of attention, both by users and by potential employees.

This doesn’t seem to happen with MUDs. New MUDs are likely to come from an average Joe, or an established group making a new MUD that does not need to establish a new staff.

Why is this? First, there seems to be a stigma surrounding leaving your MUD to go make a new one. You would be seen as abandoning your friends there. In the business world, people coming and going is simply a way of life and (usually) no offense is taken. This is infinitely worse if you try to recruit some of your talented friends to get the new project going. Talent poaching is highly frowned upon in the MUD world, even on a small scale. Lastly, people have a strong sense of loyalty to their MUDs. Even if the previous problems didn’t exist, few people want to embark on such a project.

Further, the MUD world doesn’t seem to have celebrities in the community as a whole. MUD administrators are often seen as celebrities in their own game, but players from other games will likely never of heard of them.

One way I’d like to mitigate this is to promote a more far-reaching MUD community. More networking and awareness of what is going on in other MUDs would help anyone who is trying to hire.

I don’t think I’d want to promote higher staff churn. I think the comradery and loyalty that MUD staffs have is a good thing, overall.

When you are hiring for a MUD, make sure to ask what a person’s accomplishments are, in and out of the MUD community. They probably don’t have 4 or 5 MUDs under their belt, but what they say should be interesting.

Expectations

The last difference between real-job hiring and MUD hiring that I’ll discuss is expectations. On both sides of the table.

MUDs are usually a volunteer effort. A staff member’s value is related to how many hours they choose to volunteer. Its obvious that someone who can devote 20 hours a week to a MUD is a great potential helping hand. Someone who has no time to help, no matter how qualified, is probably not going to get hired.

If someone gets hired onto a MUD, then produces less work than is expected of them, this is usually not a big loss. They can linger on as an occasional helper. If they produce no work whatsoever, or completely disappear, they can be taken off the staff list quietly with no incident.

In the world of business there is no such notion. A hire who is not as effective as needed is a major problem. They’re still around every day and drain resources without giving back.

This difference leads to less sense of risk and lower expectations in MUD hiring.

This is a good thing. Staff can be hired with a risk that they won’t work out. Some of these people might turn out great, and if not, the loss is not unbearable. Hires that are an active problem can be dealt with quickly. Be ready to take risks (if there is some reason to think the person may turn out very good) and pay attention to newer staff to see how the risk is paying off.

On the other side of the table, MUD players often expect that working on a MUD will be far more fun than a real job would be. Well, this is probably true, but occasionally there are unenjoyable parts of the job. Any reasonable interviewee for a paid job is ready for this, but far fewer MUD players are. Set expectations early. If someone gets scared by the thought of building an item that someone else designed for them, or talking to a player who has been misbehaving, they probably aren’t a good resource overall.

That’s all for today. As always I’ll leave an open question on the table. What is your best and/or worst hiring experience? From the perspective of either a employer or interviewee. Doesn’t need to be MUD related, but if it isn’t, how might the situation have been different if it was a MUD hiring?

Comment

Three-Space

94 days ago by Raesanos regarding Game Design

Approximating three-dimensional space is an interesting challenge in a text-based game. It is very easy to create a simple, sufficient model. Complications run the risk of confusing players and piling on the work for builders. I’m going to look at a few approaches, their advantages and disadvantages, and talk about an idea that I haven’t seen used.

The standard MUD approach is to use weight as its only measure of not only weight, but also size. The capacity of a container is judged by how much weight it can contain, and a character’s encumbrance is simply their total carry-weight versus a maximum, generally derived from their various attributes.

This works well in general, and is conveniently simple, but there are a few cases that throw this system off.

First, object shape is not taken into account. In my experience long, skinny objects cause the most weirdness, as the game mechanics don’t see any reason to protest putting a spear in a belt pouch.

Second, objects that vary wildly in density can cause confusion. If a player has a bag that can carry an entire wardrobe of silk they may be suddenly confused when a 7 pound sword cannot fit inside.

I have seen a few attempts to solve the size problem. The simplest is a single “size” field, separate from weight, that is then used instead of weight when determining the amount of space taken up in a location or container. This works well enough as it represents density, but it does not help our spear scenario.

In some cases further size fields are added. In the next step we start to approximate each object as a geometric shape. With two fields, width and length, you effectively consider every object a cylinder. This works well: it is able to represent those troublesome spears, and a cylinder with equal length and width is sufficient for less exotically shaped objects.

The other approach I’ve seen is including a height, width, and length: a cube. In terms of MUDs, the difference between this and the cylinder representation is not extremely great. Generally the most important checks on size involve fitting objects through openings such a door or a chest’s lid. Since such an opening is two dimensional, the smallest dimension does not play into the calculation.

I haven’t seen an attempt to create any more complex representation of size and shape. Allowing an object to be one of various geometric shapes would be maddening for a builder, much less do any calculations with, and the advantages of this level of simulation are unclear.

I’d like to propose a different approach to shape and density. I assume this is not a truly novel idea, but in my experience I haven’t seen it done in a MUD. If you know of a MUD that does this I would be fascinated, so please leave a comment about it!

Lets assume (as I always do) that we want to minimize builder effort and have extremely consistent objects in our game. We will have size and weight, as they are both useful pieces of data, and we are going to use width and height for size, as this is a sufficient representation of shape for our purposes.

The implied field is density. Say we have an object that is 12 inches high, 6 inches wide, and weighs 3 pounds. Approximating its shape as a cylinder, the object’s density is about .0088 pounds per cubic inch. Every object will have a density, based on the builder-supplied height, width, and weight.

An inconsistency has arisen, be it a subtle one. Lets say two builders create iron swords. They approximate the dimensions and weight as best they can, and each value seems appropriate. However, the density for each object is different due to the natural deviation you would expect in such an approximation. In reality, iron, as a substance, has a given density that does not vary so much.

We can remove this inconsistency and reduce builder effort at the same time. Assuming objects have a material type (most MUDs I’ve seen do) we can attach a density rating to each material type. A quick look on Google shows me that the actual density of iron is around 0.284 pounds per cubic inch, so lets use that.

Now, we can figure out everything we need to know simply by asking the builder the height, width, and material of an item. The weight can be determined automatically.

Lets say I create a sword of height 3 feet, width 1 inch, and material iron. A little math on the game’s part tells us that such an item should weigh eight pounds. This is about what a three foot sword weighs in real life!

36 * π * .5^2 * .284 = ~8

This approach sounds good to me, and I’d love to see it used in the future. I’ll leave an open question though: What MUD features might require a more complex representation of size, and how would it be done?

Comment [4]

More than MUDs

107 days ago by Raesanos regarding Community

I ended up reading this fine blog due to a link from a commenter on this site, and from there started exploring various other types of “Interactive Fiction” (IF), that being a general term for the type of games that includes MUDs.

Its interesting just how isolated the MUD community is. Really, I have had almost no experience with the other types of IF.

For example, I didn’t even know what a roguelike is until I started playing Legerdemain, which was a fantasticly novel experience for me. To a MUDder, this is a graphical, single-player MUD. Graphical only in that there is a colorful ascii representation of your world, and MUD-like only in the similiar set of text-based commands. The biggest draw was the way exploration works, and I only stopped playing when the difficulty started wearing me down. I doubt this will be my last run-in with roguelikes.

Of course, the type of IF that everyone is familiar with is games like Zork (basically a single-player, turn-based MUD), which I did enjoy greatly at some time long past. What’s interesting is that there is still a community for this and new games that are released. And I, someone who has dedicated years of my free time to games that are effectively the same thing, have played none of them.

Assuming I’m not simply daft and that the separation of these communities extends beyond my own personal ignorance, my first response to it is that this is a problem. I want to see communities for lovers of all forms of interactive fiction. If there are any, I want to see what they’re like and why I haven’t heard of them. If there are not, I want to take a shot at creating one.

Getting my feet wet in the roguelike world seems like a good start. I’m thinking about writing my experience on this site, but I don’t have a good feel for if my readers would be interested in hearing about it, since its not MUD-related. But I do think you should be interested! Are you?

Comment [3]

Older Articles