This is the mail archive of the
mailing list for the Xconq project.
- To: email@example.com
- Subject: Re: Supply
- From: Stan Shebs <firstname.lastname@example.org>
- Date: Tue, 25 Aug 1998 19:54:05 -0700
- CC: email@example.com
From: Sami P Perttu <firstname.lastname@example.org>
Date: Mon, 24 Aug 1998 13:05:30 +0300 (EET DST)
The supply rules have evolved in my head into this over the weekend:
Looking good enough to try implementing! I've discovered that this
level of supply is about as much as you can expect to define before
trying out the algorithm - sometimes you discover that the tables
really don't work as expected, or that the tables expect too much
intelligence from the algorithm, and you have to add doctrine bits
or something to fill in the gaps.
I might prefer the term "interdiction" to "deterioration"...
-There is no limit to the distance supplies can travel.
Why wouldn't you just constrain supply zones to have no more than
a given radius?
I've already begun writing the new scheme. In the meantime, someone
should add the ability to display the cell control layer. Maybe
replace/augment the people display with control display? And use a
side's color instead of white for displaying the control boundaries.
Supply zones could be displayed by giving a color encoded supply zone
strength for each cell?
A "tree" of hairlines connecting cell to cell starting from the supply
source would be cool. Another possibility is a set of arrows placed
over borders, showing the flow of things.
If I could have a few bits from the Unit structure I could use them
That's fine, only one of the 16 available bits is in use now.
"Supply source" could be added as a unit type property, and isolated
units could be displayed by painting a suitable icon next to them;
but that is just a matter of convenience. Of course, in games that
rely heavily on logistics (A3R springs to mind: in that game being
isolated is a rather grave condition) it's nice to know if your units
are out of reach of any supply sources (even if they happened to
share supplies between themselves in the same turn). What do you
Yes, display is critical for playability.
The other thing to think about implementationwise is what AIs,
in particular mplayer.c, will do this new set of constraints.
At the very least, it would have to decide whether moving out
of supply range was worth the risk.
Are you building an actual game design that will use all this? I've
been on a campaign to either use GDL constructs in actual games, or
else delete them. Constructs that sound cool but aren't actually used
or usable just waste disk space.
In any case, I'm looking forward to seeing the code!
- Re: Supply
- From: "James R. Dunson" <email@example.com>
- Re: Supply
- From: Sami P Perttu <firstname.lastname@example.org>