Complete.Org: Mailing Lists: Archives: freeciv-dev: April 2002:
[Freeciv-Dev] Re: [RFC] Caching AI values
Home

[Freeciv-Dev] Re: [RFC] Caching AI values

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Gregory Berkolaiko <Gregory.Berkolaiko@xxxxxxxxxxxx>
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [RFC] Caching AI values
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Thu, 4 Apr 2002 16:47:08 +0200
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Thu, Apr 04, 2002 at 11:58:39AM +0100, Gregory Berkolaiko wrote:
> On Wed, 3 Apr 2002, Raimar Falke wrote:
> 
> > On Sat, Mar 23, 2002 at 03:09:07PM +0000, Gregory Berkolaiko wrote:
> > > 
> > > But first a couple of examples:
> > > ======================================================================
> > 
> > > Cached value: list of all own refuelling points of the type FUEL_CITY
> > > (basically the list of all cities)
> > 
> > IMHO the speed improvement for this is very small if only cities are
> > included. The problem are the airbases. To get these you have to
> > iterate over the whole map. What about a global airbase list? 
> > Mantained by set_special and clear_special.
> 
> Yes, this is very good idea.
> Still if you have 10 bombers and you consider them one-by-one, it make 
> sense to build the list only once.

It may make sense. But this doesn't neccessary gives you a speed gain.

> > > Counter increment: hooked up on events 
> > > --CITY_LOSS, 
> > > --CITY_ACQUISITION
> > > 
> > > Cached value: list of all friendly refuelling points
> > > (basically the list of all cities + non-occupied airbases + ally cities)
> > > Counter increment: hooked up on events 
> > > --CITY_ACQUISITION, 
> > > --ENEMY_DESTROYED (it could have been occupying an air-base), 
> > > --END_OF_PHASE (assuming that city loss can occur only during the enemy 
> > >                 movement phase)
> > > Note the event ENEMY_DESTROYED is higly unlikely to change the cached 
> > > value, so we can skip it here.
> > 
> > Same as above.
> > 
> > > So, ideally, 
> > > 1. The counters would be subscribed to certain events.
> > > 2. This "subscription" can be hardcoded.  
> > > 3. Counter <-> cached value relation can be flexible: one counter can 
> > > expire several caches.
> > > 
> > > Other possibly useful cached values: 
> > 
> > > enemy cities on the continent (useful for global invasion
> > > management, diplomat code etc)
> > 
> > It has to be tested how much faster this would be compared to a
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > for each player:
> >  if enemy player:
> >   for each city:
> >    if city.continent==continent:
> 
> Same as above: you have 100 units, why do this cycle 100 times if you can 
> just cache the list?
> 
> > > enemy targets reachable by unittype around a city (useful for
> > > bombers etc)
> > 
> > for each unittype:
> >  for area accessible with this unittype around city:
> >   if tile has enemy unit:
> > 
> > should be fast.
> 
> and same here yet again
> besides you don't just count enemy targets, you calculate the want, which 
> uses win_chance

I don't understand this.

> > > wonders built on a continent (useful for caravans and not building
> > > too many wonders at the same time).
> > 
> > Same as the first: list of cities for a certain player and continent.
> 
> In this case it might be faster.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Many of my assistants were fans of Tolkien, who wrote 'Lord of the Rings'
  and a number of other children's stories for adults.  The first character
  alphabet that was programmed for my plotter was Elvish rather than Latin."
    -- from SAIs "life as a computer for a quarter of a century"


[Prev in Thread] Current Thread [Next in Thread]