Back to index

The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

Keeping Control of Grief Players

by Patrick Dughi

How many mud-administrators have had one of these scenarios;

Alex tells you, 'There was this guy on a while ago who spammed everyone with obscene and racist language!'
Betty tells you, 'Someone said that they're going to erase my hard drive if I don't give them my equipment!"
Carl tells you, 'This jerk just waits by the mud entrance and keeps killing newbies.'

A frozen lake

Frozen Lake Erie in winter, I wonder what it did wrong?

What Alex, Betty and Carl are describing are some of the several types of grief players. People who, for one reason or another, exist to simply make someone else's life miserable. As a game designer, you are devoted to making everyone's playing time enjoyable, and these grief players are the wrench in your gears. There are all sorts, far too many to list, and they are more frequent than you would like. Every online game will eventually have to figure out how to deal with them, and this article documents some of the more common techniques, and more importantly, how they are applied.


Banning is the most severe form of punishment that can be imposed upon a grief problem. It is, simply, disallowing that person (the player, not the characters they play), from using the system. Usually this is performed through selective IP address blocking. The down side to this is that many people use dialup connections which are prone to a randomization of their IP address; to successfully ban someone, whole subnets must be disallowed. Imagine having to block all of, for example (though some people have that setup as the default).


I find this to be a step often skipped. If a player has gone so far as to have their character deleted, often times, they are banned as well. There are exceptions, as the deletion of one or all of a players character may be based on exploitation of bugs, or character-based infractions, such as stealing, item hoarding, etc - per a games individual rules.


Frozen, jailed, or disabled all have one common theme; the character is unable to perform any actions which affect the rest of the players. Often times this means they can only watch as the rest of the game goes by - not even able to issue the 'quit' or 'logout' command. In some instances, this is a period-based punishment, like being placed in the stocks, while others use a more banal solution and have common administrator-access-only jail rooms.


Many times a player is simply weakened as a result of poor behavior. This can be anything from removal of equipment, or gained power (like levels), to curses or demotion within the mud structure. Of the punishments available, this is the most flexible, and oddly, one of the least developed.


Usually the first form of punishment (but not always, see below), being silenced means that a player is unable to communicate with others. This is enough to 'fix' most online game problems, as the majority of your grief players will simply be standard players who posses both a loud mouth, and a chip on their shoulder. Some games allow a limited form of communication while silenced.


Rare, but one of the original forms; a grief player is labeled in such a way that all players see that he or she is a problem. "Player Killer" and "Thief" are the two most common, but in the world of political correctness we live in, more are certainly possible. Depending on the theme of your mud, "Oathbreaker", "Dishonorable", "Coward" may have more weight.

That sums up our basic coping techniques, now to the more important issue, how to apply them.

As a longtime MUD player, programmer, builder, and administrator for several muds over the last years, I feel I have an uncommon viewpoint on the subject of rules. I have seen many different administration styles, and systems, and have a very good feel for what works from both the administration side, and the player side. What I will first present is what I consider the best solution; automated control.

Automated control of grief players

When I say automated control, I refer to the fact that no person - be they administration or player - takes part in the enforcement of rules. For example, if I have a rule against swearing, it is a simple matter of programming to generate a function which detects the presence of curse words in conversation and act. Whether that should be silencing, or perhaps even a preventitive measure such as changing the words for others (a 'swear' filter), is not so important, as the fact that it is universally applied. This rule works on players as well as our builders, as well as our administrators.

Perhaps my biggest problem is player stealing. Programming changes allow us to track the ownership of items from player to player; in situations where it is obvious that theft is involved (such as looting a corpse or use of the 'steal' command), it is an easy thing to Tag the player, and then have NPC's such as guards apprehend the player - sometimes even killing them in the act.

In anycase, the biggest source of problems is adverted; the human component. I have seen, in 8 years of MUD experience, 12 separate muds either die completely, split, or otherwise fade away due to what we will term 'politics'. I have heard of many more that suffered the same fate. In every event, it is the same; Administrators do not trust other administators, players do not trust administrators, and administrators does not trust players. This degrades the administration structure, and player base falls off as they experience the fallout from above, and also notice that their problems are not resolved satisfactorily. The causes of these vary, but usually come from the combination of four things:

  1. nepotism - administrators favoring certain players, allowing them to bend or break rules they hold other to.

  2. hypocracy - administrators allowing themselves to bend or break rules they expect others to follow.

  3. trust issues - administrators expecting that everyone thinks like them all the time, and will accept their decisions at face value.

  4. player angst - every change an individual makes, good or bad, will cause problems with SOME of the players ALL of the time.

I could label examples of any of these, but you will see them prevailant in situations where the line between players and administrators starts to blur. Systems where the administration are also the players are particularly prone to the first two. The phrase, "The players will like this," often comes up in situations when the administration should be saying "This will ruin the challenge of the game," and are thinking "This will make my character all-powerful!". It is not surprising that the most powerful characters on these systems ARE the players of the administrators. Near-perfect knowledge of the system and the ability to change it do not lend themselves easily to weak positions. There are more examples, but I will leave them to you to see them in the games you play.

The important thing is that automated control removes at least 3 of those four issues. A program will not have favoritism, or be a hypocrite. Once programmed, it will respond in the same way for every similar event - you can have absolute trust. The last, player angst, is also partially averted as well, since a player can now only blame themselves for not following the rules, as opposed to directed blame at an individual.

The highest goal for any MUD then, is to automate as much as possible of the grief handling system. It is simplistic to think that your system will catch all, but the less humans in the system, the better off it is. Of course, at least one administrators should have the ability to overrule the system, in the advent that programming goes awry, or unexpected circumstances come up. Hope that administrator is not a player though.

Administration control of a grief player

This is the most common form of grief control. It relies on two flawed concepts.

  1. Someone will be present and omniscient at all times.

  2. That person will be fair and just.

The first is obvious; if a person cannot be present at all times, as well as know the facts in every situation, they will not be able to make an accurate judgment on events that they know nothing about other than descriptions from others. They must rely on the trustworthiness of others, and worse, punishment should be secondary to control of the situation. If you are not around to stop the newbie killer, it does not matter if you delete the character later - you have lost a potential 10 new players who now hate your game. The second issue is also simple to tackle, its failings are demonstrated in the automated control opinion section above.

Aside from these major flaws though, there is alot which is good in an administration system run by a competent staff. The first is that often, the rules in a mud regarding social ettiquite are very difficult to enforce any other way. Can you foresee that your anti-swear filter from above should have to deal with Sweedish curses? How about some filthy Swahalli comments? Maybe some nasty Thai quip about your mother? How can you let that same failable automated system decide who should be Deleted, or Banished?

I notice many administration controls leaning towards a more complete automation as the problems in their system become apparent. Most mud's adapt their online logging features as one of their first changes for their player-testing beta procedure, simply to catch people exploiting bugs, or abusing the system.

People are not as rigidly defined though. They can adapt to new circumstances and follow though with new punishments. On one mud which I both programmed and administered, we included a toggle for players called 'god hate'. In essence, it added or removed 20% of any result for a player in such a way as to hurt them; they got 20% less experience points for a kill, and needed 20% more to level. They were 20% more likely to miss an attack, and if they hit, the attack does 20% less damage (and they were 20% more likely to be hit! etc). This was for what we considered potential problem players - those with just bad attitudes who did not do anything against the rules now, but promised to be a hassle if they ever got ingrained in the system. By toggling this, those players gained power at a much slower rate, giving us more time to react to their grief-causing abilities. It was subtle enough to exist mainly unnoticed, but had a definite end-effect. I believe it was one of the tools responsible for stopping an array of potential abuses from one school-based domain system which had a history of grief players.

Of course, you could have never written a program to 'condense fact from the vapor of a nuance'[1], much less decide which potential problems to advert and how.

The problems with this system are shown above though - it falls prey to politics as often as not. Even for a fair system, there is alot of guesswork that has to be done; did a person mean to do this, or not, did they lie about it or not, etc. This lets the administration go with their 'gut' feeling - increasing their responsibility and doubling or tripling the blame. Many people - had they known about the 'god hate' setting - would have ostracized me for it, claiming that I was being too harsh and judgemental, or just plain unfair. I could easily see many players leaving a game with that sort of standard rule, especially if they were once grief players themselves. Lucky for me, I was considered a fair hand by most, and the players that received the setting rather deserved it, and the players would have agreed it was necessary... this brings us to our last system;

Player control of grief players

Let me start by saying that this is NOT my idea. As a matter of fact, I think this is the worst idea I have heard in a long time. In a nutshell, the players decide which administrative actions should be carried out upon which players. There are still administrators - who else to watch the watcher - but they are more subtle managers. It is assumed that the social pressures in an environment will cause everything to fall into the correct order.

Let us take a step back, and remember back to when we were children. At some time or another, we attempted to play the game Monopoly. Did you finish your game, or did it degrade into some sort of interest free loan scandal bigger than anything the US government could be involved in? If you were at all like the kids my sister and I were, I would bet there were not any 500$ bills left in the money bin.

This childish look shows us the view of our standard online gamer. They want instant gratification - more levels, more power, more equipment, more spells, more skills - but most of all, they want it now. Granted, this is a bit of a derivative idea, but would you let your players have all this, when they want it, just because they all agree it is the best thing?

Of course not. That is because the players are interested in themselves and their friends, and not in the welfare of the game as a whole. Lets just turn the focus back to grief players - allowing the majority to rule on the position of any given player. Remember Alex? Well he was dating Betty, and they just had a bad breakup. Alex tells all his friends what a horrible girlfriend Betty was, and suddenly, she is kicked off the game due to popular opinion. Worse, some large group from another mud sees your mud as a threat, and maintains a majority presence in order to delete or ban every player, or maybe just muting. Just as bad, they could simply interfere enough with the system so that no justice is performed at all. Normal players would do this, as the popular ones would escape punishment.

I believe you need at least an administration level system to handle this sort of responsibility. Players should never have the ability to ban someone, or mute them; especially not based on popular opinion. Deletion, and the other punishments are also less than likely to be fairly metted out.

Lets assume though, for a moment, that your game is not simply a destroy-the-monster-get-the-treasure type. Lets assume that you have a complete world view, with kings and peasants, and towns and villages. Under a well developed atmosphere, it is possible how a character could play the sheriff, and be responsible for enforcing laws and rules. That would be an incredible blending of player with environment leading to a rich role-play system. The sheriff could Jail people, or Tag them - but Mute, Delete, or Ban? No. The sheriff must work within the constraints of the world system. If they want to jail them, they should have to catch them. If they want to fine them, they will have to figure out how to collect the money. The point is that though this person is acting in an enforcement role, he is not doing grief player administration. He is playing a role playing game, and this is his part. His role does not include taking care of someone who logs on just to recite all of Andrew Dice Clay's dirty limericks, or someone who logs on 40 new characters and has them all perform the same actions in a room to knock someone off with excess network traffic. Players cannot be trusted with that level of power, or you have the same monopoly problem above eventually developing.

The monopoly problem is the same reason that I believe administrators should not be players on the game either; better to be above, and clear headed than down in it, and conflicted.

It has been claimed that variants of the player-controlled system ARE in effect upon several muds, and for long periods of time. I have attempted to follow up on that, but to no avail - the posters of such comments do not describe their systems or explain how to connect to the systems they are talking about. I believe such systems such as the sheriff above are workable, with a well developed world. However, the difference is between game administration, and playing a role in a game. The two could not have less to do with each other. As for a true player-controlled system, I cannot believe there is any such thing. You probably should not worry about proving me wrong, and should concentrate on getting that new modification to your system logs in ;).

[1] - a quote from Neil Stephenson's "Snow Crash", I believe.


Patrick is a long time mud player, builder, and programmer, paper RPGer, frequent contribuitor to the circlemud, and more recently mud-dev mailing lists. Currently programming for IBM, and not currently associated with any particular mud - just sort of freelancing and working on my own projects, though he has been head programmer on several muds in the last 8 years or so.

A man who owns his own claymore.