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

[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: Tony Stuckey <stuckey@xxxxxxxxxxxxxxxxx>, freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: [RFC] Caching AI values
From: Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 19 Mar 2002 21:52:24 +0100
Reply-to: rf13@xxxxxxxxxxxxxxxxxxxxxx

On Tue, Mar 19, 2002 at 08:36:02PM +0000, Gregory Berkolaiko wrote:
> On Tue, 19 Mar 2002, Tony Stuckey wrote:
> > On Tue, Mar 19, 2002 at 02:47:28PM +0000, Gregory Berkolaiko wrote:
> > > > There is another solution possible:
> > > >  3. Update the value whenever this is necessary
> > > 
> > > You probably mean "whenever environment changes".  It is a very good 
> > > approach.  But again there are arguments against it:
> > > - too complicated: go trace all events which lead to "cnahge in 
> > > environment"
> > > - you might be doing all this in vain --- how do you know that these 
> > > values will ever be accessed?
> > > 
> > > To implement 3 we would have to rewrite half of Freeciv to be 
> > > event-driven 
> > > system.
> > 
> >     My gut says that this would really only have to be re-evaluated
> > when a unit is killed.  Of course, I might be thinking a bit too much in my
> > preferred turn-based paradigm, where targets don't move out from under you
> > while you try to figure out how to kill them.
> That might be right, but let's have a look at the overall picture:
> 1. Unit A thinks about moving to city C to kill things around.  The number 
> of things to kill around C is calculated and recorded in struct city C.
> ----

> 2. we are doing other stuff, but whenever we kill a unit, we have to 
> figure out if it was counted in the targets_around_C and if it was, 
> subtract its value

This would indead hard. What about "update these targets_around_foo
counter of all cities after a unit is killed".

> 3. Now unit B thinks about moving to city C and it can use the up-to-date 
> number of targets around.
> I think that doing part 3 is technically difficult.  I guess we would need 
> to create a list of cities for which we counted targets_around, together 
> with max distances at which the targets were.  Then when we have a dead 
> unit, we iterate around it to see if there are any cities from the list in 
> the neighbourhood.  Sounds very much like fog-of-war, only maybe harder.
> Undoubtedly this is how the things should be done.
> But I am not keen on doing it right now.
> I think time approach would perform quite well (on average).


 email: rf13@xxxxxxxxxxxxxxxxx
 "> WHY?! Isn't it better to put $(shell cat cscope.files) on the list of
  I only have a yellow belt in makefile kungfu.  These fancy gnu make things
  are relatively new to some of us..."
    -- Mark Frazer to Vassilii Khachaturov in linux-kernel

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