by W. William Stoll & Roger Burton
RECRUITING_PLAYERS
If you are recruiting from the internet, post an announcement to alt.games.vga-planets and/or rec.games.pbm with a subject such as "VGA Planets players wanted." Whatever your source of players, try to cover the following points when recruiting.
(Typical answers are shown in square brackets.)
o When will the game be starting (i.e. when will the first .RST files get distributed)?
o How often will turns be run? [Once per day; Mondays, Wednesdays, Fridays]
o When are the turn deadlines, and when will turns be sent out? If using internet, give consideration to international players by including a GMT time as well as your local zone. you want players to compress .TRN files before sending them back to you. Some common compression programs are ZIP, ARJ, ARC, and compress.
If you are using internet, leave at least a few days for responses to come in, and make sure you have connectivity to each player's site before starting the game.
o Will you be playing in the game? Some players don't like the Game Host to play, so its only fair to warn them off.
o What skill level will the game be? (In practice, what sort of player are you looking for?) [Novice, intermediate, expert]
o Which version of the game will be used? [Shareware or Registered; Version 2.x or 3.0?]
o Are private alliance negotiations allowed? [Usually, yes]
o Are player passwords in use? [Normally not, over Email]
o How should players choose races? ["State first three choices" seems to work well.]
o Are non-standard race names usable? [Up to you as host]
o What is the ending condition for the game? [First to reach a specified number of points; highest score on specified date; last player or alliance left alive]
o What is the game configuration:
- Distances between homeworlds? [Short, Medium, Long, or
Very Long]
- Mineral richness of homeworld? [Normal or Extra Rich]
- Starting Engine tech level? [1-10]
- Recycle rate of colonizing ships? [0-100%]
- Odds of a large meteor impact? [0-100%]
- Minefields allowed? [YES or NO]
- Alchemy ships allowed? [YES or NO]
o What subject line should Emailed turns carry? (Useful if you can extract files automatically.)
o Where should players send their .TRN files, and where should they address questions? If using internet, this usually means a clearly-specified Email address.
o Any other information. Remind internet players that they will need a uuencode and uudecode package. (You could use something unusual, like PGP radix-64 or xxencode, but its probably not worth it.) Uuencode is a program that will encode a datafile as text so that it may be treated as a text file. Uudecode translates the text file back to data.
Some Game Hosts compress .RST files before distributing them; if you do that, be sure that everyone has a copy of your compression program before you start.
GAME_SETUP
Select a directory to contain the data files for the game being hosted. Roughly 500K of space is needed for a game with eleven players. Running the game is easiest if the directory is a new, empty subdirectory of the directory containing the game executables.
For example, suppose you have installed the game at C:\PLANETS and wish to host two games in directories "game1" and "game2". Its recommended that the game data files be put in C:\PLANETS\GAME1 and C:\PLANETS\GAME2. This can easily be done using these commands:
c:
cd \planets
master game1
hconfig game1
master game2
hconfig game2
If it is not practical for you to host games in subdirectories of the game directory, that's fine. Any directory that meets the 500K space requirements may be used. Just be careful not to host two games in the same directory!
THE_GAME_CYCLE
HOST:_PROCESSING_TURNS
The HOST.EXE program processes the current game turn, and packages individual player turns into turn files which must be delivered to the appropriate players. Turn files have names of the form PLAYERx.RST, where x is a number from 1 to 11 corresponding to the player's race number.
For example, suppose you have installed the game at C:\PLANETS and are hosting a game in subdirectory "game1". The following commands will process the current game turn:
c:
cd \planets
host game1
HOST.EXE produces a few pages of output to the screen, and an error log in the file "ERROR.LOG" in the game data directory. If the Game Host has 300K or more of free memory, she/he can run HOST.EXE from a DOS shell.
The first time you run HOST.EXE (right after running MASTER.EXE and possibly HCONFIG.EXE), don't worry that there are no .TRN files in your game data directory; this is normal. This comment will make more sense when you read the section "HOST: PREPARING TO PROCESS TURNS (.TRN FILES)" below.
HOST.EXE has several caveats that have the potential to make players very angry with the Game Host. They do not apply to the run of HOST.EXE done right after the game is created. Here they are -- be sure you understand them!
1. If any .TRN files are missing, the game will continue with no problems. Ships and planets belonging to players whose .TRNs are missing will continue performing their last order. Ships will continue on the same course and speed, and planets will continue to mine minerals and produce supplies. Players are usually not hurt badly by missing a turn in this way.
This feature can be taken advantage of in playtesting. Order a ship to go to a destination that it will take ten turns to reach, then simply run HOST.EXE ten times (don't bother running UNPACK.EXE, PLANETS.EXE, or MAKETURN.EXE). Then play the turn, and your planet should be at its destination (if it had enough fuel!)
2. A missed turn CANNOT be made up! There is a turn counter that is incremented every time HOST.EXE is run, and this counter is kept in a game data file. HOST.EXE knows when a .TRN file was generated from a previous turn, and rejects it as stale. A message is printed, and the file is ignored.
3. If you accidentally forget to put the latest .TRN files in the game data directory before running HOST.EXE, then any .TRN files present will be rejected as stale, and all players will be treated as having missing .TRN files. DO NOT try to fix this mistake by putting the .TRN files in the game data directory and rerunning HOST.EXE! The .TRN files will simply be rejected, and the game will advance yet *another* turn.
The best way to prevent this sort of problem is to make a backup of the game data directory after every invocation of HOST.EXE. Also make a habit of backing up the most recently received .TRN files before running HOST.EXE. If there is a problem with the HOST.EXE run, restore the game data directory from backup, copy in the (hopefully correct) .TRN files, and rerun HOST.EXE.
4. HOST.EXE will display messages from the "TIM CONTINUUM" when two or more players in the game are using the same registered copy. HOST.EXE will punish such players in unexpected ways. It is strongly suggested that everyone register their OWN copy.
5. There is no reason for anyone except the Game Host to run HOST.EXE.
PLAYERS:_PLAYING_TURNS
Players select a directory for playing their game turns, and copy their PLAYERx.RST file there. Suppose their VGA Planets executables are in directory C:\PLANETS, they are playing this game using game data directory C:\PLANETS\MYGAME, and they just finished downloading PLAYER3.RST to C:\download:
c:
copy c:\download\player3.rst c:\planets\mygame
cd \planets
unpack mygame
planets mygame
maketurn mygame
UNPACK.EXE decodes the PLAYERx.RST file into data files that can be read by PLANETS.EXE.
PLANETS.EXE is the main program in VGA Planets; running it plays the game. Players should exit PLANETS.EXE when their turns are completed. If a player exits then suddenly realizes that they want to make a change, there is no problem rerunning PLANETS.EXE.
The turn can be replayed up to the point that the PLAYERx.TRN file (produced by MAKETURN.EXE) is delivered to the Game Host. This can be done by copying the backed-up PLAYERx.RST file to the game data directory, running UNPACK.EXE again, then running PLANETS.EXE.
MAKETURN.EXE converts the player data files into PLAYERx.TRN files, ready to be delivered to the Game Host.
When running on a single computer out of a single game data directory, the Game Host should be the only one to run UNPACK.EXE and MAKETURN.EXE.
PLAYERS:_RETURNING_TURNS_TO_HOST_(.TRN_FILES)
The PLAYERx.TRN files must be delivered to the Game Host. Here are some suggestions for various host scenarios. When game is being hosted...
o FROM A BBS: most BBSs support attaching an uploaded data file to an Email message. Alternatively, you can uuencode the .TRN file and Email it or post it as text. File compression/decompression is also an option, though the uploads/downloads are usually quite small (less than 10k).
o WHEN NO NETWORK AVAILABLE: simply copy the .RST files to individual floppies and distribute them to the respective players.
HOST:_DISTRIBUTING_TURNS_(.RST_FILES)
The Game Host will find PLAYERx.RST files in the game data directory after HOST.EXE is run (x is 1-11). These files must be given to the appropriate players. Here are some suggestions for various host scenarios. When hosting...
o FROM A BBS: most BBSs support attaching an uploaded data file to an Email message. Alternatively, you can uuencode the .RST file and Email it or post it as text. File compression/decompression is also an option, though the uploads/downloads are usually quite small (less than 10k). BBS hosts are advised to set things up in such a manner that .TRN files can only be uploaded by the proper players, unless player trust is not an issue.
o ACROSS INTERNET: usually uuencode the .RST file and Email it. Some Game Hosts may wish to lump all .RST files together in a compressed, uuencoded archive so that they can Email the same file to all players. In this case, player passwords should be enabled at game configuration time.
o ON A SINGLE COMPUTER: there is no need to transfer files if everyone is playing on the same computer, out of the same directory. If this is the case, the Game Host should run UNPACK.EXE at this time; for example:
c:
cd \planets
unpack gamedirname
then alert the other players that they can run PLANETS.EXE at their leisure.
o ACROSS INTERNET: usually uuencode the .TRN file and Email it. Some Game Hosts may want .TRN files compressed first, and/or may want a particular Subject line so that they can more easily automate the .TRN extraction process.
o ON A SINGLE COMPUTER: there is no need to transfer files if everyone is playing on the same computer, out of the same directory. If this is the case, the Game Host should run MAKETURN.EXE at this time; for example:
c:
cd \planets
maketurn gamedirname
o AND NO NETWORK IS AVAILABLE: simply copy the .TRN file to a floppy and deliver it to the Game Host.
HOST:_PREPARING_TO_PROCESS_TURNS_(.TRN_FILES)
The Game Host should backup the players' .TRN files, and copy them to the game data directory. Suppose the VGA Planets executables are in directory C:\PLANETS, the game data directory is C:\PLANETS\GAME1, and the current .TRN files are backed up in C:\download:
c:
copy c:\download\*.trn c:\planets\game1
The Game Host is now ready to begin the cycle again by running HOST.EXE.
MOVING_HOST_TO_A_NEW_COMPUTER
Its easy to move the game data directory to a new directory or even a new machine. Simply copy the game data directory and all its contents to the new directory or machine, and run the VGA Planets executables using the new directory. Of course, the VGA Planets executables must also be present on the new machine to be able to run the game!
For example, suppose I want to move a game from C:\PLANETS\GAME1 on machine #1 to C:\GAMES\PLANETS\MOVED on machine #2. One way to do it is to copy all files from machine #1's C:\PLANETS\GAME1 to a floppy disk, then copy all files from the floppy disk to machine #2's C:\GAMES\PLANETS\MOVED.
Then (assuming VGA Planets executables are in C:\GAMES\PLANETS\MOVED on machine #2), you can run HOST.EXE as follows:
c:
cd c:\games\planets
host moved