This section discusses specific kinds of design problems and ways that you might solve them in Xconq. These are merely suggestions; in the past, game designers have come up with all sorts of ingenious ideas. If you come up with one yourself, please pass it along!
In some cases you may want to constrain the total number of units in play, perhaps because of performance reasons, or because some type tends to proliferate more than is desirable, or because your game concept requires a hard limit on the number of units. You have several ways to do this.
Xconq does give you several parameters that put a simple cap on total numbers, either by unit type or for all units, and per side or for all sides together. You can also define a material type that is essential to the creation, completion, or operation of units, and make that material be hard to come by. Iron to make ships, gold to pay armies, or food to feed armies could all work this way. If the only source of the limiting material is an initial supply in a starting unit, then this is a hard limit; if production of the limiting material is slow, then the limit is softer but still very real.
Limits on unit quantities have some interesting uses beyond the obvious ones. For instance, a useful type that is limited to at most a single instance could be a sort of "football" where the side that has the one unit finds itself being chased after by all the other sides trying to get it. You could make a WWII-era game with "Oppenheimer" as the only scientist who knows how to make an atomic bomb (I know, it's not realistic), and have the different sides trying to kidnap him.
Very rarely will the Xconq players in a game all be at the same skill level. Sometimes this is OK, since weaker players really do learn more from their losses than their wins. However, when the goal is to have fun, or when the difference in abilities is extreme, you can balance things out in several different ways.
One simple approach is just to design an imbalanced scenario, document it as such, and let players choose the stronger and weaker sides as desired. In many cases this should be sufficient; for instance, accurate historical simulations.
The next most simple solution is to set up sides or side classes and fill random properties differently. Weaker players could choose a side with more technology or whose class allows more powerful units. This isn't very adjustable, since all the sides and their property values have to be predefined.
To enable the most precise match of player abilities, you can use the
initial-advantage property of player objects. This property is
a relative value, defaulting to 1, and indicates how strong the initial
unit setup should be relative to the other players. For instance,
if a three-player game includes advantages of 2/3/7, then the second player
will have three units for each two of the first player while the third
player (the weakest) will have seven. The implementation of relative
advantages is up to game synthesis, so for example the make-countries
will adjust all the numbers of initial units to match the requested
advantages. Note that this affects only the initial setup, and only
certain synthesis methods.
Once a game has started, all sides are always on an equal footing.
A common form of game setup is to give each player a quantity of "money" of some sort, then give them a menu from which to buy things. The way you would implement this in Xconq is similar to the method for limiting unit quantities - make the money be an initial supply of a special material type not used for any other purpose. This initial supply should be given to a first unit that each player starts with. This first unit could be something like the adventurer in a fantasy game who starts with a pot of money, so the first unit is also the most important one, or perhaps a little dummy unit that buys the other units and then is of little interest thereafter, sort of like the national bank for the player's country.
Here's an example:
(unit-type adventurer (start-with 1) ) (unit-type shop (start-with 1) ) (unit-type sword) (unit-type armor) (unit-type boat) (material-type money) (table initial-supply (adventurer money 200)) (table acp-to-create (shop (sword armor boat) 1)) (table material-to-create ((sword armor boat) money (20 100 1000)))
The shop can't do anything besides create items when given money. The adventurer starts with the money and has to give it to his/her shop, then order the shop to create the items desired. The shop will create completed items instantly, ready for the adventurer to use. A slight simplification would be for the shop to start with the money itself.
Note that this can't be extended to buy extra intrinsic qualities, such as hit points or action points.
Some games, particularly wargames set in Napoleonic times or earlier, feature the concept of a "leader" as the sole individual who can make things happen. Without a general or field marshal, the army won't move. Whether or not this is truly realistic, it does have the effect of focusing the game on key individuals!
One way to do this is to make the leader be a self-unit and limit the distance of direct control over other unit types. Another way is give armies 0 acp and allow leaders to push them around, and still another way is to use leaders as occupants that add to an army's speed.
The concept of a navigable unbridged river is a real problem for Xconq. Non-navigable rivers are easily done as border terrain, and navigable rivers with lots of bridges can be connections (since by their nature, connections can never prevent movement). But a navigable river that can't be crossed easily is more of a problem. One way is to make a chain of adjacent cells of a water terrain type. However, this can be quite unrealistic if cells represent large areas, say 10-100 km across; you can end up with continents consisting of more river than land. In some cases, you can define a "river valley" terrain type where both vessels and ground units can exist, with the river border terrain along just one edge of the valley.
You can also allow border sliding. Border sliding allows a ship to pass along the length of a border, but it does require the ship to be in compatible terrain at both ends of the border. So define the river as a chain of alternating water cells and water borders connecting them together. Then the river acts as a barrier to units wanting to cross, while allowing them to see over to the other side, and at the same time ships can pass up and down the river freely (modulo any ZOC exerted by units on either side).
One of the problems that you encounter when defining a lot of interrelated units with lots of properties and tables is to decide where to start out with the numbers. There are a couple ways to get started.
First, you can start from real-world numbers. Let's say your game concept
is based on turns that last about one day, and you want to use worlds
with cells that are about 10 miles across. Now a person in good shape
can walk about 2 miles per hour, or 20 miles in a day, which comes out
to 2 cells/turn as acp-per-turn for units on foot. This allows
a speed of 1 cell/turn for injured, tired, or overburdened persons, via
the various speed modifiers. However, if this same game includes
automobiles and airplanes, then using the same calculation,
we get automobiles that can move 60 cells/turn and airplanes that can
move 600 cells/turn! The massive disparity in speeds makes for poor
playing; every turn each airplane will make 300 moves while the foot
traveller makes 1. To make the game work, you'd have to make airplanes
slower (they have to refuel a lot perhaps) or make people faster (nobody
walks anywhere anymore). So the real-world numbers approach isn't
foolproof.
Another way to go is to start with the smallest values and work up. For instance, in the monster game above, you could assume that the mob moves the slowest, and give it a speed of 1. Then you say that the national guard should be able to move twice as fast, and give it a speed of 2. Then the monster should be able to chase and catch mobs and guards that run away, so you give it a speed of 3 or more. This approach is more painstaking, particularly when lots of numbers are involved.
You can use both approaches together as well, working with real-world numbers until they get too weird, then adjust to make relative values sensible, then do some more real-world calculations. As always, only playtesting is the final arbiter. Once the numbers "feel" right in a game, only the obsessive-compulsives will care about their exact values.
Players are often unmerciful to their units, moving them nonstop, going into battle after battle, never a thought for how tired the poor units might be. Although Xconq does not include fatigue as a basic concept, it does have several ways to implement the effects of fatigue.
One way is to use acp debt. If you allow the acp to go negative during a turn, then the player can work the unit really hard for one turn, then it has to rest until its acp builds up to positive levels again. While acp is negative, the unit can take no action on its own. Over a period of time, the effect is that of a unit that can only do so much, but can exert itself when needed.
Another way to do fatigue is via a material type, perhaps called "energy" or "enthusiasm". As an abstract sort of material, don't let energy be passed around (unless you want to have "infectious enthusiasm", might be useful sometimes for leaders and morale builders). Units need energy in order to move, and can consume energy faster than they produce. For instance, if a unit has a speed of 3 hexes/turn, consumes 2 units of energy per move, and only produces 4 units of energy each turn, then on the average the unit will only be able to move 2 hexes in each turn, although if it saves up energy, then it can move the full 3 hexes. Since different kinds of terrain can have differing productivity, you can also make some kinds of terrain be more tiring than others. A resort hotel unit could also be allowed to transfer energy to its residents, restoring them faster than a Motel 6.
One special case to watch out for occurs in games with "unintelligent" units, that is, they have an acp of 0. If a side loses all of its units except for the unintelligent ones, the player will not be able to do anything except wait for the game to end. This might be OK, for instance if the idea of the game allows for a side to own a particular unit, whether or not it can do anything with it (perhaps the unit is a fort, and a side can win if it owns the fort, even at the cost of all its other units). Usually, however, the side ought to just lose, in which case you will need to define a special scorekeeper that requires each side to have at least one of some sort of unit with acp > 0, or else it loses.
[should go elsewhere]
The Xconq world can be made to revolve around its sun and to rotate on its axis. [etc]
To get a realistic hour-by-hour simulation, say
(world (day-length 24) (year-length 8766) ; this is 365.25 days )
The add form is very powerful and very useful for making
groups of objects share some data. The grouping also helps the
designer to see how sets of numbers compare to each other.
In other words, instead of having multiple forms:
(unit-type foo ... (acp-per-turn 3) ...) (unit-type bar ... (acp-per-turn 49) ...) (unit-type baz ... (acp-per-turn 2) ...)
you can say
(add (foo bar baz) acp-per-turn (3 49 2))
to get the same effect.
To get an inheritance-like effect, you can append lists of types together, as in
(define mammal (dog cat cow)) (define bird (hawk eagle condor)) (define animal (append mammal bird fishie))
which results in a list of seven types. It is possible to append different kinds of objects together.
There are many scenarios extant from the version 5 of Xconq. Many of them are good games despite some of the quirks of version 5 that they had to work around. Converting these scenarios to the new GDL syntax should provide some great new modules and at any rate provide a goldmine of ideas for updated Xconq game modules.
A set of conversion scripts are provided that will help to ease the transition from version 5 to version 7, but they won't save you from learning the new GDL syntax or features. These scripts will NOT generate working games modules, but they will generate valid GDL syntax, and thereby spare you much tedium in conversion.
The first thing to consider is the naming of the files/modules.
There are already some loose guidelines for naming version 7 game
modules (see section Game Module Organization).
Terrain or worlds should be in modules named t-xxx.g.
These are roughly equivalent to version 5 .map files. Collections
of units, such as the cities to populate world maps, should be in
files named u-xxx.g, where xxx generally identifies which
map they go with in addition to a general identifier (e.g. 1942).
Name generators are in files of the form ng-xxx.g, but you probably
don't know or care about these yet. And finally, if you are building
a set of scenarios based on a core set of rules, you should consider a
naming scheme that will link them all together so that players can
find them easily.
Having said all that, let's get on to the conversion. The conversion scripts go somewhat blindly on the assumption that you've split everything up in the "standard" way. That is, assuming that you've got a spiffy big scenario, that it comes in three parts: a period definition, a map and a scenario file. If not, if you've dared to combine some of these files, you should split them manually before starting the automated part of the conversion.
Convert the map using map2g. You want to use the -o option and your
new t-something name and the -b with a full pathname to the period
file that has the terrain type definitions in it. This allows map2g
to set the default base module and the get the appropriate character
list for creating the map file. The generated world will have its
circumference set to match the width of the generated area,
i.e. it will wrap from side to side.
This is because all maps are cylindrical in version 5.
Next, do a pass over the .scn file with scn2g.
Again you should use -o to get the naming the way you want it.
This should leave you with
a very pretty set of units and a very rough hack at a set of victory
conditions (i.e. scorekeepers). The scorekeepers will need to be
completely reworked, since they work rather differently in version 7.
Now the home stretch, convert the .per file with per2g.
Keep an eye on the output.
If it complains about "unknown keywords" then you've
probably used one of the more obscure features of version 5. Don't
panic because your obscurity will be preserved--commented out--in the
resulting game module.
Now you have to edit the module and start sorting out the
bits that per2g couldn't handle. Search for occurances of FIX.
These are lines inserted by per2g to note places that need
your attention.
per2g may have done nothing to the line except comment it out,
or it may have done a partial (or partially correct) conversion,
or it may have done a complete and valid conversion but wishes to call your
attention to related forms that can be added.
For this process you are going to need to have the documentation close at hand to make sure you get the syntax right. The best thing to do is read thru this chapter of the manual and then have the Reference Manual chapter on hand while editing the module.
Generally the place to start will be the make and maker
lines from the old period definition.
These are not converted at all by per2g
(because the machinery has changed so radically in version 7),
but are often essential to being able to start up a game. From there you
can work your way through the rest of the file with frequent references
to the manual and occasional test runs. Check out the debugging tips
in this chapter.
Xconq version 5 had a sometimes-useful flag called "setproduct" that could be set to false, with the effect that any attempts to change construction were disabled. So for instance, a city that was set by a scenario to build bombers would then build bombers throughout the game. The advantages were both in realism (retooling a factory can be very time-consuming) and in playability (no construction planning required).
To emulate this in version 7, you can set acp-to-toolup
to be zero for cities, but at the same time require 1 tp for each
type that the city can construct. In the scenario, set the value
of the city's tooling to be 1 for the one or more types that you
want it to specialize in (maybe switching between fighters and
bombers should be possible, but not to submarines).
Players can then start and stop construction as desired,
but are limited to only particular types.
Even captured independent cities can be limited in what they
can be used to construct.
An unwanted unit in a shared library file
could be gotten rid of by matching on id or
name and then setting hp to 0;
(unit "Corinth" (hp 0)), for instance, would eliminate
Corinth from an ancient Greek game.
Elevation data, while interesting to include, can take up a lot of space and be more detailed than necessary. The parameters here allow you to restrict elevations to a smaller range of values, which will allow for more compact encoding and simpler games. For instance, a game set in rolling countryside doesn't need a huge range of elevations; you could set elevations to range from 0 to 300 meters, in 30-meter increments. Then only 4 bits will be needed to encode each value, and yet the player will still see reasonable values like "150 meters", and formulas for temperature and other elevation dependent data will be correct.
Note that just because a player controls a side doesn't mean that the controlled side can be taken out of the game; for one thing, certain types of units will not change sides under any circumstances.
People materials should usually not be directly movable between units.
ZOC should be less than combat range usually, since it means that exerter should be able to control ground (but could attack further in multiple turns). ZOC levels should be only those reachable by the unit.
With all the costs of moving around,
it may be that a unit has movement points left, but
not enough to meet the full cost of a desired move action.
You can allow player extra movement points to complete the action
by setting free-mp to effectively add the needed mp.
A hit on a complete unit should reduce by whole cp/hp, otherwise it will appear to be incomplete. Xconq will not fix this, you have to arrange all the numbers yourself, or run the risk of player confusion.
Bases should "anti-protect" aircraft in games involving both, but fighters should protect the base.