[Freeciv-Dev] Re: Threads!!??

[Jordan Crouse <jordanc@xxxxxxxxxxx>]

So my read is that this is best left to a client side AI system, spawned
and maintained locally.  My focus has been working on diplomacy primarly
for offline play.  Client side is a good solution, but I worry about the
scaling and complexity that it gives the standard joe who just wants to
fire up a game and play offline.  I normally set aifill to 4 or 6.  Do
we spawn 6 identical processes?  Is this better or worse than spawning 6
identical threads, or waiting for the server to crunch options for 6
different AI players?  I suppose that is a question for the
philosophers.

None the less, event processing is an idea who's time has come if server
side diplomacy is ever going to get off the ground.  But I yield myself
to the voice of the people, and I will back off of my server side work,
and offer my services if any of the client side AI folks need someone to
throw in a couple of extra cycles.

Happy hacking,
Jordan


Reinier Post wrote:
> 
> On Tue, Feb 06, 2001 at 05:03:20PM +0100, Fabio Lopiano (ELN) wrote:
> > What about having the AI players in separate client-like processes ?
> > We could have something like an ai_civclient process which will
> > run like any human client, getting all info from the network.
> 
> Yes, Raimar Falke, IQ and others are working on that.
> See the recent archives.
> 
> [Jordan wrote:]
> 
> > If not, then I am looking for comments on a couple of different options
> > for the AI to receive and process event packets:
> >
> > A) - Send the messages to the appropriate AI hooks as they come up in
> > the list, ie:
> >
> > if (i_am_ai) ai_send_packet(blah); else send_to_network(boah);
> 
> The server itself isn't multithreaded.  The AI players really don't
> participate in the asynchronicity of multiplayer mode.
> 
> > This has the disadvantage of delaying the sending of packets to
> > legitimate players while we crunch the AI.
> 
> Note if you put the AIs on localhost or even Unix sockets.
> That way you don't have to maintain AI-specific interfacing code.
> 
> > A2) - A slight variant on the above -- send all network packets first,
> > and then handle the hooks for all AI
> > This has the disadvantage of delaying the receiving of incoming packets
> > while we crunch the AI
> 
> It will always be a hack, though.
> 
> > B) - Add AI players to their own thread, and set them up with a socket
> 
> If you're adding a socket, why not let them be full network connections?
> (Unix sockets can be a generic option, also available for human players.)
> 
> I don't think programming with threads in C is feasible, you'll hurt
> portability.
> 
> --
> Reinier