Coding the Diplomacy Model

[Gary Thomas]

I'll find a way to extend Treaty and CivContact to share the same interface. Are you suggesting to use Map? I am a little lost with the last sentence.

Sorry, I was thinking a bit ahead to the actual use of the information. An obvious use is, when units of two civilizations meet, "what are are our feelings about, and formal treaties with, this other civilization". This, in turn, implies a method for a civilization like:

public DiplomaticStatus getDiplomaticStatus(Civilization otherCiv)

To look this up, the list of diplomatic statuses will need to be in a hash map, hence my assumption of a Map interface.

Cheers

[Sancio]

Due to Gary's suggestion I have redesigned the ExteriorMinistry and created a new Interface Ministry.

package game.model.diplo;

/**
 * The Diplomat interface must be implemted by any class that wants to
 * keep a diplomatic relation with another civilization.
 * 
 * Diplomat provides methods for storing diplomatic contracs
 * and keeping track of diplomatic relations with other civilizations.
 * 
 * @see DiplomaticContract
 * @see DiplomaticStatus
 *
 * @author Jose A. Garcia-Sancio
 */ 
public interface Diplomat {
    /**
     * Adds a diplomatic contract.
     * @param contract contract to add to this ministry
     * @return true if the contract was added successfully;
     * false otherwise.
     */
    public boolean addContract(DiplomaticContract contract);
    
    /**
     * Removes a diplomatic contract.
     * @param contract contract to remove from this ministry
     * @return true if the contract was removed successfully;
     * false otherwise.
     */
    public boolean removeContract(DiplomaticContract contract);
    
    /**
     * Returns an iterator over all diplomatic contracts.
     */
    public ListIterator getAllContracts();
    
    /**
     * Returns the number of contracts.
     */
    public int numberOfContracts();
    
    /**
     * Returns current diplomatic relation with otherCiv.
     * @param otherCiv the civilization to get the diplomatic status
     */
    public DiplomaticStatus getDiplomaticStatus(Civilization otherCiv);
    
    /**
     * Sets a new diplomatic status for a given civization. Adds a 
     * new diplomatic status if one doesn't already exist.
     * @param otherCiv the civilization to change diplomatic status
     * @param status new diplomatic status for otherCiv
     */
    public void setDiplomaticStatus(Civilization otherCiv, DiplomaticStatus status);
}

Sorry for the slow progress but I am still trying to figure out all the detail of the current clash implementation.

[Mark_Everson]

I think I'd call it Diplomacy rather than Diplomat...

I also get the feeling that there should be more to the interface, like whether certain types of actions are permitted to military units on another civ's terrain, but I'm sure that will become apparent as coding goes forward.

Then again, I haven't even Done the interface for Econ yet, so don't feel bad

[Sancio]

Originally posted by Mark_Everson
I think I'd call it Diplomacy rather than Diplomat...

Agree. Already made changes.

[LDiCesare]

A few questions from a military standpoint:
The military AI will have to know whether it can attack armies and which.
A description of which actions are allowed according to a treaty could be a good thing?
I see the following:
(Supposing a unit has received an order to do something - I decide whether or not that violates a treaty-):

* Entering a square of civ X.
* Claiming a square from civ X (if unauthorized, I just cross the civ territory, if authorize, I take control of the square).
* Building things in a square from X (is it allowed to build a road through an ally's territory?????)(this one has links with infrastructure I am not sure of).
* Attacking armies from X in a square they control.
* Attacking armies from X in a square neither of us controls.
* Attacking improvements from X (pillaging...).

Some are altogether war acts, but depending on treaties some may not be (e.g. "we don't fight on our soil, but unexplored land is another thing").
I should be able from a civ to retrievve allowed moves, like:
IsAuthorised(targetSquare,archetype,order);
The square knows which civ it belongs to, the archetype is the type of unit (e.g. diplomat / settler / chariot), and an order can be sentry, attack, fortify, scout or whatever.
The reason I put the square not the civ is you might allow to cross border squares but not inner squares. The question is how do you define which square is a core square, which one is a border? (regions?)
The current list of orders is limited, maybe the orders can be checked as being part of a category (war, truce, peace) to make things simpler, or we identify them by name and allow each order based on each kind of treaty.
What do you think?
I can put up whatever is needed from the militray standpoint.

[Sancio]

I am now starting to designing the DiplomaticConract interface. I was wondering if contract had to be enforced (performed) every turn. Or is it up to the player to perform the actions required by the diplomatic contract?

I have more question but I'll post them when I get an answer to this one.

[Sancio]

Originally posted by LDiCesare
* Entering a square of civ X.
* Claiming a square from civ X (if unauthorized, I just cross the civ territory, if authorize, I take control of the square).
* Building things in a square from X (is it allowed to build a road through an ally's territory?????)(this one has links with infrastructure I am not sure of).
* Attacking armies from X in a square they control.
* Attacking armies from X in a square neither of us controls.
* Attacking improvements from X (pillaging...).

A better question is who should make the decision of attacking or controlling a square. I think that this should be let up to the Military model or Military AI/Advisor. The Diplomacy model can provide you with the information needed to make the decision but it should be up to the military model to make the decision.

Does this sound reasonable? Yes? No?

[Mark_Everson]

I think diplo contract actions should happen automatically. Otherwise the player will be forced to undertake a mind-numbing amount of actions every turn. However, the player can revoke a contract if they choose.

IMO that can also be a model for the 'can attack' issues. I think the players' units should always obey deals the player has made, but if the player (or AI) chooses to shaft someone it should override the contract (Diplomacy model should handle it), allowing the attack or other action to be upheld by the unit. At least that seems the most straightforward way to handle it to me .

[Sancio]

Originally posted by Mark_Everson
I think diplo contract actions should happen automatically. Otherwise the player will be forced to undertake a mind-numbing amount of actions every turn. However, the player can revoke a contract if they choose.

IMO that can also be a model for the 'can attack' issues. I think the players' units should always obey deals the player has made, but if the player (or AI) chooses to shaft someone it should override the contract (Diplomacy model should handle it), allowing the attack or other action to be upheld by the unit. At least that seems the most straightforward way to handle it to me .

That sounds reasonable to me. The next issue will be what contract should be canceled and how they should be canceled.

If civ Y has a couple of contracts (treaties) with civ X (for example one contract set their diplomatic status to cooperation and requires civ Y to give 1000C to civ X every turn, and the other contract just makes civ X give civ Y 500C) and civ Y decides to attack civ X, then the first contract will be cancel because it violates the first clause. On the other hand the second contract will still stand because none of the clauses have been violated.

Of course it is very likely that civ X will cancel the second contract on the next turn.

All I have to do now is figure out how to do this. hehe

[LDiCesare]

I agree that the miltary AI or player controls the moves, but I was listing the list of information that I deem necessary in order to take a decision about an action.
In particular, crossing territory may be forbidden by treaty, but that can have impact on pathfinding, so it may be necessary to have a list of uncrossable squares. The list was a list of information needed by the AI (high tactical level) so they know what they can and cannot do.

[Sancio]

Sorry for miss reading your post. I added a new method to the Diplomacy interface:

    /**
     * Returns current diplomatic relation with given MapSquare.
     * @param mapSquare Map square to check for diplomatic status
     *@return DiplomaticStatus if the civilization that owns this
     * map square has been contacted; null otherwise
     */
   public DiplomaticStatus getDiplomaticStatus(MapSquare mapSquare);

Let me know if extra functionality is need.

[Sancio]

Hello,

I am currently having some design issues. I am trying to keep the design simple so that it is easy to code and understand but I am having some problem achieving this. This is mainly concerning how diplomatic status are updated. For example when one civilization attack another there are a couple of things that have to be taken care. One of them is the diplomatic status between the two civilization (but there are many others). The attacking civilization could be responsible of changing the diplomatic status for both civilization or an attack event could be fired and any listening object can catch this event performed any needed actions.

I don't see such event/listener system been used in the current code but it will be very useful for the diplomatic model since it depends on so many different models.

This will also abstract many responsibilities from the other models like the military model. And act as a message passing between civilization...

[Gary Thomas]

The military model uses the Observer/Observable system to some extent.

Personally I am against that approach. It has been pretty much deprecated since Java 1.1, and replaced by the action listener system, a much better approach.

The problem with the Observer system is that it is a shotgun approach, broadcasting to the world, in effect it is a copy of the Windows messaging system.

Action listeners, on the other hand, are directed, and can be tailored to the situation. It is also possible to make sure that someone is listening.

Cheers

[Mark_Everson]

Sancio:

Are you still working on this, or have you become one of our disappearing team members?

-Mark

[Sancio]

Hey Mark,

I am still here but I put coding in the back ground. I read the message board everyday to keep up with the current status of clash of civilization.

I have not done much to the model lately but I will work on it in the future. I just don't know where to go next. Once the code for D5 is released, I'll again start working on the diplomacy model.

Been looking at other civ games to get some idea (inspiration ) on how to handle user input.

Sancio