[Freeciv-Dev] (PR#12568) RFC: restructuring of civworld

["Reinier Post" <rp@xxxxxxxxxx>]

<URL: http://bugs.freeciv.org/Ticket/Display.html?id=12568 >

I like this.

Note that I don't intend to do any coding but since you were soliciting
ideas, let me reiterate mine.  I'm not 100% sure it's appropriate or
even correct.

My idea is that the Freeciv protocol can largely be described on a
higher level, i.e. a level largely independent of the fact that it is
used to play Freeciv, namely, as a special kind of client-server data
structure synchronization protocol.

The data structure in question is the game state, which is, essentially,
a fairly simple recursive structure of objects pointing to each other. 
The fuill (server side) game state can be described by an ER diagram or
UML class diagram with a couple of constraints.  The job of the Freeciv
protocol is to keep a synchronized copy of the game state at the Freeciv
client side.

A couple of things make this synchronization more interesting.

First, a client cannot see the full game state, but only a subset.  With
fog-of-war enabled, this subset becomes more complicated.  But we can
still describe this by saying that we have various users, and nodes in
the data structure have "owner" users, and we have a Unix-like
permissions system is used on the nodes, limiting read and write access
to users.

Second, synchronization is not a one-way process, but typically consists
of two steps: the request, in which a client requests a particular state
update, and the responds, in which, if the update is granted, the server
must inform all clients of the resulting changes in state.  In addition,
some automatic changes occur, such as a turn timeout.

Third, a client cannot request just any change.  Instead, there is an
update language, in terms of which any update request must be stated. 
For example, a unit cannot be arbitrarily relocated, but must be moved
according to the game rules.  Updates are subject to quite complex
constraints; for example, moves are typically subject to ZOC
constraints.  These updates are sent from client to server; the
information from server to client, on the other hand, is essentially
just state updating, mostly in the form of "diffs".

So in principle you could give a neat, abstract description of the
Freeciv game in these terms, by using, let's say, Abstract Data Types,
or Z, or VDM, or category theory or whatever.  Then you could continue
by saying: the Freeciv network protocol is essentially an implementation
of this abstract API over TCP/IP, although it is slightly "polluted" by
 additional features and optimizations, and by the fact that AI players
aren't clients.  But in principle it is a pretty general implementation
of a network-transparent game engine API with concurrent play that
happens to be used for playing Freeciv.

Now my reason for bringing this up:

How does editing logically fit in?  Is it another game on the same state
space, or is is the reversal of the synchronization in which a client
takes the role of authorized source whereas the server humbly accepts
any kind of state change the editing client will submit?  I think the
former fits best into the present protocol but it would tie the Freeciv
editing protocol to a specific set of editing capabilities; extending
them would imply extending the protocol.  The latter is most general but
 it's not clear to me how to cleanly fit it into the present protocol.