 |
|
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
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:15
|
|
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
|
|
quote:
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
|
 |
New Zealand
Mar 2001
time: 17:15
|
|
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
|
|
| |
|
|
|
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
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:15
|
|
quote:
/**
* 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).
quote:
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
|
|
quote:
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.
quote:
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.
quote:
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.
quote:
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.
quote:
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
|
|
| |
|
|
|
Sancio
|
|
Due to Gary's suggestion I have redesigned the ExteriorMinistry and created a new Interface Ministry.
code:
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.
|
|
| |
|
|
|
Sancio
|
|
quote:
Originally posted by Mark_Everson
I think I'd call it Diplomacy rather than Diplomat...
|
Agree. Already made changes.
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:15
|
|
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.
Last edited by LDiCesare on 05-09-2001 at 17:04
|
|
| |
|
|
|
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
|
|
quote:
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?
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:15
|
|
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:
code:
/**
* 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...
|
|
| |
All times are GMT. The time now is 05:15.
Apolyton Time is 00:15. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
31-08-2001 03:20
.
.
|