You answered your own question in your first sentence -- ". . . before you model objects, you need to model the world." Model the world in an object model, which has not been done yet for the tech model. You just did that, tho, in deciding that there are two types of tech objects.

As you pointed out, it looks like ya'll have 2 objects required by a tech model -- basically, a 'theory' or 'field of knowledge' object and an 'application' object. This suggests that the concept of breaking the model into 4 levels is a mistake that can limit the models realism.

For a specific example -- what about applications that only require a single, basic piece of knowledge? Does it in fact make sense to require that to be a '4th' level tech object?

Is it possible that a more accurate way to model this might be to have 'application' objects encapsulate 'field of knowledge' objects as requirements? An application can require one, two, four, a million differing 'fields of knowledge', each 'field of knowledge' can have it's own level of specificity.

This obviously gives much more power and flexibility than a static model, and more customizability as well.

This hierarchy supports your tech model, and also supports any changes you might wish to make -- even if you chose to completely re-do the tech model to include magic, or psionics, or whatever. Once this framework is coded, you can go back for game-play reasons and force a 4-tiered structure if you wish.

So the second step, now that you've defined two tech objects (we'll call them 'fields of knowledge' and 'application', for now), is to define their behaviors.

What methods do you think each should have? What behaviors do they have in common? Should they each extend an abstract 'technology' object? Or would you rather use an interface? Personally, I'd almost certainly inherit from a 'tech' object, because that will make it easier to handle them later, in loops.

So, specifically,

1. What methods should 'field of knowledge' have?
   
2. What methods should 'application' have?
   
3. What methods should be moved up to the 'technology' abstract class?
   

OOA/OOD is not the best type of programming for anything that requires serious processor power, way beyond what we're dealing with.

My last client project was for MetLife, when they purchased SFG in LA, and part of the Vantage program we installed had to process the interest added to each of their 1.5 million policies *every night*. It takes about 2 hours on a mainframe as it is, and we had to make several maximizations.

But OOA/OOD is always the best way to achieve realistic modelling results. It can just be very processor intensive. And if you create a good object model for wonders, then you could even give people the ability to make their own wonders, within whatever parameters you create.

I've never thought much about wonders, so let me ask you -- functionally speaking, how many different types of wonder-types will there be?

• ones that give static bonuses to existing abilities?
  
• ones that give new abilities?
  
• ones that introduce a new game concept?
  
• ones that allow the user to bend/break one of the game rules?
  

General types

Religious (each usually helping a part. religion)
Governent (Provitial/Ruler organized)
Private/Non-gov

Structure types

places of worship/Tombs
monuments/statues/memorials
Walls (yes there's enough important walls thoughout history to make a seperate one for this)
Palaces/Fortresses
Government buildings like libraries, banks, etc.
Buildings with specific purposes like lighthouses
Toruism/Entertainment buildings like colloseums

Subcategory: Ruins

These won't be discovered until after ~1000 ACE and with a high enough acheology tech level.

These will be things like lost cities, tribes, etc.

This doesn't include projects, natural wonders or items.

Now on to ur questions:
ones that give static bonuses to existing abilities?
-----
Depends. Mainly social bonus increase and science basic tech increases. A few others might be migration, tourism (later on after its original use has long past), conversion, etc. These won't be instant changes, but gradual and change over time (in 5 basic time periods: instant (0 turns, ie that turn), short run (1-5), moderate run, long run and extremly long run. Each has multipliers so that say a really great wonder would have a multiplier of 4 well then short run would be 1-5 turns x 4 or 1-20 turns. It only multiplies the last number.

ones that give new abilities?
-----
Not for wonders, but maybe for projects.

ones that introduce a new game concept?
-----
new concept like abolition of slavery? probably not.

quote: Originally posted by F_Smith on 03-08-2000 04:51 PM But OOA/OOD is always the best way to achieve realistic modelling results. It can just be very processor intensive.

I'm emerging from lurkerhood to question that piece of conventional wisdom. The advantages of OOD are almost exclusively human ones, and its disadvantages computational ones. Therefore, while its disadvantages are inherent, its advantages depend on the particular human in question.

It looks like you've got in mind one type of Wonder object. The type of structure it is won't affect the behavior of the object, in game terms, it seems. The differences in behavior will be mostly along the lines of what input the behavior will require.

How did you have in mind for these wonders to behave in the game? Am I correct in understanding that every game turn the object will modify a specific parameter in the civ that built it?

If so, it looks like that object will have at least one method, 'addWonderBonus(Parameter p)', that gets called once a turn, probably by the civ.

Does this seem correct so far? Am I forgetting any behaviors?

Then so far, it appears you have at least two choices --

1. create a single wonder object that holds building choice and the parameters to be changed (and by how much), or
   
2. create wonder objects by extending the wonder superclass, then give each wonder specific behavior by overriding the 'addWonderBonus()' method.
   

The first option is far more customizable. You can create any number of new wonders easily. The second option is rather more powerful, because you can be far more creative/varied with the behaviors -- altho new wonders could only be built thru code.

If all wonders will act mostly the same, I would likely go with #1. If you want widely varied wonder behavior, then do #2. In this case, it seems that the wonders will almost all just modify attributes.

I'll agree with you, with one small change -- the advantages of OOD are mostly organizational. Which in fact, as you said, turns out to be mainly gains in human ability to manipulate/understand/write code, especially gains in coding time. You can literally save years with a good OOD.

But there are other gains from better organization as well . . . especially gains in realism when modelling real-world systems. Because those systems operate in terms of objects and behaviors.

Fascinating about the Japanese programmers. I know several Phillipino programmers, and interestingly enough they have all elected to stay with the Cobol side, rather than jump to Java.

I like them a lot, but I would say that none of them are very strong in creative/design skills. And this has been largely true of many other oriental people I've known over the years, too. I know their culture is very rigid -- perhaps there is some connection?

I'm leaning towards #2 simply because #1 i would have to have too many modifiers input in there that would have to be turned off/up in differnt circumstances.

Okay, then. It sounds like so far we've got an object superclass like --

class Wonder
instance variables:

• name
  
• building type
  
• date built
  

• public void applyModifiers(Civ c);
  

At least for starters. What other behavior will a wonder have? What will it have to do, in the game? What attributes (instance vars) will it need?

This is the main solution to your problem with programmers, too.

As it is, you are asking programmers to read, understand, analyze, design and code a model. This is a chore of (at a minimum) 3-4 weeks for a moderately complex system, assuming there are no snags (as if it were possible to do a project without snags!!!).

If ya'll do the object analysis up front, then you can just hand object models to the coders and ask them to code up classes according to this design -- a matter of a day or two.

That's basically what I'm trying to accomplish with this thread, I think.

I'm willing to work with anyone interested in posting here. I think we're already doing some good stuff.

Altho I'm concerned that people are still trying to rush past this basic necessity and work on detailed algorithms. Even tho an algorithm is *not* a model.

For example: If you're going to code up a combat system, it doesn't matter what numbers/algorithms you use, at first. Only after it works do you begin to try and refine the actual algorithms. And you must do so by testing (trial and error), to cover all the possibilities that you can't fore-see. The detailed algorithms that people are spending so much time on will certainly, at the very least, change radically, wasting all this effort.

I guess I'd sum up my concerns like this -- what is going on now is not modelling, it is the creation of algorithms that produce realistic results. But that is not modelling. You can work up all the algorithms to fly a plane, but you have not modelled a plane. You have not built a plane that can fly.

Excellent modelling work, so far.

Okay. We have a superclass 'Wonder'. Now we have 5 subclasses of that --

• Man-made Structures
  
• Natural Structures
  
• Projects
  
• Items
  
• Ruins
  

Okay, then. We need to define each of these object's behaviors. So -- where to start?

How about the first one first?

Man-made Structures

• Instance Variables:
  
  
  
  • level
    
  • base chance
    
  • max chance
    
  • max length of effects
    
  • length of effect
    
  
  
• Behaviors/Public Methods:
  
  
  
  • buildStructure()
    
  • applyModifiers(Civ c) -- this will over-ride the method inherited from 'Wonder'.
    
  • oneTurnAgingEffects()
    
  
  

What else am I forgetting?

(From the demo 5 Econ thread... this seemed the most appropriate thread to put the response in)

quote: What is it about the extra detail that ya'll are so against? You want flexibility and customizability without detail? That's a contradiction. We can easily allow players to turn the detail off, and do everything at a province (or even civ only) level. So why not have the extra detail available in there? It is simple to code.

There are trade-offs here that I believe you are ignoring. As you push down the level of the acting agents in the system, very frequently the system's response to changes becomes much more complex. Frequently this sort of system is even subject to chaotic behavior, meaning that it can thrash rapidly between different sorts of behaviors. This means there can be flaws in the system that actually come from the complexity. I do agent-based modeling work as part of my job, and I know a lot about this sort of behavior. Frequently changing even a few simple behaviors in a low-level model can lead to radical changes at higher levels. So debugging of code is not the only source of fine-tuning we need in the project. There is also debugging of models per se. And this IMO can become much more complicated as the models go down to a lower level.

So, I believe, as the design becomes better in your definition, getting the right behavior out of the models will also become more troublesome. I'm not talking about a strict debugging computer sense, but understanding the system, and seeing why it produces bizarre answers. What we are trying to do in this project is to produce both a fun game, and where it does not conflict with playability, a reasonable cartoon of how the real world works. If we can't even figure out what the system is doing, how can we Possibly write good AI for it? So that's one trade-off you are IMO ignoring.

All these design questions, for which you claim to absolutely know the answer, IMO have trade-offs involved in them. Now it is true that you could make the object model extremely general, and then hobble it so that it only produces the particular level of models the group had generally agreed upon. In that case, my objections against increasing complexity go away, since we are in fact left with the same level of complexity we were expecting. (That is already a daunting amount of complexity) But as soon as the extra flexibility is actually used, then we are back in the soup! And, going back to one of my old standby arguments... If the complexity costs you extra system resources, then those resources are not available for other parts of the program, such as AI. So again there are some more trade-offs.

Why aren't you pushing that we model everything on an individual person level? That clearly would give much better answers than these crude assumptions of assuming that blocks of people that are in squares 3600 square miles big will react in the same way. It's clearly much better object-oriented design at least as I understand your expression of it! Can you explain to me why you don't favor that?

I believe we are seeking balance in our models. We want to use the minimally complicated model that still gets the largest effects we are looking for there. Of course, each player's decision of what the right level of sophistication of the world model should be is different. But at least at the start, I think we should focus on getting one not-too-complicated model going in each area just to see how the general game feels. We can't possibly make the decisions about the right level of abstraction at which to handle each of the models at this stage. You are doing one sort of experiment with the government model. Laurent and I are also trying another detail-level experiment on the economics model. Personally I think that's sufficient for now.

quote: I disagree strongly -- doing tech at the mapsquare level could add another level of detail that I, personally, would love.

quote: All these design questions, for which you claim to absolutely know the answer,

Yikes.

I'm sorry. I sometimes act like a know-it-all. It's a genetic flaw, I think (my mother does it, too). Forgive me. I'll try not to do that.

It drives my wife nuts.

Please just understand that I have had this conversation a hundred times before. I am certain of what I'm saying, because of long, hard-earned experience. I don't mean to be cocky. Just confidant.

I'm sorry.

* * *

My feelings on your comments:

1) This is a 'data storage' strategy discussion, not a 'business/game rules' discussion. We're talking about a 'database'. Not the game program's 'turn' rules. There is no tradeoff. We analyze the models and list all the info they need. Then we devise a simple, compact data-storage hierarchy (like element-atom-molecule). This will be the smallest, fastest way to store the necessary data.

That is why I do not suggest tracking info by individual person -- no model calls for it. But the data storage system/database can easily be enhanced to include that (just extend 'EthnicGroup' and add in people objects). I am suggesting we store data at the mapsquare level because that is the lowest level of any game model. We have to store all that data anyway. It's exactly like storing all our data in a Database. I've just designed my own set of 'tables', if you will (and use methods instead of SQL calls). The 'mapsquare' table will hold all the mapsquare's detail info. If someone later decides to add a 'person' table, then it should hold the person's detail info. I simply object to ya'll wanting to store 'mapsquare detail' info in the 'province' table.

2) This is also why the added detail does not equal added complexity. The added detail is like a filing system -- it organizes the existing complexity. OOD is like the Dewey Decimal System, a 'complex' hierarchy system for storing data. Like the 'element-atom-molecule' hierarchy. It also simplifies, and enables you to do things you never dreamed possible. Things that might even scare you (like electricity and the atomic bomb).

3) Build it using a 'component' architecture, and you have the fastest possible tool for resolving all systemic instabilities and conflicts -- testing. Plug this piece in, turn that on, switch that out. As you said, you can't possibly make the decisions about the level of absraction until you've played it . . . no amount of theorizing will ever prove a theory.

OOD prototyping is the best possible method for quickly making a software 'machine' work right, the way you want it to.

4) The reason to create this deep, rich database is so that later, when someone (like me) wants more detail, it's available. We 'hobble' the system to make a simpler game immediately, and then over the years we enhance it in any and every way possible. That's how you keep a game interesting and playable, isn't it?

You build it to be flexible, even if you don't intend to bend it right away.

* * *

Again, I'm sorry for anything I've said that was rude, or aggressive. I'm just like that sometimes.

Hey, there are no serious personal problems here... we're just discussing an issue. But you might get further with your arguments if you took a softer approach . And I have to apologize too... You did mention in that thread that you were talking about the data only at one point. But then the discussion went on without that specifier being raised, and I frankly had never noticed the "data" specifier.

What you were suggesting was that each map square have its own unique Tech object. I was alarmed both because of the complexity issue I raised, and the fact that Tech will be a Large object in memory. If you just want to give each MapSquare a pointer to a Tech object, and all the ones in the civ for now point to the same one, then I don't have such a big issue. I Still think very few people would use that flexibility. However, at a further stage we could decide whether doing the Tech object at a provincial or MapSquare a level gave the player significant benefits.

But when pushing your "ultimate flexibility" ideas, IMO you need to consider that to use them the model-balancing effort might explode on you. So in fact all we might be giving the player and scenario designer is the ultimate flexibility to create lousy things that don't work very well.

Each mapsquare will have to hold it's own data on what tech level it has. This can either be one single tech level for the entire civ, or an individual one for each mapsquare (or Ethnic Group, even). Gamer's choice. It can do both.

That's why this tech discussion is a 'data storage' question.

The idea of storing the tech data at the 'civ' level is, in my experience, bad design, because you only allow one possible outcome. The component approach allows more choices, codes easier and works just as well for your purposes.

There is no additional complexity raised, in fact it simplifies everything quite a bit.

And I promise, this method will never blow up on us. In fact, it is how we keep the game from ending up unplayable. This is how you turn out good, quality software. People using the other approach are the ones that make buggy, poor performance games and other software. This approach turns out a product that runs like a machine. The other approach turns out a hand-crafted piece of art that often has as many flaws as it does benefits.

Can I try and summarize it?

The idea is exactly the same difference as happened between 'machine made' gun barrels and 'hand-fired' ones.

As I'm sure you know, once upon a time individual craftsmen used to make gun barrels one at a time. Then someone came up with a complicated system to turn out machine-made gun barrels. Suddenly you could replace a barrel on a rifle with another one easily. This component approach lead to better, cheaper rifles that could be much more easily repaired/customized. Then they produced machine made screws. And nuts and bolts. And stocks. Etc. Now, using this component approach, we can make engines, bicycles, etc. Highly complex machines that work wonderfully, far beyond that early gunsmiths possible understanding.

That is literally the only difference between ya'lls approach and the one I'm selling: I'm suggesting we use an OO 'component' approach in building it. Ya'll were 'hand crafting' an entire end-to-end gameworld system.

I want a flexible, powerful data model so that later we can 'bolt on' any type of model we want.

Well, this is actually a perfect example, so I'll use the difference between the tech concepts. Please understand that this is not criticism, simply illustration. I hope I don't upset ya'll.

* * *

• Ya'll have built a tech system in the image of how you wanted it. You like a province level game, so you store everything at the province level. You calculate everything at the province level. Your 'province' object is a one-size-fits-all creation designed to handle all allowable game situations. It is not very flexible, and comes near to a 'god' class, since it has to know everything about almost everything, and do all the calculations itself.

• I chose to make the smallest game world unit, the 'Mapsquare', a self-contained component that plugs into a 'province' object. This 'mapsquare' is responsible for it's own tech levels, turn logic, etc. These pieces are themselves custom 'components' that are designed to be snapped into place in the mapsquare. Each can be replaced or extended in a very simple fashion.
  

Yours is a work of art that reflects the strengths and weaknesses of your focus and approach. Mine is not art, just a software machine that maniupulates data to end up with the desired results. It's just fast, accurate and cheap.

Your 'province' will be very hard to code. My 'province' will build itself, since each smaller component is basically 'single-purpose'.

Give examples. That's what I'm wanting!! and give a comparison as to how it is as good/better than our current one. And for the things you seem to want to, tell how you can mimic their results in your model.

Later, when I actually write my idea for a tech system up in code, I'll start a seperate thread and do a step-by-step OOA/OOD, much like I did in the govt and social models.

If you want an example of the approach and it's results, check out the threads on the OOA/OOD in those models, and the 'Object Builder' that is in development.

I'm feeling better, so tonight I'll be back on coding instead of chatting so much. So I won't have time to go in-depth into my idea of a Tech system until I actually do the analysis for coding.

At that point, I'll do it in open fashion, and we can discuss it again.