Clash Coding Standards Discussion

[Mark_Everson]

Hi Laurent:

You and Gary should definitely talk this over to make sure you're using similar approaches, since the two of you are doing the XML stuff at the moment. You lost me on the vocabulary half way thru the post, so I don't think I have anything germane to say about the technical details.

"actual military units on the field" If you mean you want to save every single unit in the active game in XML I personally think this is a waste. They should just be saved as binary using serialization IMO. XML will be prohibitively large to save everything in the game, and should I think be only used for initialization files.

[Gary Thomas]

Sorry, just saw this one.

I have been using a small part of the Xerces SAX implementation. As it happens DOM would work well for our system where you want to read in the whole file. Since I used code that I developed for work, I used SAX, which has the advantage that it can skip anything it isn't interested in.

My stuff is finished and tested (for the tech model). I would be happy to email you the source code for you to check for your purposes. For obvous reasons it would be better if we used a uniform pattern.

I intend to extract, from the Xerces source code, the part relevant to what we do and use only that (rather than the whole of Xerces - 1.49MB in jar format). Because this is relevant to my work, and because I get paid an obscene amount per hour for work, I prefer to do this at work. Unfortunately, I cannot always set the priorities in that area, so it is still on hold...

Send me (gthomas@takaro.co.nz) your email address and I will send you a zip file with the xml package.

Cheers

[Mark_Everson]

Code package proposal:

Gary made a good suggestion that we change the package game.data to game.model since its not just data, but whole models that are in there.

Unless someone objects, I'd like to make the change the next time I have everyone's work unified I'll make the changeover.

Anyone disagree with the change?

And also I would like to change the main dir name to ClashD5. Its a better name than the AlphaClash... I've been using, and it will leave each of us a set of direcories with milestones of the project as we move on to demos 6 and 7.

Again, does anyon object? If not, I'll make that change the same time as the other stuff.

-Mark

[Mark_Everson]

Ok, I'm going to make the changes above today, or as soon as I get the most recent code from everyone. The (new) model package will go in ClashD5\game\model

I'll put the tiles semi-permanently in ClashD5\class\tiles\ (Maybe it should just be ClashD5\tiles\ ?

I'll put the class files in ClashD5\class\ so I don't have source and class files all jumbled together. I will also put the xerces.jar file in that dir since then it'll be on the classpath.

Other suggestions, criticisms?

[This message has been edited by Mark_Everson (edited April 22, 2001).]

[LDiCesare]

We need a place to store resource files (xml). I suggest they go in a directory at the same level as the tiles: class/resources for instance. I'll send Mark my xml file for military units as soon as I can and put some code in UnitBuilder to read the file. I believe a common service to locate the resources should be provided. Where is the class/tiles path stored? Can we reuse that to build the military units (which are model, not view)?

[Mark_Everson]

Yeah, that's right Laurent, we should figure out how to do that stuff now. I'll leave the discussion to the pros, who will actully know what they're talking about .

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.

IIRC when we go to a jar file we may need to use getResource anyway. Is that right? If so, we should move to a system using that.

[Gary Thomas]

I deduce from various minor snippets of information that the system used for code is:

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?

Cheers

[Mark_Everson]

Gary:

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.

Applet functionality is generally not to play D5 over the web, there's likely to be too much data that needs to be passed for people to do it without being frustrated. But where I heard strong resistance on demo 4 was that people (generally passers-by) didn't want to download d4 and then another many-meg runtime environment for java. So the idea of the applet is to let people that are only moderately interested do the one download of D5, and then use their browser's java setup to run D5. Of course they won't be able to save files and such, but it would let them see what the demo does and comment on it in general. Does this sound like a good plan, or a boondoggle? If its too much work, or dumb for some other reason, we can always skip it, and just put up with occasional abuse . I'm experienced with that anyway .

[Richard Bruns]

Applets are good. They can be loaded uo and played with absolutely zero effort. Having to download and do manual setup can be quite a turnoff. Many popular web game sites like www.javagamepark.com have applet-only games. Saved games are not such a big loss.

But I thought we were using xml for game data, which means that we should be able to save games. Some applet games will save progress. What is it about an applet that eliminated savegames anyway?

[Mark_Everson]

Richard:

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.

Applets have restrictions on what they can write to disk (basically nothing). So unless the server is set to save things, they can't be saved AFAIK.

[Mark_Everson]

Another issue...

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.

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

So what TestEcon does is run the normal turn handler for most squares, but the one that is the focus of the test, it excludes as in the code above, and runs its own lower-level version of a turn handler with detailed diagnostic output. The defect in doing this on a larger scale is that you always need to be prepared in the midst of turn handling to switch over to some test method to execute the turn handler for some particular object. Anyway, its something I've got in now, and I'm not sure if it's useful long-term or not. Your thoughts would be welcome.

[This message has been edited by Mark_Everson (edited April 29, 2001).]

[LDiCesare]

I don't like it.
There are two ways I think output can ve handled:
Either you pass a diagnostics object or figure to all interested code, and
they manage it:
For instance, you have a method

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

or you can have a set of listeners that you put on the interesting objects, and the listeners make the "ifs". Probably less efficient, but IO/GUI needn't be known from the code so you can change it or, even better, use 2 different GUIs for one thing. This means you need some formatting of the data passed to the listeners.
For the moment, military code uses that pattern, with data being all Strings. In the long run, data should derive from a class with some more info like the concerned civs, the string and probably type/detail info.

[Mark_Everson]

Thanks for your idea Laurent. It sounds workable in general to me, but I haven't had a lot of time to think about details. Hopefully Gary will pop by to give his perspective on how to do this too. I'd prefer not to make a decision with just one person's input!

[tjawatts]

A comment about java runtime environments. Now firstly, a casual user obviously would not want to download the JRE just to run Clash. However, it is a useful thing to have installed in general, you can run other things with it!

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?

Tony

[Mark_Everson]

Hi Tony:

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.

What do the other coders have to say about this? I'd hate to have Tony waste his time...