Players, Alts, and Zombies
This page discusses the ways in which new players join the game and make additional ("alternate") characters or zombies.
By: Brian Jones (aka Otter)
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:
- acquiring and retaining good players
- avoiding and removing problem players
- 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:
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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:
- 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).
- 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.
- 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.
- 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.
- 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!
Created by Otter
Last modified 2006-10-10 09:30 PM
