[MUD-Dev] Star Wars Galaxies: 1 character per server

[Caliban Tiresias Darklock]

From: "Ron Gabbard" <rgabbard at swbell.net>

> One player that plays 60 hours per week has a significantly
> greater potential impact on the server than 15 players that play 4
> hours per week.

Another angle to this is that one player playing four characters has
more impact than four players playing one character, because each
*player* needs to learn certain things. Skills, locations, secrets,
whatever -- the player with four characters can multiplex his
knowledge across the four characters, and each character after the
first gains a significant advantage. The ability to choose between
characters then provides the multi-character player with options
that aren't available to the other four players.

> Add the trend towards soloability and the full-time players in an
> MCS environment have the ability and opportunity to dominate
> multiple "skill markets" as the wealth generated by the first
> characters funds the development of subsequent characters.

Yes, roughly, but I think it's important to recognise that even when
the wealth is *not* some resource in the game world... characters
after the first will still have advantages. Even in an SCS
environment. I for one will commonly make one or more throwaway
characters to learn my way around before committing myself to a
permanent persona; this is natural and normal behavior, reflecting
the wisdom of "look before you leap". SCS and MCS are really *not*
relevant to the root problem, which is that advancement is only hard
if the player has never done it. Once he knows, it's easy, and he
can advance at a much faster pace.

When we call this problem "account abuse", we commit the same error
in thinking that Scott Adams once revealed in a Dilbert strip --
"Problem: Bicycle seats are hard. They hurt. Analysis: There must be
something wrong with your pants." This analysis presupposes that the
problem is with the customer and not the product, much as we assume
the problem is with the player and not the game. When a player can
(and does) advance faster than we would like, this is not the player
abusing his account... it's the player playing the game exactly as
we have designed it to be played, and achieving exactly what we have
told him he should achieve. If that's wrong, it's not the player's
fault, it's the game's. We can't fix it by piling rules and
requirements on the players, we have to fix the game.

To be fair, sometimes we can't fix the game. It's already in the
hands of players, and we can't very well take it back. This is most
obvious in console titles; once the player has the game in his hand,
you are not going to patch or replace it without significant effort
and expense. MMOGs face a similar problem with problems in the game
world; while a client can be replaced cheaply and easily with a
downloadable upgrade, the game world really can't. Combined with the
rule of "never trust the client", MMOGs and console titles are in a
very similar place, where correction of problems after launch is
extremely difficult and potentially impossible for all practical
purposes.

However, we can't let this distract us from the reality that players
advance more rapidly with later characters because advancement in
the current crop of games *expects* players to be casual, and
thereby allows the non-casual player to excel. The catch-22 here is
that the rabid player who plays for 60 hours a week is your best
source of advertising, while the casual player who plays for 15
hours a week is your best source of revenue. Initially, your game
has to attract a large number of rabid players to ramp up the
playerbase, and in the long term it needs to retain a large number
of casual players to generate ongoing revenue.

The initial response to this would appear simple: design your game
to become boring. Let the rabid player have his fun for six months
or so, and then find that nothing remains to be done. The casual
player will need to play for years before he exhausts the content,
so the rabid players eventually become bored and drop off the
system, leaving only casual players.

The flaw in this thinking is that rabid players become attached to
their progress, and do not want to give it up. At this point, the
rabid player is trapped: leave all his hard work behind, or stagnate
in a boring game?  Neither is really acceptable, so many players
respond by making up their own games. Some of those games are
destructive to the other players, largely because the rabid player
is angry at the game for becoming boring. When administrative action
is taken, the rabid player feels cheated -- because, after all, he
only had to make up his own game when yours failed to interest
him. That's a losing battle, and nobody ends up happy.

To make a broad and sweeping statement designed to annoy people into
examining their priorities:

   Accounts are abused because the game has been poorly designed,
   period.

Wherever the game suffers abuse, we should make some notes to help
prevent this abuse next time, then make some effort to fix the
problem -- but recognise that the game is abused because the *game*
has a problem, not because the players have a problem or are just
inherently jerks. I think we can reliably expect that every game has
an imperfect design, and therefore that every game will be subject
to some amount of abuse, but the pursuit of ways to *prevent*
account abuse is occupying a lot of time that is (IMO) better spent
on improving the game for legitimate players. Instead of controlling
the way the game is played, it seems more sensible to control the
way the game plays -- and then let go of it, see what happens, and
step in only when absolutely necessary.

To use the common idea that your game is your baby, release is when
it grows up and moves out; you will certainly want to keep an eye on
it and help it succeed, but you can't hold its hand forever, and if
it can't stand on its own two feet you really can't do much about
it.


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev