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

[Caliban Tiresias Darklock]

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

> However, I would be interested to learn what a player "needs" to
> know that is so critical that it can't be learned in the process
> of normal game play.  Facilitating this process is why most games
> start up relatively simple with minimal risk and increase in
> difficulty.

The way I see it, it's not that they don't learn it through
gameplay, it's that learning it through gameplay involves making
mistakes they would rather not have made. Some mistakes are flaws in
the game, like "this skill doesn't do anything". Some are
deficiencies in the community, like "nobody speaks that
language". And some are just personal preference, like "it takes too
long to gain levels with a multiclass character". The next character
doesn't make those mistakes; certainly, he may make new ones, but
the character after that will not make those mistakes either.

> Secondly, a player can learn almost everything there is to know
> about a game from the various fan sites.  They have the cumulative
> knowledge of hundreds and thousands of players stored in neat
> little data bases.

The interesting question here is whether this is something to be
encouraged or discouraged. On the one hand, it may help the semi-new
player to make fewer mistakes and have a better gameplay experience;
on the other, it may prevent the same player from trying things
because another player has reached an erroneous conclusion. It has
impact, certainly, but that impact is variable.

My response to this has been to develop a highly dynamic world which
approaches outright chaotic. Knowledge about how equipment works is
useful; knowledge about the environment, however, is made obsolete
almost immediately. Most equipment is designed to develop happy
synergies with other equipment by doing very small jobs -- and, much
like the utilities that ship with UNIX systems, this job may be
utterly useless until you combine it with another job which is
similarly useless in isolation.

The primary problem here is that it takes a great deal of time and
energy to learn how all the hundreds of equipment options can be
productively combined; some things actually can't be combined, since
they accomplish tasks that are perfectly meaningless. (You can buy a
wet bar for your spaceship, for example, but this has no game effect
and will only enable you to imagine yourself enjoying a martini on
the bridge. Which is rather ridiculous anyway, since the ships are
ostensibly piloted remotely and there really isn't *anyone* on the
bridge. Or even a bridge, for that matter.)  This presents a serious
barrier to entry that we'd like to reduce, but I'm not really sure
how to do that without falling back onto the same old in-game help
and tutorial facilities that I hate so much.

>> 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.

> Or, a player chose a game that doesn't fit their style of play...

That's poor design. The player should have *known* it wouldn't fit
their style of play, and hence chosen a different game.

> or, they are "hackers" whose main goal it is to find loopholes in
> the code...

Loopholes in the code are always poor design.

> or, they are just an asocial person that likes to push the
> envelope to see how many ways they can piss people off... comma.

If your game doesn't provide the rest of the players an adequate
means to avoid being victimised by those asocial people, this is
poor design.

It is worth noting that "adequate" is a variable term dependent
largely on how undesirable it is to piss off the other players. Some
games can't function with pissed off players; others thrive on the
"sturm und drang" of heated interplayer rivalry. If pissing off
other players is actually a good thing, "adequate" is a very low bar
to surmount; if it's simply unacceptable, then pissing people off
has to be made well-nigh impossible.

Basically, the statement stands. No matter what reason a player may
have for abusing his account, the fact that he can abuse it is a
symptom of poor design. A perfectly-designed game simply *cannot* be
abused. The player who wants to abuse his account then discerns
readily that abusing the account can't be done, and he either leaves
or plays the game properly.

It's reasonably obvious that someone will respond with the
observation that a game where "abuse" is simply accepted and
considered part of the game would then be perfectly designed, but we
also need to remember that good *design* doesn't always make
something a good *game*. Teapots are well-designed, but they don't
make very good games. ;)

>> 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.

> Isn't this exactly what implementing an SCS policy intends to do?
> Control the way the game plays?

Well, yes. I'm for it, remember? What I'm against is the idea that
altering game policies after release is a good way to combat abuse;
it's more like the little Dutch boy with his finger in the
dike. Sooner or later, the dike itself has to be patched... because
hiring legions of little boys to put their fingers in the dike just
isn't a viable long-term solution.

As an aside: it's arguably more of a deterrent to make abuse
annoying to the abuser than it is to try and prevent it. ;)



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