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

[Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>]

On Tue, Jun 04, 2002 at 11:13:38AM +0200, Christian Knoke wrote:
> On Tue, Jun 04, 2002 at 08:25:04AM +0200, Raimar Falke wrote:
> > On Mon, Jun 03, 2002 at 11:51:01PM +0200, Christian Knoke wrote:
> 
> [discussion about problems with saving attributes]
> 
> Thank you for your attention.
> 
> > > Here is the point where I don't follow Raimar. He claims that agents
> > > *need* to have a memory. But there certain are a lot of situations where
> > > this is impossible. 
> > 
> > > The agents have to (and of course will) have a way to start work
> > > from the "blank table".
> > 
> > > And thats why I think they shouldn't have a memory at all.
> > 
> > Without memory you will not see any planning which goes beyond the
> > current reflexive scheme. 
> 
> 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.

> 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.

> > > Think of an improved AI which remembers the positions of units it
> > > can no longer see. Want to save that? What happens if you play a
> > > single turn without the AI? All data lost?
> > 
> > What do you mean with without AI? 
> 
> Think of a game on civserver.freeciv.org. One player stops, another
> continues. Another client. Another client side AI implementation
> (aka agent). No agents at all. No client at all (--> aitoggle).
> So much can happen, you *will* have trouble with the attributes.
> You have it already with CMA (though it's not widely tested in the wild).
> The CMA has a good algorithm, but the attributes are error-prone.

Specific for CMA: IMHO the AI controller of the CMA will either
request general goals like "maximize science" or it will use the CMA
to micromanage the city: I want to build a settler, for this I need a
population of 2 = 14 food and 25 shields. How can this be achieve in
the smallest possible time?

> > The data is held by a history
> > agent. You can't disable it but you may clear specific parts of its
> > memory i.e. clear anything about player 3 because I just eliminated
> > him.
> > 
> > > If there is a server side, central, authoritative memory, you run into
> > > problems: some of them have been mentioned. 
> > 
> > > What if you use different agents for the same task? They can't share
> > > their data.
> > 
> > They can't share their data. Just think of first one as a neural
> > network and the second one as a prolog program. There is no automated
> > way to let them share their data.
> 
> Yes, but you expect the agents keep working, don't you?

The other agent will work on the instructions it receives. If it
doesn't receive instructions it won't work.

> > > What if another player continues your game, with another client?
> > 
> > They can't share their data.
> 
> s.a.
> 
> > > 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.

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.

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.

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.

> Store it in a way
> the client can interpret it still, when cities, units, and terrain has
> changed. - If the client can't find any local information, this only means
> the user has to input his goals and preferences again (if it is still the
> same user), and the client is a *bit* less knowledgeable about the game.
> 
> > > But you may say this is cheap talk.
> > 
> > So are this general objections or are you happy if the bandwidth usage
> > is reduced?
> 
> Just some ideas about agents.
> 
> The ultimate test for bandwidth usage happens after the release.

        Raimar
-- 
 email: rf13@xxxxxxxxxxxxxxxxx
    1) Customers cause problems.
    2) Marketing is trying to create more customers.
  Therefore:
    3) Marketing is evil.