Diplomacy Model v1.1

[Mark_Everson]

Jacobo:

I agree with your thrust, there is not too much else we really need in the alpha one model. I think the biggest thing is to get an interface up so that the player can actually run the diplomacy. I would say, code up what you suggested and a crude interface, and then we can integrate it into the code and see what we want to do next. Kull should be back shortly, and we can see what his take on the deal is.

[jacobo]

Cool.

One question I've got a rough model of how treaties class will be coded, should I post it for critique?

[Mark_Everson]

Jacobo:

You bet, we Live to Criticise

[jacobo]

You asked for it.
From the above model i've come up with the following

Each treaty is made up of clauses and each different type of clause(tribute, changestatus, etc..) extends this class

class clause{
boolean obsoletevar;//for clauses with
shorter lives then the treaty
treaty ownertreatyvar;//treaty clause belongs to
void clause(treaty ownertreaty);
boolean obsolete(); //check obsoletevar
void makeobsolete();
short doaction(); //carry out what the clause does, # returned is sort of like diplomatic error code
short oncancel(civ cancelingciv); //what to do if the treaty is cancelled
boolean enforced(civ thisciv); //sees if thisciv is enforcing the treaty
? aistuff(?); //ai stuff i dont know much about this
}
thats the generic clause here's the uncompleted treaty.
treaty{
byte numclauses;
clause[] clauses;
byte numsigners;
civ[] signers;// above self explanatory
boolean secret;// if it's a secret treaty
meaning only signing civs know about it
boolean ineffect; //this is so you can store the data for a treaty without it being implemented for instance if you were negotiating(how that works is another question)
short turnsigned;
byte percenttoreview; //meaning the percent of the signers needed to agree to a renegotiation of treaty. range 0-101 with 101 meaning cannot be changed
byte percenttoaddsigner; //percent of original signers needed to add a new one.
range 0(open treaty)-101(closed treaty)
void treaty(?); //constructor
boolean enforced(civ aciv);// is aciv enforcing treaty?
void cancel(civ aciv);// if aciv is cancelling(leaving) treaty. aciv=null if treaty has run out of time.
boolean requestreview(civ aciv); //if aciv
calling a review meaning wants to change the treaty returns true if enough signers want review else false. use aciv=null for natural review.
? aistuff(?);// ai routines don't know how this works
...}
there are more but i don't want to bore you what i really need help on is figuring out how negotiations work. Also helpful suggestions for methods/variables needed.
-thanks for your time

[Mark_Everson]

Jacobo:

I see you've made good progress. I've spent some time looking over what you posted, and everything seems reasonable to me. I have a few suggestions on the negotiations part of the coding, that I'll mention below.

But first, I wanted to suggest one change in the way you name variables. Your names are good and descriptive, but the lack of capitalization inside the variable names makes them sometimes very difficult to read. Also, you, or someone else using the variables may misconstrue what the variable's meaning is. (I have certainly screwed up the meaning of variables that I myself named when returning to coding a particular area after a long period.) One example of the potential confusion can be seen using a variable you have in your write-up, ineffect. Does ineffect mean it is now in effect, or that is ineffective? Reading the comment near the variable definition makes it clear, but sometimes coders (like me ) will just make an assumption about what it means without checking. IMO such naming is a potential source of bugs.

I suggest you use the convention I've been already using in a substantial amount of code I have so far, which is to capitalize the beginning of all words that are internal to the variable or method name. So you would have inEffect. This makes it immediately clear that the meaning of the variable is that something is "in effect", rather than "ineffective". It also makes reading the variable much easier, since you can pick out immediately what the words are. Others like the in_effect style, but I dislike typing all the underscores.

Anyway, on to the negotiations issue. I don't have any deep thoughts to give you right at the moment, except to suggest that you can use the framework for evaluating negotiations that's already present in my diplomacy code. Two or more sides in negotiations would only agree to a treaty if its valuation were better than what they already have. I think going any further in the alpha-1 model is impractical, since to go any further one needs a full-blown diplomacy AI.

Using the valuation methods that I have already included, you would go through a round of negotiations each turn. At the end of a round you would either end up with a treaty agreed-upon, a breakdown in negotiations, or an agreement to negotiate further the next turn.

What does everyone think about the negotiations round concept elaborated in the bold section above? I think it will give a real-world flavor to negotiations, in that especially in ancient times you don't have forever to bargain over the minutae of any treaty. As distance decreases, and communication gets better, the number of rounds available for negotiations between the parties would increase.

Jacobo: if you and others agree with this concept, I propose that we start off with two rounds of negotiations available per turn. Each round would allow an offer by side A, and a counter offer by side B. Once a side has used its two rounds with any possible counter-party, the only message it could send to the other would be that it was willing to continue negotiations next turn, or that it was breaking off negotiations.

The diplomatic state value functions that I was talking about are all in the Diplomacy class. I've included an outline of what one of them does below.

valueOfDiplomaticChange(...)
evaluates how much a change in diplomatic status between us and otherCiv will be
worth. ** will consider changes due to modifications in:
1. offensivePower
2. loss or gain of targets for conquest
3. general benefits of peace for economic and/or military buildup
4. competitive situation vis-a-vis the other civ

I hope this is what you are looking for, if not let me know.

Mark

[jacobo]

Mark the negotian idea sounds good. It's better then what i was thinking. One problem, if a player needs to sign many treaties it's gonna get boring. Possible way around this player offers treaty he/she wants then lets his ai "negotiators" get the treaty closest to that. Is that possible?

Now I shall look to the future and begin discusions on other diplomatic topics.

Threats, Protests and Promises oh my!

my view is we have a generic object called action which like clauses is extended to specfics such as changeTariffs,signTreaty, changeTerritory,withDrawTroops,cancelTreaty
,War (took your advice Mark) etc.
and to accsess these you would have a method like this Threaten(action yourAction,civ ToCiv,action ToHaveThisAction)
example Threaten(War,Romans,signTreaty)
would be you threatening the romans with war if they didn't sign some specified treaty.
This is all in my head right now but what do people think of the general idea.

Clauses

We need to think up some more clauses in addition to the ones mentioned above i will give my list. treatyDuration, relationsVeto( for alliances so no seperete peaces), collateral, allowMilitaryToUseTerritory(for bases+alliances) i can't think of more right now, suggestions.

AI

I looked at the diplo Ai code and had no idea what the numbers meant or where they came from could someone help me here

Intelligence

People working on this are going to have to sharpen it up I found the descriptions vague especially in the funding area, if you double funding what kind of effect will that have?

Well thats it

[Mark_Everson]

Jacobo:

I'm pressed for time, but here are some quick responses...

Negotiations:
Yes the AI can do it, or we can change it if its too much a pain for the player.

Threats, Protests and Promises... and Clauses:
Sounds reasonable to me.

Current Diplomatic AI:
Well this is tough to go thru quickly. The main idea is to use the relative military power of potential opponents compared to the civ who's AI it is. Relative military power comes from absolute military power modified by diplomatic state of all adjacent civs. So ones we're at peace with tie up little of our potential power (in military units) while those we are at war with can tie up a lot. Of course the power needed for a potential adversary depends on its power, which depends on Its diplomatic relations... I'll try to write up something more helpful later

Intelligence:
Yeah, its vague so far... Just put in your best guesses for how to do it reasonably, and let the group know what they are, and we can discuss it.

Lookin' good so far

Mark

[jacobo]

Some things i need to finish alpha1 stuff up is there a way to see if a given civ is the player or not? This is critical to AI making Diplomatic offers, and i have looked through the civ class and found no such function.

Also to simplify diplomacy i am going to do things on a Imperial Conquest(really addictive but cheap ancient meditteranean strategy game) rather then civilization type interface. What this means is when an Ai civ wants say peace with you it will offer peace and that will be displayed on the console and you have to go and set it yourself from some interface that lists all your relations with other civs. This contrasts to the civ approaching you and asking for a yes no answer(a la civilization) Does this make sense and if so is it acceptable.

[jacobo]

Ignore what i said above. I did some searching and found everything i need a simplified diplomacy interface is in place and all it needs is the graphical part of the interface(for player offers and responses) and to add to call a method i have written every turn.

[Kull]

Well, I'm back....and you've been quite a busy bunch, haven't you? Glad to see we have a Diplomacy model coder. Jacobo, here's a quick synopsis of where I can be of most use to you:

1) Coding: My coding skills are effectively non-existent, so I won't be of much help in this area.

2) Model Concepts: About half are mine, and most of the rest are Mark's. I can help you out here.

3) Interface: I'm quite interested in what you've done in this area. Feel free to use me as a sounding board.

4) Other stuff: When in doubt, ask. I'll try to react as quickly as possible. I have a pretty hectic day job, so most of my contributions will appear in the evening (8-12 MST)

[jacobo]

Kull:

Good to see your back. What would be helpful would be if you could look over the treaty description and come up with any suggestions for needed things/unneccesary things. Also if you could offer any psuedo code on what variables/methods are needed in the various topics. Tell me if you understand anything and i'll try to explain(some parts of java i don't understand myself )

[Kull]

Necessary Treaty Components for the Alpha (Selected from section III.5.b):

1. Change of basic diplomatic status. There are 13 Diplomatic State constants (section IV) to choose from, but lets limit the Alpha to five. (War, Cease Fire, Contact, Peace, and Off Alliance). By definition, a treaty implies an improvement in relations, and this requires both parties to agree. Relations may be worsened unilaterally (and are usually the result of a provocation by one of the parties)

2. A request or offer of cash

3. A gift or trade of territory

4. A gift or trade of technology

We can omit items 5 thru 10 for now.

I looked at some of your earlier posts, and this looks pretty similar to your own ideas for the alpha.

One of your posts questions the relationship between Funding and Intelligence. First, lets note that in the pre-modern eras, there are really two types: Intelligence from merchants and emissaries (procurement of info which is contained in the Social, Economic, and Governmental models) and that employed by the military (information on size and location of enemy armies and bribing of cities). Allocating $$ to your intelligence budget simulates payments to foreigners (and even your own merchants) in order to "loosen their tongues". Obviously, the more $$ you devote to this purpose, the more info you garner. The civilian info should be random (ie. your collection method is passive, so you only learn what someone happens to know). Military intelligence should be different, involving one-time expenditures to achieve specific goals. Example: $25 buys guards at one gate for a 25% chance of success while $100 buys guards at all 4 gates for a 100% chance of success. Likewise, $10 gets one villager to tell you "there's a big army out there somewhere" while $100 incentivizes every hunter in the province to report in with exact details on the size and location of the enemy army.

Hope this helps!

[jacobo]

On the intelligence i see what your saying but what if you offer $35 to the guard do you get a 35% chance of success? In addition if you pay the villagers $20 will you get twice as much information? But what is twice as much information as "there's a big army near here"? A way around this is allow only certain amounts(possible random) to do something so $10 gets you information that there's a big army near, and $100 gets you more detailed info but $99 gets you the same as $10.
I hope this makes sense, because i barely can follow it.

Ps this thread is getting a bit long, do we need a new one?

[Kull]

The more I think about it, we probably should steer clear of any tactical military intelligence issues. It's probably best to let the Military model handle things like using bribery to determine the location and strength of opposing forces. Likewise bribing guards to open the gates of cities which are under siege.

On the other hand, sending an emissary with fistfuls of cash to purchase the allegiance of an enemy provincial governor is clearly a feature of the Diplomatic model. Coding it may be a bit complicated, since variables would include size of province, distance from enemy capital, type of government, presence of enemy forces, religion, social conditions, etc.

If you think this thread is getting too long, feel free to start a new one ("Diplomacy Model Coding Discussions", or somesuch)

[jacobo]

Got some questions about treaties.
1)if A and B have a treaty and A violates it what can B do?
2)if A and B have a peace treaty and A wants to declare war on B does A have to cancel the treaty first or can A declare war and thus cancel the treaty?
3)on negotiations assuming we use some like what Mark suggested should A and B both come up with treaties and both offer counter offers and then decide either whose is best, end negotiiations or agree to meet next turn.
Or should A offer a treaty to B and B can return a counter offer and if A doesn't accept B can either accept original treaty, end negotiations or continue negotiations next turn.
4)I hope to implement multiparty treaties eventually but they offer some major difficulties especially in how to negotiate them. Any ideas?
5)Should all treaties be in one array/list or should they only be referenced by civs that signed them?