[Freeciv-Dev] (PR#8394) Another stab at diplomacy

["Per I. Mathisen" <per@xxxxxxxxxxx>]

<URL: http://rt.freeciv.org/Ticket/Display.html?id=8394 >

Here is another attempt to solve the diplomacy problems with a new
diplomacy model.

 1. Diplomacy is disabled for games with timeout > 0. If, in such a game,
players want to do diplomacy, they must turn off the timeout first.

 2. New concept: "Emissary". An in-game proposal sent by one player to one
or more players. Receiving an emissary unpresses your turn done button, if
it was pressed. Should be displayed prominently by clients, eg as icons,
_not_ a popup dialog. Server sends name of sender and type of emissary
only. A player _may_ choose to "meet" with an emissary - in this case one
of the following happens:

 3A. Resolve in same turn. Any emissary has to be acted on during the turn
it was received, or its default result applies as if it was not met with.
   PRO: Most laid back solution for player. Good for multi-windowed
clients, as the emissary window can be kept open while doing/watching
other things.
   CON: Changing-things-while-meeting exploits still possible. Harder to
code, harder to generalize (generalized treaties).

  - OR -

 3B. Resolve while meeting. When an emissary is met by a player, the
server will reject any other commands except an answer to the emissary
until an answer has been received. Clients will show the dialog as modal.
   PRO: Easy to code. Safe. Does not give multiwindowed clients an
advantage over players using clients with fullscreen meetings.
   CON: The dialog is modal.

I strongly prefer solution 3B, since this would allow easily writing
generalized AI diplomatic meetings similar to Civ1/2/3 and MoM and Moo1/2.

This is essentially a message passing system. But it is patterned on the
way I believe most players treat the diplomacy dialog (when they do not
simply accept a proposal as is):  Look at proposal, make adjustments, turn
attention back to game and wait for other player to notice and act. In the
above proposal, a player would: Look at proposal, make adjustments, send
it as a new emissary to the other player and wait for an answer. So while
player<->player negotiations would not be real-time (except perhaps with
AI), the behaviour would be very similar.

Notice how server votes and diplomacy are handled within a single turn.
Exception: It should still be possible to use server votes with timeout,
though, and in this case only, emissaries should stick around after an end
of turn.

  - Per