From gl8f@fermi.clas.Virginia.EDU Sun Sep 27 18:10:25 1992
Return-Path: <gl8f@fermi.clas.Virginia.EDU>
Received: from nkosi.well.sf.ca.us by well.sf.ca.us with SMTP (5.65c/SMI-4.1/well-920924-2)
	id AA26499; Sun, 27 Sep 1992 18:10:19 -0700
Received: from Virginia.EDU (uvaarpa.Virginia.EDU) by nkosi.well.sf.ca.us (5.65c/SMI-4.1/nkosi-920918-2)
	id AA21534; Sun, 27 Sep 1992 18:11:38 -0700
Received: from fermi.clas.virginia.edu by uvaarpa.Virginia.EDU id aa10941;
          27 Sep 92 21:09 EDT
Received: by fermi.clas.Virginia.EDU (AIX 3.1/UCB 5.61/1.34)
	id AA43183; Sun, 27 Sep 92 21:09:56 -0400
Date: Sun, 27 Sep 92 21:09:56 -0400
From: Greg Lindahl <gl8f@fermi.clas.Virginia.EDU>
Message-Id: <9209280109.AA43183@fermi.clas.Virginia.EDU>
To: jerod23@well.sf.ca.us
Subject: Re: Frequently Asked zine Questions
Newsgroups: alt.zines,rec.mag
In-Reply-To: <Bv9BxB.DzD@well.sf.ca.us>
Organization: Department of Astronomy, University of Virginia
Cc: 
Status: RO

%Title:  PBEM
%Descr: electronic 'Zine about free play-by-electronic-mail wargames.
Reviews, game openings, information.
%Info:   Available on the Usenet newsgroup rec.games.pbm, or via ftp
from ftp.erg.sri.com, directory /pub/pbm/PBEM-Fanzine, or you can get
on a mailing list by writing gl8f@virginia.edu. No paper distribution
available.

Here's a sample issue:

======================================================================
@@@@@@@@@@@@      @@@@@@@@@@@@      @@@@@@@@@@@@@@    @@          @@    
@@``````````@@    @@``````````@@    @@``````````````  @@@@      @@@@``
@@``        @@``  @@``        @@``  @@``              @@``@@  @@  @@``
@@@@@@@@@@@@  ``  @@@@@@@@@@@@  ``  @@@@@@@@@@@@      @@``  @@  ``@@``
@@````````````    @@``````````@@    @@````````````    @@``    ``  @@``
@@``              @@``        @@``  @@``              @@``        @@``
@@``              @@@@@@@@@@@@  ``  @@@@@@@@@@@@@@    @@``        @@``
  ``                ````````````      ``````````````    ``          ``
======================================================================
A Fanzine for Free Computer-Moderated Play-By-Electronic-Mail Wargames
======================================================================
volume 92, number 3  (yes, volume 92 is the first)  september 15, 1992
======================================================================
Greg Lindahl, Editor                                 gl8f@virginia.edu
======================================================================

Table of Contents:

Opening Stuff

   o  The Editor's Corner

Articles

   o  Space 1992 -- PBEM For The Complete Beginner, by Luis Sequeira
   o  Game or Simulation?, by Luis Sequeira
   o  A Beginner's Guide to Galaxy, by Greg Lindahl

Columns

   o  The Game Administrators' Corner, by Mel Nicholson

Regular Features

   o  Game Descriptions & Information
   o  Hints about sending electronic mail to other networks
   o  What's this "ftp" thing anyway?
   o  Archives and subscriptions by email

======================================================================
The Editor's Corner
======================================================================

As predicted, this issue got held up because my article wasn't done,
and then I went on vacation to visit my girlfriend. Such a silly
editor.

As usual, I'm looking for submissions. I'd like to see strategy
articles for other games, as well as information about new games.

In game-related news, the Olympia playtest is now over. I hope that
Rich Skrenta will have the New and Improved Olympia running soon, as
it's certainly an addictive game. The first Star Empires game
finished, and the moderator is threatening to start another game,
although he's not sure if his schedule will leave him enough time.
And, last but not least, the new version of Galaxy is due out soon,
which will make my article obselete...

-- greg (gl8f@virginia.edu)

======================================================================
SPACE 1992 - PBEM For the Complete Beginner              Luis Sequeira
======================================================================

[ This is an article about an upcoming game -- the author (Manuel
  Arcangelo) hopes to go "public" with the game in November. -- editor ]

Having to live with a site which has an improperly installed network,
and thus unable to play most of the existing and exciting PBEMs around
the world, I found myself limited, until very recently, to the one
PBEM which is run from a site in my home country and is still in the
beta-testing stage.

SPACE 1992 is a Cosmos-like clone, but simpler, and with textual
orders instead of the Cosmos-gibberish like MIZST11ST14 (which
translates roughly as "Move 1 Scout from T11 to T14"). For those among
you who don't know the Cosmos game, it's yet another galaxy-conquest
type of PBEM, designed and programmed by Glenn Herrin [and currently
not publically-available -- editor]. In this game (as in SPACE 1992),
you play one of the different races in the universe in a free-for-all
exploration & conquest game, building starships, increasing your
industry or production (and thus building *more* starships) and
establishing colonies on new systems.

SPACE 1992 was designed for those who prefer a simpler game than
Cosmos.  There are lots of commands in Cosmos with very precise
meanings, but you always need to have some kind of table in front of
you to translate them to command lines like the one mentioned before
--- or have an astounding memory). This complexity slows down order
writing; SPACE 1992, using a neat, simple parser, accepts commands
like "move scout 1 to system t11" or "attack MyEnemy at system t14",
which is much more user-friendly for beginners, as you can easily spot
errors in your orders. The gamemaster also usually warns you if
something went wrong with your orders; it is most often a minor typing
error.

There are no races, and besides moving around with your spaceships,
attacking other players in other systems, transporting "production
points" to systems with industry, and building lots of starships (and,
of course, sending annoying messages to the other players), the game
doesn't have much more to offer. But the rules are so simple that most
of the time the gamemaster simply mails you some examples and off you
go to your private space conquest until you meet the borders of your
neighbors' empires.

Being so simple, turnaround time was significantly reduced over the
last months - from two weeks' time to about 3 days! This proved to be
the minimum time for email to reach its destination (with a large
margin for the gamemaster to send extra notes to the players). As it
is still in its beta-testing phase, players are advised that rules may
change during the course of the game, and suggestions are welcome, and
most of them are accepted (if they involve minimal programming).

======================================================================
Game or Simulation?                                      Luis Sequeira
======================================================================

Five years ago I joined a PBM (not a PBEM, mind you, but a
computer-moderated postal game) which is still running now, and which
was constantly upgraded from month to month, never achieving its
final, mature state (and it certainly never will). The game was one of
those with a fantasy setting (based somewhat on TSR's World of
Greyhawk, but without magic, only warfare and economics), and its
rules, while never having been considered to be simple, have grown and
grown to the point that its current gamemaster does not know them all
(he is the fourth one trying to referee about 250 players on the same
game).  There wasn't even ever a rulebook!

Much of this complexity was due to the fact that most players demanded
more rules and more freedom of choice, thus providing them (as they
proclaimed) more "reality".

In fact, the reports one got were quite extensive and needed some time
to read and interpret. And if you add to that the time required for
all your political/diplomatic messages, one could easily spend 4
or 5 hours planning your orders for one turn. But your lost time
was quite rewarding in terms of game play.

In its primeval times, the game was run on an Amstrad PC, using about
1 megabyte of dBase III code, and one turn's processing look about 8
hours of computer processing time (obviously not counting the time
needed to manually process each order form for all 250+ players) and
about the same time for all printouts. Now it runs on a 486 clone and
its 3 megabytes of Clipper code are processed much faster - but in
games of this size, bugs invariably creep in.

This was quite annoying for most players - but many of them actually
used them to their advantage. For instance, knowing exactly what kind
of orders to give to trigger some hidden bug could give that player
unlimited money, or unlimited movement points for his armies or
navies, or vast amounts of combat points for incredible small armies
(1 man!). Some of those bugs were so deeply ingrained in the system
that they soon become features (there was no other choice for the
gamemaster, except to rewrite large amounts of code, which in turn
would get some more bugs for the players to discover and exploit...).

On the other side, new rules were created to limit certain facts, but,
without careful planning done by the game creators, these rules soon
became new sources for bugs. For example, to limit the number of
armies, their maintenance costs were quadrupled; but the game allowed
the players to slaughter cattle in order to send rations to those
armies, which reduced the maintenance costs to their original prices.
Cattle reproduced each month by about 3%, and consumed some grain. But
players soon complained that having to raise cattle just to get it
into their armies was awkward; they wanted to include the cattle in
the army itself (which was somewhat logical, as in the Middle Ages
this worked that way). This was accepted by the gamemaster and
allowed. But he forgot the cattle-grain dependency; now cattle
reproduces 3% *inside* the army, and consumes *no* grain at all! Thus,
no one ever grows cattle (except for sale), nobody buys grain, and no
one converts cattle into rations (except to put it into fortresses to
increase the siege time - but this is more expensive than creating
*new* armies to intercept incoming enemies).  So, just because one bad
decision was made, the game has now obsolete rules that no one ever
uses, and the "reality" of the game has decreased...

This happened with lots of other rules. For example, spies were
necessary to obtain information on the movements of enemies and to spy
upon their fortresses - but one spy could only look at one hex at the
time, so great spying networks were needed. But players complained
that they should be able to give *all* the spies one single order and
get a map of *all* the enemies' territory, instead of getting
information hex by hex. This also was allowed. However, spies were
subject to counter-spies and police levels in the countries spied
upon, and information wasn't always reliable, and spies *could* get
captured and ransomed.  Nowadays, for the price of about 10 excellent
spies, you get a detailed map of the enemy country (like some kind of
satellite photo), which is not subject to any countermeasures by the
enemy...

Thus, the game degenerated to a kind of World War I battle-and-
conquest game, with medieval troops. Communication with your troops is
almost instantaneous, the economy has stock markets not unlike those
in the 20th century, enormous armies (80,000 men!) may be supported by
rich countries, sieges are avoided because it is so much easier to
"overrun" enemy fortresses by assaulting them (just 2 weeks' time
instead of many months...), pirates and Vikings have fleets to rival
today's superpowers, and so on.

Not quite what you would expect on a medieval-fantasy setting.

Soon the gamemaster abolished the idea that this was a "realistic"
game. It's just a game, with its set of rules, but nothing more than
that. Don't expect it to work as in the real world, they advised.

What is, then, a "realistic" game?

I have for some time now divided most complex games into two kinds:
the simulation, and the normal game. A simulation is a special kind of
game, where you may give realistic orders and get realistic feedback.
How this is accomplished doesn't matter much (I'll get to details
further on), but the important issue in a simulation is that you can
react to it as if you would react in the real world. The other kinds
of games have no resemblance to the real world; they have their rules,
and you play by them, but they are abstract, not connected to reality.
For instance, Chess is without doubt a kind of a wargame. But it is by
no means a simulation. The knight movement rule has nothing to do with
cavalry charges.

This doesn't mean that all simulations must have thousands of complex
rules and be terribly difficult to play! You can find simulations with
few rules (but still simulations nonetheless) which are easy to play,
and non-simulations like Chess, also with few rules, but quite hard to
master (I just can't play Chess at all, the computer always beats me).

Simulations need not depict *all* of the details of the real world. If
you know Avalon Hill's Advanced Squad Leader (ASL), you understand
what I mean: one *can* fight large-scale battles worrying about
weapons which don't fire or about the amount of ammo *each* of one's
men has. You need only to stick with a particular scale you want to
simulate and create rules for it.  Diplomacy, for example, has simple
rules (but is quite difficult to play correctly), and only two types
of units on the map - but it simulates only the diplomatic aspect of
warfare, and at that, it is quite excellent. There is no need to go
much more into details.

That computers are excellent for simulations isn't a new discovery --
just think about the supercomputers used for weather forecasting. You
can cram all levels of detail you like into them, and, in a game, just
show the players what they need to know. For example, in a WWII
simulation, you *can* use all the ASL rules to resolve your combats,
but HQ (at which level the players sit) only receives a report like
"Lost battle at Dunkirk, 52% casualties, 3 airplanes shot down". The
player gives orders like "Capture Berlin" and needs not write down all
details like "1st Platoon advances through the Brandenburg Arch and
seizes the Parliament; all units with heavy weapons deployed here, and
here, and there". Such orders would be appropriate on a tactical
simulation - on another scale - but never on a strategic/diplomatic
one! Of course, if you like, you *could* write zillions of lines just
to get your computer-controlled platoon leaders on the field to "act
like humans".  Please remember to buy your Crays first.

If you stay at the diplomatic/strategic level, the most complex game
you need to create is something like Avalon Hill's Empires in Arms
(which is not suitable for PBEMs at all, but you could make something
similar). Here you get to decide which leaders get which armies, and
how to join corps into armies. But you don't need to raise horses for
your cavalry, or buy guns for infantry! On the other side of the
simulation world, you may recreate just the Battle of Waterloo in
tactical terms - but then you wouldn't have to include economic rules.

You may ask why there are so few "real" simulations around. Well, for
one thing they aren't that easy to create. A "normal" game is just a
set of rules, and that's that. On a simulation, you must "hide" the
rules - i. e. the mechanics of play - under a layer of "real"
feedback. There is no point in talking about "Unit 52 stacked over
level 3 city has 5 combat factors and fires twice per round, losing
initiative when on the far side of river hex without type B-9 bridge
and gets only 53% offensive bonus". Wargamese is out; you want to know
about "Your 1st army didn't succeed in crossing the bridge and
suffered many casualties" and then react to it with "Ok, get to next
river crossing and try there". The rules are still there. But you
offer the players some kind of "interface" where they cannot possibly
know what REALLY is happening (in terms of random numbers, bonuses
added and factors calculated), and which they can control and
manipulate with everyday language - or "real" war jargon. While the
"kernel" of the game must be able to process turns just like other
games, the "realism" is experienced mostly on the "user interface"
from the side of the user.  However, it isn't that easy to combine
those two facets. Imagine a classical wargame where one ally says to
another "I'll take Berlin, while you advance on Hamburg and bomb it".
For us, humans, this is very easily followed on a mapboard. But how do
you get a computer to do this?

Fortunately, there is no need to get your doctoral thesis in AI to
write something like this. "Diplomacy" works fine, and there are
surely many other simulations. I think you could also put the
"simulation" label on Olympia, too, especially because of its weight
on some role-playing aspects. As you see, you can get simulations in
many areas, and not only with wargames. Simulations of stock markets
and elections are other examples.

One final note about simulations: it should be more difficult for the
players to find bugs - "features" - to their advantage than in other
games. If the orders you can give and the reports you receive are
"real", you have an advantage if you think in human terms, not in
computer terms. Thus, the emphasis is put on the way you play, not on
the rules you need to learn. This is easily seen in most wargames.  In
a war simulation, to achieve success, you must be a good strategist.
In a game, you must know the rules very well, and when to apply them -
especially that Rule #2463764, which gives your B Unit those extra 5%
firepower you need to smash a Z-15 tank, if you have refueled your
unit last turn...

About the author:

The author was never good at any type of wargame, has always lost
(except when playing Amoeba Wars, a 1980 boardgame, where he boasts
having been third place more times than everyone else), especially in
Empires in Arms where he plays Prussia until the last of his men dies
(which is always almost at the beginning of play), does play Chess
very badly, does not play Go, doesn't understand anything about
Military History, has been writing his first PBEM since 1987 and never
finished it, is proud of being able to write four-word English
sentences without (many) mistakes, and still thinks XConq is the best
game you can get on a Unix machine, or role-playing games on a Sunday
afternoon.

He can be contacted at bc@fccn.pt at almost all the time (but
is quite inaccessible from most sites in the world, including from the
computer on the same network next door), does not read news (proudly
never installed on *our* site!), and is playing something 90% of the
time and sleeping during the last 10%.

======================================================================
A Beginner's Guide to Galaxy                              Greg Lindahl
======================================================================

So you signed up for a game of Galaxy, and then you read the rules,
and then you wondered, "How on earth do I play this game, anyway?"
Or, like I did, perhaps you thought it was all obvious. Then you lost
your first game or two, and finally realized that you don't know it
all.

For those of you who've reached this stage, here's a little sage
advice from another beginner.

First off, let's talk about economics. In order to win, you're going
to eventually build up your population and industry to many times its
starting value. Since your home world starts off fully developed, you
must start colonies on other worlds. The best worlds to colonize are
ones which you can reach quickly, that are relatively large (more than
500 possible population), and that have Natural Resources ratings of
at least 1.

Once you've picked several worlds to colonize, you must bring in
colonists and capital. Since 1 unit of frozen colonists unfreezes into
8 colonists, it is relatively cheap to ship in colonists and
relatively expensive to ship in capital. The best cargo ship is one
that is as small as possible, i.e. with a cargo capacity of 1. I
design my cargo ships with no shields, and with engines just big
enough to reach several close-by planets in one turn. I pick this
engine size by drawing up a map of local planets and figuring out the
size of circle needed to enclose a reasonable number of worlds.
Remember that a full cargo hold weighs twice what it does empty, and
take this into account when you are picking the engine size.

Once you start colonizing a planet, it will start growing its own
colonists, at 10% per turn, and more capital, at 14-16% per turn,
depending on the Natural Resources rating. Note that a Natural
Resources rating above 1 really doesn't help you much more, but a
rating blow 0.5 really begins to hurt. I generally only bring in 1/4
the maximum number of colonists and capital; then the world can fill
itself up in about 14 more turns, while I colonize more worlds. (Clue
for the non-financially-minded: divide 72 by the growth rate in
percent to find the doubling time. It's called the "rule of 72".)

In order to be able to colonize new worlds, you have to be able to
defend them and capture territory, if necessary. So, we now arrive at
the general subject of ship design. The first time that I tried to
design a ship, I totally goofed it up, so I'd advise playing with the
numbers a bit.

The first thing to note is that shields become less effective as ships
become larger and larger: the number of shields is divided by the cube
root of the ship mass. Since a ship with an attack of 10 has a 50%
chance of hitting a ship of size 30 with 10 shields, this means that
ships smaller than 30 will have shields stronger than an attacking
weapon of the same size, and ships larger than size 30 will have
shields weaker than an attacking weapon of the same size.

A corollary of this point is that a very small ship with a shield of
1 can barely be hit by a very small ship with a weapon of 1. So, if
you want to design some small armed ships, it is much better to put a
small shield on the ship than to put no shield on the ship.

So, let's say that you want to design a big ship with no engines to
defend your home world. If you have 1000 industry and a Natural
Resources rating of 10, the biggest ship that you can build is of size
90. Let's say that we want to design this ship so that if a similar
ship attacked it, each ship would have a 50% chance of destroying each
other -- hence, you want an equal effective attack and defense rating.

This isn't what happens if we have 1 weapon of strength 45 and a
shield of strength 45. The mass of our ship is 90, so the effective
strength of the shield will be:

    strength = 45 / 90^(1/3) * 30^(1/3) = 30.8

So, a weapon of strength 31 would have a 50% chance of destroying our
ship with a shield of 45 -- so let's build a bigger shield and a
smaller weapon.

If you play around with the math a bit, you will discover that a
shield size of 53 and weapon size of 37 is optimal. The effective
shield strength is

     53 / 90^(1/3) * 30^(1/3) = 36.7

Now, you may be wondering, why am I multiplying by 30^(1/3) above?
This is a fudge factor that takes into account the statement in the
rules that a ship of size 30 with 10 shields and a weapon of size 10
has a 50% chance of hitting itself.

Designing a ship with engines is a similar process. Generally I pick
the speed that I want first, and then buy the weapons and shields to
be equal.

Once the game has been running for a while, you will want to purchase
higher technology. I would advise waiting to do this until the price,
5000 for one level, is no longer many times one turn's production. The
first level is the most important, as it doubles your movement,
firepower, etc. Once you are spending a lot of income buying ships, it
is often more economical to buy tech and ships than just ships alone.
Eventually, the smaller players without advanced tech will find
themselves easily wiped out.

Now, I'll pass along a few pieces of sage advice, mostly courtesy of
Howard Bampton. Armed scouts can get you into trouble in the early
game because many players won't declare peace until they have a reason
-- which means you'll be in a war with them if you encounter any of
their armed ships. I generally declare peace on everyone, but I seem
to be unusual. Ships that move will not fight any battles at the
planet that they start the turn at.  Finally, you cannot load a group,
move it to a new planet, and unload it all in one turn. Ships do not
arrive at their destinations until after all your orders are
processed, so the 'U' order must be given on the next turn. It is
possible to unload cargo, load new cargo, and move all in the same
turn.

Hopefully these Galaxy tips will help you survive those first dozen
turns or so. Good luck.

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

The Playtester

The one indispensable resource to a game designer is the playtester,
as no matter what genre or format the game takes, there must be
someone to play it.  Playtesters provide lots of very useful feedback
towards the design of a game, but they can also be a real burden on
the game designer.  To start, I'll try to categorize the playtesters
into a few large classes.

1: The hard-core enthusiast

This is the sort of players who wants to put a seemingly infinite
amount of time into the game.  Enthusiasts spontaneously generate
user-client aids, huge statistical analyses, start and run magazines
about the game, and provide all sorts of wonderful labour intensive
work.  For the most part, these playtesters are great, so long as you
can keep their efforts from drifting over into the sorts of things
which require too much work on the administrator's part (as they can
fill all of your free time if you let them, leaving none to put the
finishing touches on the game).

2: The bad loser

The bad loser is the all too familiar sort with a particular breed of
egomania who can't seem to accept that others might just get the
better of him from time to time.  I imagine these players flushing red
when they read turn reports, with foam drooling from their mouths and
pooling on their shirts.  They often become paranoid and will even
accuse the game administrator of tampering with
score/results/whatever.  If you are one of those, I have some advice
for you: calm down.  If my experience as an administrator is typical,
I usually run all the games and send out the results BEFORE I look the
results over to see who did well and who didn't.  We should all be
nice to our administrators and avoid being this person, and keep in
mind the difference between "Wow!  I thought I had that
battle/game/whatever sewn up.  How'd s/he manage to beat me?"  and
"What?  I had that game sewn up, who are you trying to kid?"  If you
REALLY think your administrator is out to get you and is willing to
cheat, just quit the game.  If that administrator was a jerk, then you
are safe. If you were being paranoid, then the poor administrator
doesn't have to deal with you.

3: The bungler

In every batch of players, no matter how simple your turn format is or
how carefully you explain what to do or when the deadline is, there
will be one person who can't cope.  That is the Bungler.  This person
can't type correctly, can't get things in on time, and often makes you
wonder how they managed to log in to a computer and send you mail in
the first place.  I am of two minds in dealing with this sort.  There
is a mean streak I try to suppress which says "Drop 'em --- no one will
notice" but I have a feeling that isn't the best way (or even a good
way) to deal with them, as often someone who has a little trouble
catching on will finally get their act together and become a really
good player.  Fines for errors and tardiness may help a little, but
for the most part only patience and reminders seem to work.

4: The dropout

This guy isn't evil, but s/he sure is damaging to most games.  The
dropout's modus operandi is to sign up for (usually many) games, sound
very enthusiastic and ready to go, and then disappear without a trace.
A few will at least warn you as they disappear, but most of the time
silence is the only notice that you get.  While you ignore a bad
loser's whining, plead with the enthusiast for lack of time, and write
better error-checking/recovery to deal with the bungler, it isn't easy
to deal with the dropout.  The easier-said-than-done method is to
"just screen them out in advance". Forcing the player to jump though a
few hoops when signing up (like a waiting period or having to submit
some orders which don't affect the other players before things start
in earnest) will eliminate many of them, but others will slip through.
Try to be verbose about what sort of commitment you want from your new
players, and make it clear what effect dropping out will have on the
others BEFORE you admit them to the game.  As a player, try to meet
the administrator halfway and ASK if you aren't told, then if you
don't think you have the time, don't sign up.

5: the invisible man

This guy just plays the game, and surprises you when he asks a
question because you'd forgotten that s/he exists.  While s/he
certainly isn't much work to maintain, s/he won't provide all the
support an enthusiast will either.  One important thing to keep in
mind is that this is the most common sort of player there is.  As
such, this person may be the best playtester of all, as they provide a
typical sample, and that which affects them is likely to reflect your
game's overall popularity.

However...

Real playtesters often won't be easy to categorize into the these
categories, since real people usually have more to deal with in their
lives than just your game.  Even Joe Enthusiast may find that
work/school/whatever intrudes upon his playtime occasionally, and
perhaps all the time he spent on the game instead of other commitments
will turn him into a dropout.  The invisible man may burst out with
some brilliant play or amusing press release, and the bungler may be
the first to pick up your new system.  I suppose bad losers won't
change much, but we can always hope.  Dropouts, for all the problems
they cause, are gone: replace them and go on.

Most importantly, remember that games are supposed to be fun.  Next
month I'll try to talk about methods for game automation unless
something really brilliant forces it's way into my head and demands to
be written first.

======================================================================
Game Descriptions and Information
======================================================================

Galaxy -- Galaxy is a closed-ended strategic economic/military space
simulation. The game typically takes place on a 100x100 2D map, with a
few hundred planets and 20 to 50 players. Players compete to capture
planets, which can be used for economic expansion. You may purchase
technology in many areas, allowing your ships to fight harder and move
faster. Galaxy turns range in size from 10k early in the game to
100-200k late in the game. Games are being run by the author, Russell
Wallace, and also by Rob McNeur, Howard Bampton, and the Generic
Gamer's Association at Western Washington University.

The rules and source code are available for ftp on ftp.erg.sri.com,
directory /pub/pbm/galaxy.

----------------------------------------------------------------------

Star Empires -- Star Empires is a simple closed-ended strategic
space-opera-style game. Game 1 just ended, and the author, Roger
Lincoln, is hoping to start a new game soon, although he is not sure
if he will have time. If the new game does get going, he will announce
it on the Usenet newsgroup rec.games.pbm. If you don't have access to
that group, but still want to play (the game turns are small enough to
be mailed to CompuServe), send me email (gl8f@virginia.edu), and I'll
keep you posted.

----------------------------------------------------------------------

Celestial Empire -- Celestial Empire is a closed-ended strategic
economic/military space simulation. Empires compete to capture worlds
which produce many different types of resources, of which different
amounts are needed to manufacture various items. Two games are
currently in progress, and the author, Dougal Scott, plans to start 3
more games soon. The rules may be ftp-ed from yoyo.cc.monash.edu.au in
the directory /pub/celemp. After you've read them, if you still want
to join a game, send your name to Dougal.Scott@fcit.monash.edu.au.

----------------------------------------------------------------------

Olympia -- Olympia is an open-ended economic/military simulation in a
fantasy setting, with a little role-playing thrown in for good
measure. The beta-test just finished and hopefully the next iteration
will be out soon.

----------------------------------------------------------------------

Diplomacy -- The Diplomacy Adjudicator is a fully-computer moderated
gamemaster for Avalon Hill's Diplomacy boardgame. To get more
information from the moderator, send email with the word "HELP" in it
to judge@u.washington.edu. Some information is available via FTP from
milton.u.washington in the public/misc subdirectory. All of the
information up for ftp is also available via the email server. As of
August 1992, there are roughly 120 games in progress, and 750 players
are registered. In addition to standard Diplomacy games, several
variants are available for either normal or anonymous play.

Diplomacy is covered by its own on-line magazine, which you can
subscribe to either by reading the newsgroup bit.listserv.dipl-l, or
by sending email with the phrase:

subscribe dipl-l Your Name

to the address listserv@mitvma.mit.edu

----------------------------------------------------------------------

Other games -- although it isn't exactly a wargame, an Australian
Rules Football simulation run by our popular columnist Mel Nicholson
has an email server and is occasionally looking for new players. For
details, send email to munch@soda.berkeley.edu with the subject
"help" to receive information about the game.

======================================================================
Hints about sending Electronic Mail to other networks
======================================================================

OK, so now you're wondering, "I'm using FidoNet or CompuServe or
FoobieBlech and those email addresses he keeps on talking about sure
look funny to me!". Welcome to the modern world of networking. See,
there's this big amorphous network called the Internet that lots of
other networks, like FidoNet and CompuServe (but not GEnie, yet) are
hooked up to. And you can send email between all of them, if you know
the right incantations. Often size or cost limitations will keep you
from being able to play games on another network, but at least you can
send me letters to the editor or articles.

Compuserve: If your ID is [76515,1122] then your canonical Internet
address will be 76515.1122@compuserve.com. The comma is replaced by a
period, and that's your username. Compuserve.com is the name of your
site. The .com on the end means that Compuserve is a business, and
also generally means it's in the USA. This address is the one that
non-compuserve people will use to talk to you.

To send mail from CompuServe to the Internet, you use this sort of
address: >INTERNET:gl8f@virginia.edu In this example, the ">INTERNET:"
part indicates that the email is going to the Internet, and
gl8f@virginia.edu is a normal Internet address (mine).

Compuserve users have to pay extra for mail to or from the Internet.
If you're a flat-fee user, the cost is 5 cents per 2500 characters,
minimum 15 cents, and the first $9 per month is free. This can add up
to a bit of money if you're playing Olympia, where a typical player
might get 500k of email per month in 100 messages.  In addition, the
maximum size for a given message is 50kbytes, and most Internet games
do not split their game turns into pieces if they are too large. But
you can try. Diplomacy, for example, should be ok and not that
expensive.

To go from FidoNet to the Internet and back is a similar process.
Actually, it's not so simple. I have a document that describes this,
but since FidoNet seems to be a bit of an anarchy, you can't even send
netmail from some nodes and others may not be configured properly to
send mail to and from the Internet. And, when you send email, someone
is paying to send it, or maybe there is a local gateway and it's free.
So, you should probably talk to your sysop first to figure out what's
going on.

Anyway, the long and the short of it is this: FidoNet users can send
mail to the Internet by sending normal netmail to the user UUCP, and
then on the first line of the message, put the line:

To: gl8f@virginia.edu

To send email from the Internet to FidoNet, you take an address such
as "Dale Webber at 1:105/55.0", and turn that into
dale.weber@p0.f55.n105.z1.fidonet.org. Again, this is subject to the
same caveats above about the gateway and the costs involved. From what
I've gathered (but I haven't asked recently), they ask that you keep
messages under 10k bytes and to only send two or three a day.  This is
a fairly small amount that would limit your ability to play Internet
games, but you can still submit articles to this fanzine (hint, hint).

If you want to avoid the limitations, yet don't know how to get
directly on the Internet, I can mail you a list of public-access Unix
sites with Internet email capabilities. Just send me a short note,
using the above info, to "gl8f@virginia.edu", and I'll mail a copy
back.

======================================================================
What's this "ftp" thing anyway?
======================================================================

ftp is an acronym for "file transfer protocol", and it is only
directly available to the privileged few who are directly hooked to
the Internet using heavy-duty hardware. There is a way to use ftp via
email, and if you can get email to me, I will send you a document
explaining how to use it.

======================================================================
Archives and subscriptions by email
======================================================================

PBEM is archived at "ftp.erg.sri.com". I will also be setting up a
mailing list to distribute this magazine, but keep in mind that it
will be posted on a regular basis to at least Usenet and CompuServe,
so if you're reading it now, you probably won't need to get on the
mailing list to receive it in the future.

======================================================================

PBEM is published monthly. Please redistribute it far and wide, but do
not modify or delete any articles.

PLEASE CONTRIBUTE! Our focus is primarily on free wargames, but we're
interested in articles about anything relevant.



