When I first posted here it was with some suggestions to further details to the models, but since then I have realised that my major concerns are really the basic design, and particularly the OOD of the game. The game does certainly not need further attention to detail. It is my clear impression that the reason why a casual 'stranger', making a few analytical posts, can create such a havock is that the basic design is unclear.

This has spurred quite a few posts in several more or less related threads, all of them a little off topic, but nevertheless necessary IMO. This has been a process for me, as it probably has for some of you, and with hindsight it should have been posted in a thread of its own. But better late than never, so on the suggestion of Mark and F_Smith I have started this thread, where I will try to gather some of the main points, with some of the main comments. At least when I start my own thread nobody can claim that I am off topic .

quote: ]Originally posted by Beör sept 20th in the Model organisation thread The basic data structure may be in place, but it seems to me that not everybody is familiar with it ( I know I am not ). F_Smith has adopted component modeling and I couldn't agree more (from a laymans point of view). To what depth the components should be modeled is a result of what the smallest entity is that could influence game play. The entire game is really based on interactions between two distinct ressources: physical surroundings (the map with geographical ressources) and the people living there (population) guided by some rules (the models) and a context (the civ). It has been decided that the basic unit of territory is the square (there could be options for playing the game at the province-level like Risk, but the default game is square-based). Since ownership of territory is based on the square, population must also be modeled at the square level. If all people were alike, this would be the lowest level of modeling, but all people are not alike: It has been decided that people differ along ethnic boundaries so we have to track Ethnic Groups at the square level. Somewhere I saw a suggestion (probably LGJ - he's really into detail ) that people should be modelled occupying different parts of a square. If this was adopted we would have to model EGs at the square-location level! So what I am saying here - and I'm sure F_Smith will agree - is that we have two basic storage containers for the game data (one for each basic ressource): The mapsquare and the EG (= the number of people of one particular ethnicity living in a mapsquare). These are the basic game objects from which the whole game is assembled. The basic task is to decide which attributes and behaviours should apply for these objects. I suspect that F_Smith has done much of this already. But now it begins to become more complicated. At many points in the game it will be necessary to aggregate these different objects into larger objects: For map squares this is intuitive: One or more mapsquares form a province based on the players preferences. One or more provinces form a civ, the size of which is based on the players military and political actions. One or more civs form the planet (actually there might be a catch here: Barbarians - will they be rogue civs or will they have their own class and AI? Rodrigo and I discussed it briefly in the social thread). So far so good. For EGs it is apparently not so intuitive how to perform aggregation. For some time now I have been trying to draaaaaag out of Rodrigo and F_Smith how they intend to aggregate the square-based EGs into FE an EG at the province level. F_Smith suggested that EGs should be aggregated if they share a common culture object. I was not happy with this: It works fine as long as the EGs remains in the same civ, but if a square changes hands, the culture object would have to be divided in two, because the culture of an EG can change every turn, in a direction decided by who owns the square. The EGs thus no longer share a common culture object and the twain shall remain forever apart (sounded rather archaic don't you think). If a lot of squares changed hands, shortly we would not be able to aggregate any EGs because every one of them would have their own unique culture object (these objects might have very similar or even identical attributes, but since they are not shared, but separate entities, it is not possible to aggregate by them). And maybe even more important: When EGs migrate to another civ they would also have to have their shared cultural object split from the original. 'So what' I hear you say, but concider this: If we start with say 100 shared cultural objects (=100 separate flavours of ethnicity, probably too low), in a while each may be divided on average into 5-10 cultural objects (a conquest here, a migration there). We now have 500-1000 cultural objects on which to aggregate EGs. With vivid migration in theory we could have at least 50 of these represented in an average map square. 50 times 10000 land map squares is 500k square level EGs. In my opninion these estimates are very conservative. In particular the 500-1000 shared cultural objects might be low by a factor 10 later in the game. These 500-5000 k EGs might not represent a serious computational problem, but it is highly unrealistic. Some of these effects could be mitigated by the recent allowing for a minimal EG size. Small EGs would be assimilated into larger EGs, and thus they would not have a pointer to a culture object, and if this was the last pointer the cultural object would be destroyed. Nevertheless, basically migration screws things up. It is no accident that this has not been modelled in any civ-like game so far. In fact most civlike games don't even model population in individual squares! I think that the basic problem with this approach is that a cultural object is not an entity in itself, but rather an attribute of an EG (just as tech=knowledge is an attribute of an EG - right F_Smith ) I am still waiting for Rodrigos response to my latest query in the social thread, but I suspect that he will answer along one of the following lines: EGs are aggregated if they have identical cultural attributes. Every turn each EG is compared to every other EG in the province. If they have identical attrubutes they are aggregated when the need arises during this turn. This is easily done by comparing the cultural objects in a 2x2 matrix. But there are 9 cultural attributes each with 101 levels, so you theoretically you have 101^9= 1.093685272684e+18 possible values of the culture object. If a random culture object was chosen for the EG the chance of having two EGs aggregate is virtually zero. Granted, the culture of an EG is not chosen at random, it evolves gradually from a common origin, but players will tend to choose more radical cultural attributes than in real life, and I strongly suspect that in the dynamic environment of Clash very shortly there will be no two identical EGs to aggregate. From a scale-theoretical point of view the combination of 9 ordinal scales with 101 discrete classes is equivalent to a 9-dimensional continuous scale where identity is not an option. EGs are aggregated if they have similar cultural attributes. This adresses the issue that, eventhough no two cultural objects will be alike, they will certainly be similar in some ways. Every turn all EGs in the province are grouped acording to their proximity on the 9-dimensional continuous scale. This can be done using hierarchical cluster analysis, but I do not know any details of how complicated this is. Probably this would get the job done, but one possible complication is that in a large province by pure chance an EG in the far eastern part might be similar to an EG in the far western part, they would aggregate, and wouldn't that look funky. EGs are aggegated if they have the same entry in the attribute Nationality that Rodrigo included mainly for identification purposes (this is actually what I have been trying to lure him into saying all along ). The attribute Nationality is very different from all the other cultural attributes: It is measured on a nominal scale, meaning that it is really a classification system. The good thing is that there is a limited number of classes/cathegories (=the number of ethnic groups/nationalities included at game start + any we choose to create during gameplay) making it inevitable that a lot of EGs will be aggregated in each cathegory. Another good thing is that for a given EG it is constant (at least with the present definition), not subject to change as the EG changes status by migration or conquest. What Rodrigo didn't like was that I suggested replacing the txt constant Nationality with a pointer to an object with the sole attribute being a txt constant Nation (I might not have stated it this clearly at the time, primarily because I didn't have the clarity of mind I have now (regarding the game design that is )). The advantage of this would be that in the Nation class you could have methods allowing the splitting of a nation if EGs drifted apart geographically or culturally (this is not posible with the present definition of nationality). Another advantage is that we could include a dynamic array in the Nation class, pointing to every EG having this nationality, thus having easy access to all EGs pointing to the same Nation, without having to loop through all EGs to check their Nationality. The disadvantage would be that once in a while we would have to check if two nations were close enough and culturally similar enough to make it desirable to merge the two into a new nation. I never intended to have the Nation class have any independent behaviour (except from the splitting) - I mentioned (wish I hadn't - it confused the issue) the option of having meta-cultural attributes on the national level, but this is not a good idea.

And elaborated on that the following day

quote: ]Originally posted by Beör September 21st in Model Organisation thread Actually there is another thing about several of these aggregation techniques (common object, identical attributes, similar attributes) that I don't like and that I think points to a problem with the method: YOU WILL NOT KNOW WHAT TO CALL THE AGGREGATE. If you use the nationality approach you will call the aggegate 'Germans' or 'Germans in XX province' or 'Germans in YY civ'. With the other methods it will be: 'All persons that were originally German, but are now something else characterised by their cultural attributes a,b,c,d,e,f,g,h,i' or 'All persons with cultural attributes a,b,c,d,e,f,g,h,i' or 'All persons with cultural attributes close to a,b,c,d,e,f,g,h,i' Grouping by nationality will preserve the flavor, while still allowing EGs to have differing cultural attributes. The aggregates will be larger and more heterogenous, but isn't that closer to reality?

F_Smith replied:

quote: Originally posted by F_Smith September 21st in Model Organisation thread Actually, the player can easily filter/aggregate by each and every EG attribute. Since the player won't have god-like control, the only reason the player will need to know what civ-level aggregates are would be for whatever game models require. So the aggregate problem is a matter of the 'civ' level modelling, not 'square' level 'ethnic groups'.... I will have the filter available for a player to see how many people of a single ethnicity, how many people of a single culture, etc, are in their civ.

This clarified things somewhat in my mind:

quote: Originally posted by Beör September 21st in Model Organisation thread Of course, you are right. EGs can be aggregated by any of the attributes, and the player will rarely if ever have to do that. I was going of on a tangent because of the discussion I had with Rodrigo in the social thread. I guess the filter you mention will translate values on the 0-100 scale into another scale with much broader intervals (FE 0-20, 20-40. 40-60, 60-80, 80-100 or maybe even wider) which we could then give a name and use this name to describe the people to the player: '15% of your people are very agressive' or 'On average your population is moderately nationalistic'. Beneath this we would still have the actual numbers thus allowing aggregation of EGs either on the detailed scale with the disadvantages I have outlined or on the less detailed scale. The other kind of aggregation is the one performed by actions/events in the game, and here we can decide ourselves which method we find most appropriate in the circumstances.

quote: Originally posted by Beör These discussions regarding the nature of things, the proper way to model the game in OOA terms, and the level at which this should be done are proceeding in so many threads that it is almost impossible to keep track off. So since this is really a reply to F_Smiths post I will post it in this thread. If anyone feels that this or any of my other posts belong in a different thread feel free to copy them there (but please tell everbody about it).

quote: While a theoretical analysis of the real world may reveal the 'true' objects we should concern ourselves with, I think (and I know Mark has made this point earlier) that it is important that we also think OOA/D from the game perspective. There is no need to reveal complex object structures, if the effect on gameplay is negligible. Here are some question I asked myself: Who am I? I am 'controlling' an empire. This is maybe the greatest abstraction of all. I am a Being in charge of the destiny of an empire. I have everlasting life (or at least live for the longest possible duration of the scenario), and in some areas considerably more control over what is going on than my mortal reallife counterparts had historically - although I have no 'magical' properties. This longevity and limited omnipotence permits longtime planning and is actually the prime instrument in achieving better results than historical counterparts, whose aims rarely exceeded their lifetime. This is not very lifelike, but it's what makes the game fun. What do I have to work with? I have two basic kinds of ressources, that translate into all that is happening in the game: Land (handled as mapsquares), which is immobile and in practice unlimited, and people (handled as EGs), who are mobile and unlimited. Actually there's a third ressource: Time (handled as game turns), which is limited. It is a basic assumption that people given the time have an inherent capability to work the land and produce a rudimentary output. The output takes the form of units (food, production, service, specials). What is the empire? Another huge abstraction: In a way I am the empire. You might also say that the game-interface is the empire. I control the interface, thus I control the empire. The empire/interface is linked to one of the basic ressources of the game: land, (since it's immobile). By controlling land, the empire controls the people living on the land. So if people leave the territory under my control, I loose them. This translates into: If the game-interface does not have control over some land inhabited by some people, then the game is over. Only under very special cirumstances (nomadic civs) can an empire exist without land, and this obviously requires special handling. What do I aim to do in the game? Basically I want the empire to survive - the game to continue until scenario end (this is more than most historical civs have achieved). On the other hand surviving as two hunters and a gatherer in New Guinea might be easily achived, but not a very rewarding game experience. So there has to be more: Something like having a large empire with a large population. There might be other qualifiers like having a happy population, clean environment, total world dominion, immense wealth etc, but for now let's concentrate on the simple aim: I want a huge empire with lots of people. How do I improve my conditions from the starting ones? This is were all the fun is. The trick is converting the output from the people working the land into more people, more land, or increased productivity. This is basically done by creating infrastructure. Units are transformed into infrastructure, which in turn either makes it possible to get more people in the already controlled territory (increasing reproduction, decreasing mortality, increasing immigration, decreasing emmigration), extends the controlled territory (military units), or makes the people more productive (anything from a plough to a nuclear power plant and beyond). Infrastructure extends the capabilities of your empire beyond the basic rudimentary level. Is that it? Basically this could be it. Notice that not once have I mentioned tech/knowledge/research/lore or whatever terms are used. Tech is not a goal in itself, only a means to an end. And notice - contrary to what F_Smith stated - that it is infrastructure that perform tasks. Infrastructure increases land, people or productivity by converting units into some sort of bonus - knowledge doesn't. Where does tech fit in then? Tech makes it possible to differentiate infrastructure in time and space. It is a qualifier for infrastructure. It makes some infrastructure more effective than other. The people working the land has an inherent capability of transforming some of the produced output into RPs which are then converted into tech. The tech in itself does nothing, but it permits the construction of more sofisticated infrastructure, which in turn increases land, population, or productivity. You may have the knowledge, but if you don't have the necessary infrastructure it won't do you any good. So infrastructure produces, knowledge does not. Are there other distinctions between the two? Infrastructure is immobile - it is a physical thing existing in a mapsquare - it belongs to the land (mapsquare). If people leave the land, the infrastructure will still be there. They cannot take it with them. I have a small problem here with simple applications as the plough, which could probably be carried. The infrastructure model talks of mobile parts and immobile parts, but what is really done here is the disassembly of infrastructure into its origin Units, which can then be converted into infrastructure at a new location. Tech/knowledge is mobile - it is not a physical thing - it belongs to the people (EG). If people leave the land, they take their knowledge with them. Knowledge is not left on the empty land floating in thin air. Knowledge cannot be separated from the people. You can sell a copy of your knowledge, but you cannot sell the knowledge itself. Infrastructure is volatile. Infrastructure requires upkeep to counter wear and tear over the years. You have to pay a certain amount of maintenance cost. Knowledge is persistent. You do not have to maintain it. When it is - it is. I know that here I am at odds with the present tech model. When - in real life - it seems that knowledge deteriorates, IMO it is because there is no need for the associated infrastructure. As long as infrastructure associated with the tech exists, the knowledge will persist. If the last piece of related infrastructure disappears, the tech is obsolete and therefore it seems as if it has deteriorated. But I claim that if need be the tech will still be there. You might have to dig a little for it but it would be there. I do not think that it is necessary to discover the same thing twice. Infrastructure can only be produced at a cost. You have to spend Units to get infrastructure - it does not grow by itself. It does not dissipate or reproduce. Knowledge can and will frequently be achieved for free. FE by doing things, having contact with other EGs or using applications knowledge increases automatically. Knowledge can reproduce itself indefinitely, dissipating to other EGs. It is possible to spend Units on increasing knowledge, by investing in knowledge producing infrastructure, but you cannot 'purchase' new knowledge from nature. You can, however, purchase already discovered knowledge from another civ. So I guess that what I am proposing is that a mapsquare object holds one or more EG objects and one or more infrastructure objects. An EG object holds one or more knowledge objects of varying type and level. Infrastructure objects function like F_Smith suggested in 2: They take some input and produce some output. If the infrastructure is destroyed, but the EG remains in the square, it will always be possible to build the infrastructure again. Knowledge objects permits the creation of infrastructure objects: The presence of certain levels of knowledge objects of a certain type in any EG in the square will permit the creation and maintenance of certain infrastructure objects. If the EG having the permitting tech leaves the square, the infrastructure will gradually be destroyed, due to lack of maintenance. This is the clean, mapsquare view of knowledge. There is another possibility. Square-based knowledge objects could be aggregated into knowledge objects at a higher map-level, FE province or civ. How they should be aggregated is at the moment beyond me. Similarly, infrastructure objects could be aggregated at higher levels providing province- or civ-wide improvements. Again the details elude me. EGs will of course also be aggregated, I refer to my post in the Model Organisation thread .

F_Smith replied

quote: Originally posted by F_Smith september 21st in the tech model thread I almost totally agree. One thing I disagree on is the infrastructure doing the producing. I'd argue that it always (at least, until AI is developed) requires people to produce something. And they 'use' the 'infrastructure' to produce, as a 'tool'. 'Factory Workers' would use a 'factory' (along with raw materials) to produce output. The factory doesn't do that itself. The other thing I disagree on is your not seperating 'theory' from 'application'. That's why I'd have 'theory' objects that are stored in certain 'infrastructure' objects (churches, universities, govt agencies, guilds, etc). The 'theory' objects would determine in part what 'application' knowledge an ethnic group could learn. If they have access to a church that 'teaches' literacy, they could learn to read and write. There's also a matter of 'skill level' at using any of these techs. I think it's one of the most fun parts of this game to have an ethnic group who are the most skilled boat builders in the known world, and that kind of thing. Other than that, I think you've outlined the basic program data architecture for gameworld info

To which I in turn replied:

quote: Originally posted by Beör september 21st in the tech thread You are so right on your first point: People produce Infrastructure catalyzes and amplifies production and diversifies the output. Instead of just producing food, production, service, specials and RPs, infrastructure makes it possible to produce a wide range of possible outcomes: From military might to happiness, from health service to oppression etc. Knowledge qualifies infrastructure making some infrastructure more effective than other. I am not sure I understand the distinction between theory, application and skill. I see them all as knowledge objects - or at least derived from a common knowledge object. I am actually really fond of the level 1, 2 and 3 techs in the present system. What are the differences between your system and the existing system. One thing I know I don't like: A knowledge object belonging to an infrastructure object. IMO infrastructure cannot possess knowledge in any form. Knowledge is possessed by people. If knowledge belongs to infrastructure it would be tied to the land with several consequences I don't like: If the square is conquered the knowledge passes to the conqueror and is lost to the original owner. While it is true that knowledge might be conquered, I will argue that the conqueror only takes hold of a copy of the knowledge (the copy might even be imperfect, incomplete or misleading). The original knowledge will remain with the original owner. Knowledge persists. If the infrastructure object is destroyed the knowledge would vanish into thin air. There is a historical corollary in the burning of the library of Alexandria. While many priceless scrolls disappeared, I doubt if this had anything but a transient effect on society due to loss of knowledge. It was a disaster, but because of the artistic value, not the knowledge content of the burnt scrolls. Art is infrastructure and can thus perish in a fire, knowledge persists because it is with the people. If the people choose to migrate they would not be able to take the knowledge with them. Need I repeat myself ? Your example of a church teaching literacy is IMHO nonsense . Just as a factory cannot produce anything, a church cannot teach anything. People produce - in this case the clergy produce knowledge - catalyzed by the church. The clergy possess 'literacy' and the clergy are part of the people. I know/guess that what you want is a kind of civ level maximal tech level that limits the levels of more practically oriented derived techs. In a way this is similar to the 'Ideal' and 'Actual' tech levels mentioned by Richard I guess (I have tryed to find info on this without success). But making a separate object is not the way to go. As with our other base objects this should be achieved by aggregating the tech objects of the EGs in the civ. Don't ask me how yet - I haven't figured it out

F_Smith

quote: Originally posted by F_Smith september 21st in tech thread I would agree, both might extend an abstract 'technology' object. But that is actually a plus. I basically took their system and did an OO analysis on it, which is why it looks so similar. By breaking the monolithic tree into the two 'theory' and 'application' objects, and combining them with 'infrastructure' objects, I am able to reproduce the tech system they want, and more. As far as 'infrastructure' objects 'owning/storing' tech 'theory', here I'm talking about written or stored knowledge. Books in a church library, for instance. Knowledge in a teacher's/priest's head. Knowledge in a plant manager's head, operating procedures for a factory, Etc. As in the Library at Alexandria, yes? Certainly you'd agree that the library should 'store' or 'hold' book knowlege (theory objects), yes?

I wasn't satisfied then - as I'm not satisfied now

quote: Originally posted by Beör September 21st in tech thread I still strongly disagree with having infrastructure objects possess knowledge objects. Yes, libraries contain many books, but they are only digested, organised reference to something that is inside a persons head. The books are infrastructure, not knowledge. If the books disappear, the knowledge remains either as other copies of the same books or inside the head of people, on microfilm, on CD or in songs and tales. The knowledge inside a preachers head - well there's knowledge, but a preacher is not infrastructure, he's a person. He's part of the religious class, remember. The preacher is not part of the church object, neither is a teacher part of a university object. If the church/university is destroyed, the preacher/teacher will still exist. Same goes for the planter. Just as knowledge objects cannot belong to an infrastructure object, neither can people: They are separate entities with independent existence. Operating procedures in a factory is part of the infrastructure. They do not become knowledge unless they are in such general terms, that they apply to other similar facilities, in which case they would not belong to a single piece of infrastructure, but be a part of general human knowledge. The fact that knowledge could be destroyed or conquered along with the infrastructure or the square is very counterintuitive to me. The loss of the library of Alexandria was a catastrophy - because of the loss of art (infrastructure), not because of the loss of knowledge. Let me turn it around: In gameterms, what do you aim to gain by having knowledge objects belong to infrastructure? What is the purpose?

F_Smith giving reasons for doing it his way

quote: Originally posted by F_Smith September 21st in tech thread This could be one way the player affects/runs his civ thru govt decisions. If 'infrastructure' objects hold 'theory' objects, then the player can help his people's production levels along thru building and maintaining several 'infrastructure' objects. Building a church somewhere to teach the locals things -- like the Spanish missions in the Americas were suppose to teach reading, writing, Spanish, etc, to the native Americans. And it's scalable. The player could fund different types of schools. Basic schools can teach literacy, art, science. If the player gains access to a 'sextant' theory (a book, say, on how to build a sextant), he can build a 'navigation' school to store and teach that to the people, increasing their navigation 'knowledge' objects. Building factories could work in the same way. ... I would actually say that the preachers of a church are part of that 'church' infrastructure object. And the teachers are part of that 'school' object. We're not modelling those in particular, anywhere else, so there's no overlap. Altho we could track them as 'characters' -- but that's getting a little too detailed, I should think. P.S. -- do you mean to imply that the loss of the knowledge of Alexandria wasn't a significant tech loss at the time? I thought that there are books that were lost that we still don't have copies of . . . but I'm not much of an expert on the subject, so I'm not sure.

Richard commented

quote: Originally posted by Richard September 21st in tech thread - excerpts Infrastructure should not store tech. Technology as we defined it is not a physical thing tied to the ground. It is an innate characteristic of the people in your civ. That may seem silly, but I think it works as an abstraction. So the burning of a library would have no effect on the tech level. If the stuff in the library was common knowledge, nothing is lost. If the stuff in the library is not known or used by anyone in the civ, then it was not part of the tech level to begin with and nothing is lost. Knowledge is volatile, however. If it is not used to do anything and is not taught to the next generation, it will be lost. If nobody is using that knowledge to do anything, no RP's will be generated and the tech level will fall. This simulates the loss of knowledge as people see no reason to keep it. People produce things using infrastructure and tech(theory, knowledge, and skill). Tech will define the efficiency of the production process and the quality of the final product. It also defines what infrastructure you are allowed to build. Important Note: When the tech tree was designed, Clash had not fully adopted the no-buildings approach. So applications (Tier 4) were to include things like libraries, factories, and churches. These applications would play a big part in determining what was in the infrastructure. But we no longer have these buildings. Their place was to be taken by the actual tech level A. Basically, A was the abstraction of the technology that manifested itself as physical objects. It increased only if there was investment into the province infrastructure. It amalgamated and abstracted those Tier 4 buildings.

Well, some infrastructure will be represented as objects. See what Mark writes in the Infrastructure thread (this is out of sequence, but fits in here):

quote: Originally posted by Mark september 23rd in Infrastructure thread ... One other thing... You mention about military units being handled as infrastructure. And that this necessitates livening up the "dry" infrastructure version of the military units to the given flavors such as x units of cavalry, Y of infantry. This is not what I intended. Military units can probably be built with the general preferences set up, but should Always be built as specific units IMO. This requires the military unit "infrastructure" class (if we do it that way) to be a bit different from the others. Essentially, you would enter in a queue of units that you desire to be built (or the AI will) and when the cost of the unit has been paid, the particular unit that is at the top of the queue comes into existence. That is the way I envision it. Whether we should handle this as an infrastructure class at all, is a topic I/we need to think about.

I am still in doubt how much infrastructure will actually be present as real objects, and how much will be abstracted as Infraclasses, tech level A or whatever you call it.

quote: Originally posted by F_Smith september 22nd in tech thread I am also curious what effect on gameplay this 'no buildings' approach will have. I do *not* like that the infrastructure is not tied to a location. That will hamper the 'wargame' part of this game tremendously, won't it? What happens during the square-by-square conquest of a civ? Do they keep all infrastructure until the end? I'm really turned off by the highly abstract approach to this game, making it more like 'Risk', less 'real'. I was under the impression that the game was going to excel as a game with more detail than any other, as long as the detail aided gameplay. With AI to allow the player to play an 'abstract' version, where they didn't deal with the details they weren't interested in. But the details have to be *there*, underneath, for those that like playing with them (or just enjoy the game more knowing there's a realistic model underneath).

There might be a serious disagreement here!
But it seems to have been defused by Mark:

quote: Posted by Mark september 22nd in tech thread Right now Laurent and I are trying first the mapsquare-based econ model. (simpler to code, will put in a switch to aggregate at prov level later) That has infra on a mapsquare level. Even for the province-based system we were going to (and have always planned) crudely keep track of infra on a square level. Where are you getting your info from? And while I'm here, the 'infrastructure' objects hold 'theory' objects seems arbitrary and has nothing to do with the real world objects you are always so ardently championing. I am with Beör and Richard in this argument. At least I can understand your previous assertion of associating all techs with people... Infra does help tech thru education and research institutions, but those, in the current system, Contribute to the people's (or civ's) tech level, they don't 'contain' the tech. If all the people were dead all the infra in the world doesn't help you with tech.

And F_Smith replies (while discussing with Richard how clear the OOD has been posted previously)

quote: Originally posted by F_Smith September 22nd I'm sorry, I must have misunderstood the use of the term 'no buildings'. My mistake. Arbitrary? Nothing to do with real world objects? Again I don't get this communication problem. The analysis seems so clear to me. Like the Ethnic Group stuff. I should think the example of a Library like the one at Alexandria would illustrate the point perfectly. Universities, too. The monastaries in the 'dark' ages 'stored' civilized knowledge. Spanish Missions in the new world. How many times in 'Star Trek' do they come across a store of alien knowledge in some computer, in some long-lost city on Beta Centauri (or wherever)? 'Technology' is 'knowledge'. 'Knowledge' can be 'stored' in a variety of ways -- books, operating procedures, experienced staff. 'Knowledge' can also be used by people. This OO analysis delivers exactly that. Are you of the opinion that books don't store knowledge/technology? Man, we just are *not* on the same page here. How can I explain myself better? What am I doing wrong?

And on it goes.
Now, hear Richard

quote: Originally posted by Richard September 22nd in tech thread The tech level of a society has absolutely nothing to do with some forgotten and unused tome molding away in the back of a building somewhere. People, not buildings, are the things that store technology. Technology is the theory, knowledge, and skills that allow the people to do things. They are a part of the society and civilization. Monastaries, libraries, and universities do not store knowledge. People store knowledge.

Mark clarifies

quote: Originally posted by Mark September 22nd in tech thread As I see it, the major thing we've been discussing is the object that holds tech. (Putting aside this infra idea for the moment) F_Smith wants tech to be at the EG level, Richard (and me too) at the civ level, or at most province level. By putting an overall tech object pointer at the EG level we can have Both solutions. For the EG level model this means each EG has its own unique Tech object which does all the complex things F_Smith wants (and Enormous computational and other baggage IMO, but that is another discussion). Simply by having a checkbox that says 'Tech at civ level' you can instead have Every EG in the civ have its tech object pointer point to The Same 'civ' tech object. Then you would sum over what RPs are being produced in the civ could be applied once to the overall 'civ' tech. When that tech object changes all the EGs tech pointers point to the new modified object and things are basically the same as if there only Were one tech object, associated with the civ.

F_Smith

quote: Originally posted by F_Smith September 22nd in tech thread, edited ever so slightly (hope you don't mind) Thank you, Mark: Exactly so. You've summed it up perfectly. Richard: I understand you have not defined things this way. But step back for a moment, and consider -- can you see why I would say that a library 'stores' technical knowledge? That is a 'true' statement, agreed? Whether or not it fits your system, isn't that an accurate analysis? And you should worry that your system is causing you to make statements that are inaccurate, outside of your system. ... Do you really feel that in real life libraries do not store knowledge? This sounds amazingly off-base. That analysis you posted is an OO analysis. That's how we should be discussing this -- comparing and critiquing the analysis each other have made. So I would simply refine the OO analysis you posted -- You break 'technology' down into 'theory' and 'knowledge' in your definition (skill, I would argue, is a variable associated with a 'knowledge'). So those need to be two seperate objects, for coding purposes. Agreed? I would agree that tech is a characteristic of people. Since the game has to store people at the mapsquare level, that means the tech has to be stored at that level (per EG, per square). As you point out. A civ is more than just that, but it is also a collection of people. I agree. But since people must be in a mapsquare, and a civ is a collection of people, then tech must be stored in an eg (in a mapsquare). That is what your own analysis just proved. It looks like you didn't arrive at this from your analysis of your above points -- you started and ended with this assumption without thinking thru your analysis. Tech can not be stored at the civ level. It can be aggregated at the civ level, for you model's purposes, so your game model can play that way (altho I think there are better options available). But it can not be stored there.

Richard

quote: Originally posted by Richard September 22nd in tech thread, slightly edited Libraries are an intermediate step in the transfer of knowledge from person to person. They store information, not knowledge. That is an important distinction. Knowledge is what a person uses to do something. Information is a collection of facts. I'm sorry that I wasn't very clear. There are several definitions of "knowledge." I should have said at first which one I was using. Here it is: 1) the fact or condition of knowing something with familiarity gained through experience or association 2) acquaintance with or understanding of a science, art, or technique Based on that definition, knowledge simply cannot exist outside of a human head. What libraries do is to store information and use that information to pass knowledge from one person to another. Information is not modeled explicitly because it does not do anything; things only happen when humans with tech (theory, knowledge, and skills) take action of some kind. Technology is the ability to do things. Information stored in libraries does not do anything. People do things. Libraries are a tool used to pass knowledge from one person to another. Thus, the role of libraries is to affect tech decay and communication. Tech should be stored in people, not libraries.

I think this is a very acurate description, with which I almost totally agree

And it goes on and on and on and on.

F_Smith insists on keeping Theory objects in infrastructure objects. But somewhere in all this there is an opening that I don't think anybody else spotted:

quote: Originally posted by F_Smith september 23rd in tech thread Just to reiterate, for your amusement: The 'tech system' will not belong to the 'civ' object. The 'civ' will hold 'provinces'. The 'provinces' will hold mapsquares. The mapsquares will hold EGs. The EGs will hold knowledge. Either the civ will hold a collection of 'theory' objects or the infrastructure objects in that civ will hold 'theory' objects. You will be able to define two different levels of 'theory' -- 'General Theory' (your level 1 tech) and 'Theories in a Specific Field of Knowledge' (your level 2 techs). You will be able to define any number of levels of 'knowledge' (your level 3 techs) objects -- and don't worry, we'll start with just one.

Did you notice it:

Either the civ will hold a collection of 'theory' objects or the infrastructure objects in that civ will hold 'theory' objects

But F-Smith why didn't you say so before. Theory objects don't need to be stored in infrastructure, they can be stored at the civ level, which is an entirely different concept.

This is much more like the original idea of the tech system where there is a civ level amalgamation of knowledge. The next step would then be to consider how this civ level tech level is derived.

In my opinion it should be a function of the tech level of each and every EG in the civ. But I imagine that some would claim that the civ level tech should be something more than just the sum of all available knowledge. They would like to see Universities and Cathedrals producing knowledge that is far beyond the grasp of the ordinary population. This is realistic, and in my opinion can be achieved seemlessly using the tagged RP approach. We should just equip a university with the ability to transform output into RPs tagged for theory development, and we would have our specialised infrastructure objects. The people living in these squares would have far superior theoretical knowledge, and would pass it on to the civ level tech level. Likewise, people at the cost could produce RPs tagged for shipbuilding and would become extraordinarily skilled shipbuilders. A skill that would also be passed to the civ level.
What we should use the civ level tech level for is then open for discussion.

I will post these same observations in the tech thread, but keep them here as well as they illustrate important points in how we see the object structure.

quote: Originally posted by Beör September 23rd in tech thread I thought about my last couple of posts some more and found several inconsistensies that points to a faulty object model. This lead to some rather surprising conclusions, that I would like to share with you here. They might be totally wrong, and definitely somewhat OT, concerning the economic model, the infrastructure model, the tech model, the population model and the general OOD, but since they are related to the discussion in this thread I will keep it here for the moment. First, I assumed that infrastructure cannot hold people and is immobile. And almost in the same sentence I mentioned a type of infrastructure that must hold people and can move: Military units. I suddenly remembered seeing somewhere that military units would absorb some people when being created, they could loose people during combat and if put on reserve or disbanded the people contained would return to civilian life. It is obvious that military units are mobile containers of population. The more population, up to a certain limit, the stronger the military unit (military strength of the unit must of course also be based on some hardware, but lets put that aside for the moment). Since the unit of population is the EG a military unit must contain EGs. Actually I had pictured military units as 'moving mapsquares with military capacity' thus being able to hold people. Next I took this reasoning further: Since some infrastructure objects obviously can hold EGs it is reasonable to consider if not all EGs in fact should reside in infrastrucuture objects of which the military unit is just a special mobile case. The next thing that struck my mind as odd was the fact that I assumed that people have an inherent capacity of turning ressources into output. Such 'semi-magical' powers are suspect. Elsewhere in the model it is infrastructure that has this ability of transforming some ressource into another - in the presence of people. In fact I had given EGs some infrastructure properties. A thought that had previously crossed my mind suddenly surfaced. I actually also mentioned it as an exception in the post mentioned: Nomadic civs or migrating civs. They are exceptions since they have no land, and yet they have to produce output or they could not sustain themselves - how should this be done? Having no land they are in fact invisible to the civ/interface construction I proposed which is based on possession of land. Again I had this feeling: If they were in fact 'moving mapsquares' they could both produce, have population and be visible to the civ/interface. A further thing that had bothered me earlier also popped up: When I read the economic model the concept of sites seemed very abstract. I couldn't put a finger on it, it just seemed wrong: In nature there are no sites, there are ressources. The finite number of food and production sites are limitations in terms of how much of these ressources man is capable of 'harvesting': How much land is farmed, how many mines exist etc. Sites are more like infrastructure: a way of converting basic ressources into units. There should be two means of increasing production from a square: Increasing the output of individual sites (the improvement of sites as covered in the present economic model), and increasing the number of sites (farming new land, discovering and developing new mineral deposits etc). And finally I had been worried by the lack of cities, which didn't seem to be modelled very well. And a solution matured in my mind (I actually woke up in the night - it was almost like Descartes ). You may like it and you may not, since it will influence many models. It is primarily a programming term, and would probably never come to the attention of the player. It might even be very difficult to implement, but here goes: Imagine splitting the mapsquare into two layers: First the basic mapsquare: the geosquare that keeps the square in place geographically, and holds the basic ressources: terrain, farm land, forrests, specials etc. This would in fact represent the maximum possible yield of the land. You could still express this as sites, but these sites would represent the maximum possible number of sites that could be constructed in the square, given all technology. On top of this basic mapsquare we could place a very basic infrastructure object: I have called it a Habitat in lack of a better name. The Habitat would hold the population and a number of sites representing how much of the basic ressources are actually developed - this number of sites is equivalent to the number of sites now present in the economic model. Sites might then be separate infrastructure objects held by the habitat. They could be built as every other infrastructure object upto the limit of the underlying mapsquare, provided the proper tech requisites were met, FE if an EG reaches a tech level that would allow for irrigation or use of certain minerals (FE uranium) it would be possible to build more sites, representing the plowing of new land or the opening of a uranium mine). I don't mean that we should have 'uranium sites', they would still be represented as production sites, but acheiving a certain tech level would raise the proportion of potentially utilised sites, abstractly representing the mining of uranium/titanium/whatever. The habitat might even be capable of holding other infrastructure objects, although these might be better placed in the geosquare. This way the present mapsquare object will be represented by one geosquare object and one habitat object. The combination will be indestinguishable from the original concept. The only extra thing is the possibility to build new sites up to a maximum provided by the underlying geosquare, but this could be left out - at least for starters. 'Well, so what' I hear you say. Here it comes: A military unit is nothing but a mobile habitat! A mobile infrastructure object, holding people and a limited number of sites, representing the ability of the military unit to live off the land (of course the influence of this on other inhabitants of the underlying square would have to be decided). A further capability of a military unit infrastructure object is to transform the people present into military power. Similar a nomadic civ is nothing but a collection of mobile habitats. Instead of having the empire consist of a collection of mapsquares it would consist of a collection of habitats, thus allowing the interface to 'see' nomadic civs, despite the lack of controlled mapsquares. By making sites infrastructure, we avoid having EGs have inherent production capabilities, which streamlines the object model. The only object producing is an infrastructure object: For historical scenarios people would have to be present, but for SF-scenarios, fully automised, robtic assembly plants or mining constructions would be possible. Military units, being infrastructure object are no exception, allowing for cruise misiles and the like. Other infrastructure objects could be seen as mobile or semimobile habitats: Particularly oceanic ressource collection could benefit from this: A fishing fleet would carry with it its own food sites (how do you like that Mark?), and likewise Oil rigs would carry production sites. The habitats wouldn't even have to be placed on the map, but could be abstractly off map, like orbital production facilities or mining stations on the moon! Now it is getting really wild: You could imagine the same square having more than one habitat (akin to locations mentioned earlier). I am particularly thinking of having one rural and one urban habitat. The urban habitat could be constructed, representing the founding of a city. We would then have a way of modelling people moving from rural areas to urban areas. The city could have its own particular mix of sites, EGs, infrastructure objects etc. The implications are astounding! All this derived from one object!

F_Smith

quote: Originally posted by F_Smith September 23rd in tech thread Hmmm. I'm not sure I agree with that analysis. I was of a mind that a 'military unit' would just be another type of 'group'. Perhaps 'ethnic group', 'military unit' and any other 'mobile' groups of people would simply extend a basic 'pop group' object, or something like that. I wasn't aware that there will be no cities -- is this true? That's not good, I can't agree with that if that's the case. What kind of a wargame will that leave us with? Besides, I think Mark already told me that some infrastructure would be tied to mapsquares. This is all why the basic architecture has to be done before we go any farther. The 'map' object hierarchy must be done *first*. Then the 'population' object hierarchy will have to be designed. I would love to begin doing a basic OO on the map stuff, if you're up for it. In another thread, I should think?

quote: Originally posted by Richard September 23rd in tech thread You are much more inventive and clever than I ever was, and will do a much better job of helping build the game. The Habitat proposal is brilliant.

It's mainly people that hold knowledge (techs), but any application of a given tech has *some* knowledge in it also. In engineering, there's a term called "de-engineering" (I hope I translated that well). It means you pick something (like a car) and you dismantle it to see how it works. Doing that you can actually learn from the application. You can get part of the knowledge involved in it as if someone was teaching you about it. This is common practice in developing countries using goods from the 1st world.

Freak Catastrophic Event 1: All people involved in car manufacturing die suddenly. Do the rest of us have to start all over again? No. We can do a lot of de-engineering and in a very short time *learn* from our cars because these machines "contain" in a way the knowledge itself. To be precise, the infrastructure contains the potential for someone to learn something.

If you think about it, infrastructure is just a type of "book". You can learn from it. Books, videotapes, machines, factories, etc are all sources for people to learn new things. If all these items were built with a superior tech than the one the current people manages, then the items become a way to expand people's knowledge. Knowledge can be obtained direclty from the infastructure.

Knowledge isn't contained entirely by people.

Freak Catastrophic Event 2: All infrastructure (including books) are destroyed in an instant. Is knowledge lost? Absolutly! All people in the world for a simple human physical restraint don't hold all the info and knowledge there is. People would start to back up what they have in their minds and they'll find a lot is still missing. They, FE, won't be able to reproduce ALL scientific conclusions from thousands of investigations.

Little time, but wanted to throw this in --

Freak 3 -- All people die. Like the sect that left behind the dead sea scrolls. Your knowledge can live on, in scrolls and books. People find it later, and learn from it.

Freak 4 -- The Greek civ is wiped out by the eruption of Thera, causing the Greek dark ages. Centuries later, translations of books written by Greek minds are discovered in Arab libraries, sparking a 'Renaisance' in Europe.

Freak 5 -- The Chinese civ has become very rich making and selling a new cloth called 'silk'. They guard this information very closely, considering it a 'national secret'. You send an army to raid the trading town just across the border, taking away from their 'silk grower' guild books on how to grow, harvest and weave the precious 'silk', and perhaps even capture the guild master.

Freak 6 -- The Vikings raid your 'Frankish' civ, destroying the lowlands and wiping out 'literacy' everywhere they can reach. But the 'Monasteries' in the highlands preservered 'literacy', and you as king can rely on these monks to provide 'literacy' and rebuild your empire.

Freak 7 -- An asteroid smashes into the planet, wiping out life as we know it. Capt. Kirk and Spock come across your buried cities centuries later, and after Kirk kisses some hot, green-skinned space alien chick they learn tremendous things from your databanks (how many episodes there were like this, I can't keep track!).

I can think of a million more, too.

Books store knowledge. This seems like an obvious statement.

If all the programmers in the world were killed instantly, written knowledge would greatly ease the re-aquisition of programming knowledge.

I admit there is something in books

In all your examples the 'thing' in books only turns into knowledge when it is 'discovered' or 'brought back' to life by humans. There has to be an interaction with humans otherwise the information contained turns into enthropy - disorder. There is a lot of information in linear-A writings of the minoan civilisation you mentioned. But we cannot read it, so its meaningless giberish - not knowledge! There has to be a meaningful interface, a lookingglass or a filter. Call it what you want, what's in books is not knowledge to my understanding - its information: Bits if you want. Its like a harddisk full of bits, but without an OS to interpret the stuff.

Agreed, the information must be in readable format. But I think we've proven that given sufficient time, we'll decipher just about anything!

Thanks for going to all the work to put this stuff here. I think it makes a lot more sense, and will have better longevity in this format.

All:

Here is my first stab at responding to be Beör's monster post. I have binned my response in different areas so that I can later chop this up and also put my comments in the correct threads. When I quote something it should be understood that it is a comment of Beör's unless it has someone else's name in front of it. I am going to try and be brief, because otherwise my comments could run on forever

SOCIAL:

quote: It has been decided that people differ along ethnic boundaries so we have to track Ethnic Groups at the square level.

I hope I am not misunderstanding your English again... if so I apologize but...

Actually, that is not the case at all! The Data Storage for ethnic groups is done at the square level. This says Nothing about what the standard game models support.

Hopefully you just misunderstood this distinction because you are new to the group, and also the discussions about this had not been very precise, and with many misunderstandings. This was true even for people who have been around a long time, like me .

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. F. Smith has plans for how to handle things in terms of the interface etc. down to this level, because the ultimate in flexibility is something he considers important. (And I do support that In the Code) However, I think it is counterproductive to discuss this at length as if it were part of the basic system. And discussion of these alternative systems should really take place in threads dedicated to the specific alternative system. Otherwise things will get really confusing. Now, some of the issues you speak about still come up for civs with far spread geography, etc. We should continue to talk about those things since they are in the base system.

Rodrigo, F. Smith, Axi, please tell me if I'm wrong...

quote: EGs are aggegated if they have the same entry in the attribute Nationality that Rodrigo included mainly for identification purposes The advantage of this would be that in the Nation class you could have methods allowing the splitting of a nation if EGs drifted apart geographically or culturally (this is not posible with the present definition of nationality).

Yes, clearly we need rules to support this. I think it's a pretty important thing, although perhaps not a core issue right at this instant.

OVERALL GAME:

quote: Who am I? I am 'controlling' an empire. This is maybe the greatest abstraction of all. I am a Being in charge of the destiny of an empire.

This is my view also. Although different people in the project have differing opinions on this. There was significant discussion about exactly who the player is in a thread called Who is the player and what is the player controlling?
a month or two ago. I'd like to hear your thoughts on this discussion . Since it is so fundamental, we should try to come to an agreement on this issue fairly soon!

quote: Nomadic civs or migrating civs. They are exceptions since they have no land, and yet they have to produce output or they could not sustain themselves - how should this be done? Having no land they are in fact invisible to the civ/interface construction I proposed which is based on possession of land.

quote: Here it comes: A military unit is nothing but a mobile habitat! F_Smith: I was of a mind that a 'military unit' would just be another type of 'group'. Perhaps 'ethnic group', 'military unit' and any other 'mobile' groups of people would simply extend a basic 'pop group' object, or something like that.

I am pretty much with F. Smith on this one.

TECH:

quote: Knowledge is persistent. You do not have to maintain it.

Well in fact, knowledge levels have declined many times in the history of the world. I believe that even though an aqueduct exists, the people may have lost the ability to make a new one, and so I would consider the tech level responsible for creating an aqueduct to have been lost before the last aqueduct disappears. I think the Tech model does a reasonable job on handling this. Although the details aren't quite there yet.

quote: If the square is conquered the knowledge passes to the conqueror and is lost to the original owner.

I disagree with this statement. If the conquerors are not receptive to the knowledge that people have, or simply slaughter them, that tech should never be transferred to the conqueror. I think it is better to handle this similar to Tech transfer, as an acquisition of RPs that is weighted bicultural and other factors just as intact diffusion.

quote: Richard: Important Note: When the tech tree was designed, Clash had not fully adopted the no-buildings approach. So applications (Tier 4) were to include things like libraries, factories, and churches. These applications would play a big part in determining what was in the infrastructure. But we no longer have these buildings. Their place was to be taken by the actual tech level A. Basically, A was the abstraction of the technology that manifested itself as physical objects. It increased only if there was investment into the province infrastructure. It amalgamated and abstracted those Tier 4 buildings.

Richard, I don't know where you got this from, but Clash has been no-buildings from the beginning. You probably got these ideas because of a miscommunication on my part or from someone else.

quote: Theory objects don't need to be stored in infrastructure, they can be stored at the civ level, which is an entirely different concept. This is much more like the original idea of the tech system where there is a civ level amalgamation of knowledge. The next step would then be to consider how this civ level tech level is derived.

This is the result I am more comfortable with also.

ECONOMY:

quote: F_Smith: One thing I disagree on is the infrastructure doing the producing. I'd argue that it always (at least, until AI is developed) requires people to produce something. I would actually say that the preachers of a church are part of that 'church' infrastructure object. And the teachers are part of that 'school' object. We're not modelling those in particular, anywhere else, so there's no overlap.

Actually, many of the infrastructure classes already have the contributions of people working in them handled implicitly. When you put services into an infrastructure class, for instance schools (educational infrastructure), that represents the teachers doing the teaching. It is a bit abstract, but I think it works quite well. However if you stop investing in educational infrastructure (no teachers) then the education level will decay as those who were previously educated in the general population forget what they have learned or die.

quote: There should be two means of increasing production from a square: Increasing the output of individual sites (the improvement of sites as covered in the present economic model), and increasing the number of sites (farming new land, discovering and developing new mineral deposits etc). Imagine splitting the mapsquare into two layers: First the basic mapsquare: the geosquare that keeps the square in place geographically, and holds the basic ressources: terrain, farm land, forrests, specials etc. This would in fact represent the maximum possible yield of the land. You could still express this as sites, but these sites would represent the maximum possible number of sites that could be constructed in the square, given all technology. On top of this basic mapsquare we could place a very basic infrastructure object: I have called it a Habitat in lack of a better name. ...but acheiving a certain tech level would raise the proportion of potentially utilised sites

I agree completely, and this is already in the plan. And works basically the way you have proposed it. I haven't had time to dig for this, but I know that either in one of the Econ threads, or the ecology thread, we have discussed that technology and things like cutting down forests etc. can change the numbers of sites available for economic activity.

quote: By making sites infrastructure, we avoid having EGs have inherent production capabilities

Population does not have inherent production capabilities... they also require capital, and sometimes economic sites. Am I misunderstanding you here? Perhaps you're saying something more refined that I just don't get.

quote: A fishing fleet would carry with it its own food sites (how do you like that Mark?)

Sorry Beör, I don't like that all... I think the fishing fleet needs to go where the fish are, which should be associated with map squares. Right now I envision treating fish as a special of the sort described in the Econ model.

quote: Now it is getting really wild: You could imagine the same square having more than one habitat (akin to locations mentioned earlier). I am particularly thinking of having one rural and one urban habitat. The urban habitat could be constructed, representing the founding of a city. We would then have a way of modelling people moving from rural areas to urban areas. The city could have its own particular mix of sites, EGs, infrastructure objects etc.

1) Nomads do not invest in fixed (immobile) infrastructure.

2) The nomad EG has mobility. Wow, what a statement. I'm brilliant! What I mean is we don't have to treat nomads as a special military unit, but have to give all EG's a "mobility" or "nomadic" level.

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.

I think it is a very good idea for military units to be a special case of an infrastructure type Habitat object. That way, they could inherit any characteristics of that object and thus could be more versatile and capable. For example, consider combat engineers. If military units are a seperate object, we have to write seperate rules and procedures for what they can do.

But with this proposal, all we have to do is enable certain bits of infrastructure code contained in the Habitat class. We can easily give them the ability to build fortifications, encampments, canals, and bridges by simply using the code already contained in the Habitat object. And since the interface and methods are exactly the same as a normal infrastructure object, the player will know exactly how to use these abilities.

I really think we would be missing a great opportunity if task forces were just a type of population. This allows them to do much more, and the things they can do are the things that would already have to be programmed.

I think I know what Beör is saying about fishing fleets having sites. It works just like the farming sites. If the terrain had a potential of 50 sites and your Habitat has 20 sites, you get 20 sites worth of food. You have the ability to exploit 20 of the 50 terrain sites. To expand the number of habitat sites, you must develop the infrastructure or get higher technology. As you do this, you get the ability to exploit more of the potential terrain sites. But you could never exploit beyond the number of terrain sites.

The "sites" in a fishing fleet are actually the fleet's ability to exploit the natural sites. It is a combination of tech (fishing techniques) and infrastructure (fleet size). So if the ocean square had 20 fishing sites and the fleet had 5 fishing sites, you would get to exploit 5 of the 20 natural sites. You could exploit more sites by increasing tech and infrastructure. But if the ocean only had three natural sites, you would never get to exploit more than those three sites.

Once again, Beör's plan shows its brilliance. The code for dealing with farming is exactly the same as the code dealing with fishing. I can say with certainty that this would solve a lot of problems with the Ecology model.

And not only that, it allows for easy implementation of underwater colonies or any kind of infrastructure in the ocean. The Habitat object that started with a simple fishing fleet can easily turn on other features like oil drilling and housing for people. We just have the technology model define when these can be turned on and how much it will cost. The resource sites on the ocean terrain square that were previously locked away can then be accessed.

I also believe that this would be a very good way to model nomads. Since the potential for military and industrial stuff is already in that one object, it is easy for nomads to change their ways. They have all that functionality available to them, so they could easily switch from rampaging hordes of fighters to peaceful merchants carrying and trading mobile infracless wealth. They have far more flexibility than they would if they were just an EG or a type of military unit.

There are a few things I notice about the proposal as a whole. First, habitat objects will have to have the ability to split up and reform seamlessly. For example, a Capital habitat gathers resources from the other province mapsquare habitats, and then splits itself and forms a task force habitat object. This task force then moves elsewhere. In the process of campaigning, it takes resources from the land and adds fortifications to itself. But then the object must split up as one part moves and leaves the fortification behind. Another task force can then come and join with the fortification habitat. That TF can then build up the fort or strip it of anything useful and move on.

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

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: Originally posted by Rodrigo September 24th in this thread 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.

quote: 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?

This Habitat system easily allows military units to sack and carry any infraclass object. Then, when they come home and recombine with their civ's habitat objects, thet plunder/infrastructure goes back to the home civ. That is the beauty of the system.

I think it would seriously hurt the system if infrastructure is put in the geosquare rather than the habitat. For example, consider what the Russians did when the Garmans advanced in WW2. They loaded their factories into trains and moved them east. That can easily be modeled if factories are in the habitats, but it would be hard to do if they are a part of the mapsquare.

I think that the only infrastructure that should be put on geosquares should be stuff that is a part of the land and absolutely cannot be moved. That would be things like dams, dikes, irrigation, terracing, and fertilization. But the habitats would contain all the functionality for creating those things. This would allow combat engineers to do fun things like build dams and divert rivers.

Sorry for misstating myself. I should have said:

All people and man-made objects should be a habitat object or a part of a habitat object.

quote: 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).

The data are Not stored at the MapSquare level in the sense I think you mean. What is at the MapSquare level in the code architecture is a "pointer" to the data characteristics of each EG. You should read my item 3.in my first post in the thread Overall Project Issues -- A Proposal for how to Proceed
. That part describes pointers and how they relate to data storage. But what you need to know here is that pointers can be a many-to-one connection such that many pointers can all indicate the same data object. So in this case even though the pointers are at the square ethnic group level, if all the pointers indicated data object that represents an average characteristic at a province or civ level, no aggregation needs to be done, except in rare cases.

Beör & (to some extent) Richard:

On habitats...

So IMO i'm not saying anything about the code. I think this is a game design issue.

The 'habitat' idea is interesting, but I don't see what it's purpose is. All that functionality is in the existing architecture, and it's more simple and direct.

An EG object doesn't in any way need a 'wrapper'. They are mobile, period. People can move. In fact, that's just one of the many reasons to model individual, square-level EGs. We can move individual EG objects from square to square without any added code.

And the 'terrain' info should be stored in a 'terrain' object, shouldn't it? An 'ocean' mapsquare differs from a 'mountain' mapsquare only in it's 'terrain'. That way, later, we can have people living in/farming, etc, the ocean squares. It's more scalable.

I still don't agree about 'infrastructure' doing the producing, either. People have to be able to produce on their own, without infrastructure. People have to be able to take a stick and scratch out a living from virgin land. A factory is a 'tool' that can increase their output. So an 'EG' must produce output by combining 'tools' (either/both infrastructure and mobile tools) with 'raw materials'.

Also, is it possible to make infrastructure that acts like a military unit? Could a scenario designer make an "automated war factory" unit that moves and fights like a military TF and then uses internal factories to make new units and weapons from the terrain resources and the remains of the enemy?

Can we make sure that doing things on the ocean works the same way as doing those things on land?

First, to answer your post in the other thread --

Infrastructure is not 'tied' to a mapsquare, altho it does get stored in a mapsquare (with the option to only view those at the 'province' or 'civ' level).

Infrastructure objects can be moved from one square to another, as can EGs. Altho the infrastructure object will need a 'mobility' variable, because some infrastructure objects can move themselves (Mobile Army Surgical Hosptial), others can only be moved (a factory) and others can't realistically be moved at all (aqueduct).

Okay, now to answer the above post --

Military units and EGs will have to have 'carrying capacities'. This will be required for tools (farm implements, weapons, etc). This will be affected by the tools, in many cases (trucks will add carrying capacity, for example).

As far as 'altering terrain', that's why I say that pop groups must be able to 'produce'. If you mean 'cut down trees', yes. The pop group (military or EG) will need a 'tree cutting' knowledge object. This object will require two inputs ('tool' -- like an axe, and the 'terrain' object where the trees will be cut down).

Yes, an 'automated war factory' would require an 'Artificial Intelligence' object in place of the 'pop group' (military or EG) object. That factory could be made mobile, assuming of course all relevant abilities in the builders.

And the ocean/land thing is a perfect example of *why* it must be architected this way. The only difference between an 'ocean' square and a 'land' square is the terrain object.

And this architecture allows us to even easily change that terrain, when the player gets the tech (raise mountains, dig canals, fill in swamps, etc).

Note to all:

I am perfectly aware of the pointer thing. What I mean is that in principle every sqEG contains a pointer to it's own egTech objects. I know it can be a many-to-one relationship (after all I've been using relational databases for a decade ), but it isn't necessarily. So if you have two sqEGs pointing to two different egTech objects and you want to aggregate them into a two-square prEG, you should decide how these two egTech objects are aggregated into a new prTech object pointed to by the prEG. These are not trivial matters IMO. If the modellers don't consider it, the programmers will have to do it by themselves. Here lies the seed for long discussions, if it is not taken care of beforehand. In fact I think I'm thinking more like F_Smith here than you are, but then I may be wrong.

F_Smith

OK, I know I am on your turf here, and by no means will I insist on the habitat thing. I think it's neet, but if the existing code can provide the same functionality in a simpler and more scalable way, it's fine with me. It is not I who do the coding, so it's not my call. As has been frequently stated recently: If the code gets the job done, the coder is at liberty to code it anyway he wants.

Instead see the proposal as an interest in exchanging views on the basic architecture of the game. I know it can be difficult sometimes to keep on coding without getting much feedback on the basic structure of things. I am by no means an OOA guru, but I know the basic lingo, and have one great advantage in this: I'm not prejudiced, since none of the existing parts of the game are mine .

So F_Smith: I'm sure your basic architecture will work, but could you please share some of your thougths with us. I for one would like to learn how this can be done. You say we can judge your architecture by the scalability and flexibility. Then show us at least the general ideas. Is there a way you could forward some UML or similar - just for the basic elements. I wish we could draw this . One of the real pains of working in a forum like this is the lack of graphics. Objects are sometimes much better described with drawings. In fact I think many differences of opinion could be resolved if we had access to a drawing facility.

To your comments.
I agree that it seems silly to have people reside in infrastructure while they move. People are mobile by nature. The only reason I even thought of this was that military units as far as I can see will have to contain sqEGs. And as far as I can see military units are infrastructure. And if you think about it people also live in infrastructure (housing), eventhough the rudimentary housing of early days is not specifically modelled. So if people move they move from infrastructure in one square into infrastructure in another square. If they are military units or nomads they reside in infrastructure-like structures. It might streamline the object model if all people always belonged to infrastructure.
We can probably argue for a long time whether infrastructure produces or people do. The truth is probably they both do. I agree that stating that a hunter/gatherer has infrastructure seems absurd (but then the whole site thing becomes absurd to me: I imagine sites as some kind of organised production capability FE farms or mines), but then you must grant that in principle fully automated infrastructure objects produce without people being present. I'm not talking AI here, simply robotic assembly plants and the like. Real AI, I mean really intelligent non-humans, should not be modelled as infrastructure but as population (a different race if you like). The adamant statements were just a way of simplifying things. This is what you do when you do analysis, right?
Back to the mapsquare. You state that an oceanic mapsquare differs from a mountain mapsquare only by it's terrain. And this is not correct in my opinion, at least not when discussing from the point of view of the economic model. The interface that the economic model demands from the mapsquare doesn't give a d… about terrain. It needs: number of sites, number of people living there and the presence of production-modifying infrastructure. It couldn't care less if it was a swamp, a dessert or a crater on the moon. Of course there are other uses for terrain: during movement and combat FE, but as far as I can see, the production of a square does not depend upon the terrain of a square. It is probably right that terrain needs to be stored in a terrain object, but this IMO is of no consequence to the economic model. That is, unless you imply that the number of sites depends on the terrain and is stored in a terrain object.

To avoid unnecessary discussion please do not answer the comment part unless you really want to, and you think that these considerations will bring us closer to an understanding of the OOD.

Sorry I misunderstood what you were saying... Personally for merging EGs, I think simple weighted averaging is sufficient for all the social components, and geometric averaging for Tech. At least that's a good first start. And as I think you were alluding above, the main question is deciding Whether two groups Should be aggregated, or have evolved away from each other sufficiently to be considered distinct. Any merging technique may be dangerous in the hands of players who are in mind to abuse the system. So we may need to wait for playtesting for the final answer anyway...

Absolutely, please do ask these questions. I will get at least a dozen things wrong when I first try to design the hundred or so objects we're talking about.

Find 'em. Make me talk about 'em. Ask anything.

Besides, I could ramble on about this stuff forever.

First, how about this -- could "Habitat" be a subclass of 'infrastructure'? That's kind of the way I'd work it, I think.

Are you familiar with the old line "is a or has a"? The phrase is to help decide 'encapsulation' and 'inheritance'. If something 'has a' something, it encapsulates it. If something 'is a' something, it extends it.

Because to my mind, habitat "is an" infrastructure object. But housing objects don't "have a" people group. I would say it the other way around, people groups "have a" housing object. So that's how I'd code it -- EGs will contain pointers to the infrastructure object they live in, if any. And yet there can still be truly homeless EGs. Early man scenarios. Refugees. A moving 'civilization' like the barbarian nations that gave Rome so much trouble. An army in the field.

Here's the process I go thru when 'analyzing' a system to break it into an object hierarchy --

1. Pick out the important nouns. "People". "Infrastructure". "Habitat". These are our objects.

2. Define each noun. In this case, "Infrastructure" -- the basic, underlying features of something, esp. of a technological kind, as the military installations, communication and transport facilities, etc, of a country or organization.

3. List all *relevant* properties of that object. I have not done this for infrastructure, so maybe ya'll would like to do it for me now, here, so I get it exactly the way you want it?

4. Make a class (object) for each noun. Arrange the nouns in any hierarchy that presents itself using "is a" and "has a" logic.
   

This makes coding a system that represents those objects a snap. And by sticking to absolute realism with the object structure only to the "relevant" properties, we automatically control scope. And, we will be able to scale the system to any level up, since we stuck with reality.

Scaling down can be a problem. But that's why you must do things at the lowest level the first time -- otherwise, you never will be able to easily.

'Sites' are encapsulated in the 'terrain' object, at them moment. 'Terrain' "has a" number of 'production sites'.

It's a combination of the quality and the quantity of 'workable' land in the mapsquare. It assumes an unimproved area -- not a mine, just a mineral rich area.

So for the 'econ' system, the 'sites' come from the 'terrain'. Likely, the 'econ' system will get run from the 'EGTurnHandler', which will do something like a 'doProduction' method. That method will take the pop info from the group and the 'terrain' object as inputs. The 'site' and 'infrastructure' info is in the 'terrain'.

I can allow the player to add, remove or change in any way a 'site'.

I had suggested splitting 'sites' into the two different variables, but Mark had good reasons not to (I forget what that was all about, to be honest). Mark can fill you in better, I think.

About automated facilities, I would like 'EG' to implement an 'Intelligence' interface. And then an 'AI' could also implement 'Intelligence'. And a tool/infrastructure object would require an object with 'intelligence' to operate?

I would definitely say that any plant that can run for any length of time requires *seriously* advanced AI. It would have to repair itself, deal with supply (what happens if a shipment doesn't arrive?), that sort of thing. I wonder if we could build something like that, at least a simple one? Possibly, now. I don't know.

And by 'AI', I mean even a low-level 'expert' system that can make only a few simple decisions by itself. Even if it's a simple 'if this, then that'.

The truth is F_Smith's last post was clarifying to me in how to see OO-coding. I'm maybe still understanding all wrong, but I wanted to try to organize these elements we're talking about as if I was the coder. Please, please don't give any of you big importance to what I'm about to say. Even more, if your name is not F_Smith, you can skip this post freely!

This is more like asking a personal favor to F_Smith. Below there's a "proposal" to implement in OO-code the ideas we have. Could you F_Smith tell me if it sounds reasonable from an OO-perspective? I just want to see if I have understood anything about OO-coding... I just want to learn, so please be my teacher for a moment.

Using your "is a", "has a" approach, I would say People (EG?) and Mapsquare lie in the "is a" category. So I'd define them as the most important classes.

Among other info, People "has a":
-Knowledge
-Mobile Infrastructure

Mapsquare has:
-People
-Sites
-Immobile Infra

I'm trying with that to model at the same time settled peoples, nomads and military units. Assuming both types of infra can be divided in several sub-types and in particular assuming mobile infra has as sub-categories military equipment of several types like "swords+shields", "horses", "muskets", etc., then I think a military unit would be a People object having some amount of military equipment. If I understand correctly, People would be an OO-class that "extends" (is that the term?) a sub OO-class called "military unit".

The military unit sub-class would then have all the info needed in the mil model to perform a battle. The number of people, the amount and type of military equipment and tech level for that equipment is all the info needed to calculate the military unit's abilities and strengths and that info is completely held in the object itself.

Since other type of mobile infra can be there too, then "military engineers" can exist having the ability to change the terrain assuming the People class has procedures to use its mobile infra to do so whether the people conforms a military unit or not.

I presume also that mobile infra such as "sails" or "aircrafts" could give the object the abilities to move through sea or air respectively, or, in general, to change the behavior of the object.

On the production side, I imagine the Mapsquare OO-class would have something like a "DoProduce" procedure that makes all People objects in it produce the economic activity. Since People has the mobile infra and the techs to produce, and the sites and immobile infra are part of the mapsquare, then I see all the info is there to generate the economic activity.

This would be true for settled and nomadic People. I'm more and more inclined to model nomadism as a cultural attribute defining the chances for the People to migrate and their preference for investment. Nomads do not invest nor use (they don't know how to) immobile infra. So this cultural attribute plus the already mentioned info should be sufficient to know how to exploit the mapsquare and get production.

Of course, military units would also be allowed to exploit the land having the necessary mobile infra.

Other things mentioned like people being able to "run away with a factory" could be possible if mobile infra is held by the People object. Fishing fleets could be an extension of the People class having "boats" mobile infra and using the "fishing" tech level.

If People=EG then I guess all EG attributes could be used in the various processes. Aggressiveness could be used in the military unit and Asceticism in production, FE.

However there is one thing I'd like to ask posters to consider. It is quite obvious that this is going to sort of a one-way thread. Us asking, F_Smith answering. So while I think any question is OK, really, please consider the time and effort F_smith puts into this while at the same time doing our main programming.

So, let this be a motto for this thread:

Ask anything, but accept that answers might only pertain to issues that will bring us along in our understanding

• Yes.

• Yes.

• Absolutely.

• Yes.

• No I did not have sex with that goat. I don't care what the goat says.
  

That's a home run!!!

Perfect. Exactly right.

I did add one more thing, and we can discuss whether or not I should change it. But I decided 'mapsquare' "has a" 'terrain', and then 'terrain' "has a" 'infra'/'resource'/'sites'/etc.

The main reason for doing this was so it could scale to having more than one terrain object in a mapsquare. So the Mine is in the Mountains, the wood is in the forest, that kind of thing.

I hope this is and will remain a conversation, not me talking all the time. When I start to ramble too much, people see the lights dim and the world closes in around them!

Besides, in no time, everyone will be on the same page. Everyone will probably figure this out quick enough.

I figured it out too, last night and this morning while walking the children to school (3 girls, you'd lov'em).

My idea of a habitat (silly wasn't it) in a way was caused by the need for organisation of people, their possessing infrastructure, their capability to exploit the land, move, settle down, engineer the land etc. But we already have that object: The EG. I thought at the time that EG=people, but that is of course simplistic. The EG is much more, in fact almost everything I wanted the habitat to be.

I see only one real limitation compared to habitats. The habitat allowed several EGs to be part of FE military units, while with F_Smiths approach there will be only one EG associated with the mobile infrastructure. The loss is by no means great, and surely the benefits are much greater.

There might be some other problems though: In a way the 'has a'-relation is turned around: With habitats a military unit has troops (perfectly valid IMO). With the present objectstructure an intelligence interface has some military equipment. One thing that I find slightly counterintuitive is the need for an 'intelligence interface' to have mobile infrastructure. You could have independent immobile infrastructure acting like weapons I guess (minefields), but you cannot have a mobile military unit unless owned by an object presenting this interface. So if we want a Cruise missile, we must give it to an object with 'dummy'-intelligence and have the whole thing fly off. But if military unit is an 'intelligence interface' that has mobile infrastructure, it cannot be otherwise.

It wasn't silly. It was largely correct. I would just store it in a different place -- as a 'subclass' of 'infrastructure' (in other words, as one type of 'infrastructure' object).

Actually, a 'task force' object still has to be defined fully, but I am assuming it will be able to hold any number of people and subdivisions, probably user defined. Limited by/dependent on infrastructure, tech, leader's skill/experience, etc. We'll have to define that object some day.

So in the present structure, a 'Task Force' "has" troops. Troops are going to be objects that 'implement' intelligence. So a 'Task Force' "has" intelligent objects. All 'tools' will require an object that implements intelligence -- that is to say, tools can only be used by objects with intelligence.

So if you want a 'cruise missle', you will have to have some sort of 'intelligence'. I would think this is a 'guidance system' -- and the more advanced an 'AI' guidance system you can make, the better the accuracy, etc, of the missle. Which explains quickly how the code will allow the tech and military to interact. Even a basic 'V2' rocket needs a 'gyroscope' guidance system which can alter the course of the weapon based on changing circumstances.

You could have short range rockets without guidance systems, as 'artillery' weapons. Perhaps some of these can even have a pretty decent range, a few mapsquares (at best, I think). But that has to be determined.

This also has not been discussed as far as I know, but I assume that the 'Task Force' will be seperate from the 'EGs' in the square. The 'task force' may be supplied by an EG (replacements, etc.). But not directly tied.

So your city of 100,000 Romans would 'recruit' soldiers from within itself (or possibly from adjacent squares?). They would then have the choice of either assigning those troops to an existing 'Task Force', or creating a new one.

A civil war between two EGs . . . hmmm, neat question. I'll have to think about it. The team should discuss this.

I agree that defining a TF object will provide great flexibility. It will be sort of a frame keeping the various parts of the military unit together.

But in that case wouldn't it be better to have the TF object rather than the EGs have the infra objects. Just fill up the TF with people/intelligence and you have a functioning military unit.

NOTE: I found a resemblance to SMAC in the proposed way of splitting terrain into geography and vegetation. Here's another one:

In SMAC military units are created by combining chassis (3 land, 2 sea, 2 air, 1 missile), armour ( many types), weapon (even more types, some of which are more like abilities), reactor (4 types, primarily for hit points, and decreasing price with better reactor) and 2 slots of special abilities (from increased police strength to deep radar). The player actually has access to a unit design system, allowing you to make your own unit prototypes, from almost any combination of the above. The number of possible different units exceeds 60.000 as I recall.

This time, the only similarity between us and SMAC is the OO approach.

SMAC's military is run on an 'arcade' level. Each 'piece' is one thing, of one type only. Our 'task forces' (the military gamepiece the player will move around/give orders to) will not usually be single-type units, they will almost always include a number of different 'elements', 'combined-arms'-style. A 'task force' is more like an 'army'. The player will absolutely be able to set the number/size of each element, and the type and quality of each element's equipment. And can re-assign elements from task force to task force.

While SMAC had tremendous options when creating units, they were very much static once created.

The TFs have much greater flexibility. Could actually pick up abandoned equipment, transfer equipment from TF to Tf or from TF to somewhere else.

But my point really is that we have to be very careful when we design the interactions between different types of capabilities/equipment. Especially when modelling combined arms effects

But I'm really getting in over my head here. I don't know much about the current status of the military model. When I have time, I will take a look at the military stuff to see how the guys overthere intend to handle this.

Actually this thread has sort of drifted somewhat away from the topic. I think most of the intended discussions have moved to the Maspsquare OO thread. Most of my qualms have been taken care of or postponed for a little while, so: