Model implementation levels: A summary

[axi]

There have been various discussions lately about the detail level in which the gamedata must be stored and the game functions be run. I have summarised my view of how things should be run and I present it below in the form of a matrix. I took the liberty of adding many options, bearing in mind the need for flexibility and customisability in the game, but I feel that we will have to make some cuts.

I believe that it would be very helpful if everybody would present in this thread his own version of that matrix, corrected and possibly enlarged (with more game features). This way we can all get to an agreement about how things should run. All general discussion concerning this sort of thing could be done here too.

Until now, there are 3 types of hierachical structures in Clash (Square, Province and Civ) and data can be stored in any of these 3 levels, all the time or only in special cases. Features that can be implemented in a "Parent structure" and, through interpolation, be temporarily (for reasons of smooth gameplay) "inherited" to a "Child structure" form two new levels (P/S-I and C/P-I). For each game feature there is a default, or standard (S) level and there may be one or more optional ones (O) and restricted ones (X). For some sets of game features we will certainly have to apply some more restrictions to their comparative levels (f.e. we can't have Kapital at a lower level than Sites). We will also be obliged to provide all the Interpolation and Compression functions needed for all the game features. Finally we will have to secure the various model interconnections against all possible configurations.

Game Feature___Square____P/S-I____Province___C/P-I____Civ
Terrain&Veg type___S________X_________X_______X______X
Population________S_________O________O_______X____ _X
F&R&Sp Sites____S__________O________O_______X_____X
Kapital__________O__________S________O_______X____ _X
Prod.Function____O__________O________S_______O____ _X
Civil Infra_________O_________O________S_______O_____X
Transp.Infra_______S_________O________O_______X___ __X
Trade Routes_____O_________O________S_______O_____X
Ethnic Groups____O_________S________O_______O_____X
Social Classes____O_________S________O_______O____O
Culture___________X_________O________S______O____X
CNPs____________X_________X________O_______X_____S
INPs_____________X_________X________S_______X_____ O
Rul.Govt Profile____X_________X________O_______X_____S
Rul.Excl.Policies___X_________X________O_______X__ ___S
PAFs____________O_________S________O_______O____O
RP Generation____O__________O_______S________O____X
Tech Levels_______X__________X_______O________S____O
TF Generation_____X_________X________S_______O____X
Mil.Infra__________S_________X________O_______X___ _X
Mil.Operations____S_________X________O________X___ _X

To avoid misunderstandings, I specially declare that the above matrix is only referring to the gamedata model and not to the player interface. We're talking about the level the actual data will be stored and the functions run and NOT about the level in which the player will actually play (what data he will see and what moves he will make), with the exception of Rul.Govt Profile and Rul.Excl.Policies, where these two coincide. So a configuration from this matrix will be more or less proportionate to the computer resources that the game will demand, but NOT to the complexity that the player will have to face. Of course the detail that the player sees must always be equal or less than the detail the computer sees, so to a point, this will also reflect the complexity of the player's game.

[F_Smith]

Excellent idea for a topic, Axi:

But I have a few suggestions on direction, here.

Think in terms of a 'filing system' stored in a 'hierarchy', like the tree you see in Windows Explorer when you browse files:

GameData Object Hierarchy used by the 'Object Builder'

[*]Civ

[*]Civ Elements:[*]Ruler

[*]ruler details[/list][*]Provinces

[*]Prov Elements:[*]MapSquares

[*]MapSquare Elements:[*]Ethnic Groups

[*]Group Tech Info[*]Selected Culture[*]Selected Religion[*]Group Tendency Values[*]Group Attributes[/list][*]Terrain Object[*]ResourcesAvailable Objects[*]Any Other Mapsquare Elements[/list][*]Any Other Prov Elements[/list][*]Other Civ Elements[/list][/list]

GameData stores a list of all mapsquares, a list of all civs, a list of all baseethnicgroups, a list of all religions, cultures, tendencyvalues, groupattributes, etc. To access any of the data anywhere in the gameworld, use the above 'tree'.

This 'filing system' is, I believe, the absolute minimum, based upon all requirements for all models.

[F_Smith]

Just a little more clarification, just in case:

So if you want to compute the economy at a province level, you need:

[*]Resources Available[*]Labor available[*]Number of Production Sites[/list=a]

This gives you several choices:


[*]Province by province, calculate once all the mapsquare resources available and don't recalculate until and unless the Province border changes. Calculate all production zones available and don't recalculate until and unless zones available changes. Ditto with population/workers avaialable.[*]Have each mapsquare calculate it's output once, then only recalculate when any of the inputs changes. Add all mapsquare outputs together at the Prov level once, and then again only when one of the msq-level outputs change.[/list=a]

These are the competing approaches right now. I believe we code up both in the 'turn handlers', since the math is pretty simple either way. And that goes for all models that are in question -- tech, econ, etc. We can allow the players to chose the level of detail they want, since the two approaches will produce somewhat different outcomes.
[This message has been edited by F_Smith (edited August 08, 2000).]

[Lord God Jinnai]

I read your heirachy chart and one thing F_Smith...tech isn't stored under enthnic groups.

[Richard Bruns]

A couple disagreements:

As I explained in the tech thread, we can no longer produce RP's at the province level. RP's must be produced at the level the economic model is being run at because their generation depends primarily on economic activity.

All ecology characteristics are stored in ecological provinces. An ecological province is a group of 5-30 squares assumed to have identical terrain characteristics.

I am working on a new population model to be reviewed by the team. While the basic population number will still be stored in squares, some characteristics of the population will be stored at the level of civ, province, or social group (player's option).

[Mark_Everson]

quote: Originally posted by Richard Bruns on 08-08-2000 09:52 PM As I explained in the tech thread, we can no longer produce RP's at the province level. RP's must be produced at the level the economic model is being run at because their generation depends primarily on economic activity.

I completely disagree with the sentiment that just because the economic model Might be run at the MapSquare level that you need to change the technology model. First of all, the economic model may well Not be run at the MapSquare level. Second, as both F. Smith and I have explained even if the economy is run at a MapSquare level we can still aggregate the economic information at the province level and you can use that! It is in extremely simple matter to add the production outputs from every MapSquare in a province to gather to generate a provincial production figure. A province with three squares each of which produced respectively x, y, and z food per turn will have a provincial generation of food per turn of x + y + z. That is all you need! Can you explain to me why it is you think everything needs to change???

[Mark_Everson]

Axi:

Your list looks basically OK to me. I would put more thought into the specifics, but there may be details in the program structure that I haven't thought of yet that could change my guesses anyway. Furthermore, I am certain that no matter what the group as a whole decides, F. Smith is going to code the part he does in the way he wants to regardless. This is not a sniping comment, just a statement of fact . So the payoff to having a long discussion about this seems minimal to me.

[roquijad]

I believe any piece of info (data object) must be at the detail level where it's desired in terms of gameplay. We can have techs at the square level if we feel that's nice and adds fun effects to the game, but we'll keep it at the civ level if we feel no extra fun is achieved.

I think it's fair to say that having data objects in low level units (FE, squares) adds more realism and consumes more computational resources than handling that info in a higher level (FE, civ). The main question to answer, IMHO, is what's the level at which each of the objects should exist in order to achieve the optimum relation between realism (fun) and cost (comp resources). Here's my optimum level for some of the objects considered so far:
Social Classes: Civ
Techs:Civ
Cultural Attributes of Ethnic Groups: Civ (or maybe Province)
Ethnic Groups populations: Square
Attributes of Great Religions of the World: Planet
Govt policies: Civ
Economy: Province


I think this thread should help us define in a more specific fashion what is what we desire for the game.
[This message has been edited by roquijad (edited August 08, 2000).]

[F_Smith]

Guys:

Mark's certainly right about my scenario designer -- I will use an object-oriented design, as I outlined above. If someone disagrees with my layout from an organizational standpoint, I'll listen (and likely change it).

But I'll only be swayed by arguments that I've mis-filed something, not claims that the program will run better with a less organized filing system (I, of course, do not agree -- there are coding costs you just don't understand that will destroy all the 'gains' you think you see).

I just can't see any benefit to storing unlike things together. I do not see any gain in filing values for 'local people's tool ability (tech level)' in a file called 'Civilization'. It doesn't make sense to me, from an organizational standpoint.

But if it works for whoever ends up programming the final product, more power to 'em.

This object design will scale up without a problem to store whatever you want wherever up the hierarchy you want.

[F_Smith]

P.S.

Rodrigo:

quote: I think it's fair to say that having data objects in low level units (FE, squares) adds more realism and consumes more computational resources than handling that info in a higher level (FE, civ).

This is not accurate. Storing things at the lowest level you will need is more efficient, because you have to consider data retrieval costs.

Now 'running' computations at a lower level (turnhandler logic) does take more 'resources' (is slower to run). That you control thru 'scope'. If you don't want mapsquare-level computations, don't do them.

But storage does not use up clock-cycles. And it doesn't use up any more memory, because you're only storing what you absolutely have to have. You'll have to store it anyway.

[axi]

I'm bumping this thread up because it has two very useful things in it:

1. The matrix of default and possible implementation levels for each game feature, that I have posted.

2. The object hierarchy of the Object Builder, that F_Smith posted.

It seems that our recent disagreement about technology is just one of the many cases of disagreement on the level that various things should be run. I fell that further discussion on this should be generalised and take place in this thread.

I will analyse the problem in my subsequent post.

------------------
"In a time of universal deceit, telling the truth is a revolutionary act."
George Orwell

[Richard Bruns]

This thread is a good reference, but I think that the object placements should be discussed in the appropriate thread. We can post the results of those discussions here so all the info is in one place.

[axi]

*bump*

Seeing the confusion recently created in the "coding the society model" thread, it reminded me of the good old days, when F_Smith was coding and I was modelling and I remembered the existence of this thread, which now I bring up because IMO we should finalise some things, now that the coding is actually being done. If until now we have implemented something different than what we ultimately intend, then we can post it here for everyone to see and act as a reminder to fix later.

My views haven't changed since, however some names of game features have.

[Mark_Everson]

Hey Axi:

You might want to just start a new thread with this. I am afraid people might misconstrue the old coding architecture stuff as current...

In any case what is in the code Now for Econ is that everything is at square level. But I do expect that to change to something close to what you have down at some point in the future...

Long term my guess is it should be (showing changes only)

Game Feature___Square____P/S-I____Province___C/P-I____Civ

Prod.Function____O__________S________O_______O____ _X
Civil Infra_________O_________S________O_______O_____X
Social Classes____O_________O________S_______O____O
Culture___________X_________S________O______O____X

And what the heck are CNPs, and INPs? And Don't say you were hoping I wouldn't ask. It would also be helpful to have what a PAF is defined so that someone not familiar with the govt model will know what it means.