By: Brian Jones (aka Otter) brianj@otterspace.com

Part of the Management Series.

Introduction

This page discussions various policies used to bring new players into the MU.

This is not about the marketing or attracting of players! If I had any advice on how to actually generate new player interest the page would melt from MU users accessing it!

Instead, this page focuses on two things: the process of converting those people who wish to play into active members and handling the cases where some people want more than a single "point of view" character.

The Challenges

The challenges that face the management of any game in regards to players are these:

1. acquiring and retaining good players
2. avoiding and removing problem players
3. avoiding players who don't cause problems but who add no value

It's in solving these challenges that the staff forms policies on player admissions.

The Basic Approaches

There are four main approaches to bringing new players into a MU:

1. Players simply create themselves
   
   In this approach, there may not even be guests at all. It's common for the login screen to allow new players to join right then and there as simply as "create name password-chosen". The players on these sorts of games have no validation of anything and are free to do as little or much as they like to decorate themselves.
    
2. Players create themselves after providing required (and software validated) information
   
   This approach typically uses a guest login and then allows players to run in-game programs to setup their new character. Then, they invoke an in-game command to create themselves. At this point, they've required no interaction with anyone and now have the standard privileges of membership.
    
3. Players are created by an authorized person (staff or wizard or player with permissions) after verifying that provided information is sufficient and appropriate
   
   With this approach, players do the setup of their character, but they are provisional until someone else enables them. This may have them create a "g.Character" or simply delay conversion from GuestN to Name.
   
   The key to this approach is that someone must be authorized to approve new players that join after those players have done the setup work themselves.
    
4. Players submit an application that goes through a process before they are allowed to become official
   
   This is the most formal of all the approaches. A candidate player goes through an application process, which may include interviews, sample role-plays, references, and the like. The site's goal with an application process is to ensure that new members are going to be good fits with their game's mission and players. Often, after the application is approved, a new member is considered to be provisional and certain in-game events (or the passage of time with no complaints) must occur before full membership is achieved.

There's variations on these, and there's not "hard" lines between them. For instance, some games with applications allow an authorized person to approve a guest into a g.Name, and then they start the application process. Like any sub-division of a spectrum of choices, there's artificial breaks. However, this range of choices captures all the examples I've experienced.

Policy Decision Criteria

In choosing how to manage the admissions process, it must be determined what represents an ideal player. This sounds obvious, but it's neither easy nor often consciously thought about.

For instance, is it desirable that all new players be competent role-players?

What a silly question! Of course it is! Right? Well...

In fact, many MUs don't have a role-play focus, or a minimal RP focus at best. Some exist as social centers for groups of friends, for instance. There's no over-arching storyline, theme, or genre that those people would role-play within.

Some MUs are thematic and role-play is the entire purpose of the system. So, they'd certainly want only competent role-players at least, right? Well, again... If a MU is based on a movie or set of books, it's acting more like a fan-club than a role-play system. In that case, while role-play may be a huge portion of the system, they welcome new members who don't know how to role-play at all but who love the books/movie/whatever. They are willing to teach role-playing if the people are willing to learn.

The systems with the more formal admissions processes are well suited to filtering players based on their experience and abilities. This for instance would allow them to verify that any candidate have the desired competency in role play, as well as good grammar, spelling, and so on. The more strict the filtering, the fewer candidates will be approved, and the slower the systems will grow (if they grow very large at all).

These formal systems often have extraordinary RP logs posted. Their selection process is an excellent tool to restrict the membership.

The downside of the process is that they lose many players who might have the skills and abilities but refuse to submit to the procedure. This may be a lot more common than people realize; it may not matter, though. The MUs that value their results are willing to give up players who won't accommodate their methods.

Many times, what's needed is a fairly minimal level of competency. It's OK if someone doesn't know anything about MUs, but they need to be willing to fit in. In these situations, an application process might be excessive, but you want to be sure people are willing to read and follow basic directions. And you want the means to prevent clearly destructive people from getting in. This is when having an authorized person "check over" and approve a new player becomes a useful approach.

The candidate still has to perform some amount of effort, and there's still a human in the loop to approve them, but it's much less onerous than a full application system. The downside of this, of course, is that if there's nobody online who can do the approval, you are going to lose the player.

This brings up a key issue to all the human-mediated approaches: they require staffing to work. If it takes three weeks to process an application because your staff is busy, you're going to lose a lot of players who pass your application and then aren't interested anymore by the time you get back to them. If you require someone be online to approve a guest, and there's nobody online, you will NOT gain characters during those periods.

Not only do you have the problem of time and online availability, you have the issue of choosing people to evaluate the applications and guests. This can become a serious challenge. The gatekeeper staffers can perform two major mistakes: they can block reasonable applications and they can allow unreasonable ones. You'll need to careful supervise your gatekeepers to be sure they're being consistent with your policies. And you'll have to remove those who aren't (an always unpleasant experience).

In many cases, the system doesn't need serious approvals at all. In a purely free-form system, just joining at the welcome screen might be sufficient. Most free-form systems though want a few basic pieces of information (like email address, gender, species, etc.) so they provide a setup program that the guest runs and at the end the guest can create themselves.

This approach has the advantage of allowing the game to grow even when it's empty. People who seek to play right now can do so.

The problem with skipping human-mediated approval is that it's very easy for the system to be abused. The email addresses could be false. The characters could come on and stay only line enough to cause problems. This possibility is very real; it's not paranoia on the part of staff to fear "trolls" or the like to join a normally fun and friendly system.

The systems that have easy membership often have a period in which the player is limited in permissions to give the others a chance to object. This provides the ease of joining and the safety of human mediation. It's why some systems have the "g.Name" period in which a character is provisional. A troll can come on, but they can only do limited harm for a brief while.

The ability to remove a trouble-maker rapidly (or at least to restrict them to the point of harmlessness, such as being able to suspend them pending review of others) is a necessary facility to staff on a system where there's easy creation of new players.

A reasonable thing to ponder is whether the likelihood of problem players is greater than the loss of good new members because of non-availability of authorized staffers. There's no right or wrong answer, but it's a way to help decide whether an open admission policy is feasible in your case or not.

The above discussion is related to a new member's first character. However, if that member enjoys the game, they often want other characters.

Alternate Characters (or "Alts")

Alts have been the subject of many debates, in-game programs, policies, and serious arguments. This section hopes to take some of the fire out of the topic and address the issues so your policies can reflect what suits your game best.

Types of Alts

The main types of alts are:

1. public alt
   
   In this case, it's expected that everyone (both staff and non-staff players) know who the other characters are that the player controls. This is the case when lists of players by email address and their characters are published, for instance. And also when players have web-pages where they list their alts.
   
   The key aspect of a public alt is that there is nothing to hide from anyone.
    
2. private alt
   
   Here, the player running multiple characters doesn't want other players to know what characters are controlled, but keeps the staff informed.
   
   The key aspect of the private alts is that the player doesn't want non-staffers to know which characters are really controlled by the same player. This can be for any number of reasons (good and bad). But since the staff "knows" about it, it must have been approved.
   
   A minor point: it's nearly impossible over time to prevent players from recognizing styles and discovering the private alts. This is so likely that private alts are almost always exposed in hours to days of regular use.
    
3. secret alt
   
   In this case, the player doesn't want even the wiz-staff to know that the characters are controlled by the same player. This is almost always a way around some kind of rule, ban, or quota. To effectively fool the wizards, the player typically connects through other proxy systems.
   
   Like private alts, these are very hard to maintain for more than a few hours. However, if the purpose is just to artificially increase quota (each "player" gets a certain quota, so more accounts, more quota) then the character won't be RPed with anyway and can avoid giving away identity.

When the alts are public or private and managed by staff the staff at least doesn't have complaints per-se. Whatever the policy is (limit alts, alts only with permission, etc.) the policy will be followed without trickery or deceit

There's a common belief that players "can't handle" more than a small number of alts and that this causes some of the characters to be basically cardboard shallow and played poorly if ever. This is often true, but it's not always true. If there's a player on the game that has 20 alts and they all get used regularly and well, there's no real concern here. But, many policies limit the number of alts to prevent the pathological case of someone with hundreds of characters that only sign on once a day for 1/2 second to avoid being destroyed for non-use.

If a staff decides to make the policy more flexible, instead of limiting the number of alts, they can add to the policy "with additional alts as authorized by the staff." This way, someone who clearly can run many alts will be granted permission to do so inline with documented policy. If someone else wants more and gets turned down, they can cry "favoritism!" (and possibly be right) but at least they can't cry "special case!" because the rules expressly allow increasing the quota with permission.

When a system has a quota that is per-character, alts will serve the effect of increasing that quota unless the system provides the alts with no additional quota. If the goal is to increase quota, it's better to have a policy that allows productive building players to request more quota than make alts for the purpose of gaining more quota. If you see players making alts not to play them but to use them for some other purpose (like more quota) then consider solving the real problem instead of using alts as a means to get around it.

Another common use for public alts is to hold land that is shared by many players. In this case, the alts often have either a shared password (bad, but the only way on some systems) or a controls-lock that lets people on a list work as if they where the alt. In either case, this is a clear artifact of the way MUs manage ownership. This should not be counted as a "rules" work-around when players seek alts to use this way; it's just players working within the nature of the server. Often, staff uses these sorts of alts to avoid wizards owning all the lands and programs as well.

Most of the negative connotations of alts involve secret alts. Specifically, the reasons people make secret alts almost always tend to generate issues that the staff must deal with. For instance, if a secret alt is made to get around quota, then when the players discover the identity of the secret alt, they complain (rightly) that such-and-such a player is getting around the quota they have to live with. Or, a secret alt may be used to page "You sux0r!" messages thousands of times to a player they don't like (ah, client-side scripting is such fun). Until, eventually, the wizards boot/banish/toad them.

Anytime secrecy is involved, there's almost always going to be a negative attached at some future point and secret alts are no exception.

Hopefully, by clearly distinguishing the types of alts (public, private, or secret) the players who want public or private alts can be supported without causing stress or confusion to the wizard staff.

So, when formulating an alt policy, consider:

1. Whether to allow alts at all
   
   In some systems, the decision may be that no alts are allowed or needed. This is typically the case if the system stresses zombies instead, for instance (see next section).
    
2. Whether to restrict the number of alts
   
   Some systems don't care about alts at all, so they don't restrict them. Others want to track alts and use a restriction as a way to keep the bookkeeping work down.
    
3. Decide whether to allow exceptions so that some can have more alts
   
   If you have alt restrictions or quotas, providing a way to grant exceptions without special-casing the rules is a nice way to avoid complaints and make clear to players that if alts are used well then you don't mind letting them use more.
    
4. If the staff tracks alts, determine if the alts should be public or private
   
   As long as the staff knows who the alts are, the staff needs to know (and the players need to know) if the alts will be published and the staff refer to alts, or if the alts will remain private/privileged knowledge and the staff will not divulge who the alts are. If there is no policy, then the staff should default to "protect the privacy" and not tell anyone who is an alt of whom.
    
5. Describe what the consequences are for secret alts
   
   It's really wise regardless what your policies are for legal alts to specify that secret alts are not welcome and what will happen. For instance, on Redwall, if a player is banished, all their alts are banished and they aren't allowed to make more characters. That's documented. That way, when I am forced to carry out removal they can't say "But this character didn't do anything!" (I know, they say it anyway but at least I can refer to the policy and end the argument).

Sometimes, the player really doesn't need an alt. They just need a side-kick, or perhaps they want villain they can vanquish (and let die!) or they need to be in a room offering help. If all they need is a quick character that can be someplace else, a zombie is a great alternative.

Zombies

Many people have limited experience with zombies. Zombies are objects that are set to be controlled with the "force" MUF primitive, "@force" command, or "{force}" MPI expression and which transmit to their owner whatever things they see. Basically, they do what characters do only without having a password. They only work properly when their owner is awake.

Zombies aren't as flexible as alts; they don't own things (since they are things) though they have access to what their owner owns. And the zombie (like all objects) exposes the owner with basic examine commands, so zombies are useless for secrets. Some games include zombies in reports such as where or who, but most don't. As such, zombies also provide the means for people to explore without showing themselves moving. In that sense, zombies can act surreptitiously even though they aren't in secret.

Since zombies are just objects, they don't have to be given the same tender loving care that a character gets. Meaning, it's reasonable to make zombies so they can be killed. It's one of the few ways to allow permanent effects without causing players to lose their characters.

As such, zombies are a good alternative for a horde of bad guys for the heroes to kill, or for animals that can be hunted. And for the programmers among us, they are good things to build AI controls into for very special effects.

Zombies have some downsides. They are often left laying around by people who like to "keep an eye" on places. As such, you'll sometimes see zombie stones, logs, etc. These are basically spy objects; they are usually forbidden by wizards except in places owned by the spy's owner. In this way, owners can build special effects. But, when you see random objects that can send back to their own things that are happening, they're often trying to be hidden.

Expressly making policy that zombies should not be used at all for spy objects, or even writing the code so that look always shows zombies in the list of players in a room (thus making them very obvious rude spying objects) is feasible. If the only reason to consider forbidding objects is because of spying, that should be worked past with code and policy.

Sometimes, players end up with lots of zombies and they leave their character in a small room out of the way; essentially becoming a puppet-master instead of a player. While this is a bit extreme, as long as the zombies are being used reasonably, it's really no different than someone with lots of alts. So, the discussion on alts and proper use of alts can be applied to zombies as well.

Zombies do present security risks when people get clever. For instance, some people make shared zombies by using force-locks and common MPI. This works, and the effects can be interesting. But, it's very easy to be abused. If a player can force another player's zombie, that player could use the zombie for instance to destroy everything owned by the owner! That would almost certainly generate a complaint to the staff. However, the player who so abused the zombie probably didn't break any rules, because the permission to use the zombie was explicitly granted. Thus, it would be wise to remind people that zombies act with the permission, rights, and responsibilities of the owner, regardless of who is controlling them.

Whatever the standards are for characters, such as species or quality and style of descriptions, should be applied to zombies as well. Since zombies act like characters, they should be given the same attention to detail as characters. Even if they're going to be horrible killed by a werewolf in two hours, they should have a better description than "You see nothing special."

When you need "extras" (in the Hollywood sense of a bunch of people to fill out a set) consider zombies. Even if the decision is not to let players create and run zombies, they are a great aid for the staff in making targets and victims, canon-fodder and damsels in distress.

Conclusion

Your worlds are populated by players and zombies. Some of the players may be run by the same person as alts. Make sure that your policies support the goals of your game. If your goals are to have only exceptional role-plays with only the best of players, you'll have different policies in acquiring new players then if your goal is to let the new players jump right in and start making mistakes.

Whatever you choose, be certain to train your staff at the least on welcoming in new players and helping them get involved. First impressions do matter, so make sure your staff and players provide a good one!