There are several things one needs to do when starting a game (other than
getting players).

1) Porting & compiling the code [See doc/INSTALL for major details]
2) Creating a galaxy [See below]
3) Setting up a server or other way to do turns & forecasts. [See below]

                  Creating a galaxy

Code-wise, there are a few changes you may wish to make before you are
ready to mail out turn 0 reports.

In new-game.c, there are 3 constants defined: LOWHW, HIGHW, and RELPOS.

It seems unfair to players to have their homeworld in the first 99 systems,
or last 99 (?), since some players will do probe sweeps of those systems,
but not the middle ones. LOWHW is the highest numbered system that a homeworld
will not be. Similarily, HIGHW is the number of systems from the highest one
that can not be a homeworld.

A second problem is the quality of the starting positions. Standard galaxy
just throws homeworlds down 20+ LY appart and calls it done. Older versions of
Blind galaxy tried to balance things by moving size 0 and 1000+ worlds away
from homeworlds. I have redone the code, so that if BALANCE is defined, a
function is applied to all worlds near each homeworld, and the values of that
function can not differ by more than a factor of RELPOS.

The function gives each planet the following value, based on its distance
from a homeworld. (It is assumed that MINSEP is 30 for this table, changing 
it should change these numbers somewhat, but isn't done at present.)
   Dist    Value   Rationale
  >MINSEP    0     Probably closer to someone else, or at least distant
  <2.0       2.5   Really close, quick to top off.
  <5.0       1.25  Close, easy to top off.
  <7         1.00  Close, not trivial to top off
  <10        0.80  Most likely yours, but it'll take 2 turns for cargo ships
                   to get to it.
  <15        0.50  Three turns (or fast & small cargo in 2 turns), might
                   not be yours.
  <30        0.25  3+ turns, unlikely to grab it easily.
  30+        0     Not likely to have any influence on first 10+ turns.

At the moment, RELPOS is 1.2. For some games, this might take a long time
to create a galaxy that will work. Changing the galaxy size (bigger), or
RELPOS might be needed.

What happens when the best & worst positions differ by a factor of more than
RELPOS? The highest valued position gets a system moved away from its
homeworld, and the lowest valued one gets a system moved close.

Criterion:
  Best:
    The system that runs up the total the most, and which is unowned, is
    moved several light years away from the nearest homeworld.

  Worst:
    The system which is at least 2LY, and at most 25LY away and is of size
    at least 50 (no real point in moving small systems) which contributes the
    least is moved several light years closer.



Once you've got the tuning done to move_planet, find_bottom, find_top,
planet_value, LOWHW, HIGHW, and RELPOS, you are ready to go.

Edit the Makefile (as described in doc/INSTALL), and type
make New-game

If all goes well, there will be a program "New-game". Run it.

You will see something like this:
Galaxy v2.9 by Russell Wallace  <Date>
Blind  v2.42
Checking for existing blindrc....
Size of galaxy?

Give it the size of the galaxy (true size, not divided by 2).
You will then be given a ">" prompt. These are the options that you can
type from there, and what they do:
Q = Quit playing around, and finish galaxy
X = Exit without saving

+ = New random seed
D = Delete player
C = Create rest of galaxy
F = Full report on all systems
L = pLanet info
M = Map
N = New location for a world
P = Create Player
V = Version info
Z = RCS Version info

Note: You should create all your players ("P") before doing the rest of the
galaxy ("C"). Most of these options are detailed in doc/Notes.


One you've created the galaxy, and made any changes you desire, save it
("q"), and you are actually ready to do send out reports and set up your
server (if you are going to have one).


++++++
Setting up a server:

If you've got an account/mail-alias that you can set up exclusively
for player mail (orders and messages (if you are allowing anon-mail)),
you might perfer that approach. If you have fancy mail handling tools, such 
as procmail or mh's slocal, you do not need an exclusive @.

What your server may need to do:
1) Handle orders
2) Handle forwarded messages
3) Handle mis-addressed mail (about 5% of my mail is of this sort)
4) Handle bounced messages (this is a non-trivial task, espeically if
   one of your players is at a misconfigured site).
5) Handle report requests (maybe)
6) Handle player add/drop requests (maybe)
7) Handle message forward list enquires (maybe)
8) Handle rules/help/source requests (maybe)

Points 1, 3, and 4 are pretty much mandintory. 2 is nice for Blind games
(knowing the other player's e-mail @ takes all the fun out of it). The last 4
are tougher to do (I've only automated #7).

I've written a server for my games, which is an ugly hack. It is provided
in the source. Don't even bother to ask questions about it- most people just
write their own. The server does handle 1, 2, 3, 4, and 7 from the above
list.
