28-08-2000 05:43									#91
	Support Apolyton, buy Civilization III: Complete

The objects are easy to define, but they cannot do anything without the methods. I could finalize my plan for the methods if the following object list is agreed upon:

Tech Tag objects, with the Tagged RP's as parameters and the methods for calculating the tagged RP's.

One Tech RP object for every technology, with the methods for calculating itself based on parameters in the Tech Tag object.

The Technology object, with the level as a parameter and methods for calculating the level.

(Would it be better to have the RP as a parameter in the tech object? I'm not sure about this one.)

The Application Objects, with methods for calculating the level based on parameters in the tech object.

	11-09-2000 20:55									#92
	Help yourself to an AD-FREE life

I think we should discuss technologies relating to the breeding and improvement of domesticated animals and plants. These techs are similar enough to be covered by the standard tech model, but there are a few differences that require a couple special rules. Here is my view of the situation:

I think these techs should be defined as follows:
The quality of the animal, and the civ's knowledge about how to train and use the animal.

First, the tech for a certain animal cannot exist if the civilization has no access to that animal. Native American civs could not develop the Domestic Horse technology.

The first domestic horses were not strong enough to hold a rider on their back. They were only able to pull chariots and carry lighter loads. After people developed better breeds, they were able to hold humans and light cavalry was developed. Contrary to what Civ 2 says, chariots were developed earlier and they are much less effective in warfare than mounted riders. When horsemen appeared, chariots became obsolete. But the horse still wasn't strong enough to carry a heavily armored rider. They had to develop better breeds before cataphracts or knights could be used.

Training is also an important issue. Horses have to be trained well before they will go into combat, and training them to deal with explosions in modern combat is even more difficult.

So in Clash terms, we have the following progression of the Domestic Horse level 3 technology. This chart does not show all advances and the applications have other prerequisites not shown, but it shows the general idea.

Prerequisite: Wild Horses available
Level 10: Pack animal only
Level 25(better training): Chariots available
Level 40(better breeds): Light Cavalry available
Level 55(better breeds): Heavy Cavalry available
Level 70(better training): Riders can use gunpowder weapons.

There are also a few other effects. The level of the technology helps determine the effectiveness, speed, and range of mounted soldiers. The level also does a little to determine the effectiveness of farming and transportation before the internal combustion engine.

There is also a more complicated application. If your cavalry is not trained to deal with gunpowder and you face an eneny with explosive weapons, the effectiveness of your cavalry troops will be greatly reduced. This helps explain why early guns were so effective even though their range and striking power were worse than the bows of the time.

In general, there should be a check for the reaction of your animals in a battle. Inputs are the technology your enemy is using and the tech level of the animal you are using. Depending on the results of the check, some percentage of your animals may bolt. This takes those troops out of the battle and causes confusion on your side. Military model people (if we have any), how would this be implemented in the battle system?

The spreading and trading of this tech is another unique aspect. While most techs can be copied and transferred as data, this one cannot. You have to physically deliver the better breeds of horses. Also, it is a lot harder for this tech level to decrease. In fact, it may never do down normally. The genes will stay steady or improve by themselves, as only the healthy and fit horses will breed.

Conversely, the tech will drop more easily in some situations. Ownership of a group of horses is a zero-sum game, so if someone steals or kills all of your best horses the tech will go down. This won't happen if someone steals a normal knowledge based tech. Also, assunming that the best horses are chosen for war as they usually were, extensive battlefield deaths could reduce the tech level.

So we will probably have to define a derived class of Tech objects called Breeding Techs. They will have most of the characteristics of teh base Technology class, but the methods will have to be changed to account for their differences.

Does this sound good?

	12-09-2000 05:25									#93
	Support Apolyton buy from Amazon

Use, taming and creation of new horse races is IMO such an important factor in warfare history that if a special tech system for that is needed, then we must go for it.

I like all the things you say with the exception of mixing within the same concept the actual technique of breeding/training/taming with the availability of horses themselves. What if we treat horses as a "special" in terms of the economy model?

Specials like copper or oil exist in some mapsquares and people can take advantage of them for economic production. They can also be traded. If we now make some specials, like horses, transportable, that is, a mapsquare can change to "having the 'horse' special" from not having it, then the avilability of horses is IMO modeled better.

Civs, through trade or military appropiation, could obtain horses, which in gameplay terms means changing one of the mapsquares they control to "have horses". The tech on the other side has to do with the technique itself. Together, you can produce military units with the abilities you described.

The number of military units you can produce in a turn is given by the amount of with-horses mapsquares you control, while the characteristics and types of units available depend on the tech.

The tech could also be useful to produce more with-horses mapsquares. The greater the tech level, the greater the chance for reproducing animals and get a new with-horses mapsquare.

	12-09-2000 06:34									#94
	Help yourself to an AD-FREE life

Rodrigo: This tech does not include the presence of wild or tame horses. Rather, the provinces in your civ must have enough wild horses (as defined in the Ecology model) before you can get the tech. Once you have the tech, horses are assumed to be integrated into the economy so IMO it would not be good to keep modeling them as a natural resource at that point.

You saw the posts out of order, so I understand the confusion. I should have mentioned that this was a continuation of the post in the Ecology thread. We should discuss the map availability of horses in the ecology model, and this thread should be dedicated to the advancement of the tech once you have the horses.

	12-09-2000 07:21									#95
	Increase Your PM Length

I see now how I caused some confusion. When I said that taking horses would lower the tech level, I didn't mean that the level included the quantity of animals. I meant that if the horses lost were of the best breeds, there could be a small drop in the quality of the gene pool. If you had horses of similar quality elsewhere, there would be no drop in the tech level.

	12-09-2000 11:00									#96
	Support Apolyton, buy Call to Power 2

Yes, I got all confused.

Here's my new proposal considering also your idea to handle horses as infrastructure. I'll put all the implications for the three models here, just for simplicity.


In the tech model:
I'd suggest the tech itself shouldn't count in any horse-specific info such as genes or horse race. The tech should be only the taming/training/breeding technique. And therefore, the only special thing about this tech would be that animals are needed to develop the tech, while in other senses it's a normal tech.

In the ecology model:
For other animals such as oxes, mules, etc the ecology model indicates if they exist in the province or not and how many of them there're. For horses it's the same, but we can split them, only because of their importance in history, in, say, 3 races. Wild/Ancient/Natural horses, FirstBreed horses, SecondBreed/Nowadays horses (or simply horse1, horse2, horse3). Of course, in the ecology generator only Wild horses appear in the beginning of the game.


In the economic model:
It sure sounds really odd to consider animals as infrastructure, but it makes a lot of sense. However, a couple of differences between "real" infrastructure and "animal" infrastructure make me prefer to simply manage animals as a new feature in the econ model.

People and the govt can invest in real infrastructure, increasing it, while this would be kind of strange for animals. Real infrastructure can't be moved/stolen/traded, while animals can. Real infrastructure doesn't "grow" by itself, while animals do (they multiply).

So why don't we just add animals as a new "thing" in terms of what a province has in the economy model? Having their own properties (such as tradable) ensure a better modeling. I believe for the econ model is really simple to include them as a factor to production. I propose the econ model to have a "animal force" variable. Just one variable related to animals as input to production. Using the info from the ecology model about what animals are present, we compute this "animal force" like, FE:
Number_of_horses3*1
+Number_of_horses2*0.7
+Number_of_horses3*0.4
+Number_of_oxes*0.6
+Number_of_mules*0.7
+...

The econ model then treats animal force as a normal infrastructure variable for production.


How the three models interact?
The ecology generator creates "wild horses" as a special. Once a mapsquare with horses is within an economic/political province, the special disappears from the map and a number of Horse1 appears in the province stock.
The same is done with other animals. The province then has a list of animals in stock like:
Number_of_horses1
Number_of_horses2
Number_of_horses3
Number_of_mules
Number_of_oxes
etc

The ecology model also manages, each turn, their multiplication, increasing number of animals in stock via a base value and a modifier given by the tech system (the breeding/taming tech). Then the econ model uses the number of animals to compute "animal force" as an input to production.

Animals this way can be traded, stolen, killed and moved without problems. It just changes the stock. Everytime a military unit is created that uses horses, the number in stock is reduced and the military unit gets part of its properties based on the horse race and breeding/training/taming tech level.

The higher the tech level is, the higher the probability for a new race of horses to appear, unless the horse3 already exist in the province.

In this way IMO everything has sense. For simplicity instead of having a large list of animals, we can aggregate the least important ones and have only:
Horse1
Horse2
Horse3
Camels
Other1: mules, oxes, etc
Other2: cats, dogs, etc


What about animals for consumption (like pigs)?
In the ecology generator I'd give each mapsquare a "wild life" value according to climate, etc. All mapsquares conforming an economic province would be summed to create a "wild life food value" that would act as a multiplier for food production in the econ model. This multiplier can in time be also affected by the Breeding Tech, so the better the tech level, the greater the multiplier.

What do you think, Richard?

	12-09-2000 17:44									#97
	Support Apolyton or Terrorists Win

Well i don't think we need to model many animals. Like everything else, just those important to history (outside religion...cuz there we can have anything modeled). Horses are definatly one. Dogs are too, though mainly in the beginning. Dogs are also the first animal to be domesticated (or rather wolves were).

Here's the list of what I think is essential to model:
Camels
Dogs (Formerly wolves)
Horses
Elephants
Cars (maybe...Other than reducing mice/rat population and religious importance i don't see any use).
Livestock in general

Remember everything we add makes things more complicated so think carefully what is really needed.

	12-09-2000 19:25									#99
	Support Apolyton or Terrorists Win

roquijad:

The problem with taking horse quality out of the tech equation is that it becomes hard to do tech prerequisites that way. You need a certain breed of horse for heavy cavalry, and if that isn't in the tech it becomes difficult to define the time that your civ can make those knights.

It is possible that we could ignore prerequisites and use the horses as required inputs in the production function. So when you order a province to make knights, it checks to see if it has enough horses of the right quality. Those horses are taken out, and the quantity and average quality of the province's horses decreases (they took the best horses).

While that would work, it seems like it would generate more micromanagement than the tech level approach.

This multi-topic thing is getting out of hand. Posts are getting missed or read out of order. We haven't really begun to discuss the military aspects of this, and I think the population model might get dragged into the discussion as well. So, I'll copy everything we have to date into a new thread devoted to this topic. That way we can have a semi-coherent discussion of the issue. When we have finished, then we can post our conclusions to the proper model threads.

	15-09-2000 01:57									#100
	Got spare money?

The quote was copied from another forum so i put it in a more relavant thread:

F_Smith:

quote: Lordy: Again, this is data model speak -- the 'Ethnic Groups' will absolutely have to hold info on what their individual tech levels are. Like an individual 'car' holds info on what kind of tech it was built with (to an experienced eye). That has nothing to do with how the player manages tech info, or how the game 'models' technology . . . they're two different things. It's a 'data storage' thing only.

	15-09-2000 02:38									#102
	Help yourself to an AD-FREE life

Well it was originally planned to be that way (or atleast via the province), but for better to store 'functional tech level' at the mapsquare level for more realism....though i don't know about the 'maximum tech level'

	15-09-2000 03:09									#103
	Remove this text

Um, ya'll don't understand:

It's from a coding organization standpoint *only*.

It has to do with object design. Objects must contain (encapsulate) all info about themselves, so that other parts of the program can use that data.

How your game models handle the data is an entirely seperate deal -- (altho if ya'll were using OO design, it could improve the models, without a doubt . . .).

Ya'll are designing a game. We need to make a game program. That means 'OO' models. So any models ya'll make will have to be translated to an OO design by the programmers, anyway, in order to code it.

Just keep that in mind.

	15-09-2000 03:12									#104
	Support Apolyton, buy Alpha Centauri

I think techs cannot be stored under EGs. You'd then have to model inter-EG tech spreading, because techs an EG develops can be easily copied by another EG living in the same province/mapsquare.

Storing tech info at the mapsquare level seems like a lot. That'd imply heavy use of compatuational resources. I'd keep it at the civ level or at most at the province level.

	15-09-2000 04:43									#105
	Suffering from ads?

Well we can try at the mapsquare level...an see how it works although i think it won't work as tech info has more objects in it than any other model and as time progresses the amount of calculations which will almost definatly need to be done every turn will increase exponentially because more basic techs are added and more application techs are added and their levels are calulated as well as the probably the application tech above/below it for social conditions that could slow changing over to newer tech and the fallback on older, but reliable technology from loss of education of the civ as a whole. So new application techs won't go away unless the tech level drops too low although they can be replaced. This also doesn't include the nightmarish rp calculations that would be done for rp generation because although the OO design might allow for quick and easier gathering ot the relavant data, it can't do sh*t for increasing the speed the CPU calculates its math problems which become increasingly complex and numerous as time goes on. These will haveto be redone every turn as simple small changes can have vast effects on RP production and basic tech costs.

	15-09-2000 09:03									#106
	Support Apolyton buy from Amazon

For the past several weeks I have been trying to comprehend Java and OO modeling. It may not be working too well, as I still don't understand why the ethnic groups have to store the handles for tech objects. Technologies do nothing to define ethnic groups.

Besides, there may be a terrible problem with this. Consider:

Ethnic groups are stored at the mapsquare level, so the number of EG handles will be the number of mapsquares times the number of ethnic groups we define.

If technologies are stored by ethnic group, each of these objects will have hundreds of technology handles inside it. This would mean that we would have hundreds of thousands of handles for the tech objects. It seems to me that that kind of thing would make the program grind to halt.

Come to think of it, that may be why Java programs are so slow. If the language requires those hundreds of thousands of handles to be created in the design, it makes sense that Java can be 10 to 20 times slower than C.

F_Smith: Okay, I saw another complaint about the design of the tech model. From my studies, it seems that we were doing okay. What are we doing wrong this time? I thought you said the outline I posted was okay.
[This message has been edited by Richard Bruns (edited September 15, 2000).]

	15-09-2000 13:02									#107
	Help yourself to an AD-FREE life

Rich:

I don't understand how you did the analysis.

When you look at an ethnic group of people, what properties do you believe they have?

Here's my basic understanding of 'OO'.

Take an object, say, an automobile.

That 'car' object has 'color', 'make', 'model' attributes. The 'car' object holds 'transmission', 'engine', 'tires', etc, objects.

Similarly, an 'ethnicgroup' is a group of people.

So an 'EthnicGroup' object should hold 'demographics', 'knowledge', 'religion', 'culture', etc, objects.

List off the properties the object has -- an ethnic group of people has a pop number and income/spending habits (demographics), known technologies and skills (knowledge), a common belief (religion), etc.

That way, when any part of the program wants to deal with/make changes to an EthnicGroup, all the relevant data is available.

At least, that's how I understand it. How do you analyze it?

And I don't believe I agree with your assessment of Java's speed . . . but that's another topic.

P.S. -- when you say 'handles', do you mean the pointers to the tech handles?

	15-09-2000 16:14									#108
	Support Apolyton or Terrorists Win

Richard, don't feel bad, I don't see why tech has to be in EG either. And I've been coding at least using a version of OO programming for years.

F_Smith:

You are trying to code objects according to how you perceive the real world analogs of those objects might work. In business that probably works fine since the world you are dealing with is the real world. In a game one can use any Logically Consistent framework for how the world works. FE we can decide that a civ is the object that holds knowledge of tech. In our definition there might be no lower level of knowledge. So one can perfectly well IMO let each civ have a tech object.... It is only because you choose to be interested in having people at smaller levels know about tech that your model is the way it is. It doesn't Have to be that way.

Anyway you can store a pointer to a Tech object anywhere you want, but as Richard says those tech objects can't be independent for the default game anyway since it would take up awesome amounts of memory and processing power. I know you are doing this to make things as flexible as possible. But don't say it Has to be that way, as you frequently do. Please say "to make it extremely flexible for scenarios, and future evolution of the system, IMO it Should be done this way..."

	15-09-2000 18:35									#109
	Support Apolyton, buy Alpha Centauri

My thoughts on where we should include stuff like tech level.

People in this game are represented in a hierarchical manner, a person (not modelled) is part of an EG, which is one of several EGs in a square, which is part a province, which is part of a civ, which is part of the planet. The level at which we should store a particular item of data is the most detailed level we
can imagine that differentiated description of this attribute could have any meaning in gameplay terms.

Thus if we can imagine that it would be important that Peter knows more than Paul, then we would have to model individual persons with individual tech levels. This is not feasible. At the other extreme, we could decide to have one tech level for the whole planet, in which case we would not need an elaborate tech system.

The other options we have are:

EG level: Do we really need to differentiate between the tech level of individual EGs?

Square level: A case could be made that since certain techs/apps would demand access to particular infrastructure or terrain, it could only occur in certain squares. Shipbuilding in the Himalayas?

Province level: Another possibility, but this would mean that you might be able to build something in one province, which you would not be able to build in another

Civ level: I guess the original tech concept.

Whereever we store the info every 'person' will have access to the tech level that is relevant for him at a given time, by accessing it throught pointers to objects higher in the hierarchy.

[This message has been edited by Beör (edited September 15, 2000).]

	15-09-2000 20:05									#110
	Support Apolyton or Terrorists Win

Mark:

Actually, my understanding of OO design is that you always break things down to the lowest level you'll have, and assemble up. It's also known as a 'component' approach.

We have models requiring an 'ethnic group' object, each 'ethnic group' will have to be able to have a differing level of technical knowledge, therefore we are suppose to store the 'technical knowledge' at the 'ethnic group' level. For several things (like migration, for instance) an 'ethnic group' will have to be able to carry the information on their 'technical knowledge' with them.

It really is considered automatic, I believe. Which is why I present it as a matter of analysis, not opinion.

And again, it doesn't chew up resources -- compared to the requirements of doing it at a higher level, then having to 'disassemble' the data. That is *very* computationally heavy. It is considered bad OO design.

At least, that's my understanding of OO design.

And I also disagree about not modeling the game systems based upon the real-world objects. That, to me, *is* the *only* way to do it. Which is why I fundamentally disagree with some of the modelling done here.

* * *

Beor:

Aside from the requirements of a 'component' architecture, don't 'ethnic groups' have to be able to have different tech levels, even per square?

I'm thinking about things like migration. Won't an 'ethnic group' migrating have to carry it's 'technical knowledge' level with it?

Or would they automatically know whatever technology is known by others in areas they move thru -- and then they lose that knowledge when they move on?

If 'technology' is 'knowledge', the data belongs with the people that have the knowledge. Knowledge is not in any way tied to an area, it's tied to people. And yes, a group of people in the Himilayas should have the ability to learn to make boats, if there's some way to teach them and some way for them to practic (a lake, say?).

I could be mistaken, I guess, but it seems so clear.
[This message has been edited by F_Smith (edited September 15, 2000).]

	15-09-2000 20:08									#111
	Avatar Enlargement: We've got the solution

F_Smith:

quote: So an 'EthnicGroup' object should hold 'demographics', 'knowledge', 'religion', 'culture', etc, objects. List off the properties the object has -- an ethnic group of people has a pop number and income/spending habits(demographics), known technologies and skills (knowledge), a common belief (religion), etc.

	15-09-2000 20:25									#112
	Put an end to popups!

I'm responding to F_Smith's simul-post:

quote: We have models requiring an 'ethnic group' object, each 'ethnic group' will have to be able to have a differing level of technical knowledge. Aside from the requirements of a 'component' architecture, don't 'ethnic groups' have to be able to have different tech levels, even per square?

	15-09-2000 20:28									#113
	Support Apolyton, buy Galactic Civilizations: Deluxe Edition

Richard:

I'm simply pointing out, from an OO perspective, since an 'ethnic group' is a specific, real world thing (a group of people), and since that real world counterpart has a 'knowledge' object (so to speak), that a good model should be built the same way.

I am aware that ya'lls current model is not done using this kind of OO analysis. I am also aware that to code the game, ya'lls model will have to be 'translated' to an OO design.

You know I disagree with that approach. But I leave it to ya'll to do what you want, in this regard. If I code it, I'll just translate the model (as would any other programmer), so that the 'game rules' work as you request -- even if the game code can *not* work that way.

For one example of why, read the 'migrations' example above.

If you mean 'pointers' (it sounds like you do), there are going to be a bunch of pointers all over the program. It's the only way to make *any* program run efficiently. They are not memory hogs -- in fact, a pointer is a way to minimize the memory requirements by encapsulating data in common objects.

One comment I'd like to make, from my experience -- OO design is a *more efficient* method of programming than 'procedural' approaches every time. The program will run more smoothly, be more flexible *and* less bug-prone.

Regarding speed, remember, 'Demo 4' was not OO in any way. It was a purely procedural program. Which is one big reason it's been stalled for so long. There is no easy way to fold all these complex models into the existing code. The complexity would (did) quickly overwhelm any programmers who would try to take on the task. Things that should take a week have taken a year.

Re-architecting the program to an OO 'component' design was absolutely necessary.

	16-09-2000 09:16									#114
	Help yourself to an AD-FREE life

I'm OT, but sorry, I must respond....

F_Smith:

"Regarding speed, remember, 'Demo 4' was not OO in any way. It was a purely procedural program."

Absolutely wrong!!! It may not use your component OO approach, but it is not procedural. You are like one of these fundamentalists that say, not only do you need to belong to this denomination to go to heaven, but you need to go to this particular church! I am using OO design practices that I learned from books on the subject. Not perhaps the best, most current ones, maybe not what you think of as OO, but OO none the less.

"Which is one big reason it's been stalled for so long. There is no easy way to fold all these complex models into the existing code. The complexity would (did) quickly overwhelm any programmers who would try to take on the task. Things that should take a week have taken a year."

Absolutely wrong again. I got sick of programming after demo 4 and stopped for a long time. I needed a break after having put in 40hr work weeks on Clash alone, not considering everyting else in life. Everyone who said they were going to code did basically nothing except consume my time in trying to get them set up. No approach would work with those resources. I have at least one clear case that the existing code structure didn't cause someone's progress to lock up. Garth was going to start from scratch so you Cannot blame the existing code for why he was able to accomplish nothing. I personally think that lack of time and committment is the major problem in the lack of progress. You are jumping to conclusions because of your evangelism for your OO component design process. Nobody Ever said to me, or on the forums "I can't work with this code" or "The complexity is too much with X model...". They said they had no time, or had lost interest. So There Is No Information That Supports Your Analysis. Just your opinion standing alone.

I would appreciate if you would not make comments like this again. You have only conjecture on your side, and all its doing is pissing me off....

	15-09-2000 22:03									#115
	Support Apolyton or Terrorists Win

Mark:

I'm sorry if I pissed you off.

I think perhaps I should take the weekend off. Maybe, being stretched too thin has made me insensitive. I still feel there's a lot of truth in my comments, but I don't want to fight over it. This is just suppose to be a hobby for all of us, and besides -- I enjoy ya'lls company too much to burn any bridges over something as esoteric as 'project management' methodologies. I've had this discussion before, with people here at work, and I know how it can end. I really don't want that.

I'll check back in Sunday, after I've had a chance to give my mind a rest.

Again, please forgive me for my rudeness.

	15-09-2000 22:09									#116
	Support Apolyton, buy Call to Power 2

Richard:

Sorry, just saw your post.

Agreed, your game model can work that way. The code will simulate that.

There will just be the option to do it more 'realistically', if we want, as an optional 'tech' system (just like the optional 'politics' system). Since people and techs will develop without much player interaction, it would make perfect sense for a 'English' ethnic group in a mapsquare to be able to make muskets, while a 'Native American' ethnic group in the same mapsquare does not have that ability.

Your approach, while fine, would allow those natives the knowledge to make muskets.

I would just like an alternative to this.

I'll catch you Sunday.

	15-09-2000 23:05									#117
	Lose 30 kilos (of popups)

F_Smith:

I'll get over it... Basically I'm already over it .

I agree with you that there could well be big defects in our project management methods... The rest of us are mostly makin' it up as we go along... Thats one of the reasons you are such an asset to the project

I'm sure I don't agree with the particular issues you raised today in that one paragraph. Or at least I don't think what you said were the Major reasons why things have turned out as they did over recent history. But anyways, if necessary we can just agree to disagree.

I see the logic behind your overall approach, and it makes sense. It was just your stating your conjectures about this important topic as if they were facts... If you had just phrased your hypothisis a bit softer, and thrown in some maybes there would have been no problem.

Anyway, I understand how being under pressure can make these things both easier to say, and easier to react strongly to on my part! Have a great weekend!

	15-09-2000 23:12									#118
	Support Apolyton, buy Galactic Civilizations

F_Smith: I know you won't see this for a while, but I'll respond while it is fresh on my mind:

I know that any group of people will have a set of knowledge; I made the simplifying assumption that they will all have the same knowledge (the civ's). This eliminates the need to explicitly state the knowledge of all the little groups. They are a component of the Civ object, so they inherit many characteristics of the civ, like tech level, life expectancy, literacy, etc. Since they all inherit the same thing, we don't have to worry about it. Isn't that one of the good things about OO?

I think it is perfectly reasonable that the natives can make muskets. The natives in your civ are assumed to be integrated into your legal system, economy, and society. They still have a cultural identity, but they are trading and working with everyone else. Members of that EG can be working in the blacksmith shop just like anyone else.

Soon, they will be able to run the blacksmith shops themselves. Tech diffusion has ocurred. I think that if we modeled them all seperately and had tech diffuse between them, the tech diffusion methods would give us almost exactly the same result: they would all have the same knowledge very soon. I'm just changing "very soon" to "instantaneous".

	16-09-2000 01:55									#119
	Support Apolyton buy from Amazon

One of the reasons we see things differently lies in the understanding of the concept 'tech level'.

F_Smith sees it as knowledge possessed by individual people (which we don't model, hence an EG).

However, I don't think this was the idea. Richard states it very well when he says that tech level represents the 'maximum knowledge level' of the civ. I would go even further and say that tech level represents the maximum knowledge level, infrastructure, knowledge processing institutions and maybe even ressources of the current civ. It is an upper limit of what can possibly be achieved in the civ.

FE say I was a part of the Danish EG in the European civ. As a civ we would have the necessary knowledge and infrastructure to build a nuclear power plant in the Danish province. But if I migrated to a New Guinea tribal civ I would not be able to 'carry' this tech level with me. It is not part of me. Even if the entire Danish EG migrated we would still not have the necessary tech level to build a nuclear power plant in New Guinea, as we would lack important infrastructure. So this tech level is not a part of an EG either. If a foreign power conquered a European square with a nuclear power plant in it, they might be able to coerse the technicians in the plant to uphold production for a while, but if the conquering civ lacked access to Uranium (or whatever is needed in such a plant), proper disposal facilities or the like, eventually they would not be able to have a functioning nuclear plant. So the tech level is not part of the square either. If provinces are big a tech of this sort might be said to reside at the province level, but very high tech levels can only be achieved and upheld by entire civs (think Star Wars project) or maybe even the entire planet (think future techs like a solar shade).

What I am saying is that the more advanced a technology is, the higher in the hierarchy it belongs. There is no unique answer to where tech level should be represented if reality is to be modelled. When technology approaches the level of the present, it seems necessary to have civ level tech levels, which in my view suggests that we should keep it at the civ level for the entire game for simplicity and ease of game play.

As F_Smith states this has the disadvantage that when people migrate they do not carry the tech level with them. The exhange of techs at the borders of civs must therefore be handled in another way:
How is the exchange of techs going to be handled?

	18-09-2000 01:02									#120
	Get a bigger avatar today!

Beör:

Sorry I didn't reply earlier; this thread got lost in the shuffle.

I agree with your analysis, except for some of the parts about infrastructure and resources. Technology tells you how to build infrastructure and use resources, but it does not include the availability of those things. The economic model handles resources and infrastructure building, while the tech model tells you how much infrastructure it is possible to build.

So if all of the Danish people moved to a primitive area, they could immediately invest in infrastructure. As they devoted economic inputs to infrastructure, it would keep improving. Eventually they could build power plants if there was no tech loss.

Migrating civs are assumed to carry knowledge with them in the form of memory, technical skills, books, ect. But the knowledge is very susceptable to tech loss when it is in this form. If no economic inputs are being devoted to a particular area, there will be no RP production and the tech level will fall pretty rapidly. So after a few dozen turns, they might lose the ability to build the power plants because they are out of practice.

Technology exchange is handled abstractly for the most part. Contact with another civ will give you tagged RP's to be spent advancing a certain tech. Tech levels will only be transferred in rare situations because the tech level is assumed to be a level of knowledge that is an integral part of your society. As you pointed out, an invader will not be able to take all of the tech level that lets them build power plants. The presence of the power plant would give them lots of RP's to advance their tech level, but they would not simply inherit your tech level. Their society doesn't have the necessary background or skills to start making power plants.