[WF-General] Distinguishing Admin and Player

Tess Snider malkin at Radix.Net
Mon Oct 9 16:06:33 PDT 2000


On Mon, 9 Oct 2000, Bryce Harrington wrote:

> Newbie
Player.

> Average player
Player.

> Guru player who knows everyone on the server
Player.

> Mentor who walks newbies through the ropes of getting started 
Player.  On Amber, for a long time, we made it a policy not to provide
mentor lists, since we could not vouch for the quality of the advice
given.  I believe that later, we provided a directory of newbie helpers,
but made a point of putting disclaimers all over it.

> Bug chaser, who is into seeking out bugs in-game and reporting them 
It is your entire game community's responsibility to report bugs and
exploits.  This idea should be fostered in your game community from day
one.  You may even want to offer awards to particularly exceptional bug
reporters (e.g. you could give rewards to the person who finds the most
*new*, verifiable bugs and exploits each month -- but only if they're not
a source code contributor! ;) ).

> Tattler, who habitually complains about abusers to others
Eh.  This should not only be just regular players, but their identities
should be protected.

> Vigilantes, who take on task of "cleaning out" cheaters
I already commented on this.  In short, I don't think there should be such
a thing.

> One who composes background music for his guild and for others
All players should be able to do this, if they want.  (Like, wouldn't it
be fun to compose a theme song for your character, and have it trigger
whenever someone enters your abode?)

SECURITY ALERT:  Composing music that other players will hear may involve
transferring music files which could contain security threats.

> Player who draws character portraits for GM quests, for CP's
Again, all players should be able to do this, and again, there is a
security issue if players are going to be uploading files of any sort.

> Person who doesn't play, but submits bug patches sometimes
Huh?

> Developer who helps create quests, and has 5 char's in game
On AmberMUSH, the "plot coordinators" were usually regular old players,
but they often had localized builder privileges, and either permission to
use, or OOC ownership of any props that would be affected by the plot
(such as a castle, a construct of power, or a pirate ship).  If one was
coordinating a plot on someone else's turf, it was important to get it
cleared with the local coordinator, since that coordinator might know
some special things about the region that could throw some serious kinks
in the plot (for example, if gunpowder didn't work in a particular city
because of a magical shield), and because the local coordinator might have
access to some resources that could greatly enhance the immersion for the
folks participating in your plot.

Consider this, for example:

[Joe is the plot coordinator for Ashegrove, and Jack is the plot
coordinator for Mudhaven.]

Joe:  Hey, I'm working on a plot for the rival teamster's guilds in
Ashegrove.  The admins liked my last big plot, so they granted me a
special gift for them to fight over.  I've got a few small, named props
that I've created for the plot.  They're pieces of a puzzle.  I want to
put each piece in a different city.

Jack:  Cool.  You can put one in Mudhaven.  I know a great place to hide
it.

Joe:  Excellent!  But, I'm not sure how to give them clues, 'cause I don't
know anything about your city.

Jack:  Leave that to me.  I'll put a bunch of clues in the rumour mill and
shake it up a bit.  I can toss a few red herrings in, just for fun, too.

Joe:  Cool.  What will happen if the teamsters attack each other in your
city, by the way?

Jack:  They'll be going home in a pine box.  Might want to set up an NPC
to warn them about that.

> SysAdmin who runs the computer system
Admin.

> Which of the above would get "Admin" accounts, and which would just have
> "Player" accounts?  What functions would one type of account have, but
> the other not?

First of all, the only thing a player can ever do to another player is to
talk to him.  *Characters* can do things to each other, but not players.
Anything that involves doing things to players, other than talking to
them, is strictly administrative.  This includes banning players, placing
them on probation, putting administrative notes on them, and, in *most*
cases, granting privileges (in some cases, you may want to grant a player
the privilege to grant *another* player some minor, unimportant
privilege).

Only administrators should see behind the curtain, or play with the things
backstage.  This is an important principle, because seeing what lies
beneath the surface can destroy the magic of the game for a player.  You
may want to make special exceptions for certain types of builders or plot
coordinators (e.g. so that they can make scripted logical triggers, and
such).  Alternatively, you can mask the tasks that they are allowed to do
behind the interface.  For example, if a plot coordinator can construct
simple props for a quest, he doesn't have to know that he is creating an
Entity, whose Archetype is PlotProp, and that the Entity is Entity #2984
and that it has 12 properties.  All he needs to know is that he's making a
prop, and that it looks like a ruby ring, and that it can be worn on the
finger, and that it's part of a collection of rings that are part of a
recipe to complete his quest.  Ultimately, some privileges may be tied to
client modules that give the player extra tools to play with, without
using the full-blown admin client.  For example, you could have a plot
coordinator module that lets you view a map, with specially coloured dots
for all of the NPCs that belong to you, and other dots for triggers that
you own, and so on.  You can click on a dot to bring up the NPC or
trigger, and modify scripts, and other surface properties (perhaps Farmer
Jack lost an eye in that last big Orc invasion, and you want to change his
look to reflect that).  You could really make this stuff pretty neat.  The
builder and plot coordinator modules would come standard with the admin
client download, and would be add-ons for the regular client.
(Ultimately, you can run any damn client with any combination of modules
that you want, but the server will determine which things it's going to
allow you to do, and will block a whole range of capabilities from anyone
who isn't logged in via the admin port).

Tess






More information about the General mailing list