You don't haveto quite go out and name the ideologies, but atleast give some terms descibing atleast the ones you know you want in there right now.

Ancient Despotism (warlord rule)
Divine Monarchy
Monarchy
Constitutional Monarchy
Oligarchy
Ancient Republic
Capitalist Democracy
Democratic Communism
Social Democracy
Fundamentalism
Communist Dictatorship
Capitalist Dictatorship

The list of course may change as the project advances.
----------------

This outlines the entire tech system procedure, starting and ending with object parameters for the other game models. This is mainly a definition of the objects and their interactions; the equations will come later.

The system is run at the end of the turn. It uses data about events and attributes from that turn and the results are implemented at the beginning of the next turn.

This system can be run at the civ, province, or even the square level. The default would be the civ level, but if you wanted different provinces or squares to have different tech levels you could run these methods at that level.

1) Data about RP generating activity in the area (civ, province, or square) is collected. I would assume that this would be a matter of inputing object parameters (trade, construction, etc.) from the other game models.

2) Tagged RP's are generated from this data. Each tech tag has a Tagged RP object that calculates itself based on the data gathered in step 1.

3) Social effects and other external multiplicative effects are applied to RP generation by tag. The object parameters from the other models again cause the Tagged RP objects to recalculate themselves. (Note that this allows society to have different impacts on different fields of study. Philosophy innovation might be frowned upon while Agriculture innovation might be supported.)

4) Tagged RP's are distributed among the technologies. Each technology has an associated Tech RP object that calculates itself based on data from the Tagged RP objects and the level of the associated tech.

5) THL (Total Helper Level) values are calculated. Each tech has an associated THL object that recalculates itself based on data about the helper and vital techs.

6) Each tech level is recalculated. Each tech object recalculates itself based on data from the associated RP object, THL object, tech attributes, and its own tech level. (This is the step that is detailed in the spreadsheet.)

7) Tech diffusion is calculated. The tech objects recalculate themselves based on data from surrounding areas and the internal conditions of the area. (Note that this is in addition to the effects of trade. Trade generates RP's that must be turned into technology by the civ or province. This gives completed technology directly to the area. So, your society not provide a good evvironment for the development of something, but they would use it once it is completed.)

8) Application levels are calculated. Each application object recalculates its level based on the tech objects and its own attributes.

9) The effects of application levels are implemented. The objects in the other models recalculate themselves based on the parameters of the application objects. These effects will take place before the start of the next turn.

So the basic outline is:

I'm sorry, I've been working my brains out the last couple of nights. I haven't been able to fully digest the steps yet, but at first glance it looks right.

This is good stuff, Richard.

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

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.

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.

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.

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

quote: Cars (maybe...Other than reducing mice/rat population and religious importance i don't see any use).

Thats a typo, right? You mean cats?

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.

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.

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.

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.

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.

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.

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.

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?).

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.

No, sorry. The EG's were never meant to have the property of "knowledge." The game assumes that all EG's with a civ are equally intelligent and have equal access to the civ's knowledge base. Dealing with EG's should not require info from the tech system. Can you give an example of where this would be needed?

The game assumes that the entire civilization has the same maximum knowledge level, which is represented by the tech level. Provinces have a seperate "applied" tech level that is based on investment and upkeep. The deatils of that are in the economy model.

So the "Technology" objects only need to be stored in the "Civilization" objects. The details of province infrastructure that relate to tech levels are kept in the "Province" objects.

The book I am studying says that handles are identifiers that point to a certain object. I think it says that handles and pointers are the same thing. Or maybe it doesn't, and I am just confused. Like I said, I'm having a bit of trouble learning all of this.

The speed issue isn't my analysis. It comes from the book I am studying and from my friends who were dubious about the prospect of getting anything complex to run in Java wuth any decent speed. And then there is the fact that my old computer could run things like Descent 2 without any problems but was incapable of running the simple Demo 4 without freezing.

Beör:

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?

Again, no. This was not meant to happen. While it may make sense, IMO it would be a nightmare for the player. If every ethnic group or every square had different tech levels, the result would be a giant mess. The player would never know what could or could not be done. It makes no sense to me that EG1 in square 55,17 can build muskets but EG2 in square 56,18 cannot. This would happen if the techs were modeled seperately, and it would create a huge nightmare IMO.

Everyone in the civ is assumed to know the same thing. It might not be exactly right but it is an assumption that we have to make. Migration within the civ has no effect on tech level.

When a group migrates away from a civ, they carry all of the civ's knowledge with them. I would assume that they create a new nomadic civ in the process of breaking away. Their knowledge level is the same as the original civ's because they were once part of that civ. As they travel, the normal inter-civ tech diffusion routines will determine how the knowledge changes.

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