scorekeeping and materials

[mskala at ansuz dot sooke dot bc dot ca]

I'd like to design a game in which two sides fight over a scarce and
nominally indestructible substance; one side wins if they can possess a
certain amount of it, the other wins if they can prevent that by carrying
enough off the map to make that impossible.

My first thought was to implement it as a material; units could gain or
lose it in combat, and scorekeepers could watch the total amount possess
by units of side A and the total amount possessed by units of any side to
evaluate the victory condition.

First issue: I can't find a nice way for combat to involve capturing
materials from the enemy unit.  The best I can do seems to be for failure
in combat to always result in being wrecked or captured instead of
destroyed, and then have wrecks automatically surrender, making their
materials available to the winner.

Second issue: how to compute "total amount of material X possessed by
units of side A"?  There is a "sum" scorekeeper function, but it seems to
want the (atomic) name of a unit property.  "Amount of material X" is not
an atomic unit property - it is an element at index X in the vector value
of the "m" property.  I don't know the correct syntax for that.  (There
are, of course, other serious problems with scorekeeper syntax
documentation - this is just the one that seems worst.)

Third issue: I tried reading the source code to find clues to the
syntax, and as far as I can tell, the behaviour I want although partly
documented is not in fact implemented at all.  The sum_property() function
at lines 448-488 of xconq/kernel/score.c appears to only ever sum up
either the point-value properties, or a constant 1, for all units on the
currently-considered side.  If you specify a property then it silently
does nothing (executing the comment "/* should complain */"), and it
partially supports an undocumented syntax for specifying a particular
side, which if used, causes it to do nothing.  That's how I read the
source, anyway.

Fourth issue: what is a "test"?  Where are they documented?  The Users'
guide gives a few examples, but not enough to infer the actual rules.

Fifth issue: this one isn't directly related, but it sure would be nice if
I could make some types of terrain damaging (not immediately fatal) on
movement, not occupancy.  I have a unit (a school bus, as a matter of
fact) that can move pretty fast and safely as long as it stays on the
road.  Occasionally you might want to crash it through a fence or a stand
of trees.  You can do that, but it'll take damage.  Well, the existing
"attrition" and "accident" systems are evaluated only at the start of a
turn - so you can go through damaging terrain with impunity as long as you
are careful not to end the turn there.  I could make the damaging terrain
slow the unit down a LOT so it's harder to avoid stopping there, but
that'll quickly become unrealistic, and players will plan their turns
carefully and unrealistically to make their moves through damaging terrain
when it's safe to do so.  Also, if the unit remains in the damaging
terrain, just sitting there without moving, it shouldn't really become
damaged for that - the existing behaviour is to apply attrition at the
start of every turn.  The damage should ideally come specifically from
*movement*.  Maybe it would be reasonable for this kind of damage to be
associated with border terrain?  One problem there is that Xconq crashes
whenever I try to save a handmade file containing a border terrain type
(not the supplied files, but I haven't been able to figure out what's the
difference), which makes editing difficult.

Is there any hope?  Is it possible that the scorekeeping is actually
implemented somewhere, and I'm just looking at the wrong function?  Or is
advanced scorekeeping just an unimplemented feature and that's it?  Kind
of annoying if that's the case, because advanced scoring is documented in
several places as a significant feature of Xconq.  I grepped all the game
files that came with the package, but they're almost all using
last-side-wins.  The "cherbourg" file has a commented-out scorekeeper that
detects moving a certain unit to a certain cell, but the uncommented
behaviour is last-side-wins.  The remaining one or two files are using
point-value.

My thought on how to solve my immediate issue is to maybe represent the
scarce substance as "token" units that can be carried by other units,
captured, etc.  Then I can give the tokens a point value and use the
implemented scoring system.  That's likely to get annoying really fast,
though, if I have a unit carrying twenty or more tokens.
-- 
Matthew Skala
mskala@ansuz.sooke.bc.ca                    Embrace and defend.
http://ansuz.sooke.bc.ca/