Re: Death of an advanced unit

["James R. Dunson" <jdunson at vt dot edu>]

At 03:49 PM 6/19/02 -0700, Lincoln Peters wrote:
> One more thing I saw was that the AI's attempt to use Brownian motion
> for colonization was almost completely ineffective.  This may have just
> been because the engineers couldn't use transports, but it also seems
> that the engineers should be able to more carefully pick a spot to build
> a civilization.  Perhaps Brownian motion is what you want when you don't
> have any effective explorers, but when it comes to colonizing planets,
> it is essential to know where you want to colonize and go to precisely
> that place.
  I've been thinking about early game strategies for the last few days as 
a result of the discussions here, and while I'm not much of a C programmer, 
I though I could present some sort of plan for discussion.  The following 
is based on my experience with "terrestrial" Civ-style games (Civ I, II, 
III; SMAC/X; Colonization; MOM; and others); IMO space-based games (MOO I, 
II; SE III, IV, IV Gold; etc.) require a slightly different approach.  In 
more general terms, I think the difference is whether terrain is fairly 
continuous (Civ), or more discrete (MOO).  I also assume that there is some 
sort of fog of war / unexplored map setup, although it should be 
generalizable to situations where the whole map can be seen (mostly by 
truncating the initial "view" distance to some reasonable limit for 
purposes of settling).

  The initial problem is "first city".  Some games start with the first 
city already present, in which case this whole bit is skipped, but in many 
game types you only have units to start.  If the cplayer has non-settler 
units to work with, it should initially walk them 1 turn in directions 
designed to reveal the most map possible in the first turn, before going on 
below.

  The cplayer should look at all the squares visible, and assign them each 
a base weight.  The enumeration and weighing routines will be used a lot at 
different stages, and should be largely compatible between games; the 
actual weights assigned should be an easily editable table (or a series of 
them), as it will need tweaking, and probably vary from game to game (or 
even within the game).  Note that this weight is *not* "what is this cell 
worth to a city" but is "what is the worth of a city placed in that 
cell".  (For speed, it may or may not be more effective to first build an 
array with the worth of the cells to a city, depending on the computational 
cost of calculating a cell's worth.)

  For a fairly Civ-like game, the weight would be based primarily on the 
total food and shields available, with bonuses for rivers, special 
resources, and coastal position.  This should be calculated based on 
initial value and predicted value; logical breakpoints to calculate for 
would be size 1 (initial), size 8 (radius 1 fully used), and size 20 
(radius 2 fully used), plus whatever breakpoint sizes are part of the game 
(such as size 6 (aqueduct / river) and size 12 (hospital)), and perhaps 
another early value (like size 3) if one is not otherwise present.  Values 
for future sizes would be depreciated compared to initial ones; something 
like value(size1) + 2/3 value(size3) + 1/2 value(size6) + 1/4 of each other 
size value, perhaps.  The depreciation ratios should probably be in a table 
for adjustment.  How much improvement is allowed for is a bit tricky; I'd 
probably handwave something like assume no improvements for size 1, roads 
by size 3, road and any single other improvement in a square by size 6, 
fully improved by size 12.

  This will give the cplayer a list of how cool a city would be if placed 
in any of the squares it can see.  It then needs to calculate how many 
turns it would take to get one of its settlers to each spot and start a 
city.  The value of each square will then be depreciated based on the 
number of turns "lost" in transit by a game-defined amount (in some 
settings, typically on small maps and/or simple resource models, plunking 
down a city immediately is a good idea; in others, typically large maps or 
those with more complex resource models, taking a few turns to walk to a 
prime spot for your capital is worth it).

  If the city has at least one square that exceeds a game-defined minimum 
adjusted value, it picks the best one (ties broken by size-1 value, ties 
there randomly broken) and gives the settler orders to go there and 
settle.  If it does not have a suitable site, it should walk its settler 1 
turn in the direction of the best available square (or the second-best 
square if it's already on the best one).  Next turn, again move other units 
to reveal more map, then repeat placement algorithm, but with a lowered 
minimum standard (and continuing to lower on subsequent turns to insure 
that it will eventually pick something).

  The system for placing later cities is generally similar, but I'll go 
into some of the differing implications in another post.

  Comments?

** James **

--
James R. Dunson (jdunson@vt.edu)
Network Administrator, Center for Wireless Telecommunications
436 Whittemore Hall, Virginia Tech     http://www.cwt.vt.edu/