Demo 6 Technology Model

[Mark_Everson]

Originally posted by Gary Thomas
The original one-effectiveness system is, as far as I am aware, still the official party line. Admittedly I am trying to change it. The code is a de facto change (which, as I have said before, I agree with), which should be made into the official model. I am trying to do that before I rework Laurent's code into the technology model. This, in turn, implies an attribute based system (for efficiency). I propose to call them Parameters.

I think actually the differences are largely purely semantic, although that may just be the fever. IMO the problem was you were calling the mono-effect thing Application, whereas Richard is using the longer-standing "Application is a multi-effect thing like a Legion" definition.

Here is something I said before, that to the best of my knowledge Richard agreed with when we were talking about Laurent's approach.

So what is the proper configuration of an Application? IMO there is no problem in it having multi-dimensional attributes. That's because the 'atomic' attributes are to be found elsewhere in the tech model, in the top three tiers. Mostly in Skills, which will include perhaps Armor Making, Bow Making, etc. IMO an Application should have the following properties .

(from my post of 09-01-2002 20:58 in this thread)

With the exception that I specified the mono-effect things as gotten from Skills etc. in the post above, it is basically what you are doing. My thought was if you call your mono-effect things FE Attributes (I like that better than Parameters), and let the interface that ElementArchetypes implement be called Application, that may be enough to close on a deal asap. So Application (perhaps AbstractApplication in the code) would have a collection of Attributes that can define its multidimensional effects. An Application still has required tech levels that make it turn on per the old model. This is completely consistent with what Richard already said was ok AFAIK except some things may have been moved back from other models to tech in the code. I don't think he cares about where the code goes.

I hope I"m representing everyone's point of view correctly here! But it seems like everyone should be happy and we should have an agreed-to spec.

[Richard Bruns]

I wholehearedly agree with Gary's rearrangement of the xml file so it is organized around properties. It does make more sense to do things that way. My version was just sort of cobbled together, and only meant as an example of the things that might go in the file. Feel free to rearrange it as needed.

And yes, my idea of "Application" is a complete thing that the player wants to make or do. Sort of like a semantic object. We can arrange the code so that this object as as many or as few attributes as desired. I can see how a programmer might refer to each of these attributes as an "application" but that's not the language I was using. An application like Legion will have attributes such as speed, health, and power.

[Gary Thomas]

Great, I do believe that everybody is agreed!

There are a couple of points from Mark's post.

let the interface that ElementArchetypes implement be called Application

ElementArchetype does not implement any interface - it is an object in its own right.

My thought was if you call your mono-effect things FE Attributes (I like that better than Parameters),

Unfortunately "Attribute" has been taken as a technical term by JavaBeans and would only lead to considerable confusion among coders. So Parameter it is. Not ideal, but better than attribute.

From Richard:

And yes, my idea of "Application" is a complete thing that the player wants to make or do

So a military element is one kind of application, as indeed it should be.

I have almost finished the coding.

Cheers

[Mark_Everson]

Originally posted by Plutarck
You can have each Attribute be set in whatever way you like. For instance, if you're into detail/complexity you could have something like this:

TankAttack = (CannonTech + HeavyProjectileTech + OffensiveSkill) / 3

TankDefense = (HeavyMoveableArmorTech + DefensiveSkill) / 2

Movement = MediumTrackedMovementTech


Which I believe is something like what Mark Didn't want.

But if this system is used, you can just as easily do this:

TankAttack = 100 + UnitAttackBonus

TankDefense = 50 + UnitDefenseBonus

TankMovement = 10 + UnitMovementBonus

Hi Plutarck:

The system that we just agreed to (!) will allow us to do both by changing the xml specs, as I think you were suggesting.

[Gary Thomas]

Now that the parameter scene is clear, I would like to raise a related matter.

Laurent called his parameters "requirements". In my view they were actually "helpers", in the terminology of the tech model.

I would like to introduce a very simple class called Requirement, this class has only a technology name, and a start level. It is intended to be checked when something is possible buildable. If the required technologies haven't reached the start level, the object is not buildable. At present, in a vague and unspecified way, the helper class is apparently supposed to do this job also. Since the aims are different, I feel they should be different classes.

Cheers

[LDiCesare]

One thing to be noted: I called them Requirements because they are used both to know if the application is available and how values increase. It could be good to have both requirements (needed in order to build the unit) and helpers, which are not mandatory, but provide a boost to abilities if they go beyond a certain level.

[Gary Thomas]

The original helpers, in the technologies, had both a start level (called an offset) and a mandatory start level, called start level. If the level was below the mandatory level, the "helped" technalogy is inactive. Helping doesn't kick in until it reaches the offset.

My point really is that we are dealing with two different things, used in quite different parts of the program. Sometimes a requirement may not be a helper, and a helper may not be a requirement.

Accordingly I would prefer to separate them. So far it is only in the parameters area (not in the technology xml), and thus in the military xml, where some things will be in twice - as a requirement and as a helper.

I don't really like the word "helper" but can't think of anything better.

Cheers

[Mark_Everson]

Hi Gary:

I am thinking about the first steps toward hooking up econ to use the tech model. Do you have any thoughts on whether we need an interface to govern objects that put RPs into Activities? ActivityContributor or something... It seemed to be that since such objects will be all over the code it'd be good to have a standard way for them to work. The names are just placeholders.

ActivityContributor

would have a contribute() or contribute(float) method. If things can contribute to more than one activity, then contribute would need a way to divide RPs between any of a number of Activities.

an AbstractActivityContributor would have a collection of pointers to one or more Activities, and a method for dividing any RPs between the activities when contribute(float) is called.

Laurent, do you have a way to do this already that is reasonably general? Would the above meet your needs?

Any thoughts?

[Mark_Everson]

Hi Gary:

I originally said:

let the interface that ElementArchetypes implement be called Application

to which the reply was:

Originally posted by Gary Thomas
ElementArchetype does not implement any interface - it is an object in its own right.

I think the tech model GUI will require Registration of some sort for Applications (Richard's definition) like particular ElementArchetypes. That is so a number of functions the player will want to interrogate the model about are available. Specific questions are "Where should I put RPs to be able to build a Legion"? or "When at current rates of progress will I get Legion?" or "What goodies is the tech Reframbulating needed for?" For all of these the tech model needs to know that there is a thing called "Legion" and be able to contact the multi-effect Application object associated with Legion. How do you plan that to be done?

That is what I was talking about in my quote above, assuming that it would be done with an interface.

[LDiCesare]

Laurent, do you have a way to do this already that is reasonably general?

There is a way to add RPs to an existing activity by
civ.getTechnology().addToResearch("Activity name",float)
The problem is you need the activity to exist in order to avoid a null pointer exception.
However, this translates the fact that e.g. a unit when it wins a fight gives better knowledge of tactics. It doesn't explain how to get better legions. Legions require a set of helper techs, so when registering these, it should be logged so that if the player wants to get a legion or a better legion, they can find the information. I am not sure a new interface is needed.

[Mark_Everson]

Well, I'm trying to hook up some economic-tech intereffects. I have run into two problems so far.

As I think Gary has already mentioned, some techs are not active because they fall below zero (their start value) as soon as a tech update cycle is run without any RP inputs. When I get access to the code Farming is already at a level of -0.29 or some such, presumably because of an initial tech update cycle where no RPs go into Farming. Since it is below its start level, Farming does Nothing. Without unusual repairs, it effectively doesn't exist.

This is a flaw that IMO must be remedied. Sure I can arbitrarily Set it to become active, but that is not the economics code's job.

What is worse, as currently handled it appears that RPs don't even go to inactive Techs, or at least don't produce a change in level. So once Farming falls below the critical level there is no easy recovery without special action by the programmer. (I guess Biology might eventually pull it out, but Biology has the same problem!)

Potential solution:
I propose that a tech that starts at 0 should Never become inactive, and that RPs can be added to, and have effect upon the level of an inactive tech. These may not be the best solutions, but we need something, or there's going to be train wrecks galore in the Dawn scenario.


I also feel the need for some Specifics about what technological levels, in terms of the real world, these levels represent. IIRC Richard above states that "everything is supposed to start around 10". That was never my understanding. I thought that 1 for the general techs like Farming and Mettalurgy was supposed to be basic stone-age technology, on the verge of taking off toward things like copper metallurgy, etc. So, Richard, can you tell me roughly what a 5 in metallurgy means? Similar for Farming? What about 10 or 20? I can make guesses in terms of my mental yardstick cited below, but I don't want to have a standard that is different from others.

I wanted a single, crude, unified scale a long time ago, where a level 1 always meant late stone age, and a level 100 always meant contemporary technology. Presumably on that scale most techs in late classical antiquity would be around 10. I lost that argument, and so now levels are arbitrarily defined per the individual technology. So what do the levels mean? I really think its time for some first stabs at answers...

[Gary Thomas]

I would say that something we need rather soon is a more fully developed technology tree in the xml file. The present file is really just a test case. For example we have "War horses" which was actually about 2000 years down the road of horse domestication.

Perhaps it needs Animal domestication, Horse domestication, Riding, before War horses. The first cavalry were not on war horses, but, of course, were on horses big enough to carry them, that is, bigger than chariot horses.

Cheers

[Richard Bruns]

Sorry for the delay; I lost the first reply I composed.

Originally posted by Mark_Everson
I propose that a tech that starts at 0 should Never become inactive, and that RPs can be added to, and have effect upon the level of an inactive tech. These may not be the best solutions, but we need something, or there's going to be train wrecks galore in the Dawn scenario.

I thought this was how all techs operated. Falling below the start value does not mean they disappear; it just means that they are less effective. RP's are still added to them, and a minimum level should be all it takes to get them back up again. Things don't disappear until they drop down to about ten levels below their starting level. For that to happen, they would have to have zero RP input for at least five consecutive turns. Since the player would still have farms in operation, there would still be RP generation after the tech fell.

Besides, an easy way to solve the problem would be to run the econ model before the tech model. That way the RP's can be applied even on the first turn.

I also feel the need for some Specifics about what technological levels, in terms of the real world, these levels represent.

Right now we get crop yields per acre that are about 50-60 times what they were for the first primitive argiculture. Rounding to a 64-fold increase gives a change of 50 tech levels. So the starting farming tech would be level 40. Level 50 would be a doubling of crop yields to 1/32nd of modern agricultural ability.

IIRC Richard above states that "everything is supposed to start around 10".

I didn't say that. What I said was that almost all techs would end up being at least level 10. Lower than ten would mean that things are less than 1/(2^9)th as good as modern techs. Like farming above, the change will rarely be so large. It will be rare to see a thousandfold change.

But even so, the model doesn't break down if the starting tech level is -40. Tech level is nothing more than an interpretation of the Knowledge variable, so can be fairly arbitrary. I've been saying this for a while:

Note: These equations and their related values are a mathematical ‘kernel’ that the players do not have to see. It would be a simple matter for the interface to interpret these values so that “Gunpowder level 50” is presented to the player as a “Gunpowder level 40” or possibly “Gunpowder AD 1720.”

The knowledge variable is the key to the model. If you don't like tech levels, you can use some other way to interpret knowledge. But as I look back, I see that I have failed to deliver equations that match what I have been saying.

I probably made an error in the way that I presented the equations. I see now that it complicated things. What I forced the computer to do is store the tech level, run an equation to unpack it into knowledge, apply the RP's to that knowledge, and then pack it back up into tech level. This is bad design. I should have just had it store and run all equations on knowledge itself, and have a seperate object to read that number and give it to the player in some other form

I am not asking you to make changes. But if you want to, here's what I recommend:

Strip the tech level out of the processing. Pseudocode:

float k = (float)Math.pow(rps, diminishingReturns) *growthRate * helperEffect - upkeep * k; // V = (RP^DR)*m*H*I - E*c*k

Call Display (k)

Display () can then be changed to whatever the designer wants. It could be as simple as:

Print k

or it could apply the tech level:

float Level = growth / (float)Math.log(multiplier) *(float)Math.log(k) + V + startLevel

Print Level.

Or we could get fancy:

Select Case k
Case 1-2 Print "Your" & techname & "is Stone age technology"
Case 2-4 print "Your" & techname & "is Bronze age technology"
Case 4-7 print "Your" & techname & "is Iron age technology"

I suggest that for the next demo, we simply output the knowledge level k to the player. So all techs start at 1 and then grow.

As for linking the two models, it should (theoretically) be a matter of plugging k into the economic equations somewhere:

Food produced = k * farming inputs

The number that the player sees is thus the same number that multiplies the investment for economic activities.

I hope that helped. I may have just muddied the issue further. The basic idea is to make sure we are thinking of k as the core of the model, and that the tech level is simply one possible way of interpreting it for the player. All our disputes seem to be in that interpretation; the core change of knowledge equations seem to be universally agreed upon so we should focus on those. If you need a review of exactly what k is, look at the first post of the thread.

[Mark_Everson]

Hey Richard, thanks for the detailed comments. Yes, they did help, at least for me!

Originally posted by Richard Bruns
Sorry for the delay; I lost the first reply I composed.

Arrgh, I hate that. Hope it wasn't too painful.

I thought this was how all techs operated. Falling below the start value does not mean they disappear; it just means that they are less effective. RP's are still added to them, and a minimum level should be all it takes to get them back up again.

I just wanted to get the effect out in the open, so that it could get fixed

Besides, an easy way to solve the problem would be to run the econ model before the tech model. That way the RP's can be applied even on the first turn.

I'm not sure that would work, the fix above is better. The problem is that a very small economy, as the model now works, might not generate enough RPs to avoid some backsliding. So I wanted a general fix. We need to consider issues like "so small you backslide" at some point, but I don't think its vital now.

Right now we get crop yields per acre that are about 50-60 times what they were for the first primitive argiculture. Rounding to a 64-fold increase gives a change of 60 tech levels. So the starting farming tech would be level 40. Level 50 would be a doubling of crop yields to 1/32nd of modern agricultural ability.

Thanks, this is what I was looking for. I'd forgotten the general approach. BTW I fixed one typo in the quote above the 60 in italics used to be 50. We may need to post a table for how to get these for the less mathematically literate can understand where the numbers come from.

IIRC Richard above states that "everything is supposed to start around 10".

I didn't say that.

Sorry for misquoting you, hazards of being too lazy to find the original post!

I probably made an error in the way that I presented the equations. I see now that it complicated things. What I forced the computer to do is store the tech level, run an equation to unpack it into knowledge, apply the RP's to that knowledge, and then pack it back up into tech level. This is bad design. I should have just had it store and run all equations on knowledge itself, and have a seperate object to read that number and give it to the player in some other form

(snip)
I suggest that for the next demo, we simply output the knowledge level k to the player. So all techs start at 1 and then grow.

That might be more straightforward, allowing easier connection between effects and what the tech model gives as a number. What do others think?

[Richard Bruns]

I need to change some existing equations. In the first post of this thread, I said that tech level was required for helper calculations, and that this was the reason for using tech levels in calculations. In an effort to remove the tech level from the core calculations, I have reformed these equations so that they focus solely on knowledge. As far as I know, helpers have not been coded yet, so hopefully this will make the task easier.

Previously, helper effects were based on the current level of the helper tech minus the level of that helper tech that was required for the other tech to exist. (By the way, this is why helper and required techs are the same. We need to know what level is required in order to know how much it helps.)

Old equations:

So each helper tech adds its effect as follows:

HelperTechEffect * ( Current level – TechRequirement + HelperLevelOffset )

This equation is run for every helper tech, and the results are added together to form a working variable called RelativeHelperLevel. This value is then run through the following equation to determine the TotalHelperEffect value used in the RP to knowledge equation:

TotalHelperEffect = MultiplierVariable^( RelativeHelperLevel / (Growth Variable * GlobalHelperEffect))

Note: We have abandoined the HelperLevelOffset value

So if Engine level 60 was required for Airplanes and we now have Engine level 70, there were ten excess levels that helped the airplanes tech. We can't simply use the full tech level or knowledge amount. If Engines started at level 30, those first 30 levels are not helpful, since they represent knowledge too primitive to put in planes. But mainly, it would makes the math do bad things and create system discontinuities.

Translating into knowledge, this means that an engine knowledge of 16 is required to build planes, and we now have knowledge of 32. The civ now knows twice as much about engines as the Wright Brothers. So it is logical for each helper tech to add its effect as follows:

HelperTechEffect * ( Current knowledge / Required knowledge )

Then these numbers for each helper are all added together to form RelativeHelperLevel, and then the TotalHelperEffect is simply:

GlobalHelperEffect * RelativeHelperLevel

Note that these equations are exactly the same as the previous ones. They simply strip the tech level out of the picture. The relationship between knowledge and helper techs should now be a lot clearer. The GlobalHelperEffect number now does a very different thing, but that is a problem for the designer (me) and not the programmer.

Does this sound good to everyone?

Another change is still needed: the Application equations. These are more closely tied to the tech level, and so will take more thought to reform. But since they won't be programmed for a while, I have some time to think about them.