[Freeciv-Dev] Re: [PATCH] Unit movement

[Reinier Post <rp@xxxxxxxxxx>]

First of all, I'm very thankful as a Freeciv user to see
the problem of client-side AI being addressed in code.

On Mon, Jan 15, 2001 at 08:47:54AM +0100, Raimar Falke wrote:
> On Sun, Jan 14, 2001 at 05:53:59PM -0800, ccrayne@xxxxxxxxxxx wrote:

[among other things]

> > Thus, as long as I am running on a fast, reliable network, I have no need
> > for any additional feedback. If I get a unit info packet within a
> > reasonable time, then the movement took place, otherwise, the movement is
> > blocked by factors beyond my control.
> 
> The programming model would be event driven. In code which is
> "algorithmic" (for example a loop over every unit under control and
> issuing commands) I think such event driven programming isn't nice.

Maybe so, but this is Freeciv's fundamental mode of operation!

Freeciv was designed as an asynchronous message sending system in which
there is no feedback for requests.  The two of you seem to approach the
task of writing client-side AI algorithms as if you're really dealing
with a synchronous RPC-like system in which the client issues a
request, waits for the feedback, then continues its operation.

Thanks to Freeciv's asynchronous design, a player can specify orders on
hundreds of units and cities in parallel, even when the connection is
down, and have these orders queued up and processed on the server as
they arrive.  Having to wait for the result of each unit order before
being able to specify the next would slow down gameplay immensely.  An
AI algorithm cannot afford to do this, either.  Your imaginary 'for'
loop over all units would never work well, even if you hacked the
protocol to support an RPC-like mechanism.  And that is what your patch
is trying to do.

The only way in which you can run sequential algorithms with actions
that are guaranteed to succeed, is to run them in the server.  The
existing AI 'cheats' by running its whole turn in a single thread; this
really shouldn't happen, so if you moved the algorithms to the server
they would still have to be event driven in a proper solution.  So
I see no alternative to an event based programming model.

> Suppose <http://arch.freeciv.org/freeciv-dev-200008/msg00248.html> is
> implemented with an extra result field and a serial number of command
> field. And if there would be a serial number in every command would
> this solve your problem? (I will propose something like that if the
> attributes are implemented)

I think it's a good idea to extend the idea presented there and I also
think extended to a general way for the client to obtain information
about the game state from the server.  But if you are going to use
it as a vehicle to specify actions, changes to the game state, I think
it will be a better approach to specify actions to run at the server
side.  See

   http://arch.freeciv.org/freeciv-data-200101/msg00001.html

for what that could look like.

Of course, if you can produce a client AI based on your ideas
I will only be happy to use it, but at the moment I don't see
how the approach of feedback packets is going to pay off.

>       Raimar
 
-- 
Reinier Post