HINTS

   Please report all bugs to me, E-mail S.Emerson@GEnie.COM. If you report
a bug, I will ship you a fixed update as soon as possible with your bug
fixed.

   After doing a couple of modules myself, and offering advice to others
who are doing modules, I've found some ways of doing things seem to work
better than others.  I'll try to pass some of these on here.

When you start designing a module, do a little preparation work first.  How
many hexes high and wide will your module have to be?  It's unwise to set
the map limits to that exact number when you initialize the module.  I've
found that a two hex pad on the edges all the way around may give you some
room to make mistakes in.  This can be visually negated by filling the
padded area with a grey hex image with no borders.

   You should also decide how many units you need in the module, and how
you're going to portray them.  Which unit data fields will hold what data? 
Will the data be summed together within a stack, or will the program only
show the lowest value of that field in a stack?  Some games have step
reductions for losses, and one "unit" might have two or more sets of game
values, depending on what step you're looking at.  Will these be portrayed
by one unit with two sides, or by two different units within the module? 
The latter will allow for the values to be computed correctly, even with
reduce-stepped units.

When you get to the map editor, do a quick layout of your game map, but
avoid doing detail work at first.  If you need to put a coordinate system
on the map, you should do so early on, as redoing coordinates will erase
existing hex names.  The default coordinate system names the hexes after
their X and Y coordinates. If you are playing with an opponent who doesn't
have the Game processor, or you want 100% accuracy, you may want to rename
the coordinates based on whatever system the game actually uses. The "Do
Coordinates" button will allow you to select a coordinate system for your
game. If you don't see the system you need, E-mail me with details.

   Using color zero in your artwork allows you to have clear spots where
you can literally "see through" the artwork to what is below.  To
understand the way the map works, think of it as two layers. Layer 1 is the
bottom layer or underlay, and shouldn't have any color zero in it. Layer 2
is laid over layer 1, and should have some color zero in it somewhere if
layer 1 is to be seen through layer 2. This allows you to lay features such
as cities, rivers, and coastlines over standard terrain types. Layer 2
images are limited to image numbers 1 to 125. Layer 1 images are numbered
from 126 to 400. Results may be less than desirable if color zero is used
in layer 1 or not used in layer 2. Since only one image may be assigned to
each layer in a hex, some forward planning might be in order to best
optimize your image resources. For instance, would it be better to place
your city images in layer 1 or layer 2? If in layer 2, will any unique hex
images be required if a city is adjacent to a river? 

   When initially laying out your map, you may find it necessary to blank
out the left-most hex on all the odd rows so that your map edge will match
the game you are modelling. One of the games I used to proof much of this
code by installing was World in Flames, which uses off-map area movement
out of the play area, and so the actual hexagon play area started two or
three hexes from the game processor edge to give room to draw these areas. 

   Rivers come in two flavors: hex edge and hex-to-hex. Some sample
hex-to-hex images have been provided in the default image library, and
should cover most requirements. These should be placed in layer one, but
may be edited to work in layer two by making everything but the river part
of the image color zero. For rivers, roads, coastlines and other terrain
features that extend from hex to hex, the hex editor has highlighted the
center pixel on each edge in red to make it easy to line up features from
hex to hex.

   Be sure when designing terrain to avoid horizontal lines of only one
pixel, or lines with odd numbers of pixels in the horizontal. Also avoid
dramatic color contrasts. This will help minimize screen flicker on non-ECS
machines which can be quite distracting.

   Hex edge river images provided with the default image library provide
all the standard combinations of rivers possible in a hex.  The way I
worked these to use as few image slots as possible was to only draw rivers
along the upper and left hex edges. If you need a river along a different
edge, just draw it in the next hex in that direction. Sometimes a hex may
have more than one hex edge symbol, for instance there are several hexes in
Third Reich which have border, river, and front boundaries. These must be
dealt with individually.

   You may have to add to these images if additional hex-edge symbology is
required, such as borders, weather areas, etc. For best results, limit
hex-edge symbology to the left and top sides of a hex. Right side or bottom
edge symbols can then be done with the same symbols by using the left side
or top of adjacent hexes. If you have to draw borders along the hex edges,
for example, you may want to copy each of the river images in the terrain
editor and change the color to black, or whatever color you want your
border to be. Unique images may have to be created as needed if, say a
border and a river share the same hex edge. Hex edge rivers are also useful
to delineate sea areas against borderless light blue seas. 

   Images will initially be placed in layer one. Images may be placed in
layer two by pressing the "Place Underlay" button. When this button is
pressed, the image will automatically be changed to the first default
hex-edge river image. To return to layer one, simply press this button
until "Place Underlay appears again. If you wish to remove an overlay
image, press this button until "Erase Overlay" appears.

   It's easy to lose track of what you've done on a large map, and you
might duplicate terrain features.  If you find that you've done this, you
might want to eliminate the duplication, but you want to be sure you get
all the hexes that are affected by the duplication updated. I found that if
you use the terrain editor "Reverse F/B" function to change a prominent
color to, say red, it makes it real easy to spot all occurrences of the hex
in question. You might also find that you made some images that you ended
up not using.  Use the usage report in the function menu to identify which
images are unused.

   You have eighteen forcepools which you should name.  Try not to give
different pools the same name, even if they're not used, because the user
will only have the name to tell him where he is as he's flipping through
the pools.  Even if you label them "unused" you should attach a number or
some other unique identifier to each name.

   The Order of Battle editor can be a lot of work if it's not approached
in an orderly fashion.  One key thing to remember is that the order that
you enter the units in the editor will be the order that they are displayed
within a stack when you load a saved game.  This may or may not be
important to you.  Future versions of the WarGame Processor may be able to
preserve the order within a stack through a save and load process.  It's
easiest to make one unit of a particular type and copy it over and over as
many times as necessary, then go back and change the details.  It's a good
idea to indicate the nationality of the unit in the name, to make
references clear in combat text.

   Before you start working on your units, you should determine what values
should be computed from the unit as it sits in a stack, and in what order
these values should be displayed.  The WarGame Processor player will
display the values like this above the hex roster:

     Val1           Val4
     Val2           Val5
     Val3           Val6

   Decide on a 4-letter name for each value.  You may want to delete value
names that are not used.  As a general rule, games that need more than six
values for each unit make poor PBM candidates.  Be sure your values are the
way you want them, because it's a painful process to go back rearranging
the data for every unit.

   The counters provided in the game don't necessarily have to be
reproduced exactly in the module.  Text on the counter can often be done as
part of the unit name, for one thing.  You should decide which factors are
necessary to be shown on the counters, and which would do the job just as
effectively as computable values to be shown to the right of the map.  You
should avoid putting too much information on the counters, or cluttering
them so that they're unreadable.  Often different classes or nationalities
may be designated by different colored borders.

   Once you've made your map, detailed the order of battle, named your
force pools, and are satisfied with the whole thing, you are ready to move
to the WarGame Processor play program.  When you first load a module into
the play program, all the units appear in the upper left corner in one huge
stack.  Large stacks like this tend to cause slowdowns when you're picking
units up.  You should provide a setup saved game file, with the units
broken down into smaller stacks, maybe by type, and possibly placed in the
correct area of the board.  Some games which have a fixed setup should have
the units placed in their startup positions.  Perhaps you might want to put
some units in the correct forcepools at the setup.

   You should keep notes on the game module and provide them with the
module as a README file.  Identify where you made a compromise between the
board game and the module, what the different values mean, and how you
arranged the forcepools.  You should also state who the original publisher
of the game is, provide their address and phone number, and tell how
someone can acquire a copy of the game, if it's not one of the more popular
games.

   When you are ready to distribute your module, you should provide the two
data files ( .GPF and .GPD) from the modules directory, the suggested setup
file from the savedgames directory, and the readme file detailing your
notes on the module.  If possible the files should be archived in place in
their proper directory.  If you upload to a network, you should have the
word "WGP" as one of your keywords, and clearly identify it as a WarGame
Processor module, and that ownership of the WarGame Processor and the
original game are required for play.