We have been discussing a lot recently coding standards for the project, and what the correct architecture we should use is. There have also been discussions about how much memory we can afford for which models, and how the guys in charge of the models interact with people programming the models. What I would like to do is use this thread to hash out agreements on these various issues. For instance, I will put up some information on how many of which type of objects we expect so designers and programmers can make crude estimates of memory usage and clock usage. F_Smith is making some persuasive arguments about how the code should be laid out, using the government model as a testbed. So hopefully he will give us a description here of what he thinks the coding standards for the project should be. Other things that generally relate to coding progress, like how we can attract more programmers are also welcome here. If they get out of hand, we can just subdivide topics, but for now I think starting this all in one place is a good idea so we can have one-stop shopping

Since we have also discussed some of these topics before, I'm going to provide several links to some old threads that I think are relevant. If anyone else has an old thread they would like to nominate, please let me know. Hopefully, once we have discussed things a bit we can come up with some real coding standards documents and put them up on the web page.

Links to previous threads:

Coding organization for Clash started August 22, 1999.

Clash Coding is a discussion of how to more effectively use the programmers in the project. Richard Bruns suggests doing the coding so that many model specifics can be input by non-programmers. This ties in with the efforts that F_Smith and Garth are pursuing in their respective coding areas.

Ooa/ood where we talk about object-oriented design as it relates to the tech model, but the comments are a general usefulness.

And also check out the Coding Model page on the Clash Web page for some more threads.

Max Numbers of Game Objects

(My) expectations for the numbers in the game of a variety of objects. I'm going to state effective maximums here, so we keep things a little conservative. The main reason for that is that our super-duper AI will require both a fair amount of memory (Much more than the industry standard) and clock cycles. So if we use the maximum estimate for everything and come in under budget, it means there will still be a fair amount of memory and clocks for the AI.

I suggest a memory budget for pure objects of something like 10 MB. In addition to this we will have graphics that are permanently in memory, graphics that are transient, and other stuff. One issue that has to do with memory usage is how we run the game for Multiplayer. I like to hear peoples thoughts on that either here, or in the long-dormant Multiplayer Coding/Issues.

(This is just a very incomplete list to start off the discussions -- current Java class names are shown in parentheses)

General:
500 civilizations (Civ.java) -- many will be passive and not have the full AI, perhaps 100 full-fledged civs
2000 provinces (Province)
64k map squares (BaseMapSquare) including ocean and unpopulated land. If we put an aerial layer above for future type stuff, then it would be double this.
20k land map squares (MapSquare)
10k populated land map squares (PopSquare)

Military:
100 task forces per civ (TF.Java)
500 units per civ (Unit)

I'd like to get ya'lls input on a proposed 'Coding Standards' statement to orient new programmers. This is just a rough draft, so please jump in with any disagreements or suggestions. Do not feel this is being imposed on ya'll -- anything you do not agree with, we will work together to find a compromise.

* * *

From the book 'Extreme Programming
Explained' by Kent Beck (p. 48):
"Designing is creating a structure that organizes the logic in the system.
Good design organizes the logic so that a change in one part of the system
doesn't always require a change in another part of the system. Good design
ensures that every piece of logic in the system has one and only one home.
Good design puts the logic near the data it operates on. Good design allows
the extension of the system with changes in only one place.

Bad design is just the opposite. One conceptual change requires changes to
many parts of the system. Logic has to be duplicated. Eventually, the cost
of a bad design becomes overwhelming. You just can't remember any more
where all the implicitly linked changes have to take place. You can't add a
new function without breaking existing functions."

Our basic 'Coding Standard' has to be the M-V-C approach. All programs consist of exactly three parts, each with a specific purpose, and Clash is no exception.

• You have 'DataModel' classes that hold all the state information for the
  Game data. These classes should extend 'Observable', or implement a vector
  of observers internally.

• You have 'Data View' classes (panels and such) that must each be
  declared as 'Observers' (implement the 'Observer' interface, actually very
  simple) and observe the Data model. The data model will fire off updates
  whenever anything in the game data changes, and the View classes will
  recieve those updates and update their screen details.

• Finally we'll have the 'Controller' classes -- game state, turn logic,
  File IO stuff (including streaming for multiplay), etc."
  

Does this sound alright to everyone? I'll post some basic, minimal coding rules next. They'll definitely help to keep everyone on the same page, and should allow new programmers to step right in and make a contribution anywhere they want.

Thanks so much for being a part of this. I agree with you completely -- finding what you need quickly is going to be a big bonus to using this structure.

1) Yes, tonight from home I'll post some actual base classes and samples here, to begin a discussion on.

2) The base classes I post tonight will put it much more clearly, but here's a brief run thru:

The 'Observer' interface has one method -- 'update(Observable o, Object arg)'. Whenever the data changes, this method will fire off, and 'arg' will be the new data.

The 'Observable' class (or any class you make into an observable) has a vector of 'observers', and related methods (addObserver, removeObserver). It also has a method 'notifyObservers(Object arg)'. Whenever someone changes something in that data class, (using a method like 'addCivilization(Civ c)') that method must call 'notifyObservers(c)'. This will tell all panels (or any type of observer) that have been added as observers that the data has changed, and pass along the data.

So, for a class like 'GameData', it will extend observable.

So when you build a 'View' of 'Data', you do something like:

• Build data class using full encapsulation rules (getters and setters), and extend observable. All setters must call 'notifyObservers(Object arg)'.

• Build 'View' class. Typically a Panel that implements observer. When you add this class to the screen, also call 'data.addObserver(view_panel). The 'View' panel should be built in two parts, to seperate the data from the view -- an 'initView()' method that just builds the Panel with blank components (do not fill in any data) and a 'updateView()' method that is called after 'update(Object arg)' fires off. 'update(Object arg)' needs to set the new data to 'arg' (selected_civ, for a 'CivViewPanel', as in the above example, and then call 'updateView()'.
  

Sorry to just now be getting to this. Here's my proposal for 'base' classes and structures.

Sample 'Data' Class:

code:

---

import java.util.*;
public class GameData extends Observable implements Observer
{
    private Vector civilizations;
    
    public GameData()
    {
        initData();
    }
    
    private void initData()
    {
        civilizations = new Vector();        
    }
    
    public void addCivilization(Civilization c)
    {
        civilizations.addElement(c);
        notifyObservers(c);
    }
    
    public void removeCivilization(Civilization c)
    {
        int index = civilizations.indexOf(c);
        civilizations.removeElementAt(index);
        notifyObservers(c);
    }
    
    public Enumeration getAllCivs()
    {
        return civilizations.elements();
    }
    
    public void update(Observable o, Object arg)
    {
        notifyObservers(arg);
    }
}

---

Sample 'View' class that is tied to the above data:

code:

---

import java.awt.*;
import java.util.*;
public class CivilizationsView extends Panel implements Observer
{    
    private GameData data;
    private java.awt.List civ_list;
    
    public CivilizationsView(GameData d)
    {
        initData(d);
        initView();
        updateView();
    }
    
    private void initData(GameData d)
    {
        data = d;
        data.addObserver(this);
    }
    
    private void initView()
    {
        civ_list = new java.awt.List(4);
        add(civ_list, "Center");
    }
    
    private void updateView()
    {
        Enumeration enum = data.getAllCivs();
        
        while(enum.hasMoreElements())
        {
            Civilization c = (Civilization)enum.nextElement();
            
            civ_list.addItem(c.getName());
        }
    }
    
    public void update(Observable o, Object arg)
    {
        updateView();
    }
}

---

And, for illustration, a beginning 'Civilization' data class:

code:

---

import java.util.*;
public class Civilization extends Observable
{
    private String name;
    
    public Civilization()
    {
        
    }
    
    public Civilization(String n)
    {
        setName(n);
    }
    
    public void setName(String n)
    {
        name = n;
        notifyObservers(name);
    }
}

---

Does this meet with everone's approval?

The pattern is simple, I think. This way, all GUI components are built in exactly the same way. And all GUI components interact with the data thru a single object -- GameData. So we can change the data model around all we want, and not have to worry about re-working any of the 'View' code.

And if the existing code is reworked, then future enhancement of the code -- and therefore making future releases -- will be much, much faster. You can begin to develop and deploy new versions with added/refined models in a matters of weeks or months -- not once a year.

Because I hope that this one thing alone has already been proven with the 'object builder' I'm working on (if the darn website ever lets me upload the newest version again!!!) -- speed of development.

I coded the entire data structure for the social model in about a weekend, then found errors in the model that could be changed to provide a faster and more powerful system. The code could be integrated into the main game in about a weekend.

The entire game, using this methodology, can be ready by Christmas.

No, I'm certain Xmas is do-able. And that's assuming we don't get anymore help on coding.

Honestly, that's how fast the proper OO approach to development is. Which is why I'm so on ya'll to switch your methodology.

If you develop the model rules at the same time we develop the model's code, both the modelling and the coding go very fast and end up bug-free. Because all 'Data' objects get coded in exactly the same way -- so it's extremely fast to code them. All 'View' objects get coded in exactly the same way. Again, it's extremely fast to write them.

If I were doing this at work, and could spend all my time on it, I could do it myself in about 3 months.

We're having extensive discussions in various threads about at what level various game information should be stored. I'm going to try to provide a very short, hopefully balanced, account of the general issues involved, so we can discuss these big issues without getting caught up in the specifics of any model. Also, for thinking about whether we should "decentralize" the economic system down into individual squares, I need to get some answers to some of these questions.

F. Smith has been pushing a good OOD approach for all the models. This includes using the model view controller (MVC) paradigm for handling code function, and also pushing data storage and handling down to the lowest conceivable level. He has talked a bunch more about these things in a lot of places, and some of it is even in this thread. He's invited to do so here again if he'd like , I'm sure you're up to it F_Smith! I need to add here that he is a professional programmer, which most of us are not. So he has a lot more experience with this stuff. It may be as F_Smith claims that I'm worrying about things that can be easily taken care of in the future. But still, I'd like to hear what others think.

My problem with the OOD approach above, is not at the philosophical level. If there were no issues of memory storage, clock cycles, Internet bandwidth, and other similar things, I agree that the things F. Smith is pushing have the ring of truth. I think they are also widely accepted in the OO programming community. Also, I have no problem with the MVC paradigm, it seems very reasonable, and would be very good for keeping us immature programmers out of trouble.

My problems with that approach is when the theory appears to collide with reality. The main problem is that we are pushing the limits in terms of model complication on virtually every front. We are also combining this with a fairly high-resolution map (64 K. squares standard). This combination of detailed models and a map with a lot of squares in it gives us great potential to have a game that is truly revolutionary. But it also gives us the chance to have a game that:
requires a 5 MB save file (for example)
takes much more than the targeted minimum rate of ten seconds per turn just to execute the game models
is almost impossible to play multiplayer because too much information needs to go down the pipe

I have raised all these issues before (there he goes again...). In some cases programming a model at the lowest level is not a problem. Since computers are so fast and have so much memory these days, it only comes up if there are a Lot of objects. In other cases, if it is found to be a problem, the code can easily be rewritten to an aggregate information at an appropriate level to fix things. But in some models (like the economy) it seems to me it would be difficult to go back. (Although careful planning might be able to prevent this)

F. Smith has raised some good points that makes some of my perceived issues less significant. For instance, sometimes things don't need to be calculated every turn, or change very modestly meaning we can estimate without much use of clocks, putting less stress on clock cycles and bandwidth. So that may offer an out in some cases. I'm still left with a few issues...

I think the file save size needs to be one MB or less. What do others think about that as a guideline? Even at 5MB files, if you save 200 of them (about the number of civ2 saves I have) that's 1GB... And I call Microsoft stuff Bloatware

For multiplayer you should be able to play the game with something like ten seconds turns on a 56 K. modem. Orders that the player or AI issue would not be the problem. The problem is updating information on a potentially large number of map squares. With 100squares (say during a war) needing updates of 100 Bytes each gives 80kb. So at max rate it'd take more than a second just to get the mapsquare change info across... Maybe not a problem, but civ2 plays pretty badly sometimes with Much Much less info going down the pipe.

Seriously? Whoah. That has got to be some serious Civ playing time!

My 'StarCraft' save files regularly run half-a meg or more, and we've got *way* more info than that. The largest map in starcraft is, I believe, something like 250 by 250 tiles, with far less pop detail and almost no econ. Caesar 3 save files are from 200 - 300 k, and that's saving one province's worth of data (altho the econ is on the scale we're talking about). So 10 provinces of data would be 2 - 3 meg, and we're going to have more than 10 provinces, for sure. And then we'll have civ data, and more.

I personally think we don't worry about it. We just concentrate on doing it 'right'. I've got a 27 gig hard drive I've loaded down with so much industrial software it isn't funny and I've still got 16 gig free. Within 2 years almost everyone will have 30+ gig hard drives. So even a 20 or 30 meg save file isn't a problem, except for save/reload time issues.

We control that thru the arguments passed to the observers.

That's all controlled by the 'controller' code (in this case, specific 'TurnHandlers' like 'MapSquareTurnHandler', 'EthnicGroupTurnHandler', and 'ProvinceTurnHandler'). These controller classes will hold the 'turn()' method for the relevant objects. So in that code we should labor to update each piece of data only once, as often as possible.

F_Smith wrote:

quote: I personally think we don't worry about it. We just concentrate on doing it 'right'. I've got a 27 gig hard drive I've loaded down with so much industrial software it isn't funny and I've still got 16 gig free. Within 2 years almost everyone will have 30+ gig hard drives. So even a 20 or 30 meg save file isn't a problem, except for save/reload time issues.

Now we want a very detailed game, but that costs. What do we do?
Reduce detail to keep requirements low? NO
Increase requirements to keep the detail? NO
Concentrate on the detail that is perceivable and usable by the player? YES

Different players have different levels of perceptive ability and like micromanagement (because that's what detail means after all) at different degrees. So to be able to track all those different detail levels, we need flexibility and customisability in the game. In the same time we need to preserve compatibility and keep the requirements low, at least for all those who can do without all that detail. Consequently, not only our interface but also our datamodel needs to be flexible.

I agree completely with every word.

Is everyone okay with using a single 'GameData' class for 'interfacing' with the data? So that anytime, anywhere you need any game data you get it thru that class?

Methods in the class are things like:

public MapSquare getMapSquare(int x, int y);
public Civilization getCiv(String c);
public Technology getTech(String t);

That kind of thing?

That way we can change the datastructures at will, but the game code will never care -- as long as the method signatures stay the same.

Is this okay by everyone?

P.S. -- I'm thinking about starting a seperate thread called 'Architecture' or some such, and putting in it a summary of the code approaches, and including a 'sample' of each type of class, mainly for new programmers to get up to speed quickly.

Do you have a preference on the name of that class? I was thinking GameData would be more descriptive, but I'm easy.

P.S. -- I was wondering if you thought it might be possible to be rather strict on the new 'architecture' thread.

Could get the 'architecture' thread stay at the top, when I post it? I was also thinking that thread would not be a place for discussion, but only for posting the architecture basics, so that any programmer that happened by could hopefully take in everything, and possibly be impressed/excited/want to get involved (I am going to spread some posts around a few newsgroups I know of after it's posted, we'll see if anything happens).

Please let me think a little bit about the Game/GameData question. In either case it's easy to switch to whichever one (or even a third alternative) we choose to take for the long haul.

On the Architecture thread...
Sure, I think we can be strict in keeping things on topic there. But if you want it to be essentially immutable, perhaps the web page is a better place. At least once we get the web page back to functional (Kull doesn't have access for the updates at the moment). While it is getting set up, and we are hashing out details, I think it would be more useful if it is really a discussion thread. We could just keep the current main architecture document at the top of the thread, and update it as needed. Because at least a problem that I foresee is that you will put something up that me or someone else doesn't agree with, and the natural place to discuss it is where the information is... At least that's my suggestion. If you don't think that's appropriate, we can do it your way, and channel the discussion elsewhere.

In keeping it on top, that's something I need the sys admins to do. For now I would prefer to avoid that, and just bump it up to the top when it gets low. I can delete the "bump" posts when they are no longer relevant so they don't clutter up the thread. If you would like me to start the thread and put stern admonitions against OT posts in a little blurb at the top I would be happy to. I don't really want to get into moving OT things out of the thread by hand. I think a fair way to handle it is if something OT appears in the thread I will stick a warning message on it, and if it isn't removed by one day later, I will delete that part of the post, or the whole thing as appropriate. But to be fair I will also have to also police you and me, who are two of the biggest OT offenders around here . Just tell me what else you would like me to say in the top bit.

But like I said, long-term the thing should probably go on the web site...

This thread absolutely will only be a repository for completely agreed-upon information. I'm only secratary for the 'architecture' information, not a gatekeeper, or a 'priest' of the architecture.

Every new addition or change to the 'official' architecture will start as an "is this okay or is it trash?" post. Only after a majority has made a near-unanimous decision does it make it into the book of law -- the 'official' architecture.

The webpage would be fine, but then I'd likely try and direct coders there first, if that's okay. So I'll wait a bit.

What we're going to attempt with this thread is a simple, concise list of what we need done in bite-sized little chunks, including how to 'cut' the meat.

Basically, an entire project architecture. (Yikes!!!).

With luck, we'll draw in a few of the programmers that might happen by. The way I see it, programmers probably do happen by from time to time, either by chance or when we advertise. By far most don't post (it's the nature of these boards). Either they're too busy, don't think it looks fun, who knows.

Perhaps by offering a bunch of two or three day tasks (single components that need coding, with templates to follow) we can catch their interest.

Just a thought.

P.S. -- my wife is going on another business trip to Dallas next weekend, so I will have 4 or 5 nites I can spend many hours banging. If others can be availabe to critique/debug, we can probably turn out a resonably polished, usable 'govt sub-game'. Maybe even begin playing with actual results, and doing some 'game balancing'.

I can't wait to put in ruler 'special orders' (I really just can't wait to send the secret police to my political opponents door!!!).

This means this weekend will be kinda slow. Altho I got an hour or two tonight.

BTW, can you put up a more-or-less current zip of the Beast soon? I can use it to look at how you're coding up some of the stuff beyond the base architecture to give me ideas other than my 'usual' ways.

Yeah I'm really looking forward to the govt sub-game!

XML Macro Language?

Modified macro language description

I'm only using XML for the beast because I had a parser written for work already that was easily modified. I don't think anyone else wanted to use it later. I believe they've got someone else working up a custom scripting language.

The XML is only a placeholder. A mere convenience.

I'll start the Architecture thread in the morning.

Consider this our very first:

Architecture Approval Vote

I am going to start the 'Official Architecture' thread off with the text I posted above (the quote from the book, the M-V-C stuff).

Is that okay with everyone?

Actually, I believe we might be talking about the same thing.

In 'M-V-C', the 'V' refers to the 'view' of the data -- which is what Swing provides. Swing itself is built using an M-V-C approach, for example 'table models' and 'list models', which seperate the 'view' of the data (the JList) from the data model specifically.

The 'controller' code is the turnhandler, file IO and other 'utility' classes, and this is the only difference between the two approaches. These really should be seperated into their own classes, don't you think? Like 'Listeners'? They don't have to be, as you say, but for ease of programming wouldn't the benefits be many?

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.

Architecture Approval Request

I want to add the next post in the 'official' architecture thread. This one will be specifically on the 'data model' classes. I will basically just reiterate what I have above --

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

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

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

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.

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:

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.