Complete.Org: Mailing Lists: Archives: freeciv-dev: June 2002:
[Freeciv-Dev] Re: CMA passes back control without reason (PR#1505)
Home

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

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: freeciv-dev@xxxxxxxxxxx
Subject: [Freeciv-Dev] Re: CMA passes back control without reason (PR#1505)
From: Christian Knoke <chrisk@xxxxxxxx>
Date: Tue, 4 Jun 2002 12:53:06 +0200

On Tue, Jun 04, 2002 at 12:08:42PM +0200, Raimar Falke wrote:
> 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.

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

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

I need no memory to compute that, just the rules. The *task*, on the highest
level of abstraction, can be recorded.

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

The user can give the instructions. If she can't, it's no game.

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

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.

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

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

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

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

Christian

-- 
Christian Knoke     * * *      http://www.enter.de/~c.knoke/
* * * * * * * * *  Ceterum censeo Microsoft esse dividendum.



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