[Freeciv-Dev] Re: multiplayer mode is all that counts

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Thu, Sep 20, 2001 at 08:03:16PM -0400, Ross W. Wetmore wrote:
> There is no reason why an AI cannot be built on top of essentially the
> same commands/protocol a human currently uses. Even for humans, one needs
> to carefully manage the data flow so it is neither too bursty for bulk
> processing and comprehension, nor too fine grained with latency problems.

For maintenance sake every client has to use the same protocol. This
protocol has to provide all essential commands. I think that the
current protocol can be slimmed in this respect. But only after the
unnecessary commands (auto-*, goto) are available to the user in
another way.

> Another way to think of this is developing an API or commandline style 
> (CLI) thin client layer with some data organizing/caching on top of the 
> protocol stream. Shell scripts and other low level processing functions 
> could efficiently interact through this interface to read and manipulate 
> raw model/data. Complex UIs can do there UI thing by interacting with an
> essentially local data store. But the split in low-level communication
> and core data updates vs human UI or AI-clients allows a lot of flexibility
> in plugging what you want on the top of the base client pipe.

It may a good idea to put another protocol above the network
protocol. This exists to some extend even now (C-API of common +
client).

About text based protocol and separate processes: nice idea and the
unix way. However there are some performance issues here. Consider
code which implements a goto functionality. It has to fetch the
terrain type of a lot of tiles. This will be expensive. Especially as
the goto code has refetch all information every time because it
doesn't know if something changed. Now you may think of caching the
information and that the common code may sent updates to the cache of
the goto code. However this just reimplements the network protocol a
second time.

> It would be really nice too if the server AIs read all their data from an
> internal stream/queue that was just a redirection of the typical client
> server flow, and sent their updates and queries back by this route. This
> may not be that difficult to actually implement, and part of the benefit
> would be a more even "round robin" mixing of server AI (and exceptional
> human players :-) queued actions.
> 
> With somthing like this you then have two interesting possiblities. The 
> first is self-contained server modules where you could plugin different 
> AI personalities. The second is stream filters where remote and server
> processing can be mixed depending on which actions the filter is told
> to handle locally and which it forwards to the remote human/AI client.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Your mail could not be delivered to the following Address:
  VTCMC.VTLPR@xxxxxxxxxxxxx        ** Unassigned error message **"