Coding organization for Clash

[Mark_Everson]

I'll certainly vote for sending the whole thing if practical. We'll just have to test to see what the deal is. Another possibility is to use the alternate-world setup I Think I may need for the AI to just send the relevant fraction of the map and other updates. This will speed things along at the beginning of the game. During modern times you'll need to send the whole thing anyway because everything is known and more interconnected. But by then people should need to do more with their turn.

Also sending a good chunk of the world would mean we could use the client machines for 'deep thought' AI that doesn't require much BW...

Anyway, those are my first takes on the situation.

[Osiris]

Mark,

The problem I have with the client machine(s) doing any of the 'guts' processing is the machines getting out of sync, I am sure there are lot lot of things that depend on random varaiables. All the client machine(s) will make different maps after a while, thats why I go by the idea of just sending the whole map over each time. This is a turn-based game, it doesn't have to take under 400ms to send all the data each turn.

Basically doing snything other thsn the simple aproach is impossible unless there isn't any random variables we make for map processing.

although, I have come up with a bit better of a way, have the multiplayer save the map from last turn, and the host sends any changes for this turn, then the multiplayer changes what is needed and then 'game.world = game.mp.world'. If you guys want to make an actual function for this than it can be like this also - 'game.world.update(game.mp.world)'

Again please give me your feedback. But one thing no matter what we do with multiplayer so far I will have to no EVERY single variable that makes up world, so multiplayer can make a couple of its own fake worlds for what I just explained above.

[Mark_Everson]

Osiris:

First, with your next post why don't you start a new thread called "multiplayer coding issues" or something like that. There are a lot of things we need to address, and it certainly an important enough topic to have its own thread. I've been thinking about the best way to do this a bit recently, and will write it up once I'm sure my ideas are completely half-baked .

>
The problem I have with the client machine(s) doing any of the 'guts' processing is the machines getting out of sync, I am sure there are lot lot of things that depend on random varaiables. All the client machine(s) will make different maps after a while, thats why I go by the idea of just sending the whole map over each time. This is a turn-based game, it doesn't have to take under 400ms to send all the data each turn.
>
I don't think you got my point here. The AI in computing its strategy does not affect the game world directly. What I'm talking about is the AI thinking about the right actions that each civ should take, in a variety of the areas, and then picking the best one. The random numbers generated, and procedure involved in this in no way affect the game world. Only when the actions are actually undertaken do they affect the game world.

Let's consider what this does if you have a hub-and-spoke architecture, where only one player's computer executes each turn after collecting information from all the others. The hub player's computer would get not only information about the other player's moves on the map, but also of the determined AI strategies for some civs. After executing everyone's moves using the player and AI strategies the public computer would then send out the new game state to everyone.

Finally, there may be ways around the random number generation problem. For instance, you could pick a number of "turn-start seeds" for the random number generator at the beginning of the game. So long as each computer has this list, and each players actions are purely deterministic, the different versions would always be in sync. I'm not sure I've thought this out completely, I'm just brain-storming here.

>
Basically doing snything other thsn the simple aproach is impossible unless there isn't any random variables we make for map processing.
>
I don't think this is right. I think the processing and information transfer can be done in a distributed fashion also. I'll outline that idea tomorrow once I've had time to think about it a little more.

>
although, I have come up with a bit better of a way, have the multiplayer save the map from last turn, and the host sends any changes for this turn, then the multiplayer changes what is needed and then 'game.world = game.mp.world'. If you guys want to make an actual function for this than it can be like this also - 'game.world.update(game.mp.world)'
>
yes, that seems like a valid way to do it if I understand your nomenclature.

>
Again please give me your feedback. But one thing no matter what we do with multiplayer so far I will have to no EVERY single variable that makes up world, so multiplayer can make a couple of its own fake worlds for what I just explained above.
>
well, I think if you need to know every single variable that makes up the world, then we're not using a proper object-oriented approach. We need to think hard about this, because I'm convinced there is an "easy" way to do this, and Lots of hard ways .

[Mark_Everson]

Progress report on high-level program structure

I am in the process (about half way thru) implementing the code structure below with my old Clash code. This will make farming out different pieces to the coders much easier. They can build on what I have or replace it at their discretion. We will try to keep some version running at all times for demo purposes. I used as an outline F_Smith's proposed system for making the code better in terms of OO structure.

[b]Game (main) class
|                   \            \...
mainWorld; turnHandler; gui; io; theWorlds; players; MacroInterpreter...
|                 \...            :
theCivs; theMap; turnNumber 
[/b]

I am done with mainWorld, TheCivs and mostly done updating TheMap. I'd hoped to finish this weekend, but it ain't gonna happen .

I think most of the names are self-explanatory. The wierd ones are mainWorld, which is an object of type World and theWorlds, that contains an array of World instances. Each World instance contains a theCivs, and theMap object and an integer turnNumber. This is a little cumbersome, but it means that a copy of mainWorld can just be stuffed into worlds to be saved or modified without further effort. This will support deep thought AI, information where differences over turns are important, and possibly multiplayer.

[This message has been edited by Mark_Everson (edited October 03, 1999).]

[Mark_Everson]

WoooHoooo! I've finally more-or less finished the reorganization of the code to the new high-level class structure shown in the post above. I will do whatever new commenting and neatening I can stand for the rest of today...

If anyone needs the version with the correct high-level structure now I can send it off. Just email me.

This is automatically generated documentation courtesy of the Javadoc feature of java. If you start at the tree link you'll see all the classes. I have now reasonably documented Game, TheWorlds, TheCivs, TheMap, TurnHandler and GUI from the diagram in the post above. Unfortunately there was a teleporter malfunction on the images, so you will have to appreciate the docs without the pretty doodads. (If you want to see them look in Game where I took the effort to hook it up properly) Added to these in the more-or-less-complete Javadocs are the ones I've done for the military model so far which are: TF (task force), Unit (military unit), UnitType and UnitStats . For the rest of the files you will get variable and method (routine) names only.

Next I will probably take a shot at integrating the diplomacy stuff that Jacobo has sent me. Unfortunately Jacobo can't do any more on it , so if there's anyone interested in the diplomacy coding job, its now open...

[This message has been edited by Mark_Everson (edited October 04, 1999).]

[Mark_Everson]

Coding Progress:

I've implemented part of what Jacobo did in the diplomacy area. The player now has a dialog pop up when an AI civ requests a change of diplomatic state and can accept or reject it. The player can't initiate diplomacy right now, but this isn't urgent since diplomacy is symmetric as now handled. So if it is to another civ's percieved advantage (using the diplomacy AI) to have a better treaty with the player They will likely propose it soon enough anyway.

New things that are better documented in the Javadoc accessed by the post above is mostly Diplomacy. Civ is now mostly documented. Diplomacy-related classes of: Treaty, Clause and a few others are partly documented.

As usual anyone who wants the new code should email me.

The game is fun even at this early stage with only a few things implemented. When we get a few more things in Clash It'll Be Really Fun IMO. I can't wait for a working demo we can distribute.

My current plan is to work on a crude model for the navy so I can invade Corsica!

[rentgen]

Hello Clashers!

I've talked with Mark a bit on the topic and he asked to post a possible package structure organization for the clash project.

Well, after a brief look at beta2 code i came up with following. It is definetely open for discussion. Before the actual stuff, a few remarks.

1. I'd suggest to re-write some classes in order to make the whole thing more MVC style. MVC stands for Model/View/Controller, a programming paradigm widely used in SmallTalk
What i mean, is that IF we separate game engine from the GUI stuff COMPLETELY, it will make easier: development, maintaining, addition of new features, even various GUIs!
(maybe i wan't a text one ;-)

Now there's a problem with a few classes, like TheCivs. If it is just an array, it should do that, and then we pass it to a corresponding GUI class to perform visualization.

2. I also wanted to say a couple of words about encouraging the use of interfaces, but i won't. Not untill i look deeper into the code.

Well, here we go.

clash:
General game mechanics, main class
Game.java
TheCivs.java
TheWorlds.java
World.java



clash/ai:
ai stuff, obviously
CoreAI.java
MilAI.java



clash/civ:
stuff related to civ as a whole
Civ.java
CivPosn.java
CivTech.java
CivTechArea.java
Culture.java



clash/economy:
economy modelling classes
BaseMapSquare.java
Cost.java
EconSite.java
EconStrategy.java
MapSquare.java
PopSquare.java
Province.java
Sector.java



clash/gui:
user interface
AboutDialog.java
AboutDialog1.java
DiploDialog.java
GUI.java
GameFrame.java
IO.java
MapCanvas.java
MapSquaresFrame.java
ProvFrame.java
QuitDialog.java
QuitDialog1.java
SmallMapFrame.java
TechFrame.java
TestJToolBar.java
TheMap.java
ToolBarFrame.java
WholeMapPanel.java



clash/military:
all related to military management/combat
Attack.java
MilTheaterStrategy.java
TF.java
Unit.java
UnitStats.java
UnitType.java
VitalSquare.java



clash/relations:
inter-civ relations, diplomacy
ChangeStatus.java
Clause.java
Diplomacy.java
Relations.java
Treaty.java
Tribute.java



clash/tech:
technology classes
Tech.java
TechArea.java
TechItem.java



clash/util:
miscellaneous classes
GenericStuff.java
MyMath.java
SerialCloneable.java
StupidList.java
TurnHandler.java
Util.java


Helps to see things more clearly, IMO.
Post comments.

Anton.

[Mark_Everson]

Hi Anton:

Thanks for taking on this job! I think in general your approach is very good. I just have a few comments about the details. I'll cite them in the order they occur in your writeup.

The Model/View/Controller idea sounds good in general. Although I'd like to hear more about the specifics. I don't understand your statement "Now there's a problem with a few classes, like TheCivs. If it is just an array, it should do that, and then we pass it to a corresponding GUI class to perform visualization." Can you elaborate further?

Packages:

I think we need a map package also. The map is involved in both economic and military things. So I don't think the four map classes belong spread out as you have them. If you put TheMap and the three classes that represent map squares together it would make more sense...

IMO the package names should be at Most 5 characters long. Otherwise there is too much typing/line space used by them. Most can be handled easily. For Relations we could either use relns or diplo.

Other than those issues it looks great!

Thanks for suggesting and looking into it.

Mark

[rentgen]

Mark,

Sure the map classes should go in one package. I was not sure how to group them here... I agree with renaming as well.

About the MVC and that nonsense sentence i wrote :-) There are at least two classes, Civ and TheCivs that except for game mechanics contain GUI related data. Like Civ class contains colors of the civilization. I think this data should be held separately. For the civilizations, for example, this could be realized with a HashMap that uses Civ as a key and some CivGUIData object as a value. Then the class that performs visualization would be passed with an array of Civs to visualize, consult the HashMap and perform the actual visualization. Thus we will achive clear separation of game mechanics/engine from visualization and user interaction stuff, that is a part of GUI.

All the other classes can be revised in a similar fashion.

Well, hope this makes things a bit more clear :-)

Anton.