Demo 6 Technology Model

[Richard Bruns]

Ok, I found the problem. The change in V is exactly as it is on the spreadsheet. However, V is not the change in tech level. It is the change in knowledge. The model had to convert this back to tech level change. The final equation is:

newLevel = growth (GV)/LN(multiplier (MV))*LN(k+V)+ startLevel (Ts)

If you add that line in it should work fine. All the architecture seems to be in place; it looks good otherwise. It may seem like a bug for tech level to be negative, but it is supposed to work that way. Tech will usually start at a level of at least ten, and we wanted it to potentially drop below the starting value. I have tested such things and the model does not break at negative tech levels. (If k were ever to become negative, the model would die, but that won't happen as long as upkeep (c) is below 1.)

One more thing: The helper calculation, to my untrained eye, looks as if it only can reference one helper tech. Is this the case?

[Gary Thomas]

multiplier (MV)
startLevel (Ts)

How do I interpret these lines?

The helper effects are summed over all the helpers

Cheers

[Gary Thomas]

Here is the missing bit of code:

  /**
   * Calculate the helper effect for one technology or application.
   * @param data the technology or application
   */
  float getHelperEffect(NamedObjectList data) {
    float result = 0.0F;
    for (Iterator iterator = data.iterator(); iterator.hasNext(); ) {
      Helper helper = (Helper)iterator.next();
      float helperLevel = getLevel(helper);
      result += helper.calculate(helperLevel);
    }
    result = (float)Math.pow(GlobalData.getMultiplier(), result);
    return result;
  }

Had to edit this, it interpreted part of the code as a smiley!

Cheers

[Gary Thomas]

How do I interpret these lines?

Read it a bit more carefully, I didn't realize before that you had both names in!

The modifications are now done.

I hope you realize that you are getting:

newLevel = growth * log(k + V) / log(multiplier) + startLevel;

not

newLevel = growth / ((multiplier) * log(k + V)) + startLevel;

Here is the new log file:

Fred, Biology research points incremented by 20.0 to 20.0
Fred, Farming research points incremented by 80.0 to 80.0
Fred, Military Tactics multiplier (MV) = 2.0
Fred, Military Tactics growth (GV) = 10.0
Fred, Military Tactics growthRate (m) = 0.01
Fred, Military Tactics upkeep (c) = 0.02
Fred, Military Tactics diminishingReturns (DR) = 1.0
Fred, Military Tactics startLevel (Ts) = 0.0
Fred, Military Tactics helperEffect (H) = 1.0
Fred, Military Tactics levelValue = 0.0
Fred, Military Tactics rps = 0.0
Fred, Military Tactics k = MV^((Tn-Ts)/GV) = 1.0
Fred, Military Tactics V = (RP^DR)*m*H*I - E*c*k = -0.02
Fred, Military Tactics newLevel = -0.29146317
Fred, Farming multiplier (MV) = 2.0
Fred, Farming growth (GV) = 10.0
Fred, Farming growthRate (m) = 0.01
Fred, Farming upkeep (c) = 0.02
Fred, Farming diminishingReturns (DR) = 1.0
Fred, Farming startLevel (Ts) = 0.0
Fred, Farming helperEffect (H) = 1.0
Fred, Farming levelValue = 0.0
Fred, Farming rps = 80.0
Fred, Farming k = MV^((Tn-Ts)/GV) = 1.0
Fred, Farming V = (RP^DR)*m*H*I - E*c*k = 0.78
Fred, Farming newLevel = 8.318772
Fred, Production multiplier (MV) = 2.0
Fred, Production growth (GV) = 10.0
Fred, Production growthRate (m) = 0.01
Fred, Production upkeep (c) = 0.02
Fred, Production diminishingReturns (DR) = 1.0
Fred, Production startLevel (Ts) = 0.0
Fred, Production helperEffect (H) = 1.0
Fred, Production levelValue = 0.0
Fred, Production rps = 0.0
Fred, Production k = MV^((Tn-Ts)/GV) = 1.0
Fred, Production V = (RP^DR)*m*H*I - E*c*k = -0.02
Fred, Production newLevel = -0.29146317
Fred, Warhorses multiplier (MV) = 2.0
Fred, Warhorses growth (GV) = 10.0
Fred, Warhorses growthRate (m) = 0.01
Fred, Warhorses upkeep (c) = 0.02
Fred, Warhorses diminishingReturns (DR) = 1.0
Fred, Warhorses startLevel (Ts) = 0.0
Fred, Warhorses helperEffect (H) = 1.0
Fred, Warhorses levelValue = 0.0
Fred, Warhorses rps = 0.0
Fred, Warhorses k = MV^((Tn-Ts)/GV) = 1.0
Fred, Warhorses V = (RP^DR)*m*H*I - E*c*k = -0.02
Fred, Warhorses newLevel = -0.29146317
Fred, Metallurgy multiplier (MV) = 2.0
Fred, Metallurgy growth (GV) = 10.0
Fred, Metallurgy growthRate (m) = 0.01
Fred, Metallurgy upkeep (c) = 0.02
Fred, Metallurgy diminishingReturns (DR) = 1.0
Fred, Metallurgy startLevel (Ts) = 0.0
Fred, Metallurgy helperEffect (H) = 1.0
Fred, Metallurgy levelValue = 0.0
Fred, Metallurgy rps = 0.0
Fred, Metallurgy k = MV^((Tn-Ts)/GV) = 1.0
Fred, Metallurgy V = (RP^DR)*m*H*I - E*c*k = -0.02
Fred, Metallurgy newLevel = -0.29146317
Fred, Biology multiplier (MV) = 2.0
Fred, Biology growth (GV) = 10.0
Fred, Biology growthRate (m) = 0.01
Fred, Biology upkeep (c) = 0.02
Fred, Biology diminishingReturns (DR) = 1.0
Fred, Biology startLevel (Ts) = 0.0
Fred, Biology helperEffect (H) = 1.0
Fred, Biology levelValue = 0.0
Fred, Biology rps = 20.0
Fred, Biology k = MV^((Tn-Ts)/GV) = 1.0
Fred, Biology V = (RP^DR)*m*H*I - E*c*k = 0.17999999
Fred, Biology newLevel = 2.387868
Fred, Military Tactics, setting level to -0.29146317
Fred, Production, setting level to -0.29146317
Fred, Biology, setting level to 2.387868

Cheers

[Richard Bruns]

Originally posted by Gary Thomas
I hope you realize that you are getting:

newLevel = growth * log(k + V) / log(multiplier) + startLevel;

not

newLevel = growth / ((multiplier) * log(k + V)) + startLevel;

Yes I do realize this. The numbers are now correct. Thanks for all your work.

[Gary Thomas]

If this post had a title it would be "Use of the Technology Model".

My access to the forum is VERY limited - I have ten minutes, so I cannot research the actual model specifications. I have to go on a combination of my memory and the way the code works.

The technology model provides the following:

An Activity which distributes research points around technologies. This is written and works, and seems to require neither change nor improvement.

Technologies and Applications. Technologies have levels and tiers, Applications have univariate effects (it isn't implemented in the code because I have been unable to find the equation). Otherwise they are completely identical in the code.

The only thing that uses the technology model is the military model, which does so in the following fashion:

Each element archetype (the pattern for an element - the building block for a unit) has a list of requirements. Each requirement specifies a technology (not an appliaction), and has a list of things which I will term properties (they include things like "attack", "defense", "morale").

Each technology has a start level specified in the military xml.

Each property has has an addPerLevel and a multiplierPerLevel.

Each time an element property is required, it searches the list of required technologies, and for each property name in the list of properties it checks to see if the property we are interested in is the current one. If so it modifies the value of the property and returns the result.

If properly designed this search would not be required.

Applications are not used at all.

It seems to me that most of the coding in the military model should be in the tech model. Also, the Application concept in the tech model is too simplistic to be useful. In effect, you need an application for every characteristic (there are about 20 of them) of every military element (there will ultimately be hundreds).

What is needed is a reworking of this part of the model to provide what is actually needed.

Unfortunately I have to go now. I will continue my comments tomorrow.

Cheers

[LDiCesare]

Agreed, most of the code should move from the military to the tech code. The various tech requirements should push an event when they are modified, so the element archetype can update its value. That was btw the original plan, and why ElementArchetype implements Observer. The tech should send some message/call some methods on registered applications when its level change, so that the effects are computed again, and only when tech level changes. I called here application something which is ElementArchetype, but it could adhere to an application interface.
Note that this rewriting is needed because the current code is slow, but it doesn't show, so it is a bit of performance problem. Having application interface that manages registering and updating could however provide a framework for uses of tech other than military.

[Richard Bruns]

Originally posted by Gary Thomas
Each time an element property is required, it searches the list of required technologies, and for each property name in the list of properties it checks to see if the property we are interested in is the current one. If so it modifies the value of the property and returns the result.

If properly designed this search would not be required.

I don't understand. What do you need us to change?

Also, the Application concept in the tech model is too simplistic to be useful. In effect, you need an application for every characteristic (there are about 20 of them) of every military element (there will ultimately be hundreds).

That was never planned. We never wanted applications named "legion attack" or "phalanx movement." There is one legion application, and a few "unit attack" technologies that increase all units' attack power. Is there something in the code that requires all of these seperate applications?

[Plutarck]

About Becoming Obsolete

In Mark's example of the bombard canon above, I realised something I feel I should add.


I see the following for when something (Unit, Building, Wonder Effect, Application, whatever) becomes obsolete:

1) Obsolete with Tech (such as, Alchemist's Lab becomes obsolete when Chemistry is invented).

2) Obsolete when something is built (Wonder, Unit, Building, etc).

3) Obsolete when an item is available for building (like #2 above, but this is when something Can be built, not when it Is built).


Then there are the following kind of "Obsolete":

1) NoBuild: For instance, if Pikeman is available to be built then you cannot build a Hoplite. (This example will be needed when "resource networks" become available, or if different regions under your control can have different tech levels. But that's a different issue.)

2) StopWorking: The effect or ability of something "stops". For instance when Synthetic Factory is built, Rubber Factory should cease it's use.

Don't know whether or not the Rubber Factory (not a Trojan Factory - that's different) should be sold off/scrapped, stay but no longer cost maintenance, or just stay there as normal but have no effect.

Note that you may never be able to build either of the mentioned buildings in Clash, but it's just a "for instance".

3) Extinct: All instances of something Extinct just disappear/disband/get sold off. Poof.



Just something to keep in mind when designing the XML files, and deciding how Applications will work.

[Gary Thomas]

Richard:

I don't understand. What do you need us to change?

That comment was aimed at the way the military model does the scan, not at you or the tech model.

That was never planned. We never wanted applications named "legion attack" or "phalanx movement." There is one legion application, and a few "unit attack" technologies that increase all units' attack power. Is there something in the code that requires all of these seperate applications?

That isn't the problem. The problem is that there isn't anything as simple as a "legion application" with a single effectiveness value.

Here I propose an example which is intended to show what the problem is.

Suppose we have an application called Biplane, which depends on just two technologies called "Guns" and "Engines" (don't worry about whether these are reasonable technologies, I am trying to make a point about single valued applications). The unit based on this application we will also call "Biplane", without, I think, any confusion. The Biplane unit has just two properties, "Attack" and "Speed".

Now, the Blue and Red civs are both into building Biplanes. The Blue civ thinks that guns are the way to go, so pours all its research into Guns. The Red civ, on the other hand, is a speed freak, so pours all its research into Engines. So one ends up with high tech in Guns, and one in Engines.

When the biplanes get to fight it out, they consult the application they are based on, and derive an effectiveness value, based on a weighted average of the two relevant technologies. And the values come out exactly equal, one because Guns is high, one because Engines is high.

These identical effectiveness values are now applied to the Biplane units, which now turn out to have identical Attack and Speed values because the Application effectiveness values are identical.

Is this the way the tech model is supposed to work?

If so, I see problems.

If not, please explain where I am going wrong in my interpretation.

Cheers

[Mark_Everson]

Hi gents:

I started out this post defending the original way of handling applications. My main argument was I didn't see much fun in the added complexity. But you will see that by the end I changed my mind! The marvels of putting prose to paper for making the mind work in an organized fashion. I will leave the whole thing here, just so you can see my thought processes. But if anyone is strapped for time, you can just read the last two paras.

Hi Gary, I've been thinking about your issue a bit more. I realize that the original application model fails as a real-world-simulator. But so does almost everything else we do in Clash at some level... I'm hard pressed to imagine a case where any but one player in 100 would bother to dig through the details to see the difference you are talking about, or even care. The biplane example is somthing that'd be critical in a game about dogfights. In a strategic game where the true effectiveness of a unit in the field (or air in this case) is the result of myriad factors that combine in different ways in each combat, it just seems overkill. That's why the group that came up with the original model thought one Effectiveness number that all characteristics of a given Application scaled with was sufficient.

Most battles will be won by the aggregate number of forces, composition in terms of combined-arms effects, field position, Overall (not detailed) technological edge, etc. I have tried, but I just can't see where the added complexity Really pays off.

If this is an issue where the code archetecture would be screwed up to do it the original way, that's a valid point. But you didn't phrase your argument that way.

I guess if you personally can't be happy with Clash unless it has this effect, I'd be willing to go with it. The system could handle it IMO with relatively few issues. (What do you think Richard?) At worst it adds a bit of complexity that really isn't needed.

About the biggest disconnects I can think of due to the non-atomic nature of effectiveness would be like a ship that needs chronometers and a ship speed characteristic. I admit it does seem a little odd that when timekeeping gets better the speed magically improves. Then again, maybe that's not so odd if the chronometer enables the ship to make a more precise course, increasing net speed. Maybe this wasn't a good example after all...

Another argument for 'guns' vs 'engines' would be player fun, in being able to design 'our' plane to be different from the enemies'. Or to be able to go all-out to increase the strategic range of fighters to be able to get bombers escorted to a just-out-of-reach target. In this case we'd need an Airplane Range level of detail in applications, which doesn't seem too bad to me. I guess this is the best recommendation I can see for doing it the detailed way. I think many players would get a rush from being able to use technology directly to enable their strategic ends. This would be an especially important aspect in scenarios, which, by their nature can afford to be more detailed than the default game.

I do like this idea, because it would allow the player to do Important things using Tech that will affect the Strategic landscape. So by the end I've flip-flopped from my original position...

[Plutarck]

In the search for the best of both worlds (I increasingly believe that two contrary statements can be equally true ), how about this. I don't know the proper names that everyone else is using, so I'm just going to make up my own here.


Let's say you have a Tank unit.

A Tank has Attributes, which are: Attack, Defense, and Movement (there can be as many or as few as is decided, but this is simple enough for explanation).

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


So if you don't need the complexity, you can easily remove it from the configuration file! Especially nice for simple scenarios, or early on when features are still limited.

And it doesn't Look like it would be very hard to implement, but Gary would know that best.


Am I right here, or am I just totally clueless as to the issue at hand?

[Gary Thomas]

Mark, you now have me confused about which point of view you support. Has that fever got to you?

The example I used was simply to illustrate the problem.

The real problem is shown by the working code, agreed to, it seems, by everybody but me. I approve of the concept, though not the actual implementation.

The existing code has no applications, but does have multiple technology effects, achieved by writing some of the technology code in the military model.

The military element, "Charger" has the following code in military.xml:

&ltElement&gt
  &ltname&gtCharger&lt/name&gt
  &ltImage&gtLight Cavalry&lt/Image&gt
  &ltdefault&gtWarrior&lt/default&gt
  &ltcategory&gthorse&lt/category&gt
  &ltattack&gt80&lt/attack&gt
  &ltmovement&gt30&lt/movement&gt
  &ltDistance&gt20&lt/Distance&gt
  &ltMobility&gt6&lt/Mobility&gt
  &ltMorale&gt11&lt/Morale&gt
  &ltCost&gt
  &ltFood&gt4&lt/Food&gt
  &ltProduction&gt20&lt/Production&gt
  &ltServices&gt1&lt/Services&gt
  &ltDecay&gt0.03&lt/Decay&gt
  &ltTraining&gt5&lt/Training&gt
  &lt/Cost&gt

  &ltrequirement&gt
    &lttechnology&gtWarhorses&lt/technology&gt
    &ltstartlevel&gt10.0&lt/startlevel&gt
    &lteffect&gt
      &lttype&gtMobility&lt/type&gt
      &ltaddPerLevel&gt.1&lt/addPerLevel&gt
    &lt/effect&gt
    &lteffect&gt
      &lttype&gtAttack&lt/type&gt
      &ltaddPerLevel&gt1&lt/addPerLevel&gt
    &lt/effect&gt
  &lt/requirement&gt

  &ltrequirement&gt
    &lttechnology&gtMilitary Tactics&lt/technology&gt
    &ltstartlevel&gt10.0&lt/startlevel&gt
    &lteffect&gt
      &lttype&gtAttack&lt/type&gt
      &ltaddPerLevel&gt1&lt/addPerLevel&gt
      &ltfactorPerLevel&gt0.03&lt/factorPerLevel&gt
    &lt/effect&gt
    &lteffect&gt
      &lttype&gtDefense&lt/type&gt
      &ltaddPerLevel&gt1&lt/addPerLevel&gt
    &lt/effect&gt
  &lt/requirement&gt

&lt/Element&gt

From this it can be seen that the property "Mobility" depends on Warhorses, "Defense" depends on Military Tactics, and "Attack" depends on both. Thus concentrating research efforts in some area will affect the relative values of the the resulting unit.

This is what we have currently working.

A factor that has sneaked in here (one that I approve of) is what amounts to an anonymous Application. The "requirement" here is very similar in specification to an Application, but has no name, and is embedded in an element specification. The element is the only thing that uses it (though Laurent's Default system means that any element that has Charger as default will also have these requirements, in particular, Chariot also has them). This means that the specification is held in the element, where it should be, not in a general list in the technology model (we are talking of data here, not code).

In essence, this system implements a multiple Application system.

I have some areas in which I disagree with the approach.

The first is that I think the code should be in the technology model, because it is generic - other models than the military will want to use it. Laurent agrees with that approach.

The next is that the xml is organized around requirements, whereas I would organize it around properties. The main effect is that instead of a having multiple scans of lists, it would use polymorphism to go directly to the technologies required for a particular property.

Under my system it would be organized by properties, as follows:

  &ltMobility&gt
    &lttechnology&gt
      &ltname&gtWarhorses&lt/name&gt
      &ltstartlevel&gt10.0&lt/startlevel&gt
      &ltaddPerLevel&gt.1&lt/addPerLevel&gt
    &lt/technology&gt
  &lt/Mobility&gt

  &ltAttack&gt
    &lttechnology&gt
      &ltname&gtWarhorses&lt/name&gt
      &ltstartlevel&gt10.0&lt/startlevel&gt
      &ltaddPerLevel&gt1&lt/addPerLevel&gt
    &lt/technology&gt
    &lttechnology&gt
      &ltname&gtMilitary Tactics&lt/name&gt
      &ltstartlevel&gt10.0&lt/startlevel&gt
      &ltaddPerLevel&gt1&lt/addPerLevel&gt
      &ltfactorPerLevel&gt0.03&lt/factorPerLevel&gt
    &lt/technology&gt
  &lt/Attack&gt

  &ltDefense&gt
    &lttechnology&gt
      &ltname&gtMilitary Tactics&lt/name&gt
      &ltstartlevel&gt10.0&lt/startlevel&gt
      &ltaddPerLevel&gt1&lt/addPerLevel&gt
    &lt/technology&gt
  &lt/Defense&gt

At this point each property becomes, in effect, an anonymous application.

This system becomes easy to code, and produces a clean OO system that can also be applied to any type of production. Although there has not been any progress in this area, a technology like banking could assist the production of kapital (I am so glad that someone else has at last objected to this thoroughly offensive "in" term which is being foisted on the rest of us).

Mark is wrong in claiming this approach is too detailed. You can achieve the same sort of detail with the existing model, but only at the cost of large numbers of named applications, removed from the area they describe.

I emphasize yet again, that this system is already in use in the code.

Cheers

[Mark_Everson]

Hi Gary:

While its possible I'm fever-addled, I don't think so. Though perhaps it takes an external observer to be sure!

I was contrasting what you were saying in the "guns" vs "engines" post to a quote by Richard:

First, you said something that Richard then replied to:

Also, the Application concept in the tech model is too simplistic to be useful. In effect, you need an application for every characteristic (there are about 20 of them) of every military element (there will ultimately be hundreds).

And Richard replied:

That was never planned. We never wanted applications named "legion attack" or "phalanx movement." There is one legion application, and a few "unit attack" technologies that increase all units' attack power. Is there something in the code that requires all of these seperate applications?

I took Richard's quote to harken back to the original one-effectiveness system, perhaps slightly modified. I am well aware of what is already in the code. Perhaps I should have checked with Richard to make sure what he said was what I thought he said first...

Anyway, I am with you that the coding details you want changed seem to all make good sense.

[Gary Thomas]

I took Richard's quote to harken back to the original one-effectiveness system, perhaps slightly modified. I am well aware of what is already in the code. Perhaps I should have checked with Richard to make sure what he said was what I thought he said first...

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 also realize that you are aware of what is in the code. So am I and so is Laurent. Unfortunately it stops there. I am trying, in effect, to get some sort of general realization and, if possible, consensus, for using the underlying idea that Laurent has based his code on. That is, multiple technology effects on an object (in particular, a military element), distinguished by the fact that different Parameters of the object are affected by different technologies.

Once that is, as it were, formalized (or moved out of the de facto category), I will write general code for the technology model, to take it out of the military model. As I said some time ago that I would do.

Cheers