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

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
      
    
    
  • Provinces
    
    
    
    • Prov Elements:
      
    • MapSquares
      
      
      
      • MapSquare Elements:
        
      • Ethnic Groups
        
        
        
        • Group Tech Info
          
        • Selected Culture
          
        • Selected Religion
          
        • Group Tendency Values
          
        • Group Attributes
          
        
        
      • Terrain Object
        
      • ResourcesAvailable Objects
        
      • Any Other Mapsquare Elements
        
      
      
    • Any Other Prov Elements
      
    
    
  • Other Civ Elements
    
  
  

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

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

1. Resources Available
   
2. Labor available
   
3. Number of Production Sites
   

This gives you several choices:

1. 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.
   
2. 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.
   

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

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.

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.

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.