The tiles path is now stored in the file where its used. I agree we should look for a scalable and consistent way to handle this.

ClashD5\game
ClashD5\game\model with subdirectories
ClashD5\game\view with subdirectories
ClashD5\game\controller with subdirectories

with all the class files in a matching directory tree like:

ClashD5\class\game
ClashD5\class\game\model with subdirectories
ClashD5\class\game\view with subdirectories
ClashD5\class\game\controller with subdirectories

and with tiles in

ClashD5\class\tiles

with similar subdirectories for other resources.

Is this right?

Yes

On another subject:

It occurred to me I haven't explained yet the point of Applet functionality for D5, and how I'd like to use it. I'll present a brief description here, and let the people more in the know tell me if it'll work right.

This Applet would take about 5 min at an average internet connection's speed to open with the size of the existing code and graphics (I think). Soon it will be double that. That's the problem.

How to handle differing diagnostics and output desired by the player in demo 5 and going forward? I think we need something like a Diagnostic class, which just has a whole lot of flags saying what the programmer or player wants in terms of information from the game. As the code executes it would output information to whatever preferred GUI element as called for by the flags. For demo 5 we can use it for things like the detailed econ output I spoke of above, and detailed military output (perhaps the government stuff that shows up in at window in the Beast code also). I would like to hear everyone's thoughts about the best way of doing this. The way that I handled it in TestEcon is shown below. I think it is an okay way to handle things for small-scale efforts, but probably isn't scalable. What I think is the more conventional way is just to have our Diagnostic class with all the flags turn on and off various types of output as the models are run. This would also be useful in various debugging activities.

What I have currently for the Econ model bears discussion since I don't think I want to rework it for demo 5 into what ever new formalism we are using. Also, you might see something useful in the way I'm doing it, so I'll tell you about it. What I do is allow the turn handlers to run, but to be passed an excluded object that will be skipped when they get to it. (It could also be an array of excluded objects if we wanted to make it more versatile) The example code below shows how it works in EconomyTurnHandler.

code:

---

public void oneTurn(GameData d, Object excludedObject)
{
    //excludedObject provides for passing turn handler a single object   
    //where turn should not be executed, here civ...
    //primary reason is if that object is being used for testing, and 
    //turn is being handled at a lower level for that one
    
      if (excludedObject != null){
        if ( excludedObject.equals(civ) ) return;
      }
    
        //go thru provinces of civ for each phase -- Do all phases for each Province for now
        
        Iterator it = (Iterator) civ.getAllProvinces("");
        
        while(it.hasNext())
        {
            Province p = (Province)it.next();              
            new ProvinceEconomyTurnHandler(p).oneTurn(data, excludedObject);
        }
     ...
}

---

And the province turn handler .oneTurn looks very similar to the one above...

code:

---

nextTurn(int verbose)
{
  ...
  if (verbose == 1)
    IO.println("Stuff");
  ...
}

---

I dont think it is necessary to go out of your way to solve this problem, especially for the demos. When it comes to a production release you need to provide downloads for those users who do/dont have JRE already, the installation of the JRE would be integrated with the installation of clash.

Maybe I could look into making installation easy?

I think your looking into portability would be great. I just don't know Anything about other OSs, so the more you can give directions for, the better. But I still think we will get resistance from some to downloading the jre. We can get you a version of the d5 code soon... Although Gary may already have something in mind for deployment.

It would be great if I could get a look at the code. Should be able to iron out any problems with protability and find any OS specific code. Then I could look at the method of deployment if noone else has done that.

Finally, I can do some actual coding, I dont know what to do, I dont want to encroach on anyone elses territory! If you are coding a specific section and would like me to do some sort of subsection for you let me know. Otherwise I can just look at the code and find something which hasnt been implemented yet!

Cant wait to get started!

Sent the code this AM, tho it isn't completely current as I explained in the email. There shouldn't be any OS-specific code in there.