13-08-2000 13:10									#31
	Tired of ads?

Yes, I have to second that motion!

Point us who are trying to learn OOP to references that can teach us. It would be a good addition to the document, after all Clash is what prompted me to try to learn OOP, though the sources I talked to said C++ was better, so I began to learn that, though you have shown me Java is just as good, if not better F_Smith . I've been programming simple linear stuff for years, in BASIC, and I thought the switch to OOP would be relatively easy, but it's not as easy as I thought.

	13-08-2000 13:27									#32
	Lose 30 kilos (of popups)

Mark:

I believe that you're using 'Listeners' to record and process the key events, so that is an example of a controller interface class in a classic M-V-C approach.

The Listener does the controlling.


Richard:

Sun's website has a
Object-Oriented Programming Tutorial. This would be a good start. Swing is just a catchy name for a bunch of good screen components Sun wrote. XML is the 'parent' of HTML, the stuff you use to put links on pages.


Toubabo:

Check that link above, and do other searches at the java.sun.com. It's got so much excellent free stuff your head will burst.

But you'll make it -- I started out as a Cobol programmer. I wrote some of the finest procedural code in Java you've ever seen!!!

	16-08-2000 09:43									#33
	Support Apolyton buy from Amazon

Architecture Approval Request

[*]All game data will be encapsulated in a single 'interface' class that (for now) is called 'GameData'.

[*]The use of observers.

[*]I'll put up a 'template' data classs.
[/list]


I'll do this in the morning, unless the gang has any requests/objections.

	06-10-2000 10:28									#34
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

Le Bump.

	07-10-2000 01:28									#35
	Increase the size of your Attachments

just read this forum, or scanned through it anyway.

smith and i have discussed mvc elsewhere, ( and will continue by e-mail probably).

64k map squares , i havnt had a good chance to look at any code, but how did you arrive at that size !!

	25-12-2000 00:17									#36
	Support Apolyton or Terrorists Win

This is a kick-off for a discussion on some general features of our object models. Specifically, how the object models act in terms of customizability and supporting interactions within the game models. There has already been some discussion on this in the tech model, and in other places. My purpose here is for us to arrive at a decision as to our general approach for how to handle these issues.

(No time for extensive proofreading , so I apologize for any 'whoppers' herein. Since I used dictation software, if something bizarre shows up, try words that sound like what is there!)

In terms of object models the question is do we use inheritance to specify for instance each technology, or do we have a more generic technology object that has various fields and generic methods to modify other game objects? I'll give an example to make sure everyone knows what I'm talking about. Generic hardware that has game effects are called applications in the tech model. So for instance Rifles might be an application. Various technologies, like Metallurgy, modify the effectiveness of your civ's rifles. In the basic tech system, all that is modified is the overall effectiveness number. Now let's say the combat model also needs a precise estimate of the range of these rifles, which can change with technologies over time. And just as an example (I know it's not a very good one) let's say that the technology Aerodynamics plays in this. The big question here is how do we get the code to establish the links between the Aerodynamics tech and rifle range, and other similar things, in the "best" way.

The best way should support as well as possible:
1. High-quality, easy to maintain and extend code
2. Flexibility in playtesting (let the play tester change the behavior of the Aerodynamics/rifle range link, or even change the length to another tech, or put in a completely new dependency)
3. Customizability for scenario designers (much of this is automatically achieved if we can do 2.)

I'm aware of two basic ways to do these good things, and there are trade-offs involved depending on which one we choose to use. The first type is using inheritance explicitly to define each thing of interest as its own type of object. So there would specifically be an Aerodynamics class that extends from Technology with possible intermediate levels of inheritance. On the rifles side we would likely have something like Rifle extends RangedWeapons extends Weapons extends Tools extends Applications or some such. This approach affords an Enormous amount of flexibility, and it's the one F. Smith was pushing for in the quoted section below. I favor a more abstract approach that I will go over below the extensive quotes. This would have those links put in by means of initialization files, and would stop the inheritance tree a bit earlier. For instance, they would be no explicit Rifle class, just an instance of RangedWeapons with a type specifier "rifle" and supporting code for the specific links. Of course, we can (and probably will) use one way for some parts of the game, and another way for different parts.

To present F. Smith's position, at least as of earlier this year, I'm going to use a series of quotes that F. Smith made in the Technology System Version 5.1 Technology System Version 5.1 thread on page 3. If you want to look at them in context they were posted on or around March 13 2000. I apologize a bit for the choppiness of these, since I just grab them straight out of context. If there's a reference you don't understand in them, just ignore it, because I'm just using these posts as a general statement of some of the issues.

quote: One big question: So ya'll have decided to use encapsulation instead of an object inheritance hierarchy, it seems? One basic 'tech' object, with properties that can be set? This choice carries serious costs, as I'm sure ya'll know. Have those choices been discussed yet? Specifically, this means that the techs can not be too involved, in terms of how they interact with other models. Gains in flexibility have a cost. The other choice is to 'inherit'. It would be somewhat less simple to create custom techs 'on the fly', but the techs would be much, much more powerful and unique. It looks like Lordy has chosen 'inheritance' for the 'Wonder' model. Was a flexible system the prime directive? Or was power and uniqueness the goal? How often will custom techs be created? Should creating them be the focus of the model? Just asking . . . More detail: With this approach, would a tech be able to modify another object (wonder, unit, resource)? For example, can a tech decrease wonder build time? Or could a tech increase the speed/power/armor of a single, specific unit? Or could a tech increase the processing speed of grain (not all food, just grain)? Would a tech be able to increase the speed of aircraft? The range of a single weapon-type? With an object hierarchy, you have that power, that uniqueness, that customizability of behavior. That is usually what you give up when you use encapsulation. Encapsulation is usually used when you will change something often, on the fly, like in the middle of a game. And it doesn't seem like you will be doing that. Does this 'model' allow for those kinds of tech, in some way I missed? Is this really the correct design choice, in this instance? Actually, the reason I'm going on and on about OOA for the tech system is that this is not going to be powerful, as it currently stands. They have already made that design choice. There is no object hierarchy for tech objects. All tech objects will use a single method to apply their bonuses. Which means two things: 1. That method will have a switch statement with 100+ parts, and associated methods -- one for each tech (a coding nightmare!!!). 2. All tech objects will have to behave in a basically similar way. The problem is no one has yet done the basic analysis you're going thru for the wonder model. No one has identified the behaviors of a tech object. So now, all the tech objects will have to behave basically the same. Instead of each tech being it's own object, and behaving in a unique way, you have one object to represent all techs. Using an object approach, you can just have the 'applyTechBonus()' method take an 'object' parameter. And that parameter can be anything. So that tech can change anything in that object. Pass in a Wonder object, and you can modify anything in that wonder with that tech. Same with units -- individual or type. Or resource, or civ, or mapsquare, and on, and on. Any object. Any modification in that object. This is what you give up when you choose not to use an object hierarchy. They can try and simulate this behavior with a switch statement, but with so many different cases that will be almost totally impossible, for a half-dozen reasons. And it means you have to re-code the basic tech object for every new tech 'type'. And if whoever does that modification makes a mistake, it can bring down the whole tech system. And that's why I'm on about doing some OOA on this tech system before they get started coding!!! and the drum beats on . . .

Before I talk about the way I envision the alternative F. Smith didn't like above, I need to state some caveats. First, I haven't double checked with F. Smith that this is still the kind of thing he thinks is the right way to go. But at any rate, what he says above states one side of the discussion reasonably well. Soon we will know for sure what he thinks (right F. Smith?) The second warning here is that F. Smith is much more experienced with this stuff than I, so my approach may have some big holes in that I'm not aware of!

There are many places in the game where connections between models will be needed. For instance, the economics model has sectors of the economy (five right now) and infrastructure classes (perhaps 20-30). In the technology area, there will probably be several hundred objects between technologies and applications. Other models have further requirements, and I don't want to get into the details here. It is my contention that while using inheritance for things like rifles, giving a Rifle class, might be practical for the economy where there are only a handful of potential classes, putting in several hundred individual classes for technologies and applications is different. It seems to me to be More error prone than handling things in an automated fashion using less inheritance based on an initialization file as I outline below. So what I am trying to reach understanding on here is why my approach isn't better in All the areas 1-3 above and the approach presented by F. Smith. So tell me .

So here is my presentation of how it should work...
We have a RangedWeapon class, that covers everything from bows to bazookas (these are meant to be hand-held ranged weapons). Each instance of the RangedWeapon class has a designation "rifle", a bunch of information on the characteristics of rifles (range, lethality, etc.) and some objects whose purpose is to handle connections like that between Aerodynamics and rifle range. The purpose of these objects is to identify the connection between Aerodynamics and the range characteristic of rifles, and to support updates and modifications of rifle range when Aerodynamics tech changes. Note that the object that I'm talking about here is a generic rifle, not the rifles that are used by any specific civ. Here is a crude example of the initialization file line from which this information would come:

"Tech" 'Aerodynamics' Affects "RangedWeapon" 'Rifle', *range* (then some parameters describing the mathematics of the exact effect, TBD)

In this expression "" means that the name represents a Java class, ' ' represents a string that is the name of an instance of that class, and * * represents a parameter of that instance. It would be more readable in XML, but I think you can get the idea from this. This expression, after being properly parsed is put into an object recognizing this link. The aerodynamics instance of Tech will have a copy of this object, and the Rifle instance will have another. Updating the effects can be done using an Observer/Observable mechanism. I have left out the necessary step of having a specific aerodynamics-related object for my particular civ as opposed to the one that just says how aerodynamics works in the game in general. That could be done in a couple of different ways, but seeing as I have company coming, I will just go ahead and post this, and see where the discussion goes.

	25-12-2000 05:46									#37
	Lose 30 kilos (of popups)

Mark:

Well, w/o hearing F_Smith's remarks, i'm more inclined with your view, with the understanding as follows for the tech model:

If there were a ranged weapons class, it would haveto be subdivided into hand-held and artillery ranged because these are so vastly differnt from each other that they cannot be the same. FE you could use cannons and crossbows in a battle if your hand-held weapons tech wasn't up to par (maybe because of size reduction problems or economic problems).

Ranged weapons could also come under a broader category also too.

There is only 1 other problem with your model and that is in reguards to mantainance and upgrading. Right now to make it more realistic a civ or whatnot's ability to upgrade and/or mantain their current level or equipment is factored in (as well as the social parameters for change in upgrading to new equipment). These are there for the reason that a country might continue to upgrade its crossbow technology evem if its more expensive because of social preasure for nonchange and lack of enemies, esp with superior tech. to spur radically new items which require new thought and in some cases can lead to the downfall of the status quo.

Again this argument may be mute depending on what F_Smith says and perhaps if i misjudged it also.

	29-12-2000 10:51									#38
	Avatar Enlargement: We've got the solution

Coders:

I think we need a logical package structure for the code. Things are already getting complicated in the new architecture, and IMO there's no time like the present to put in a logical package structure. I think the best would be along model lines since the names already help along MVC lines. What we used on the old code was packages of the type:

clash.util
clash.gui
clash.map
clash.civ
clash.econ
clash.ai

It really helps when you're looking for a class that you don't know the name of... I also think the lack of package structure will scare off some potential coders. What say you F_Smith, and others?

LGJ:

That's really a model issue rather than a coding issue per se. Why don't you put your comments in the tech model area, and we'll see how important people think is the effect you're talking about.

	29-12-2000 00:44									#39
	Got spare money?

Hi, Guys:

Me again!

First, I agree with Mark about using packages, altho I think we should name them a little differently.

Can I suggest

clash.view (for GUI stuff)
clash.data (for all data objects)
clash.controller (for all 'turnhandler' and 'fileIO' code)

This is what will help coders the most.

If sub-packages are needed, then no problem -- clash.data.civ, etc.

But can I suggest using the data/view/controller paradigm as the first package level?

	29-12-2000 00:46									#40
	Support Apolyton, buy Civilization 2

Sounds like a plan

Even a good one...

	29-12-2000 01:27									#41
	Full PM-box? Change here!

Now, regarding the tech architecture:

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!

Comments?

	29-12-2000 07:38									#42
	Support Apolyton

I expect a compromise would work best for the project overall.

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!

	29-12-2000 20:36									#43
	Support Apolyton buy from Amazon

Absolutely, we can work from the general to the specific (if I understand correctly). We can begin with generic 'weapons' classes, and then add in specific subclasses if and when we have time.

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.

One question, tho -- we do still need an 'Ammunition' class, don't we? So arrows aren't used to resupply M-16's?

	29-12-2000 20:38									#44
	Support Apolyton

P.S. -- Actually, I think what we're building is a game engine that is going to be both a grand strategy game *and* Squad Leader!

I hope when we're done with it, it can be used to play any level of detail.

	30-12-2000 00:19									#45
	Help yourself to an AD-FREE life

We will work it out, and if you convince me, more power to you!

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.

I am going to cross-post this in the mil thread since the discussion is pertinent there too.

	31-12-2000 07:04									#46
	Enter the AD-FREE zone

I must agree with Mark; while realism and complexity are important, we don't need a

quote: micromanagement nightmare

=) Basically, how I see it, we don't want to make an Action, Rolepaying, Shooter, Strategy Game; that's overkill.

quote: You can mix and match chassis, bodies, weapons, armor and special abilities to custom-make units. That is the approach I am after here.

Like Master of Orion Too (Another Great Microprose Stategy)... This is a good idea, and should be implemented sometime in the later stages. As always, this would be by user choice, and there would be plenty of default "units".

quote: I hope when we're done with it, it can be used to play any level of detail.

Don't think this should be much of a problem =) Looks like thats the basic idea of the game, and that's one of the tings I like most about it, or any other game.

	05-01-2001 06:14									#47
	Support Apolyton buy from Amazon

Coding Gurus:

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.

Is this becoming-accepted-truth about good OO practice, or is this guy on the lunatic fringe? I'm trying to improve my coding style, and keep getting different messages from the 'experts' .

	05-01-2001 19:17									#48
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

I agree that you should use subclassing only if you upcast somewhere. Otherwise, you (ab)use inheritance by tying classes which may share a method but this method is never used per se, thus there is no common semantics to that method. This may mean you avoid copy-paste of code, but if one of your class should evolve, then the second implentation may follow the code change inadvertently, or you may change both codes and end up with an inheritance you don't remember the purpose of. Better to use a third object to which you delegate the common code in that case.

quote: Originally posted by Mark_Everson on 01-04-2001 08:14 PM But the author (Bruce Eckel) says that if your inheriting classes add more methods or variables, then its the sign of bad design.

	06-01-2001 10:05									#49
	Support Apolyton

Thanks for your interpretation Laurent. It makes sense to me. I think I was trying to take the author's words a bit too literally

	06-01-2001 03:44									#50
	Support Apolyton buy from Amazon

In all programming languages theres many ways to do the same thing... Do what feels best to you in most cases, even if it is a little less "proffesional" (except If the easier code takes a lot longer to run or has other problems, of course.)
Basically: Don't do what authors tell you to do. They likely tell you a) how its supposed to be done in the most ideal situations which isn't always good, or b) what works best for them. Find what works best for you and do it, you dont need to do what some expert says you should.

	06-01-2001 16:08									#51
	Help yourself to an AD-FREE life

In heritance is there to be used , and fairly central to OO. However it can be badly used. If you have a large inheritance hierarchy then there probably a problem , but there's probably nothing wrong with a few levels, it depends largely on what your modelling.

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

	07-01-2001 03:04									#52
	Enter the AD-FREE zone

Thanks guys, I'm proceeding ahead, and trying to do things that make sense! I'm trying to make things more encapsulated than I used to, and use casting and inheritance wisely. I think I partly misinterpreted what the author was saying in my bit above also.

I'll have the demo 5 econ model out by the end of the month. Perhaps it won't be the most refined code, but it'll get the job done!

	09-01-2001 06:05									#53
	Lose 30 kilos (of popups)

One more thing that came up elsewhere and has relevance here.

IMO most of the variables in Clash should be floats not ints. This allows the game dynamics to always proceed smoothly rather than jumping around because things are always in discrete chunks. I think this can help us avoid much micromanagement.

	10-01-2001 05:25									#54
	Support Apolyton, buy Civilization: The Boardgame

I can't comment now because I seem to have forgotten everything I ever learned about Java classes. I'll try to see if I can refresh my memory.

	12-01-2001 15:46									#55
	Suffering from ads?

Is there any standard for tests?
What I read about Extreme Programming went as "do a lot of tests". I also know people whose policy is 1) define the API 2) code the tests 3) fill the API with actual code.
I suggest we should have packages like game.data.military and each such package would have unit tests like game.data.military.test.
That way tests are easy to find and can be removed fast from the real game.
Any comments?

	13-01-2001 00:07									#56
	Full PM-box? Change here!

Well, I personally think Integers are fine, as long as you leave a wide variation open for them (maybe 1-200 instead of 1-20 as it is in civ2 pretty much) Basically you can still get the same level of detail while it is easier to understand, edit and customize.

	17-01-2001 07:47									#57
	Support Apolyton buy from Amazon

Laurent:

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.

Can you explain to me why integers are easier to understand, edit and customize? The player will only see "Metallurgy tech level = 37" in either case...

	29-01-2001 10:41									#58
	Browse Apolyton AD-FREE

Hi!

I am new to Clash, and I hope I will be of help in the programming department.
I would like to know what development environment you use for coding java, if any at all. I am asking, because it`s been some time since I last used java, and I have seen there are several IDEs available for free.
Besides, what version of Java are you using?

	28-01-2001 23:02									#59
	Support Apolyton

Hey Rüdiger:

We are using Java 2 for the forseeable future. I don't have any experience with the free IDEs, but I'm sure you can get some good info on the newsgroups if not from someone in the project itself. Gamedev.net also has a decent java programming forum with a focus on game development of course. Its here: http://www.gamedev.net/community/fo...ava+Development .

	22-02-2001 18:54									#60
	Tired of ads?

And now for something completely different:

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?

----

Programmers don't die, they just GOSUB without RETURN.