[Freeciv-Dev] Re: CMA passes back control without reason (PR#1505)

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Tue, Jun 04, 2002 at 12:53:06PM +0200, Christian Knoke wrote:
> > > Planning and achieving (long term) goals not neccessarily require
> > > a complex historic memory. There are three areas: 1) things of the past,
> > > most of them not affecting actual gameplay any more. 2) things
> > > happening right now, that's what the client can see, requires no memory.
> > > 3) things to come, nobody knows ;)
> > 
> > 1) is the main problem. I agree that data from 100 turns ago is not
> > much worth it (long life info like terrain or city positions). But an
> > AI would seriously handicapped if its memory is cleared every 5 turns.
> 
> Terrain and city positions, plus the age of the information, ok.
> 
> > > A small bit of memory is needed for 1), yes. See below.
> > 
> > The question is how small and if the agents delete the old data by
> > themselfs or if an external event removes the memory.
> 
> Of course the agents should learn to "forget".

It is also possible to record everything. And then let very old just
not weight very much.

> > > > > If the memory is client-sided, you have the sinchronizing problem. 
> > > > > Same
> > > > > problems as above apply also.
> > > > > 
> > > > > I think the only content of an agents memory can be user input, some
> > > > > presets, some goals and targets the user has defined. These data can
> > > > > be read and loosely associated to a loaded game by the client at game 
> > > > > start, always keeping in mind they may no(t) (longer) be valid. The 
> > > > > agents
> > > > > need the knowledge to realize the goals into specific action. And 
> > > > > there
> > > > > are other agents which will advice them.
> > > 
> > > Save the data local to the client. Server sends seed, randseed, and year,
> > > and the client is clever enough to find the right information. It does
> > > not *depend* on that information, but if it finds some, good. The 
> > > information
> > > *doesn't* need to be exact. Say "build a road from Rome to Valencia". If
> > > Rome has grown, doesn't matter. If Valencia no longer exists, forget about
> > > the road. Ignore the Information. Most information is about user 
> > > intentions,
> > > preferences, goals, planning - - not game data. 
> > 
> > > If you think about history agents, you won't find much things worth
> > > to remember.
> > 
> > Example1: An easy thing I want to implement is a road building
> > agent. It asks the history agent how many units have crossed this tile
> > in the last n turns and if the amout is larger than a threshold it
> > will give an order to the SMA to build a road (or a railroad) there.
> 
> I (as a HI) never build roads like this. I would end with a stochastic
> deployment of railroads, interrupted by roads and non-roads. ;) I'd 
> connect cities.

I don't say that this is the ideal solution or the only one. But it a
solution which has at least some bit of meaning. Also note that this
is in addition to building roads around the cities to increase trade.

> > Example2: for a good approximation of the gains of a given settler
> > action you need to know how much a settler can "produce" per
> > turn. This number can be calculated from the past.
> 
> That sounds strange. The rules seem to give the answer, no memory
> needed.

What do you mean with rules here? 

> > Example3: you can record the positions where your units got killed. If
> > you find a certain clustering it may be possible that the attack code
> > had underestimated the danger and your troops ran into trap. If you
> > don't have this information you would just send more troops and loose
> > them.
> 
> That sounds like a blind AI sending troops for no reason.

A player may not all information. For example it can't look inside a
city to estimate how many units are there. However if it had found
around 3 warriors in the last 5 cities conquered it can deduce that
this city has also around 3 warriors. So after killing 4 warriors in
this city how many more do you expect? This is IMHO a good and
difficult question.

> > So there are a lot of things you can memorize. There are different way
> > to do the bookkeeping: you can either record all raw changes (the
> > packets) or you can derive data of higher abstraction (as mention
> > above). The recording of the raw changes is probably more flexible.
> 
> I guessed you'd propose the "raw changes". I think that's bad. I'm much
> more for "data of higher abstraction".

This is more a technical decision.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Python 2.0 beta 1 is now available [...]. There is a long list of new 
  features since Python 1.6, released earlier today. We don't plan on 
  any new releases in the next 24 hours."
    -- Jeremy Hylton at Slashdot