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

[Andrew McGuinness <andrew@xxxxxxxxxxxxxxxxxxxxxx>]

Quoting Reinier Post <rp@xxxxxxxxxx>:

> On Tue, Jan 23, 2001 at 04:44:17PM +0100, Dirk Stoecker wrote:
> > On Tue, 23 Jan 2001, Reinier Post wrote:
> >
> > > I have thought about this too, and there was a basic question your
> > > analysis doesn't address, namely, what is the Freeciv protocol
> really
> > > supposed to do?

[...]

> >
> > We don't make such an radical change, but only make the return method
> > usable (as it is not acceptable in current form). In general we do
> replace
> > text messages by parsable data structure. Nothing else.
>
> OK, let me rephrase my comment: I think it is an excellent idea, as
> long as this parsable object structure is the representation of the
> state of a server side object, and the server side object represents a
> piece of game state - *not* the encoding of a 'response'.  It may
> represent a piece of state that only the client-side AI knows how to
> interpret, its state may even be changed from the client; but all state
> info maintained by the server should be in the form of typed objects,
> so the server can read its type from rulesets, and save and load its
> contents to/from savegames just as it does for any other type of
> object.  (The existing code still has some limitations here.)  That way
> you can maintain the paradigm that server->client messages are the
> contents of objects that represent game state or game state updates,
> and client->server messages are requests to modify or show this state.
>
> I think it is a mistake to view server messages as responses to
> client requests.  The real logic is reversed: the server updates the
> game state at the client side, and the client may respond with
> requests to the server as a result.
>

Some server messages are responses to client requests.  Many others aren't

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.

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


>
> What I object to is the addition of a hack to make them seem responses
> to client requests - you can't base reliable client-side AI programs on
> that approach, it is broken by design.  Whereas, if you program the
> client side AI according to the existing programming model, namely,
> in terms of routines triggered by updates from the server, that generate
> requests to the server, your client-side algorithms will be more
> difficult to understand, but they will actually work.
>

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

There is a possible hazard of clients hanging waiting for messages that
for one reason or another aren't going to come, but as long as the client can
properly process an end-of-turn packet when it gets it the game won't suffer.


> --
> Reinier
>
>
>



Andrew McGuinness     Luton, UK        andrew_mcguinness@xxxxxxxxxxx