Complete.Org: Mailing Lists: Archives: freeciv-ai: July 2002:
[freeciv-ai] Re: time table for ai restructuring
Home

[freeciv-ai] Re: time table for ai restructuring

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: Raimar Falke <rf13@xxxxxxxxxxxxxxxxx>
Cc: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>, "Per I. Mathisen" <per@xxxxxxxxxxx>, freeciv-ai@xxxxxxxxxxx
Subject: [freeciv-ai] Re: time table for ai restructuring
From: "Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>
Date: Tue, 16 Jul 2002 23:18:08 -0400

At 07:47 AM 02/07/16 +0200, Raimar Falke wrote:
>On Mon, Jul 15, 2002 at 09:40:27PM -0400, Ross W. Wetmore wrote:
>> At 11:02 PM 02/07/15 +0000, Per I. Mathisen wrote:

>> The key elements are
>> 1)  The AI code doesn't directly access server structures and data.
>> 2)  The AI communicates with the server through the same types of
>>     channels that a client does. Note, this can be queuing packets
>>     into/out of the server packet stream/handler.
>
>Nice idea but this will require more work than you think. All map
>functions for example access the server map. You will have to
>duplicate common/map or add a parameter to every function. Same with
>civgame game and the players in it and all the other data structures.

I guess you just ruled out the pure client AI path :-).


But to specifically address the current server AI ...

Personally I think it is rather trivial to redirect all data structures
or functions to any local copies you want. I wouldn't even need a 2Gb 
boolish update or rename to do it - probably about one code line per 
struct or per file. And since the end goal is completely disjoint
operation, it wouldn't even have the constraints Mike had doing this
sort of thing for civworld.

The trick is hooking them up to the update system so the local copies
have useful data in them :-)

The map functions are the easiest. Most of the code to update a map
from a packet stream is already written.

But the task here is developing a model for how an AI manages incomplete
data since the packet stream sent to a client is pruned by the server.

In the server you can cheat during development by having any routines
that manage updates just wrapper the current data lookups until you get 
all the mechanics or extensions to the packet API working. What I mean 
is you can move the AI to an independent data model very quickly while 
actually hooking its backend up to any final packet queue subsystem over 
time - if there are any snags to stop you from just doing it.

Note, when you are done, you will have an AI with multiple personalities
rather than one personality or data source for all. 

>       Raimar
>-- 

Cheers,
RossW
=====




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