Ooa/ood

[F_Smith]

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.

I hope it doesn't ruin everything.

[F_Smith]

Mark:

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.

Does that explain my point of view?

[Lord God Jinnai]

quote: Originally posted by F_Smith on 08-05-2000 03:43 PM 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.

I still think it shouldn't be stored per say at the square level, maybe at the province level, like i stated earlier, if there are city-state ones. Because techs levels vary so little from square to square unless 1> there is a city 2> it is the border of a province/civ that has differnt apporach on tech.
Have you actually looked at the tech model and seen how many basic and application techs there are? Well there are ~10 level 1 basic techs, each with several subranches and many of those with additional subranches and all of those subranches have application techs linked to them. Now each one of these has modifiers to see if the tech level there will be easier/harder to achieve because of 1> helper tech basic levels and specific application techs 2> Ethic and religion biases toward tech 3> government support or lack of it 4> local economy (ie a farming community or bustling city). Also other factos can only be calculated at a higher level such as if 2 roads are linked to 2+ cities. This is so a player doesn't try to build roads everywhere, just where it could help. Now the storage of that info isn't the hard thing...the fact that almost every time a variable changes in a square, that square will need to be checked again. Imagine now how long will take in modern times because 1 variable change can affect many aspects of RP production, depending on what it is. Not only the production, but the advancement cost can raise/lower because of various reasons, mostly do to enthic/religious varibles, as well as tech helpers. Each .01% of advancement has the potential to change these variables and application techs will also have various levels (though no decimal places) so you'll haveto keep track of all those levels on each mapsquare? By modern times for the tech model you'd have literly 100s to 1000s of variables on each square just for the tech model alone which is why i say with, respect to your point of view, that the cost will eventually outway what little benifit there is.

quote: Originally posted by F_Smith on 08-05-2000 03:43 PM 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.

Can u explain the differance better? I don't really understand what you mean by our method...ie a comparison might help.

[This message has been edited by Lord God Jinnai (edited August 05, 2000).]

[F_Smith]

Lordy:

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.[/list]
In other words, your tech system is based upon a hand-crafted 'Province'. I built a 'Province' machine from single purpose 'components'.

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

I can write mine in about 1/4 the time I could write yours. If I find errors in the component version, I know which component to look to for the problem. On the 'god' province, it's going to be somewhere in that huge object.

[Lord God Jinnai]

Can you give details of how yours will work? And can it do everything ours does? It took us a while to sort out what was needed and what was not and how thing need to be handled because we want realism AMAP w/o cripling gameplay. Our model does such.

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.

Anyway can you do so on another thread so i can referance it easier?
[This message has been edited by Lord God Jinnai (edited August 05, 2000).]

[Mark_Everson]

F. Smith:

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.

Anyway, I need to do more coding and less yacking, so I will end it here.

[Lord God Jinnai]

F_Smith: Can you reply in the tech thread where i continued the discussion about how to store techs? Only cuz its not really to that part of the coding stage yet.

[F_Smith]

Lordy:

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.

Deal?