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

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Mon, Jan 15, 2001 at 10:45:21PM +0100, Reinier Post wrote:
> 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.

Let me rephrase what I think: the communication between server and
client is asynchronous. It was design this way because humans didn't
notice the delay or can handle it. In general (not limited to freeciv)
it possible to use a asynchronous protocol in a synchronous way. To do
this with the current freeciv protocol it would be nice if there is a
result packet but it is also possible to do without the extra packet.
If the request will be serialized there is a performance impact in
terms of extra delay. I'm willing to pay this price to get an easier
programming model. I'm not sure if synchronous use of the protocol
would really simplify the code. But my feeling says yes.

> > 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 is about returning information to the clients.

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

Nice vision. It would be nice if the server accepts string
commands. No need to for {send,receive}_packet_*. However if I look at
the current protocol and how sometimes data is compress into bits to
preserve bandwidth I think it would be hard to have a "big" protocol
of ascii strings accepted. The coding/decoding has do be done
nethertheless. Maybe also other methods (CORBA for example) can be
used.

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

I all depends how the ai code on the client will be/can be/is
programmed.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  The Software is not designed or licensed for use in on-line control
  equipment in hazardous environments, such as operation of nuclear
  facilities, aircraft navigation or control, or direct life support
  machines. 
    -- Java Compiler Compiler Download and License Agreement