Coding the Diplomacy Model

[Sancio]

Just a quick question: Does the Civilization name (civ_name) uniquely identify a civilization? Or can more than one civilization have the same name?

If every civilization is identify by a name (String), I suggest we change this and create an ID that is unique to every civilization. We should also create a Civilization (or any other class that requires unique IDs) Factory pattern to create unique IDs. I hope I gave the right pattern name

Stay tuned for more questions

Jose

[Mark_Everson]

Hi Jose:

AFAIK its done by string now, and it should certainly be true that no two civs can share a name. I don't know if the code is there to prevent a name collision. OTOH I don't really care much either way, so lets see what the other coders have to say about your proposal.

[Gary Thomas]

If every civilization is identify by a name (String), I suggest we change this and create an ID that is unique to every civilization.

Why?

[Sancio]

Aren't string comparison expensive operations?

It doesn't really matter. If it works, it is all good with me.

But shouldn't unique name still be enforced? The computer player shouldn't have a problem if two civilization have the same name but this is not the same for the human players.

Jose

[LDiCesare]

I'm strongly for names against IDs.
It is quite easy to ensure 2 civs don't have the same name.
As for string comparison, it may be slower than int comparison but I doubt comparing two civs by their name will occur very often.
In the military code, I test equality of civilization objects quite (too) often, never strings.

[Sancio]

Originally posted by LDiCesare
In the military code, I test equality of civilization objects quite (too) often, never strings.

This is a good Idea.

Jose

[Gary Thomas]

The system makes extensive use of static instances. The creation of a civilization is a rare event or an initialization event. Once created, the single instance of each civilization is identified by a reference to that instance. As Laurent said, the military model works that way. I can assure you that the rest of the system also works that way. Although each civilization has a name, it is only used for output to the user, at present. Ultimately it will be used for saving and loading games.

The use of instance references goes far beyond civilizations - it covers all units, map squares, all the visible windows, images, terrain types, unit types, ethnic groups, religions, technologies and so forth. Where specific identification is required, unique names are used, since it is intended that eventually all data be saved in XML format.

Since, once loaded, there is very little searching for objects, the efficiency or otherwise of string comparisons doesn't matter. I believe the only time it happens is when a new unit is created, when the archetype is identified by name, and this does not happen sufficiently often for efficiency to be an issue. In a whole game it might cost as much a 1 second.

Because of the use of fixed objects, comparison is normally by means of ==, rather than equals(), so, in effect the memory address of the object is its identifier within the program.

Cheers

[Sancio]

How are we keeping track of time or turns? Have to keep track of when something happened or should happen.

I noticed that we are using the GregorianCalendar class but my question is how are we using it to keep track of time or turns?

Jose

[Mark_Everson]

IMO turns are the fundamental game element for keep track of time. So all orders etc. should be indexed by turn number. Any mention of a date/time should be obtainable as a function of turn number. But its not clear we even want to tell players 'real world' dates because the military timescale in the game can be different from the other time scales represented within a single turn. We've just discussed some of this recently in the Military units movement thread.

GregorianCalendar was just something thrown in by F_Smith and I'm not sure its usable since IIRC there is a date sometime in the first few millenia BC where GregorianCalendar no longer works.

Just to keep the discussions orderly I'm going to suggest that we start a "general questions about coding thread". That's where much of the topics covered here belongs. (I'm not sure one already exists, or I'd point to it.) My concern is that someone will look at this thread for information about diplomacy coding, and find nothing directly related to diplomacy here . Or have to wade through a page of general stuff before ever getting to the diplo stuff. Sorry to be bouncing the discussion around, but its very difficult to maintain long-term usefulness of the forum if the discussion doesn't match the thread title.

[Sancio]

Ok. Lets forget about the above and start discussing the diplomacy model .

I am going to start posting the classes one class at a time. Lets start from the top, the Diplomacy class. This class doesn't do much work. It just encapsulates two more classes (Ministry of Exterior and Ministry of Interior).

-------------------------------------
package game.model.diplo;

import game.model.diplo.ExteriorMinistry;
import game.model.diplo.InteriorMinistry;
import game.model.Civilization;

/**
* The Diplomacy class represents the diplomacy model for
* Clash of Civilization. The diplomacy model is divided into two sections
* (ministries): Ministry of Exterior and Ministry of Interior. The Ministry
* of Exterior is responsible for handling events dealing with foreign
* affairs. The Ministry of Interior deals with matters internal to the
* civilization.
*
* @author Jose A. Garcia-Sancio
* @version 0.0.1
*/
public class Diplomacy {
/**
* Object for modeling the Ministry of Exterior.
*/
private ExteriorMinistry exteriorMinistry;

/**
* Object for modeling the Ministry of Interior.
*/
private InteriorMinistry interiorMinistry;

/**
* Parent civilization for this object.
*/
private Civilization parentCivilization;

/**
* Creates an instance of the Diplomacy class.
* @param ownerCiv - the civilization that owns this diplomacy
*/
public Diplomacy(Civilization ownerCiv) {}

/**
* Returns the exteriorMinistry object for this class.
*/
public ExteriorMinistry getExteriorMinistry() {}

/**
* Returns the interiorMinistry object for this class.
*/
public InteriorMinistry getInteriorMinistry() {}

/**
* Returns the parentCiv object for this class.
*/
public Civilization getParentCivilization() {}
}
-------------------------------------

I made 'game.model.diplo' the diplomacy package. Is this ok?

Jose

[Mark_Everson]

Looks like a reasonable start to me, with one possible exception...

We already have a detailed government model spec that's partly coded. My guess as to what you are calling interior ministry functions are already handled there. Please check out the govt model, and see if this is the case, and we can discuss it further.

[Sancio]

I'll look at the code tomorrow. Any class I should be looking for?

Anyway the Ministry of Interior is responsible for dealing with the following: Counterintelligence, Internal Operations, Create Civilization. Look at the Diplomacy Model v1.1 for a description.

I have not design the InteriorMinistry class yet and might not make it into Demo5 (This depends on the deadline).

Now here is the ExteriorMinistry class. Every ExteriorMinistry class has a corresponding 'advisor' (or Minister of Exterior). The ExteriorMinistry (the actual office) basically stores information about the contacted states. The Minister of Exterior (AI advisor for human player or computer) takes actions base on this information. This will allow the cool feature of hiring an advisor at a price. The player will be able to hire diff advisor depending on their policy (for example a war oriented advisor, a peaceful advisor, or a trade oriented advisor).

--------------------------------------
package game.model.diplo;

import game.model.diplo.CivContact;
import game.model.diplo.Treaty;
import game.model.diplo.Diplomacy;

import java.util.Vector;

/**
* The ExteriorMinistry class represents the Ministry of
* Exterior. This class is used for communicating with other Civilizations
* and storing general diplomatic information known about these civilizations.
* This class handles other non-civilization specific features like treaties.
*
* Note: Other non-civilization specific feature will be implemented later.
*
* @author Jose A. Garcia-Sancio
* @version 0.0.1
*/
public class ExteriorMinistry {
/**
* The list of civilizations that this civilization has foreign
* relationships with.
*/
private Vector contactedCivilizations;

/**
* The list of treaties that this civilization is involved with.
*/
private Vector activeTreaties;

/**
* Parent Diplomacy class.
*/
private Diplomacy parentDiplomacy;

/**
* Creates an instance of the ExteriorMinistry class.
* @param ownerDiplomacy - the diplomacy that owns this class
*/
public ExteriorMinistry(Diplomacy ownerDiplomacy) {}

/**
* Adds a civilization contact to the contacted civilization list.
* @param contact - contact to add to the contacted civ list
* @return true if the nation was added successfully;
* false otherwise.
*/
public boolean addContact(CivContact contact) {}

/**
* Removes a civilization contact from the contacted civilization list.
* @param contact - contact to remove from the contacted civ list
* @return true if the nation was removed successfully;
* false otherwise.
*/
public boolean removeContact(CivContact contact) {}

/**
* Returns an iterator over the nations contacted by the civilization.
*/
public Iterator getAllContacts() {}

/**
* Returns the number of contacted nations by the civilization.
*/
public int numberOfContacts() {}

/**
* Adds a treaty to the active treaty list.
* @param treaty - treaty to add to the active treaty list
* @return true if the treaty was added successfully;
* false otherwise
*/
public boolean addActiveTreaty(Treaty treaty) {}

/**
* Removes a treaty from the active treaty list.
* @param treaty - treaty to remove from the active treaty list
* @return true if the treaty was removed successfully;
* false otherwise
*/
public boolean removeActiveTreaty(Treaty treaty) {}

/**
* Returns an iterator over the active treaties for the civilization.
*/
public Iterator getAllActiveTreaty() {}

/**
* Returns the number of active treaties by the civilization.
*/
public int numberOfActiveTreaty() {}
}
---------------------------------

Jose

[Mark_Everson]

Counterintelligence probably does belong in the diplomacy model. As for Internal Operations and Create Civ, I'd say lets see where we think they fit more naturally as both the diplomacy and govt models progress in coding. But my inclination right now is that they should go in the govt model.

On hiring advisors... That seems needlessly complicated to me. The way I envision it is that you have a diplomatic advisor, and can give it (him/her) particular orders (maintain peace within x cost per turn, or prepare for me to attack the Bozos). Now, that's not to say that characters that are advisors can't have advantages in certain areas like maintaining peace or preparing for war. But I think that's a further refinement after the basic system gets going.

As a general note, I'm hoping that D5 can go out in a few weeks (I haven't heard from Gary on his expected timetable so I'm not sure). And since much of the support stuff for diplomacy, like civs having military AI isn't implemented yet, I doubt even the external diplomacy stuff will be in D5. But as soon as we have enough to make it interesting, we'll certainly put it in.

[Gary Thomas]

/**
* The list of civilizations that this civilization has foreign
* relationships with.
*/
private Vector contactedCivilizations;

Modern Java usage prefers using the java.util.List interface or the Collection interface (depending on whether the information is ordered) rather than a specific implementation such as Vector. This allows the code to be independent of the specific list implementtationn

In addition, Vector is synchronized by default, ArrayList is the current preferred option.

Is there some specific advantage in dividing the ministries into interior and exterior?

If the concept of a treaty is extended somewhat, the contacts and treaties could be objects implementing the same interface, and hence only one map (by civilization) is required to record these matters. There seems little advantage to having two lists to, in effect, cover the same set of actions. Incidently, the map should be declared as Map, but implemented as HashMap (not Hashtable, which is also synchronized unnecessarily).

As a general note, I'm hoping that D5 can go out in a few weeks (I haven't heard from Gary on his expected timetable so I'm not sure). And since much of the support stuff for diplomacy, like civs having military AI isn't implemented yet, I doubt even the external diplomacy stuff will be in D5. But as soon as we have enough to make it interesting, we'll certainly put it in.

As I said in my private email, a couple of weeks isn't too far off the mark, provided the AI is truly embryonic.

I guess most people in the forum are aware of my hatred of putting in code that isn't functional. Unless it does something useful, leave it out. NEVER put in code because it might be useful later. In this context, there is already a class called Attitude, which, currently, has three static instances of subclasses called ALLIED, NEUTRAL and ENEMY, to determine how encountering armies act. For D5, every other civilization is an enemy, but that is a scenario option, if it were otherwisem the system would still work. It seems to me that this structure could be extended to a DiplomaticStatus class with more options in it, by D5. If more things are introduced, it is unlikely that they will have a direct impact on D5 and hence should be postponed to D6, when their implications can be worked out.

By the way Sancio, I am really glad to see someone working through what are, in effect, interfaces. Have a look at the technology thread where I published the whole technology interface. This works, but is not included in D5 becouse none of the code to use it has been written.

As to hiring advisors, I like the idea, though I would put it in terms of sacking (beheading?) ministers and appointing other ones, a la Queen Elizabeth I. But not for D5.

Cheers

[Sancio]

Originally posted by Gary Thomas
Modern Java usage prefers using the java.util.List interface or the
In addition, Vector is synchronized by default, ArrayList is the current preferred option.

That's true. I already made changes to use java.util.List. Thinking of using LinkedList since I don't have a need for quick random access.

Originally posted by Gary Thomas
Is there some specific advantage in dividing the ministries into interior and exterior?

I don't like this part of the code either. I wont be implementing the InteriorMinistry any time soon so I just going to take it out of the class.

Originally posted by Gary Thomas
If the concept of a treaty is extended somewhat, the contacts and treaties could be objects implementing the same interface, and hence only one map (by civilization) is required to record these matters. There seems little advantage to having two lists to, in effect, cover the same set of actions. Incidently, the map should be declared as Map, but implemented as HashMap (not Hashtable, which is also synchronized unnecessarily).

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.

Originally posted by Gary Thomas
In this context, there is already a class called Attitude, which, currently, has three static instances of subclasses called ALLIED, NEUTRAL and ENEMY, to determine how encountering armies act. For D5, every other civilization is an enemy, but that is a scenario option, if it were otherwisem the system would still work. It seems to me that this structure could be extended to a DiplomaticStatus class with more options in it, by D5.

I have an enumeration class which I am going to rename to DiplomaticStatus that should take care of this. I can post it if needed.

Originally posted by Gary Thomas
By the way Sancio, I am really glad to see someone working through what are, in effect, interfaces. Have a look at the technology thread where I published the whole technology interface. This works, but is not included in D5 becouse none of the code to use it has been written.

Will do!

Thanks for all your comments. They were very helpful. Keep them coming.

Jose