I think we need an organizational structure that is as flexible as possible for this project. Due to Real Life glitches that are sometimes unpredictable, even committed individuals will essentially drop out for periods of up to a month or so, and the project needs to be able to make progress despite those problems. A flexible team approach seems to be the best way to handle this.

I guess what I suggest initially is to break down game areas (e.g. military or main map) by types of competence in programming, for instance graphics, interfaces, model "guts", Internet capabilities, AI, etc. As an example, I think I can do a good job with model guts and AI, but get increasingly less competent, and less interested, as we move into the other areas.

IMO there should be a programmer in charge of coding the guts for each major functional/model area. For most functional areas of the game we already have dukes to handle them (or hopefully will soon). My view is that combining the dukes in charge of the various areas, with the model guts coders, and with people doing other functional things (interfaces, graphics or tools) gives us fair coverage of what needs to be done.

For each area, the person doing the guts of the particular model would have to go first, providing javadoc or better documentation of what classes and variables they plan to use. As the organizational structure for the code is built up, there will be very tight communication between the duke and the coder for that area. Once the guts coder has the area outlined, even if they are sidelined for awhile, someone else can pick it up if needed.

The best level of documentation for each model or implementation area should show private variables and methods also, so that people doing the interface for it, etc. can see what's going on. Then there should be a lower level of documentation that just shows the classes, and methods, that interface with other modules. After that, the interface, graphics, and tools people can start in on their detailed specs.

What this would mean, is that our people that, for instance, are good at interfaces, could move from area to area starting with whatever is ready first, and not have their unique talents wasted by coding up the "guts" of any particular model. People working in the "flex" areas like interfaces or graphics, should sign up in whatever area they're interested in. When an area's team has enough people with the right skills to do its job, then new participants will have to sign up for some other area. When an area is at the point where it can't proceed much further since it is being held back due to progress and other areas of the game, those team members that can should move on to another area of interest.

I, and hopefully some others, will try to function as "flex programmers" to move along the areas that are progressing slowly for any of a number of reasons.

Will my proposal work? I have no idea. But anyway, we can start the discussion, and hopefully have some sort of agreement by the end of August. Clearly we need to plan this out in somewhat more detail. I haven't even begun to discuss low-level things like who has a lock on which part of the code etc.

Please let the group know what you think. I would especially like to hear from those of you who have done planned coding professionally. I'd like to hear your opinions on how to use your knowledge of how it works in a corporate environment, and how those planning tools might work in an amateur project like ours.

If I understand this project correctly, we are going to be building a virtural 'world', populating it, and setting events into motion. So, may I humbly suggest as a starting point for discussion:

We will need a 'Game' class that contains a 'Space' object (a map/world). Then we add a 'Life' object to that 'Space'. Finally we feed the world and it's inhabitants into a a 'Time' object (thread). We will also need some other supportive utility objects (IO, etc).

The 'Space' object will need to have a 'Map' object and various 'Screen output' objects, including and especially the map displays.

The 'Life' object will contain 'Player' objects, 'Civ' (non-player civs) objects, and all the AI.

And the 'Time' object will need threads to control the timeline, 'turn' code for the 'interaction' of world elements, etc.

So at it's simplest form, Game.class will look something like this --

import java.whatever.*;

public class Game
{
Time t;
Space s;
Life l;
IO io;

public Game()
{
IO= new IO();

s = new Space();
l = new Life(s);
t = new Time(s, l);
t.start();
}
public static void main(String[] args)
{
Game g = new Game();
}
}

*******

Again, this is just a starting point for discussion only. Please poke holes in it.

A little playing convinced me it would be better for the GUI to be it's own class, loaded first, perhaps (or not) containing it's own thread for refreshing the screen when changes have occurred.

So, how about:

import java.whatever.*;

public class Game
{
GUI gui;
IO io;
Space s;
Life l;
Time t;

public Game()
{
gui = new GUI();
io = new IO();

Assuming no one has any massive critical thoughts on this beginning, I'll move on a bit.

The 'Space' class.

This object will need a 'generateMap()' method, a 'getMap()' method, 'loadMap()', 'saveMap()', etc.

So it should look something like:

public class Space
{
public Space()
{}

public void generateMap()
{
}

public Map getMap()
{
}

public void saveMap()
{
}

public void loadMap()
{
}
}

Many were friends. Ah, well.

I agree my names are poor. That's never been my strong point. I was operating conceptually, looking for the strongest object-oriented design to enable us to fully model 'reality'. Hence 'Space', 'Time', 'Life' -- just general concepts, large scale 'groups/objects' that will be needed to model reality.

Maybe not the best place, but we need to think about the programming of the game.

My ideas:

1. We need to develop a common interface for the macro language.
2. All the possibile game "constants" must write to text files (similar like SMAC and CIV).
3. Something like a minimal part of the C or Pascal language can be the macro language of the game.
4. We need to think about to write the speed critical parts and AI parts in java, the rest is in the new macro laguage, so more people can help us to finished the game. (probably more people can write simple rutines in an easy to understand macro language, than in a full power OOP language like Java).
5. Advantage: The programmer team can concentrate the programming effort to produce the most difficult parts of the game program, like graphics or AI.

I already sent a sketch of a "new" language (a part of the C language). I'm not a professional language developper. Maybe somebody has better idea(s), or can improve my macro language.

Sorry to hear about the layoffs, that's rough.

On your overall code organization suggestions, you're clearly right. If we don't split it up like that the main class will be awfully cluttered. I will try and come up with some names, and tweaking of your suggested areas soon.

Blade Runner:

1. Is your issue I think... your initial shot at it looked good.
2. Yes, this is fundamental, I agree completely.
3. Again you... Do you have a time-frame in which you think it might be ready?
4. Wow, that's pretty radical. I think, and this is based on no experience , that a system where the macro language "shadows" Java code will work better for most users. By shadows I mean that there is java to do everything, but you can replace any part of it with the macro language. Once you have the macro language developed. I think we should first try your idea with one particular area of the code, and see what we think about that approach. We should clearly discuss this further.
5. IMO, anyone who can program well enough in a c-like macro language, can easily learn enough Java to do non-specialized programming (i.e. no graphics...) on the "guts" of any game model. So I think the potential gains in this area are not large.

I kind of have a different take on this.

1) The code itself will need to be written in OO 'Component' style (or 'Bean' style, if you're familiar with EJBs). All variables will be 'paramaterized'. That means methods will be provided so that all the variables in the code can be set from outside the code. The game itself needs to be written in Java -- the 'game engine', the graphics, the AI, the IO, etc.

Game class
Contains following objects:
civs; map; turnHandler; gui; io; worlds; players; What Else?

I think everything is self-explanatory except for:
* worlds, which are essentially copies of the whole game information that May be used for AI and / or comparison purposes. For instance we could save the game state from Last turn (or 10 or n turns ago) as a world, allowing comparison between now and then of any information on rates of change the player or AI might want.

* players, which will start out just holding information on the solo player, but will eventually hold multiplayer support information.

Unless someone raises objections to this approach, I will begin migrating the existing clash code over to this model on Monday the 5th.

F_Smith:
We decided in the meeting today that we will write all the clash code to beans specs allowing trivial use of reflection for the macro language and off-line scenario editor as you suggested. Please check out the meeting thread when you get a chance.

You can define a component (Let say CivMap) with the map array (must be static) and all the map related components what we inherited from this component can DIRECTLY read or write the array.

Yes, I know That. Perhaps I don't understand your comment. The question is, how can you access the array through reflection using the macro language? I have come to the conclusion that this one could be done 'by hand' within the macro language parser. However I wanted to see if there's either a better than the usual way using reflection (as I mentioned above) or if someone had another clever thought.

----------------------------------------

All:

I've also revised my idea about high-level program structure. Since the main game world and the ones in worlds are Really the same object it should instead look like this IMO:

Game (main) class
|...............\
mainWorld; turnHandler; gui; io; worlds; players; MacroInterpreter...
|.....\
civs; map; turnNumber

Where mainWorld is an object of type World and worlds contains an array of World instances. Each World instance contains a civs, and map 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. It occurred to me that World objects can also be used for multiplayer support since the server can then merge copies that are sent from the various players gracefully, while keeping a world recieved under each player safe from conflicts with the mainWorld on the host computer.

Whatcha think?

I'm not a Java expert. My idea came from my Delphi experience. If I want to use an array without speed penalty, I produce a common ancestor component, which have all the variables, arrays, lists, etc. what I want to read and write directly. I think (but I'm not realy sure) we can manage the Java Bean components the same way.

I.E.:

CommonAncestor{}
|
|
Game{}-- Turn{}--MacroInterpreter{}--Something{}

If we put the map array declaration in the CommonAncestor component all the inherited components can read and write the array directly. Even the macro language interpreter can inherit form the CommonAncestor, so there will be no speed penalty. On the other side we can use the reflection to reach the least important methodes, variables, etc.

In the Delphi system we have a similar possibilty like the reflection. Frequent use this possibilty can slow the system quite well, so I think to use the reflection will cause a big speed penalty too. (The experts books sad NEVER use this possibilty if you have a correct description of the component.)

I don't like everything having direct access to the map through a common ancestor. That strikes me as even worse OO than making it public. At least if its public you need to call it with Game.map.m[x][y] or so. This slows things a bit, but at least makes it clear it is the main game map you are messing with as opposed to some other world's map. Besides the Common Ancestor class idea gets Very complicated once you move beyond the map and into arrays that govern squares in each province, TFs in each civ etc.

We clearly need a timing test for using reflection vs more standard access methods for different things. The things we need to check would be speed for simple property getting and setting, 1-d arrays, and 2-d arrays. We will have to then use that information to figure which speed-critical parts of the macro language need to be 'done by hand' and which ones reflection can suffice for. Clearly any user-hacked classes will require use of reflection unless the user wants to change the interpreter also...

Anyone have Java experience with this kind of stuff?

--------------------------------------------

On another subject, I've done some experiments on the timing penalty for using serialization to automatically make deep clones of objects. Serial Cloning (sCloning) is attractive because you don't have to write a unique clone() method. Conventional clone() methods can get moderately involved for a class that contains many types of objects.

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...

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)'

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.

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.

code:

---

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

---

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.

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.

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.

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.

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 :-)