PBEM v92 n01 (15Jul92)

======================================================================
The Game Administrators' Corner                          Mel Nicholson
======================================================================

Game Administration of Semi-Automated Games

To the player, especially in a well-run game, it may seem that the
task of administration is a very simple, or even non-existent one.
You just send in your orders and the game just sorta takes care of
itself, right?

Unluckily for the game administrator, there is still plenty of work to
do in most semi-automated games.  The biggest job is maintaining a
player base.  The details may vary depending on the size of the game
and how much the sudden departure of one player affects things. The
one constant that remains is that there are a lot of net gamers whose
access is sporadic or who vanish during college vacations or suddenly
find themselves changing jobs and losing access, to say nothing of the
effects of computer downtime and the intrinsic quirkiness of e-mail.

As administrator of SPARF (a sports simulation of Australian rules
football), I've noticed a few strategies for dealing with this and
other problems that arise in game administration, and hope to pass on
my experience here. The first and biggest thing I can say about game
administration is to know your players as well as possible.  Are half
of them from Australia, and need breaks around their calendar?  Do
many of them have jobs that make weekend response time slow?  Or
perhaps they can only log in on weekends?  Whatever the case, it's
best to understand your players' limitations, as it will help you with
those regular scheduling decisions that always come up.

The biggest (or at least most common) scheduling decisions revolve
around holidays.  In most games you should plan on having to deal with
this, and will need to provide some manner for players to submit
orders in advance when leaving for a period of time, or at the very
least provide an autopilot which does not play too badly for short
periods of time.  Also, the players aren't the only ones who will go
on breaks, so try to leave room for your own absence from the game.
In this situation especially, a little communication will give you a
lot of flexibility.

Other than holidays, the other major scheduling problem is the battle
over pacing changes.  There are a few people, especially in military
simulations, who will lobby for faster and faster updates until you
are running a realtime simulator (which gratefully leaves the scope of
this magazine --- I don't have time for those games).  Counter to
these people will be those who worry (justifiably) that they will be
unable to compete (or even participate) at faster update rates.  While
there is no hard and fast answer to the question, it is a good idea to
keep things slightly slower than what the majority of your players can
handle, if for no other reason than to leave some slack for
emergencies (like email servers gone mad).  The tradeoff you are
deciding is one between overworking your players by moving too fast,
or boring them by being too slow.  At either extreme, you kill the
game, so look for a medium.

The next biggest problem non-developmental games have is player
dropout.  Unsurprisingly, player/moderator communication is a big help
here.  Some games don't have to deal with this problem, as players can
drop out without too much in the way of ripples, but for those that
can't, it is important to know who is likely to disappear.  For this
type of game, it is a very good idea to make a few hoops for the
newcomers to jump through, like submitting a couple of "practice"
orders or else having to respond to several rounds of email.  I base
this suggestion on the fact that about 80% of mid-season dropouts in
SPARF are during the first two weeks.  By creating a three week
pre-season which is played out for new players, but submitted all at
once for old players who have other things to do during this time, I
can screen out many players who will drop out early on before they
have a chance to negatively affect the game.  This sort of game also
works better with a healthy waiting list/player ratio (though in
practice the ratio always seems to be too small).

I hope these hints help you if you're planning on running or writing
these monsters.  Direct any questions or feedback to me at my account,
nicholso@pioneer.arc.nasa.gov, and I'll try to respond.  Next issue,
I'll try to write some notes on the game-in-development or "How to get
the most out of your playtesters without making them hate you".