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

["Jason Short" <jdorje@xxxxxxxxxxxxxxxxxxxxx>]

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

As discussed on IRC, this ticket describes a new structure for the 
civworld map editor.  This new structure avoids most of the problems of 
the current editor (mostly linking problems, since civworld links 
against client and server) while introducing a new set of problems 
(mostly, that it will take a lot of work).  It also allows some new 
features like in-game map editing.

The current civworld links against client and server code to form one 
executable.  This executable is capable of generating and loading maps, 
but provides the client features for viewing the mapview as well as GUI 
editing features.  The reason it's never made into CVS is that it takes 
a major hack to have it link against client and server.  This is caused 
largely because freeciv isn't very modular; it's hard to link against 
*part* of the client/server without linking against the rest of it, and 
some symbols in client and server conflict.  Some improvements have been 
made in this area, but not very much.

In the proposed design the civ editor would be part of the client, and 
would make changes in the server through network packets.  For instance 
there would be a network packet allowing the client to change the 
terrain of a tile.  When in editor mode (probably a separate mode for 
the client, like in SMAC) the GUI will allow the user to change a tile's 
terrain.  This triggers a terrain-change-request packet to be sent to 
the server.  The server then changes the terrain type of the tile (after 
a permissions check).

This system avoids all the linking problems.  However it introduces a 
whole set of new problems.  Here they are, in rough order of difficulty 
(or amount of work needed).

1.  Map generation.  Currently civworld gives the user control over the 
map generation, allowing new maps to be generated on demand.  This is 
impossible right now.  However I think it wouldn't be too hard to add a 
/generate command that creates the map in pregame (allowing a privileged 
user to view and edit it, also in pregame).

2.  Other pregame features.  All of the current civworld features would 
correspond to pregame map editing, although in-game editing is also 
possible.  To allow pregame editing it must be possible to see the map 
in pregame.  There should probably be a GUI feature in the start screen 
that sends the client directly into editing of a scenario (basically, 
launch a server, /load the scenario, enter editing mode).  Currently map 
information will not be sent to the client during pregame.  But for 
editing clients this must be changed.

3.  Permissions system.  Only a privileged user should be allowed to 
edit the map (in-game or pregame) or to view the map (pregame) or to 
have omniscient view of map_is_known information (in-game), etc.  The 
simplest system would be just to check if the client has hack.  However 
we don't want to send omniscient information to the client for typical 
single-player games, which will have hack.  I think for some other 
features we should only send info to the global observer (so only a 
global observer would be able to see and edit the map pregame, for 
instance).

4.  GUI changes.  All of the current civworld GUI features should be 
integrated into the gui-gtk-2.0 client, but with a boolean "mode" check 
instead of as preprocessor checks.  Probably the user will select a menu 
item that sends them into editor mode (with a prominent disclaimer). 
Once in editor mode the menus will change and the editor window will pop up.

5.  Server changes.  The server must be able to receive editing packets 
and act on them.  This should all be straightforward.

6.  Network changes.  Also straightforward: we just have to add some new 
entries to packets.def.  Unfortunately this will probably make 
packets_gen.c take even longer to compile.

When we discussed this on IRC everyone seemed in favor of it.  However 
there wasn't much real discussion.  So the discussion should go here.

-jason