Once you've decided how to handle sides in your game, you can move on to the initial unit setup. Initial unit setup is very important, since it has a major bearing on how the rest of the game will go, and can be done in a number of different ways.
GDL allows you to define everything about every starting unit in the game. This is a powerful approach, but requires much preparation. An advantage of predefined units is that there are no unpleasant surprises. For instance, suppose you designed an empire game with ships and cities, but a random setup leaves some players entirely landlocked. Not only will those players be very unhappy, they might come looking for you before they've calmed down!
Asking for initial units is pretty easy, you can either type them into a file or create them directly, using the appropriate designer tool in a game.
(city) (city 11 12 1) (city (n "Brigadoon")) (city (@ 10 10) (n "New York")) (city (@ 20 10) (n "London") (hp 22))
The only info that you absolutely have to supply is the unit's type. If the position is missing, the unit will be placed at a random location. If the side number/name is missing, the unit will be independent or on the first possible side.
While the type, position, and side of units is important, exact values
of the other properties are rarely important for a scenario. Also, a
unit with fewer filled-in properties can be used in different games.
For instance, a list of the present-day major cities worldwide really
needs only name and location for each; the game design can fill in
everything else. One way to do this would be to set up an appropriate
unit-defaults just before including the module.
To make units start inside transports, you need to specify the t#
property for the occupant, and have its value be the id number or name
of some other unit. Your players may get an error message if the
occupant is not of an allowed type for the transport to hold.
Despite the advantages of predefining initial units, this doesn't help
when you want variable groups of units to appear in a randomly-generated
world. Instead, you should use the make-countries synthesis
method. The basic idea is that the method picks a good location for
each side's country, scatters an initial set of units around that
location, then possibly grows the country outwards. You can do anything
from small widely-separated countries to an interlocking nightmare
resembling pre-Bismarck Germany. Because of this, and because of the
requirement that this method generate random setups that are as fair as
possible, you have a great many parameters to work with. These
parameters should be tuned carefully - you will probably need to
generate and study lots of initial setups, especially if your parameters
constrain the countries very tightly; the method cannot backtrack to fix
a poor combination of placements.
The first step in country generation is to select a location for each
side's country. The location is a point that is the "center" of the
country (the exact value will be unimportant to players, and is not used
outside this method). The constraints are that the center of each
country is farther than country-separation-min from the center of
every other country, that the center is within
country-separation-max of at least one other country, and that
the given initial area of the country (as defined by
country-radius-min) includes numbers of cells of each terrain
type bounded by country-terrain-min and
country-terrain-max.
The reason for the separation constraints is that having countries too close together or too far apart can create serious problems. Consider the poor soul who gets tightly sandwiched between two enemies, thus becoming lunchmeat, ha ha, or the not-quite-so-poor-but-still-unlucky player who ends up on the wrong side of a very large world. (Keep in mind that your players may ask for a much larger world than you were thinking of when you designed the game.)
The terrain constraints help you put the country in a reasonable mix of terrain. For instance, if you want to ensure that your countries include some land, but be on the coast rather than inland, then you should say that the country must have a minimum of 1 sea cell and 1 land cell. (In practice, the values should be higher, so you don't get small islands being used as entire countries and lakes being considered the ocean.) Keep in mind that these constraints may be impossible to satisfy, for instance if a particular world does not have enough of the sort of terrain that is being required in a country. If the basic placement constraints fail, Xconq will just pick a random location, warn about it, and then leave it up to the players to decide on whether to play the game "as it lies".
;;; Keep countries close together, but not too close. (set country-separation-min 20) (set country-separation-max 25)
Once Xconq has decided on locations for each country, it then places
the initial stock of units. You define this initial stock via the unit
properties start-with and independent-near-start. The
start-with units start out belonging to the side, while the
independent-near-start units are independent. The locations of
these units are random within country-radius-min of the center,
but are weighted according to the table favored-terrain. This
table is very important; it is the percent chance that a unit of a given
type will be placed in terrain of the given type. 100 is guaranteed to
work, and 0 is an absolute prohibition. Since make-countries
tries repeatedly to place each start-with unit until it succeeds,
then even terrain with a favored-terrain value of only 10% will
get used if there is no other choice, so the table affects the
distribution of units rather than the number that get placed. If a
starting unit cannot be placed on any available terrain, but can be an
occupant, then Xconq will attempt to put it inside some unit already
present. This is a good way to begin a game with aircraft at airports
rather than in the air.
The upshot is that all this will do a reasonable layout if the
parameters are set reasonably. If, however, favored-terrain is
never > 0 for the start-with units and the country terrain, but
there is some other terrain type for which this would work, Xconq
will change the terrain.
This example is from the "classic" Xconq game:
(set country-radius-min 3) (add city start-with 1) (add town independent-near-start 5) (table favored-terrain 0 ((town city) plains 100) (town (desert forest mountains) (20 30 20)) )
The net effect is to give each player one city outright and 5 towns
nearby. Although created independent, these towns can be easily taken
over right at the beginning of a game, so they are a kind of "warmup"
(like the pushing of pawns at the beginning of a chess game). The
favored-terrain table allows cities to appear only in plains,
while giving more options to towns, since they can appear in deserts,
forests, and mountains. Even so, towns are 5 times more likely to be in
plains, which is reasonable.
In addition to defining a country by placing units, you can also have
the synthesizer add people to the country. People in the country don't
usually have a lot of effect on a game, but are useful for heightened
realism. You can have people on your side report on units passing
through their cells by setting people-see-chance. To set up
people, use country-people-chance to define the probability
of terrain in your country getting people. For most games, you will
want to set this to a high probability for land types, and to 0 for
sea terrain types.
The optional last step in country generation is to grow the countries
outwards from the initial area. This is basically a simple simulation
of the historical forces that give countries their variety of shapes.
You enable this by setting country-radius-max to a value greater
than the minimum country radius. The algorithm works by deciding
whether to add to the country each cell at each distance from the
country's center. The chance depends on the terrain type (via the
terrain property country-growth-chance) and whether the cell has
already been given to another country. If the cell belongs to another
country already (as detected by looking at its people), the algorithm
uses country-takeover-chance to get the probability of change.
Once a cell has been given to the country, then the method decides
whether to add a sided or independent unit to the cell
(unit-growth-chance and independent-growth-chance,
respectively), or whether to change the side of an existing unit
(unit-takeover-chance and independent-takeover-chance).
Country growth stops when the absolute maximum radius has been reached.
However, you can make it stop early if no cells are being added to the
country, by setting growth-stop-chance.
This example is from one of the variants of the standard game:
(game-module "standard"
...
(variants
...
("Large Countries" eval
(set country-radius-max 100)
)
))
The resulting effect is to make all the countries border on each directly.
In games involving materials, you have to decide how much will be in the game at the beginning. If materials are at all significant (and if they're not, why include them in the game?), then you need to ensure that the initial amounts are set up correctly.
The key table for this is unit-initial-supply. By default, all
units start out empty of all supplies. This may not be a good default
for materials that units consume, however; if the production process is
too slow, then your initial units may starve at the beginning of the
game. This can be especially annoying if the initial units starve only
because they ended up on less-favored terrain. To avoid this, you can
add a clause like (u* m* 9999), which, if material capacities are
all less than 9999, causes initial units to start out full. Note that
this applies to all units, irrespective of side.
In addition, if you want your game to be based on resource extraction,
you can also set terrain-initial-supply to give amounts of
materials to each cell in the world. [mention exhausted-type here?]