Tweet
Well there's quite a few things I would like to say, which has resulted in another monster (post that is 
)
To get some organisation to my response I will primarily answer Marks post, with comments on the rest along the way.
And 'Thank You, Richard: You've seen the light.' I hope your comments will enable other members of the team thinking OO to have a new perspective to the idea (particularlyl Mark and F_Smith).
Quotes are from Mark, unless otherwise stated
SOCIAL
Well it may be a case of me stating my case badly. What I meant is actually exactly what Mark said - up to a certain point . I was just trying to describe why it has to be so:
Well I'm not sure about that last part. Two points:
It was my understanding that every single piece of data pertinent to EGs would be stored at the mapsquare level (sqEGs). I am aware that in the default game ethnicity will primarily be modelled at the province level (prEGs), but I understood that from the programming perspective prEGs would be an aggregate of sqEGs based on the attribute Nationality (if I understand Rodrigo correctly).
Given the above, and the decision to model tech at the EG level that is a logical consequence of this approach, the discussion of aggregation and aggregation techniques are IMO unavoidable, at least from a programmers view. If the team members don't state their opininons on how to aggegate the basic objects, then it will be up to the programmers to decide how to do it, because it has to be done. The programmers might do it their own way anyway, but then at least we would know where the differences of opinion lay. The general comments on aggregating objects on attributes, is IMO very important in this context.
On splitting of Nationality: I agree that this is not a cardinal point at the moment. The aggregation of EGs was just my point of entry into these considerations, and the necessity of being able to split Nationality was part of that discussion.
OVERALL GAME
I did read the thread Who is the player… and this was my opinion on the subject: I am 'controlling' an empire as a being with everlasting life, and limited omnipotens (if there can be such a thing
)
Nomadic civs, no land, military units, habitat idea:
First I don't know what pastoralists are, although I get the general idea.
Second, this is exactly the thing that can be handled by a Habitat object. (Alas, the name is not good. It does not cover the real essence, but the object first presented itself to me (weird concept, don't you think)as a basic infrastructure object capable of containing EGs, hence the name. If I were to rename it, I would probably choose something like production-population framework, ProdPopFrame)
Let me restate what I think a habitat is: Importantly it is a programming concept, not a game concept. The player will never know habitats exist, since it is a deep layer object. The habitat is a basic infrastructure object: It represents the top layer of the present land mapsquare object: Population and sites, while the basic ressources of the present mapsquare will remain in a new more primitive object GeoSquare, that also stores other basic information as geographical position and maybe more.
All people reside in habitats. Habitats are where the transformation of basic ressources from the geosquare into basic outcome (food, production, service, RPs etc) takes place. This transformation process takes place in sites, that are an integral part of the habitat. In early days the presence of population in the habitat is necessary to accomplish this transformation, but with increasing automation the number of people needed to perform the transformations falls, and in the end no people may be needed (fully automised production plants, cruise misiles etc): So production really takes place in infrastructure after all, since habitats are infrastructure. (Previously F_Smith and I agreed that production is done by people, catalysed and qualified by infrastructure: I have now changed my opinion. It was based on my previous view of population where I had in fact bestowed people with infrastructure capabilities, because there was no infrastructure interface between the ressources of the land and the people ). The sites represent the ability of the habitat to exploit ressources of underlying mapsquares.
Another implication of habitats. The presence of habitats is what distinguishes land squares (having habitats) from ocean squares (not having habitats): If there is no habitat in a square, no people can live there, and no production can take place, unless you produce and place a special habitat on the square. Of course other squares could be modelled to be just as inhospitable: Dessert squares, Himalayan squares, arctic squares, off-map squares abstractly representing space, a fourth dimension or whatever. If you have the necessary tech it could be possible to produce Habitat-derived infrastructure objects making colonisation possible: Sea bases, underwater colonies, oil rigs, mountain cities, desert cities, colonies on the moon or colonisation of a parallel universe.
From the habitat we can derive several other important game concepts, by deriving new classes based on the habitat, and inheriting these basic population-container and production facilities. One important capability that we could add would be mobility. A mobile habitat is an infrastructure object capable of containing an in principle unlimited number of people, moving from geosquare to geosquare while exploiting the land underneeth it (forraging, living of the land, exploiting ressources). Military units, nomads, pastoralists etc are all mobile habitats, of course with some additional capabilities, like military power, the ability to settle down, maybe even split, as suggested by Richard. So in a way military units and nomadic units are very alike, they are both derived from a common mobile habitat object. One might even be derived from the other, FE as Mark suggested it is possible that a Nomad obj is just a special military unit, or maybe is derived from a common military unit object.
This combination of mobile and immobile habitats simplifies the definition of what a civ is - or rather what a civ controls (which is basically the same thing):
As Mark, I also view the civ as consisting of both land and people. But making it consist of Habitats accomplishes exactly this. All people reside in Habitats, so controlling habitats (mobile or immobile) is equal to controlling the people in them. The population of your civ is the total population of the habitats you control. All geosquares have one matching immobile Habitat (the combination of the two is exactly like the present mapsquares, with some additional functionality added by the concept of having a maximum number of sites) so controlling the habitat is equal to controlling the land. The physical extent of your empire is the total number of controlled immobile habitats.
Mobile habitats also makes fishing possible as Richard stated it:
Given the proper tech you construct a fishing fleet unit of size 20, and hire the 1000 fishermen needed to man the fleet. The fishing fleet is derived from a habitat object and has room for 1000 people and 20 sites. The fishing fleet unit is of course also capable of crossing the sea, so you move your unit across the sea to a fishing bank. Here it settles and begins harvesting the sea. The beauty is - as Richard remarked - that this is done exactly like the farming/production of land squares. You don't need any special code. The habitat object knows how to harvest food sites and production sites, and doesn't give a d… if they are at sea or on land (or in space or in a parallel universe). The efficiency (decided by available tech) and the size (number of sites in the object) of the fishing unit determines how much of the ressources present the object will be able to exploit. Say the unit is capable of exploiting 20% of all available food ressources in a square. The square it is in has a potential maximum food site production of 170 sites. 20% of this is 34, but the unit only has 20 sites, so 20 is what gets produced. On the way to the fishing banks several sea squares were crossed, but they only had maximum food production capabilities of at most 75 sites - 20% of this is 15, so this wouldn't pay off with the present fishing fleet compared to the fishing bank. You could construct smaller fishing fleets to exploit the more meager fishing spots, but in the end maintenance of the unit would exceed the profit from exploiting such squares. Another way of exploiting the more meager sites is increasing the efficiency of the fishing fleet by acquirung more advanced technology (imagine improving fishing techniques or acquiring capability of expoliting a different ressource like kelp), that might be able to exploit 30% of the potential maximum (potentially yielding 22.5 sites at the 75max square).
In other words it would be possible to design any number of different units capable of exploiting any combination of food and ressource sites in any mapsquare - on-map or off-map - that you can think of. And they would all be using the same production code! These units might have any other capabilities you see fit , like having military strength, capability to sail, fly or go into space. They could be immobile, invisible, large, smelling or whatever.
A cruise-missile would be a habitat-derived object with large military power, no room for population and no production capability.
A roman legion would be a habitat -derived object capable of holding up to 6000 people in the form of one or more haEGs (EGs at the habitat level). They would have some production and food sites, enabling them to forage. They would of course have military power, which in their case would be some fiunction of the manpower present (and other factors of course), but they would also have the ability to build roads or encampments. The amount of sites present might increase if they took more a more permant stand like in the fortifications along the Rhine, and some of the legionaires might be put on reserve, enabling them to work in the immobile habitat of the square the unit is in, which would probably increase production and maybe even spur the founding of a city (lets forget the possibility of having two or more immobile habitats in the square for the moment, that is just a spin-off).
A carrier would be a habitat-derived object, holding upto 6000 people. There would be limited if any production capability, and tremenduous firepower, and of course it would be capable of sailing. It would be able to hold a number of fighter/bomber units, derived from airborne habitats objects, capable of holding 0 people (of course an abstraction, but for now I think the smallest EG is 1000 people), flying, no production and large firepower.
A nomad unit would be a habitat-derived object capable of holding maybe 20000 people, with quite a few production sites and considerable military capability (or none, depending on what specific nomads we're modelling: We could have several different nomad units, if need be).
Rodrigo had some thoughts on nomads as well:
This is very much like the habitat concept with some elements of the Roman Legion example above: When the Nomads are wandering ('Nomad =1') they are in a mobile habitat, using the sites of that habitat (which would probably be fewer than if the Nomads settled down, at least for production) to harvest the land they move across. Mobile habitats should not be capable of carrying 'fixed' infrastructure (see my remarks below). When they settle in a square they move from the mobile habitat to an immobile one, instead using the sites there. They would now be able to build infrastructure the normal way. Maybe the disbanding of the mobile habitat object would somehow give them some starting capital with which to build sites or something else in their new homeland. This would allow them to settle down in barren lands where there are really no sites in the immobile habitat present.
Richard stated that he saw all man-made object as habitats. It has crossed my mind also, although I am not sure this is the case (This is the reason I put 'a basic inftrastructure object' instead of 'the basic infrastructure object' in the beginning). At the moment I am of the opinion that while certain habitat-derived objects might be able to hold other infrastructure (particularly other military units as in the carrier example above) most infrastructure should be placed at the geosquare level, not the habitat-level. It doesn't make a lot of sense having a roman legion carrying around a major library does i, so why should there be a slot for it? On the other hand other infrastructure always works on the output produced by the habitat and transforms this into something else, so it will always be dependent on the presence of a habitat to be able to do anything. Then again I would not like other infrastructure to be able to have sites, even at some scenario creators whim. I haven't thougt this out, but I think that there should be an even more basic infrastructure object from which habitats are derived: Maybe this infrastructure unit should be capable of containing just people? (In which case it should probably be called 'Habitat' while the objects I have been talking about all along should be renamed ProdPopFrame or something similar). There is still plenty of room for innovation at these very basic object layers. I'll have to give it some more thought.
TECH
On second thoughts I concur: Knowledge can deteriorate, it needs maintenance (This will strenghten my arguments vs F_Smiths tech-in-infrastructure idea: ))
This describes what would happen if tech was stored in infrastructure as suggested by F_Smith. Like you I don't think it should be like this, it is counterintuitive.
Re the opening of F_Smith: Now we just have to hold him to it to get the knowledge out of that cursed infrastructure.
The other points in this section has been answered above.
CONCLUSION
I hope this has helped clarifying my ideas. I sincerely believe that the splitting of the mapsquare object into two layers will yield tremenduous flexibility. Please consider it some more before you dismiss it. I'll just recap the main elements as I see them at the moment:
Land: Presented as GeoSquares. Holds the maximum number of sites (ressources) that can possibly be exploited given all tech (potSites).
Infrastrucure: Basically converts some ressource into another (input one or more object and output something else). The most basic transforming is done by the habitat-derived ojects containing actual sites (actSites=production facilities) that exploit the potSites in the square underneath turning out units(food, production etc). Other infrastructure converts these units or population into output of a large number of different varieties (military power, tech, happiness or whatever).
People: Modelled as EGs. In early days people are necessary for infrastructure to function - they permit or catalyze the transformation process taking place in infrastructure. Later the function of infrastructure becomes less dependent on the presence of people. In theory, with increasing automation, people could get superfluous - at least in this respect. They are however needed for something else:
Knowledge
Knowledge qualifies the infrastructure, making infrastructure increasingly efficient, and permitting the construction of new types of infrastructure. Knowledge resides in people and only there - so if there are no people there is no knowledge.
[This message has been edited by Beör (edited September 25, 2000).]
[This message has been edited by Beör (edited September 25, 2000).]
)To get some organisation to my response I will primarily answer Marks post, with comments on the rest along the way.
And 'Thank You, Richard: You've seen the light.' I hope your comments will enable other members of the team thinking OO to have a new perspective to the idea (particularlyl Mark and F_Smith).
Quotes are from Mark, unless otherwise stated
SOCIAL
Well it may be a case of me stating my case badly. What I meant is actually exactly what Mark said - up to a certain point
. I was just trying to describe why it has to be so:quote: The Data Storage for ethnic groups is done at the square level. This says Nothing about what the standard game models support. … The code has the flexibility to track ethnic groups down to the square level. However, unless there is something I am unaware of, we are currently tracking ethnic group characteristics at the Civ Level. So all this talk about aggregation is premature IMO |
Well I'm not sure about that last part. Two points:
It was my understanding that every single piece of data pertinent to EGs would be stored at the mapsquare level (sqEGs). I am aware that in the default game ethnicity will primarily be modelled at the province level (prEGs), but I understood that from the programming perspective prEGs would be an aggregate of sqEGs based on the attribute Nationality (if I understand Rodrigo correctly).
Given the above, and the decision to model tech at the EG level that is a logical consequence of this approach, the discussion of aggregation and aggregation techniques are IMO unavoidable, at least from a programmers view. If the team members don't state their opininons on how to aggegate the basic objects, then it will be up to the programmers to decide how to do it, because it has to be done. The programmers might do it their own way anyway, but then at least we would know where the differences of opinion lay. The general comments on aggregating objects on attributes, is IMO very important in this context.
On splitting of Nationality: I agree that this is not a cardinal point at the moment. The aggregation of EGs was just my point of entry into these considerations, and the necessity of being able to split Nationality was part of that discussion.
OVERALL GAME
I did read the thread Who is the player… and this was my opinion on the subject: I am 'controlling' an empire as a being with everlasting life, and limited omnipotens (if there can be such a thing
)Nomadic civs, no land, military units, habitat idea:
| quote: …I think the civ needs to be defined as including land and people. People, or population groups, can belong to the civ, and yet not be on a map square controlled by the civ. This would be the case for either refugees before they have settled somewhere, or military units. So although a civ has no land, it can still have military units, and so still exist even if it has no land. If we modeled pastoralists as military units, or make them a special case of population units, then the civ can exist and fulfill functions such as diplomacy etc. even without land ownership. But in the most case nomads will control the land they are on anyway... A little bit more about nomads... I'd been planning on handling nomads just as a special type of military unit. The analogy would be that the pastoralists forage just as a military unit would when there were no supplies available. Pastoralist, when moving slowly enough, could essentially forage grass, in addition to this stuff that normal military units can find when living off the land. I think pastoralists are very closely analogous to military units that carry their own livestock with them for the campaign. We don't have explicit rules for this yet, but it seems fairly straightforward |
First I don't know what pastoralists are, although I get the general idea.
Second, this is exactly the thing that can be handled by a Habitat object. (Alas, the name is not good. It does not cover the real essence, but the object first presented itself to me (weird concept, don't you think
)as a basic infrastructure object capable of containing EGs, hence the name. If I were to rename it, I would probably choose something like production-population framework, ProdPopFrame)Let me restate what I think a habitat is: Importantly it is a programming concept, not a game concept. The player will never know habitats exist, since it is a deep layer object. The habitat is a basic infrastructure object: It represents the top layer of the present land mapsquare object: Population and sites, while the basic ressources of the present mapsquare will remain in a new more primitive object GeoSquare, that also stores other basic information as geographical position and maybe more.
All people reside in habitats. Habitats are where the transformation of basic ressources from the geosquare into basic outcome (food, production, service, RPs etc) takes place. This transformation process takes place in sites, that are an integral part of the habitat. In early days the presence of population in the habitat is necessary to accomplish this transformation, but with increasing automation the number of people needed to perform the transformations falls, and in the end no people may be needed (fully automised production plants, cruise misiles etc): So production really takes place in infrastructure after all, since habitats are infrastructure. (Previously F_Smith and I agreed that production is done by people, catalysed and qualified by infrastructure: I have now changed my opinion. It was based on my previous view of population where I had in fact bestowed people with infrastructure capabilities, because there was no infrastructure interface between the ressources of the land and the people ). The sites represent the ability of the habitat to exploit ressources of underlying mapsquares.
Another implication of habitats. The presence of habitats is what distinguishes land squares (having habitats) from ocean squares (not having habitats): If there is no habitat in a square, no people can live there, and no production can take place, unless you produce and place a special habitat on the square. Of course other squares could be modelled to be just as inhospitable: Dessert squares, Himalayan squares, arctic squares, off-map squares abstractly representing space, a fourth dimension or whatever. If you have the necessary tech it could be possible to produce Habitat-derived infrastructure objects making colonisation possible: Sea bases, underwater colonies, oil rigs, mountain cities, desert cities, colonies on the moon or colonisation of a parallel universe.
From the habitat we can derive several other important game concepts, by deriving new classes based on the habitat, and inheriting these basic population-container and production facilities. One important capability that we could add would be mobility. A mobile habitat is an infrastructure object capable of containing an in principle unlimited number of people, moving from geosquare to geosquare while exploiting the land underneeth it (forraging, living of the land, exploiting ressources). Military units, nomads, pastoralists etc are all mobile habitats, of course with some additional capabilities, like military power, the ability to settle down, maybe even split, as suggested by Richard. So in a way military units and nomadic units are very alike, they are both derived from a common mobile habitat object. One might even be derived from the other, FE as Mark suggested it is possible that a Nomad obj is just a special military unit, or maybe is derived from a common military unit object.
This combination of mobile and immobile habitats simplifies the definition of what a civ is - or rather what a civ controls (which is basically the same thing):
As Mark, I also view the civ as consisting of both land and people. But making it consist of Habitats accomplishes exactly this. All people reside in Habitats, so controlling habitats (mobile or immobile) is equal to controlling the people in them. The population of your civ is the total population of the habitats you control. All geosquares have one matching immobile Habitat (the combination of the two is exactly like the present mapsquares, with some additional functionality added by the concept of having a maximum number of sites) so controlling the habitat is equal to controlling the land. The physical extent of your empire is the total number of controlled immobile habitats.
Mobile habitats also makes fishing possible as Richard stated it:
Given the proper tech you construct a fishing fleet unit of size 20, and hire the 1000 fishermen needed to man the fleet. The fishing fleet is derived from a habitat object and has room for 1000 people and 20 sites. The fishing fleet unit is of course also capable of crossing the sea, so you move your unit across the sea to a fishing bank. Here it settles and begins harvesting the sea. The beauty is - as Richard remarked - that this is done exactly like the farming/production of land squares. You don't need any special code. The habitat object knows how to harvest food sites and production sites, and doesn't give a d… if they are at sea or on land (or in space or in a parallel universe). The efficiency (decided by available tech) and the size (number of sites in the object) of the fishing unit determines how much of the ressources present the object will be able to exploit. Say the unit is capable of exploiting 20% of all available food ressources in a square. The square it is in has a potential maximum food site production of 170 sites. 20% of this is 34, but the unit only has 20 sites, so 20 is what gets produced. On the way to the fishing banks several sea squares were crossed, but they only had maximum food production capabilities of at most 75 sites - 20% of this is 15, so this wouldn't pay off with the present fishing fleet compared to the fishing bank. You could construct smaller fishing fleets to exploit the more meager fishing spots, but in the end maintenance of the unit would exceed the profit from exploiting such squares. Another way of exploiting the more meager sites is increasing the efficiency of the fishing fleet by acquirung more advanced technology (imagine improving fishing techniques or acquiring capability of expoliting a different ressource like kelp), that might be able to exploit 30% of the potential maximum (potentially yielding 22.5 sites at the 75max square).
In other words it would be possible to design any number of different units capable of exploiting any combination of food and ressource sites in any mapsquare - on-map or off-map - that you can think of. And they would all be using the same production code! These units might have any other capabilities you see fit , like having military strength, capability to sail, fly or go into space. They could be immobile, invisible, large, smelling or whatever.
A cruise-missile would be a habitat-derived object with large military power, no room for population and no production capability.
A roman legion would be a habitat -derived object capable of holding up to 6000 people in the form of one or more haEGs (EGs at the habitat level). They would have some production and food sites, enabling them to forage. They would of course have military power, which in their case would be some fiunction of the manpower present (and other factors of course), but they would also have the ability to build roads or encampments. The amount of sites present might increase if they took more a more permant stand like in the fortifications along the Rhine, and some of the legionaires might be put on reserve, enabling them to work in the immobile habitat of the square the unit is in, which would probably increase production and maybe even spur the founding of a city (lets forget the possibility of having two or more immobile habitats in the square for the moment, that is just a spin-off).
A carrier would be a habitat-derived object, holding upto 6000 people. There would be limited if any production capability, and tremenduous firepower, and of course it would be capable of sailing. It would be able to hold a number of fighter/bomber units, derived from airborne habitats objects, capable of holding 0 people (of course an abstraction, but for now I think the smallest EG is 1000 people), flying, no production and large firepower.
A nomad unit would be a habitat-derived object capable of holding maybe 20000 people, with quite a few production sites and considerable military capability (or none, depending on what specific nomads we're modelling: We could have several different nomad units, if need be).
Rodrigo had some thoughts on nomads as well:
| quote: For simplicity and for now, assume we add this characteristic to the EG OO-class as a dummy variable (nomad/settled). When Nomad=1 then the econ model doesn't allow investments in fixed infrastructure. The econ model works as usual, putting people in sites (that exist per se in the terrain) and creating the production using the mobile infrastructure. The EG can move (following a leader EG? controlled by the player?) and in every mapsquare they move to, the econ model simply puts people to work in the new sites. When Nomad=0, the EG works like always and the econ model allows for investment in fixed or mobile infra. |
This is very much like the habitat concept with some elements of the Roman Legion example above: When the Nomads are wandering ('Nomad =1') they are in a mobile habitat, using the sites of that habitat (which would probably be fewer than if the Nomads settled down, at least for production) to harvest the land they move across. Mobile habitats should not be capable of carrying 'fixed' infrastructure (see my remarks below). When they settle in a square they move from the mobile habitat to an immobile one, instead using the sites there. They would now be able to build infrastructure the normal way. Maybe the disbanding of the mobile habitat object would somehow give them some starting capital with which to build sites or something else in their new homeland. This would allow them to settle down in barren lands where there are really no sites in the immobile habitat present.
Richard stated that he saw all man-made object as habitats. It has crossed my mind also, although I am not sure this is the case (This is the reason I put 'a basic inftrastructure object' instead of 'the basic infrastructure object' in the beginning). At the moment I am of the opinion that while certain habitat-derived objects might be able to hold other infrastructure (particularly other military units as in the carrier example above) most infrastructure should be placed at the geosquare level, not the habitat-level. It doesn't make a lot of sense having a roman legion carrying around a major library does i, so why should there be a slot for it? On the other hand other infrastructure always works on the output produced by the habitat and transforms this into something else, so it will always be dependent on the presence of a habitat to be able to do anything. Then again I would not like other infrastructure to be able to have sites, even at some scenario creators whim. I haven't thougt this out, but I think that there should be an even more basic infrastructure object from which habitats are derived: Maybe this infrastructure unit should be capable of containing just people? (In which case it should probably be called 'Habitat' while the objects I have been talking about all along should be renamed ProdPopFrame or something similar). There is still plenty of room for innovation at these very basic object layers. I'll have to give it some more thought.
TECH
On second thoughts I concur: Knowledge can deteriorate, it needs maintenance (This will strenghten my arguments vs F_Smiths tech-in-infrastructure idea: ))
| quote: If the square is conquered … |
This describes what would happen if tech was stored in infrastructure as suggested by F_Smith. Like you I don't think it should be like this, it is counterintuitive.
Re the opening of F_Smith: Now we just have to hold him to it to get the knowledge out of that cursed infrastructure
.The other points in this section has been answered above.
CONCLUSION
I hope this has helped clarifying my ideas. I sincerely believe that the splitting of the mapsquare object into two layers will yield tremenduous flexibility. Please consider it some more before you dismiss it. I'll just recap the main elements as I see them at the moment:
Land: Presented as GeoSquares. Holds the maximum number of sites (ressources) that can possibly be exploited given all tech (potSites).
Infrastrucure: Basically converts some ressource into another (input one or more object and output something else). The most basic transforming is done by the habitat-derived ojects containing actual sites (actSites=production facilities) that exploit the potSites in the square underneath turning out units(food, production etc). Other infrastructure converts these units or population into output of a large number of different varieties (military power, tech, happiness or whatever).
People: Modelled as EGs. In early days people are necessary for infrastructure to function - they permit or catalyze the transformation process taking place in infrastructure. Later the function of infrastructure becomes less dependent on the presence of people. In theory, with increasing automation, people could get superfluous - at least in this respect. They are however needed for something else:
Knowledge
Knowledge qualifies the infrastructure, making infrastructure increasingly efficient, and permitting the construction of new types of infrastructure. Knowledge resides in people and only there - so if there are no people there is no knowledge.
[This message has been edited by Beör (edited September 25, 2000).]
[This message has been edited by Beör (edited September 25, 2000).]
.
Comment