Ooa/ood

[F_Smith]

Mark:

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,

[*]What methods should 'field of knowledge' have?[*]What methods should 'application' have?[*]What methods should be moved up to the 'technology' abstract class?[/list=a]

P.S. this is not at all off-topic, if you ask me. This is the only topic that matters, until the architecture is laid out. Any further discussion on models is just theoretical, in fact, until this topic is firmly finished.

[Lord God Jinnai]

I don't claim to know much about OOA/OOD so i won't debate the merits except that can u give specific examples of how it would help with the tech model, and be able to defend easily against what we already have (OOA/OOD programming isn't the best out there for every solution, this I DO know)

Anyway with that said, this approach will help with the wonders model i've been working on since many structures produce similar results, but each one is slightly differnt and can produce additional results that others might not, or to greater extent. The only problem is figuring out how many differt ones we need because I'm usuing abstract items based on real-world stuff and taking some leaway. By far one of the most important to figure out early on will be religious structures, which can also co-exist as other types such as monuments etc.

[F_Smith]

Lordy:

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?[/list]

I'm not sure how many of these will be in the game, or what I'm forgetting. What other kinds will there be?

[Lord God Jinnai]

I'm only listing things mainly that deal with ancient times Each thing i list will have differnt effects which may(not) be related to others. The 3 general types have the subcategories of structure types and can be combines say religion/government FE.

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.

ones that allow the user to bend/break one of the game rules?
-----
definatly not.

[shimmin]

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.

For most English speakers (and most other European languages, for that sake) I'll agree with you almost fully. Many native speakers of Japansese, however, seem to have an easier time of procedural designs. I wondered about this until I learned just enough Japanese grammar to realize that the language was inherently procedural. Although I've never met a rabbinical programmer, I suspect Hebrew may be another language that leads the speaker to think procedurally. In a sense, all its adjectives are verbs.

[F_Smith]

Lordy:

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

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

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.

Which option do you think best suits your needs?

[F_Smith]

Hi, Shimmy:

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?

Please, dear god, don't any Phillipino or asian readers out there think I'm slamming asians in any way! No disrespect intended. And I'm sure there are many creative asians. I'm just musing about my experience! If I offended anyone, I apologize in advance.

[Lord God Jinnai]

The thing is although many wonders will have several things in common, they will all have modify differnt things. FE a wonderous bank will improve the economy and not the agricultural part while a wonderous, um, aqueduct would improve agriculture a lot and the economy also. None of these would ness improve the government nor religion, unless FE the bank was of religious nature or run by the government it would, but the aqueduct really wouldn't since it invariably helps everyone.

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.

Also on your note about Asian creativity, I think your wrong, after all they make most of the RPGs in the world today and play the most (90% on both). They also create Anime which i watch a lot. I also happen to know a few americans who are very uncreative.

[Lord God Jinnai]

I posted my model in a new forum so you can check there and see what the best way to head is.

[F_Smith]

Lordy:

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

class Wonder
instance variables:

[*]name[*]building type[*]date built[/list]
public methods:

[*]public void applyModifiers(Civ c);[/list]

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 great work you're doing. You're saving weeks of programmer time, just with this.

[F_Smith]

Mark:

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.

For example, when Lordy finishes defining the object model for Wonders, it will be simple to tell a programmer "we need you to code a superclass with these attributes, and these 20 subclasses with these attributes." You will have a lot more interest from programmers, and make much better use of their time. With at most a week's worth of work, a programmer could code and debug a huge system of wonders.

[Mark_Everson]

F. Smith:

Your general prescription is what I had thought should happen anyway... the coders are Of Course supposed to interact with the model leads to figure out the right objects etc. If a coder and the respective model leads are having trouble talking the same language, I will jump in and do what I can. If you would like to volunteer your services for occasionally pushing forward OO design on whatever models you are interested in, that would be of great help!

[F_Smith]

Mark:

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.

And you are trying to build a system that can fly. So you must model the systems in question, by creating all the pieces of those systems and putting the pieces together. Otherwise, it *will not fly*.
[This message has been edited by F_Smith (edited March 13, 2000).]

[F_Smith]

Lordy:

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[/list]

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[/list][*]Behaviors/Public Methods:

[*]buildStructure()[*]applyModifiers(Civ c) -- this will over-ride the method inherited from 'Wonder'.[*]oneTurnAgingEffects()[/list][/list]

What else am I forgetting?

Just so we're on the same page here, each actual man-made structure will sub-class the object ManMadeStructure -- this means that each specific type of Man Made Structure will have all the variables and behaviors of class ManMadeStructure, yet use those variables and behaviors in different ways. And then, you can create any number of 'instances' of each type of man-made structure. So you can create an infinite number of specific Man-made structures, each with different game effects. Simple, yet powerful. And each instance of ManMadeStructure (or any of it's subclasses) will still have the behavior it inherits from 'Wonder' -- specifically, every turn, it will call 'applyModifiers(Civ c)' to apply the wonder's effects.
[This message has been edited by F_Smith (edited March 13, 2000).]

[Mark_Everson]

F. Smith:

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

Personally, I think that the technology model's home should be a level higher than that an individual map square. Technological changes going to be relatively slow compared to diffusion anyway... IMO whoever codes up the technology model should be the one to make the decision about the initial level of the object model (we can discuss it of course before then). Then we can take it from there.