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.