 |
|  |
 |
|
axi
|
 |
Athens Greece
Sep 1999 time: 07:13
|
|
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.
Last edited by axi on 13-02-2002 at 00:05
|
|
|  |
 |
|
F_Smith
|
|
Austin, Tx 78728
May 1999 time: 05:13
|
|
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
|
|
Austin, Tx 78728
May 1999 time: 05:13
|
|
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).]
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:13
|
|
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).
|
|
|  |
 |
|  |
 |
|
roquijad
|
|
Santiago
Nov 1999 time: 05:13
|
|
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
|
|
Austin, Tx 78728
May 1999 time: 05:13
|
|
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.
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:13
|
|
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.
|
|
|  |
 |
|  |
All times are GMT. The time now is 05:13. Apolyton Time is 00:13. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|