Picking Features

[ LiB ]

There's really no solid definition of features that a MUD must have, but I've tried to go over the most common features. For example, a room-based system is almost always included in MUDs. Items and characters are also main staples . Beyond that, however, things get a bit hazy.

Feudalism or Capitalism

What kind of economy are you going to have? Both the SimpleMUD and the merchant module of the BetterMUD have open economies . Items and money are created on demand, and destroyed as well. This is clearly not how the real world works, but that's okay; you're creating a virtual world! The problem with open economies is that they tend to get unmanageable after a while. Think about this for a moment.

Open Economies

Enemy characters are spawned out of nowhere, appearing by "magic" at certain intervals producing an essentially unlimited supply of people. If every one of these characters is killed , you have a major problem on your hands, because they drop things that are worth money. Eventually the economy of your realm inflates, and there is so much money lying around that new players logging in are instant millionaires. Think I'm kidding? In my copy of the SimpleMUD, I had 10 millionaires after one month. Granted, I didn't actually spend a lot of time balancing the game more evenly, but balancing only goes so far. Eventually the fact that there is an infinite supply of wealth catches up with you.

To counter such a situation, you could implement a system of sinks that suck the money out of the game without returning anything. One very common way to implement this is to use toll roads . Essentially, you can make your players pay to move around the game. Of course, if you make too many toll roads with excessive fees, your players are likely to revolt against you. But at least toll roads are a start in the right monetary direction.

A proven way of putting sinks into your game is to use the concept of durability . In the real world, things are designed to break. Anything you buy is probably designed to stop working after a certain period of time, to make sure you buy a new one. While built in obsolescence sounds evil, it's necessary in a MUD. It ensures that items disappear eventually, and that people cannot accumulate massive amounts of wealth, because they'll have to keep buying replacements .

Another popular option is a cleanup . Lots of MUDs have a specific time every day when the MUD goes through every room, and deletes every ordinary item that is lying on the floor (as opposed to special magical or rare items). Although this is one solution to the problem, it's not very elegant. Items shouldn't disappear randomly . What if a player puts something down for a moment, runs off to kill an ogre, and comes back an hour later to find the item has disappeared? That's probably going to anger your players, so it's not a great idea.

An absolutely great idea for a sink would be charging rent . Your characters are going to accumulate wealth, and they need to stash it somewhere, so you could have an entire area of a town filled with apartments. The characters can buy keys and be charged by the week for storing stuff. If you're particularly evil, you can write an eviction script , one that automatically throws the renter's items on the sidewalk when he doesn't pay the rent.

Closed Economies

On the other hand, you could opt for a closed economy that would work like this: when the game starts, there are only a certain number of objects and wealth in the game, and there can never be more. This takes a lot of careful management, and some fudging here and there. I almost never see this kind of a system implemented in a MUD because you eventually run out of items and cash to go around. The entry of new characters into the game does not alter the number of items in the MUD. In this situation, the early players usually gain a stranglehold on all the wealth, and newer players get nothing, because the higher-ups have hoarded it all.

I wouldn't recommend going for a closed system unless you're a "reality" freak, and the very thought of spawning items and wealth out of absolutely nowhere gives you nightmares.

Combat

It is difficult to write about combat in a general sense, simply because combat is different in every kind of MUD out there. Medieval MUDs all seem to have coalesced into similar systems, usually inheriting many features from Dungeons and Dragons rules, but those systems only go so far. Honestly the whole "arm weapon and attack" system can get boring quickly, and doesn't work particularly well with anything that is modern . For example, games in which you can shoot people with guns rarely work out well, because guns almost always cause immediately incapacitating wounds; and that's just not fun.

I particularly appreciate how Frank Herbert's Dune book solved this problem. It takes place tens of thousands of years in the future, and weapons and defense technology have become so advanced that using laser weapons on a shield would cause an intense nuclear fusion reaction, killing everyone involved in the combat. Because of this, everyone in the future ends up fighting with knives versus shields , putting the "art" and the "skill" back into combat. If you're making a combat-oriented MUD, you should definitely think about these kinds of things.

Another important topic is player versus player combat, also known as PvP. This is an intensely contested feature of MUDs. It's one thing to be killed by a computer enemyyou just suck in your chest, accept your loss, and see if you can get your stuff back. But it's completely different when another player kills you. The fact that another human being controlled the character that killed you completely changes the dynamics of the attack. Instead of a numbskull computer character whose only job is to try to kill you, some other player decided that he hated your guts enough to attack you! The nerve !

Things such as PvP inevitably lead to tensions and fierce competition. This can either be really good or really bad. I've seen it turn out both ways. It's good because some people take this as simply another form of sport, and they want to play your game even more. It's bad because there are always people who take it too far. Verbal drubbings and swearing are common when people get too caught up in the game, and when this happens over global chatter, it might seriously annoy other players.

I'll leave the PvP question in your hands. There really is no optimal solution to the problem. There are a number of things you may want to try, however. For example, it's often a great idea to implement levels of penalties. It's just not fair to have a level 70 swordmaster walk into town and slaughter every level 5 character, now is it? One solution is to reward such an action with only 1 or 2 experience points or none at all. Of course, this doesn't solve the issue of psychotic players who delight in killing newbies for absolutely no reason.

NOTE

Running a MUD is an interesting sociological experiment, and it can teach you a good deal about human psychology.

To control psychotic behavior, I suggest making it impossible for characters to attack other characters whose experience range is outside the range of the attacker's experience by a specified amountmaybe 5 levels in each direction. That way, level 70 people can only attack people in the range 6575. It all depends on how you implement your ranking system. Again, it's your MUD, and you should do what you want.

Administration

Administering your MUD takes a good deal of effort. MUDs don't just run themselves ; you have to take care of lots of details.

Hosting

First you need to figure out where you want to run your MUD. You can probably run a MUD over a broadband Internet connection on your home computer, but I really wouldn't recommend that, for many reasons.

First and foremost, your home computer is probably not a server. You probably program on it and play games and music. Therefore, it's not a dedicated environment for a game server. That's acceptable if you're just running a small MUD at your leisure, but for anything more serious, you should look into a professional server solution.

NOTE

You should be aware that most broadband connections explicitly disallow the running of servers on your connection. This is mainly due to the way they calculate bandwidth usage, and they assume you'll be downloading far more content than you upload, but a server changes all of this. If you do want to run a MUD on your home connection, look at your end user license agreement to make sure it's okay first. Some ISPs even cancel your account if you run servers on it.

I've only recently started dabbling in Linux, and I'm impressed with what I see. If you know anything about Linux, it shouldn't be difficult for you to find someone who will sell you access to a Linux shell that you can run your MUD on. In fact, the site that I use, http://dune.net offers this very service, and for reasonable prices as well. There are many other hosting companies as well, in case http://dune.net doesn't fit your needs, or you don't feel like messing around in Linux.

Here are some sites you may want to check out:

  • http://www.silverden.com/ (Linux)

  • http://www.genesismuds.com/ (Linux)

  • http://dune.net/ (Linux)

  • http://www.mudhost.com/ (Linux)

  • http://www.gryphonmud.com/ (Linux)

  • http://www.mudshell.com/ (Linux)

  • http://www.ancientrealms.org/ (Linux or Windows NT available)

  • http://www.wolfpaw.net/ (Linux)

As you can see, almost all of the sites offer just Linux shells . This should tell you how important Linux is as a server platform for MUDs. If you're not familiar with Linux at all, I urge you to learn about it. I was hesitant at first, but it didn't take me long to figure out what I was doing. What's the best thing about Linux? It comes with GCC , a full (almost standard) C++ compiler, completely for free. How can you beat that?

Another great alternative is running a MUD on a university server, provided you have permission to do so. Considering that most of the original MUDs were created in universities across the world, this is sort of a tradition, and you shouldn't have much trouble gaining permission to run one.

Management

Will you be a benevolent dictator? Will you run a democracy, or will you let your realm be a complete anarchy ? These are some of the questions you need to think about when running a MUD. You are taking on the role of a god; you created the realm, you can do anything you want in it, and the players are at your mercy.

But how much control should you exert? Sometimes it's a good idea to impose a legal system such as this: no killing when people are away from the keyboard, or no stealing. These kinds of things can be enforced by the game, but at some point, actual management needs to come into play.

You're going to need people to manually enforce the rules, whether it be yourself, or people you can trust. This is a very difficult thing to manage though. I'm sure you've heard the adage, power corrupts . Who can resist the temptation of playing around with power? If all goes well, the people you recruit to have extra police powers will behave, and your realm will live in peace . If they don't, your realm will live in pieces.

Don't hesitate to be strict on frequent offenders. Generally offenders cause everyone else to have a miserable time, so making an example out of one person usually pleases other players.

Security

Security is another topic that I haven't discussed much. When going over the Socket Library, I showed you how to protect against single connections streaming tons of data to you to prevent being flooded with information.

But that's only one way you can be attacked . The SocketLib's connection manager doesn't handle denial of service attacks at all. These are the kinds of attacks that occur when one person connects to your server with dozens or maybe even hundreds of connections, thus eating up your resources and denying connections to other people trying to log on. In its current form, the SocketLib can't detect these attacks, because it doesn't detect the number of connections that it has from the same IP address. Therefore, you can have 50 connections all from the same person, all slowly flooding you below the individual connection flood rate, but collectively lagging your server to death.

This could be fixed in the connection manager easily enough, by limiting the number of connections per IP address.

On the other hand, you're going to come across an even trickier attack at timesthe distributed denial of service attack. These attacks are usually caused by dozens or even hundreds of different computers all attacking your server at once. The best way to block this kind of an attack is to simply disconnect connections that sit in the login state for too long. But if people are really intent on attacking your server, they'll just log in anyway. The best defense in that case is to have a corps of administrators that you trust, and make sure that at all times, at least one of them is online to kick off troublemakers.

Of course, you'll encounter problems besides network attacks, and many will be problems of your own design. Your players will find flaws in the game that will give them gains that they should not have. I can recall an instance when a certain NPC in a MUD I played on offered high experience points for killing him, but gave the players evil points when they attacked him. If you accumulated too many evil points, town guardsmen would hunt you down, so people tried to avoid being evil.

NOTE

The term farming refers to people staying in an area and killing the same monsters over and over again.

Of course, it got to a point at which the characters became more powerful than the guards , and started farming that NPC to death, racking up tons of evil points, and tons of experience, without any drawbacks.

So what happens when your players inevitably find your flaws? Do you punish them? If you do, you're sure to receive complaints such as this, "Hey! I wasn't cheating! Your crappy game allowed me to do that!" It's best to punish only cases in which people take excessive advantage of a bug. Chances are, when a bug is discovered , there will be little doubt that it's not supposed to be there. Your players will probably know that they are exploiting a bug, but people are people. Who can resist the temptation of getting a permanent character boost?

If anything, this should help highlight the importance of testing . You must test your game before you unleash it on the world, or else you should expect people to take advantage of your mistakes.

[ LiB ]


MUD Game Programming
MUD Game Programming (Premier Press Game Development)
ISBN: 1592000908
EAN: 2147483647
Year: 2003
Pages: 147
Authors: Ron Penton

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net