[Freeciv-Dev] Re: jfreeciv

["Ross W. Wetmore" <rwetmore@xxxxxxxxxxxx>]

At 09:16 AM 01/12/17 -0500, Andrew Sutton wrote:
>> Or we haven't started contributing for jfreeciv yet.... depends on the
>> perspective.
>> I wonders wheather this is a good alternative for freeciv 2. The advantage
>> is that alot for the client is already being done.
>
>maybe, maybe not... i'm leaning toward no. writing the client doesn't have 
>much to do with writing the server. besides, if there are any big 
>architectural changes to the game, you'd just have to end up rewriting major 
>parts of the client. also, using a client that's based on the existing 
>architecture is probably going to constrain the implementatin of more 
>ideas/features because it will require (massive)? changes to the existing 
>jfreeciv codebase.
>
>andy

The current jfreeciv client is largely a port of the "C" client, but
it is being mutated in beneficial ways by the current developers. It
is not "novel" or core FC.2, or at least not yet.

A client has three basic parts.

1)  It collects a representation of the game state. This is in general a
    subset of the server (or total) game state.

2)  It usually has a lot of GUI stuff to display this state.

3)  It can send commands back to the server to change the state in well
    defined ways.

For the most part, what the game state is and how it is displayed is
something that is more dependent on what Freeciv is and the personal
aesthetics of the GUI programmer at displaying it than the server it
gets it from.

Both the game state and the returned commands are primarily exchanged
by the network protocol. One can use different protocols, or one can
translate the current protocol into different internal models of the
game state without loss of functionality.

Thus, I think there is considerable independence between the two, and
major rewrites of one will not necessarily result in rewrites of the
other.

By the same token, rebuilding the client won't necessarily help that
much in rebuilding the server. Once the server is at a state where
it has new capabilities, e.g. compound units, there would presumably
be new model data and commands that acted on it, as expressed by new
protocol elements, or perhaps new ways of using existing ones. For
this there would presumably need to be some update to the client, 
but not major.

New client elements would be improved ways of using the existing
data and commands, such as a civbot processing module.

Note the development could be integrated more closely, but it isn't a 
given *or* a requirement.

Cheers,
RossW
=====