[Freeciv-Dev] Re: [RFC] New event handling

[Reinier Post <rp@xxxxxxxxxx>]

On Sat, Jan 27, 2001 at 12:09:25PM +0000, Andrew McGuinness wrote:

> I wouldn't advocate writing an AI client around a "make move - wait for
> feedback" structure, but neither would I want to write one that said "OK,
> the new position is this - what is now the best move?", like a simple chess
> program.  A good AI is going to make plans and stick to them, not make a new
> strategy in response to every packet it receives from the server.

The client can hold planning information just the same.  For example,
a unit can be assigned the 'plan' to move to a specific tile without
containing an algorithm to plan the road and them move each step.
(The existing server side goto doesn't do that, either, it recomputes
the next step at every turn.)

> I would write it around an event handling / dispatching loop, but that is
> likely to do processing along the lines of - this packet is a response to
> move request #54321, which was part of the "Attack Brindisium"  plan, so
> send it to that plan.

Yes, and the question is: to what extent is the information that it was
the "Attack Brindisium" plan that caused this packet to be sent at all
useful?  I think the algorithms are best designed in such a way that ut
isn't useful at all.  Zut I'm not going to do any of the real work here,
so it's just an opinion from a bystander!

> The client could of course do the same thing without
> packet serial numbers, but it makes it easier, and to my mind it is "real"
> information.

I don't think so.  Why can't "Plan Attack Brundisium" register to
any incoming updates on the status of a certain set of units?

> I would not want to see an enemy unit move, for example, labelled as a 
> response
> to a client request, but a move of one's own unit (not on a goto) is a 
> response
> to the client move unit packet, and I can't see the harm in having the server
> say so.

At the moment the server just send unit status updates.  The client doesn't
make any assumptions on what caused these updates to be sent.  For
example, in response to a move, the server sends an update of the status
of the unit in question.  The client can identify this unit.  This is
very different from havign the server send a MOVE_RESPONSE packet
with 'move failed' or 'move succeeded' and the thread number of the
initiating plan.  From the client algorithm's view, I don't see much
advantage in having this kind of information, and it bastardises the
protocol - its design becomes messy.

> Almost everything the player does has a near-immediate result, and
> for a human player it is usually better to check the result before doing
> anything else.

That's client decisions depending on the result of prior client
decisions.  The server can stay out of it.  It's like any other kind of
perception.  Compare drving.  I can drive a car in a world that just
tells me the state of the world: where I am, where I can go, how fast I
am allowed to drive, etc.  Adding return codes to server->client
packets would be like having traffic signs saying 'you successfully
turned left on your way to Amsterdam' or my dashboard panel ssaying
'your action to refuel was completely successful'.  Having such
information wouldn't make me a better driver; what is more, it would
probably make me a *worse* driver: it would confuse the hell out of
me.  I just want trffic signs to report on the world I drive in, and my
car to report on the state the car is in!  Analogously, I think return
codes in server->client packets would confuse the hell out of Freeciv
programmers.

> If I attack an enemy with my unit, the result of the combat
> usually is important enough that I will want to see it before I do anything
> else.  In any case, I can't do anything else with that unit until I have had
> the result.

That doesn't mean the result should be labeled with the reason it is
being returned.

> Andrew McGuinness     Luton, UK        andrew_mcguinness@xxxxxxxxxxx
 
-- 
Reinier