First, Mark's approach will work. That is the basic 'wargame' type approach that is used in most other games -- and it's fine.

But we can go deeper, providing more realism, if we want. We can break these objects up by their functional differences. One excellent example is in 'Sid Meirs Alpha Centauri', if any of you play that. You can mix and match chassis, bodies, weapons, armor and special abilities to custom-make units. That is the approach I am after here.

I would like a class 'RangeWeapon', then a class 'Rifle' extends 'RangeWeapon' and implements a 'HandHeldWeapon' interface. Off the top of my head, I can think of at least a few subclasses of 'RangeWeapon' that should have very different capabilities -- 'Bow', 'Crossbow', 'Rifle', 'Laser', 'Plasma', 'Mortar', etc. There are probably others.

This allows different types of behavior for each weapon type -- the 'train' method could vary. The 'breakdown' method has to vary, I think (bows don't explode accidentally, for example). The 'maintainance' methods have to vary (when you repair bows, the method should require wood, when you repair a modern rifle, you need spare parts).

All ranged weapons would require a subclass of an 'Ammunition' object to be effective, so different types of ammo are available (arrow, ball, bullet, explosive, laser battery, etc). Better ammo can be invented/created, and given to existing weapons (selectively, if it's expensive). Bayonets can be fitted onto rifles, but not bows. Iron arrow heads can be used where you have access to iron.

And this is just for rifles. Every tech type can gain added capability and realism with an object hierarchy.

Again -- Mark's idea is still a good one. It works fine. This added realism is likely going to bore 80% of our players, who will never use the depth. I've been playing Alpha Centauri for about 6 months, and I just started building custom units!

For short term stuff this is pretty much irrelevant since we will just throw things together.

I think in the middle term, when things are being actively tweaked in the military model, the way I proposed will allow faster progress. (Because a non-coder can put in whole new weapons by hand, etc.) We can implement most everything you (F_Smith) said above using my approach IMO. BTW I guess I should have called my example RangedHandWeapon since it wasn't meant to cover artillery etc.

In the long run I wouldn't object to some selected 'specialty' classes for things that really can't be handled well at the RangedHandWeapon level. We could have special tweaks based on inheriting from RangedHandWeapon and maybe an interface as you suggest. I do think that the detailed classes going down an extra level in inheritance should be the exception rather than the rule. The AI will Never be able to handle all those little nuances anyway, so the more detail tweaks, the more imbalanced will be the game IMO.

Also, I think having literally a hundred or so classes just for weapons, and another several hundred for techs is Waaaaay overboard. And most of the things that were suggested for the detailed class proposal frankly strike me as something only a few percent of the players would even care about. Who wants their empire to fall because the right ammunition wasn't available??? We would Lose, not attract, players over that one! Remember, this is a Strategic game, not Squad Leader .

So, do we have a deal? My approach in general, but the freedom to push the envelope in important cases. And for your personal version of the game you can do whatever you want!

I agree that by far most players will never want to go to that level of detail, at least at first. Altho what I find happens with my favorite games is that the complexity adds to the length of time it holds my interest. After I learn all about the basic game, and have played it a few dozen times, I lose interest unless there are new things for me to find.

Please forgive me for thinking that once you see the flexibility and power that the subclasses can give us, and how much easier it will be to code using the object hierarchy, you might end up on this side of the fence. Especially when it comes to coding up techs.

Because I'd like to point out that weapons are not the best example of a specific tech application for this discussion. The differences between a bow and a rifle, while significant, are minor compared to the differences in many other techs. I don't see a 'TransportationUnit' class being able to cover planes, trains and autos, for example.

But, as you said, we can make those determinations later.

Ammunition: I don't think individual ammo types is a good idea at all. At least my take was if a unit is in supply and enough manufactured goods get to it, then its assumed it is supplied with ammo of whatever type it needs. Otherwise you get into a micromanagement nightmare IMO. So it is assumed that the medieval society produces arrows, and the modern one produces cartridges and whatever else is necessary. Only if a unit is cut off do we dock its effectiveness due to lack of ammo. For slingers the penalty would be slight, for modern units it could get quite severe if the out-of-supply lasts too long.

A book I've been reading "Thinking in Java" maintains that it is evil to use inheritance unless you intend to use it functinally thru upcasting to a base class. So use of a Vehicles class is ok if you will have a container of Vehicles that each have their own version of move(), stop(), pickupPassengers(), pickupCargo() etc.

But the author (Bruce Eckel) says that if your inheriting classes add more methods or variables, then its the sign of bad design.

To say subclasses addding methods is bad design is in my opinion twoddle. it's probable that he java creators thought so , take at look at some of the docs and you'll find examples of classes 2,3, or 4 levels down a heirarchy adding methods to their superclases - most Swing or AWT classes spring to mind.

The most important rule in my opinion is does it make sense in the context of what you are developing.
e.g an app used in aircraft design may well subclass passenger and cargo planes from parent AirPlane class , but an arcade game probably has one class with a flag for the type to determine score for shooting it.

don't forget interfaces , in a lot of cases these are probably far more appropiate than a class, the obvious example alluded to above is where the subclass would not really have common code with the parent or siblings. e.g petrol/ deisel / electric cars are probably good examples to subclass from Car Class - they probably share lots of common code , with just a few differences like how they are started. Car and AirPlane though are probably not best SubClassed from Vehicle Class as although they have the same methods ( start , drive , stop or whatever ) the methods would probably be implemented differently for each subclass with no real common code, a Vehicle Interface would be better.

But as was said earlier do what you feel best with , there are lots of correct ways of doing things

lee

Your suggestion sounds reasonable to me. I was hoping some of the other coding pros would discuss... but for now we can do it your way. Lord knows I have generated enough tests already in coding the econ part!

Twinge:

I just don't agree. If you have 200 integers, there aren't big jumps anymore, but you still need to keep track of a reservoir to say when the integer goes up! So it just seems counterproductive to me. Now, the Player need not see the floats, and probably Should Not see most of them.

I volunteered to code the Map Generator and had a first look over the code that Mark sent me. I have seen that strings are often used as parameters for function calls. Isn't that a little slow, parsing strings "all the time"? Maybe one of the more experienced programmers could answer that?

----

I think in this stage you have to make decision which part of the code must be hard coded, which part can go to script, and finally which part is the best to put in easy to modify text files. I was looking for good quality script language for the Clash project, and I found a quite sophisticated JavaScript engine: http://www.home.worldcom.ch/~jmlugrin/fesi/ . It is freeware, but it can be a part of normally sold software too. The only restriction is, the developer must put the source files of the interpreter together with the software. I think this is the best script engine for Java. (Believe me, I did quite a research to find something useful.) To develop something on he same or similar level could be somewhere between 1/2 year to 1 year hard work. If I can give you more advice: don't hardcode anything like technology tree or unit statistics into the game engine. Put it instead into the script code or even better into text files. To maintain a kind of code quality level I suggest following a coding standard + use a source control system + elect one person (is it you Mark?) who is responsible to put the program parts together.

By,

Mark, what do you think?

My class uses a simpler interface, consisting of two methods, isOfInterest, which inform SAX whether you are interested in an element, and endElement, which returns the most recent element of interest and all its subelements. There are methods to extract relevant data from these subelements.

It does not have provision for dealing with properties of elements (though SAX does have taht facility), but that could be added quite easily.

My immediate problem with the class is that it needs the whole XERCES.JAR file (about 1.5Mb - it will not fit on a floppy!) but only uses a small part of it. One of my work projects is to extract the relevant parts from the xerces source and make a mini jar which provides just the material requires for my SAX classes.

quote: /* * The Apache Software License, Version 1.1 * * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution. * * 3. The end-user documentation included with the redistribution, * if any, must include the following acknowledgment: * "This product includes software developed by the * Apache Software Foundation (http://www.apache.org/)." * Alternately, this acknowledgment may appear in the software itself, * if and wherever such third-party acknowledgments normally appear. * * 4. The names "Xerces" and "Apache Software Foundation" must * not be used to endorse or promote products derived from this * software without prior written permission. For written * permission, please contact apache@apache.org. * * 5. Products derived from this software may not be called "Apache", * nor may "Apache" appear in their name, without prior written * permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * ==================================================================== * * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation and was * originally based on software copyright (c) 1999, International * Business Machines, Inc., http://www.ibm.com. For more * information on the Apache Software Foundation, please see * . */

Cheers

"I do not think that one should program for futures. That is, if something isn't actually in the model, it should be left out, and added later if necessary. There is an extensive literature (starting with Kent Beck et al in the XP web site) all of which says the programming for something that might be used is counter-productive. I refer you to website at www.xprogramming.org. However, here is a quote from that website:"

quote: You’re NOT gonna need it! Often you will be building some class and you’ll hear yourself saying "We’re going to need...". Resist that impulse, every time. Always implement things when you actually need them, never when you just foresee that you need them. Here’s why: Your thoughts have gone off track. You’re thinking about what the class might be, rather than what it must be. You were on a mission when you started building that class. Keep on that mission rather than let yourself be distracted for even a moment. Your time is precious. Hone your sense of progress to focus on the real task, not just on banging out code. You might not need it after all. If that happens, the time you spend implementing the method will be wasted; the time everyone else spends reading it will be wasted; the space it takes up will be wasted. You find that you need a getter for some instance variable. Fine, write it. Don’t write the setter because "we’re going to need it". Don’t write getters for other instance variables because "we’re going to need them". The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code. You’re not gonna need it!

It is a website well worth checking.

Cheers

See "Core Java, Volume 1, Fundamentals", p352

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.

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.

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.

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.