Demo 6 Technology Model

[Richard Bruns]

I'm at home now, on a very old computer that can't play any of the Clash demos.

I'm confused; what do you need me to do? Simple_Tech_Test.xml should be the test case you were talking about, and I posted it quite a while ago.

[Mark_Everson]

Hi Richard:

The issue is that when I tried to get Tech going with the pre-D6 code there were several bits missing in the chain leading from RP input to change of tech level. The two big issues were that certain techs were not set to 'Active' and so I couldn't change levels of those. The others was that RPs got put in, but nothing happened even when the techs the activities pointed to were active. That's just because (at a guess) Gary was focused on the tech editor at that time, and put in most of his testing effort there, not in tech model Function. It is a very complicated model, and the basics need to be tested reasonably thoroughly. What is needed is a concrete numerical example of what the output should be for given inputs that Gary can use to verify everything is working. The numerical predictions could come from your Tech excel spreadsheet.

I'll elaborate on what I said above to make the test case idea more explicit. Its basically black box testing. You say what the inputs are, and what outputs you expect. You need to specify enough inputs and outputs to thoroughly test basic system function. I'll put in some numbers this time so its maybe less confusing. I picure you saying (and please correct this where wrong):

1. Load Simple_Tech_Test.xml and verify that each tech is entered (I already did this in my tests a month ago, but just to be sure...). The following techs should be Active for the input levels in the sheet (list of techs). The following Activities should exist, etc.

2. Add 100 RPS to the "Food" activity

3. Run a turn of the tech handler

4. The new levels should now be: Farming = 2.36, Biology = 0.63, all others zero.

5. Set levels of Tactics and Metallurgy to 6, verify that Legion is now available (it shouldn't have been with all zeros).

6. Whatever else you think is needed.

Ideally all activities should be tested, but one or two may be good enough.

One other issue is that IIRC most of the tech levels start at 0. Can you fake up a list of tech levels for the Dawn of history, and a separate one for each of Carthago Delenda Est (like 250 BC IIRC) and Attila (what, like 430 AD?)

That way we can use the appropriate tech levels with each scenario, and not be able to build Legions in Dawn...

Gary: should the tech levels be in independent xml files, or just as a list associated with scenario names or some such?

Thanks!

Mark

[Gary Thomas]

For the moment we will have the tech levels in separate files.

However we do need to decide whether an application is a military object or a tech object. I prefer the first of these.

Cheers

[Mark_Everson]

Originally posted by Gary Thomas
With the interface approach, you don't have to worry about an application object. As long as the element archetype implements the application interface that is all that is needed.

Then, when a civ tries to build a unit, it just checks the application methods of the archetype against its technology level to see if it can build the unit, and how effective it will be.

Yes, I know how an interface works. Military is not the only thing that will use Applications, and so potentially many model coders will need to have their own code to implement the interface. Seems wasted effort to me as opposed to having a single Application class in Tech that can be overridden via inheritance as needed by any model coder that needs simple Application function. Application of course should implement ApplicationInterface too, to support Element implementing it. But when implementing the interface the coder can grab the code from the Application object (in Tech) that implements the interface, and not have to reinvent the wheel.

What is the Disadvantage to doing it the way I suggest?

[LDiCesare]

Let us just make Application an interface, put a default implementation somewhere, and then anybody can adhere to it by either derivating or aggregating the appropriate object.
I'd rather have Application and ApplicationImplementation than ApplicationInterface and Application, because the interface should be used more often than the concrete class, to avoid mistakes by sometimes using the short name instead of the interface name.

[Gary Thomas]

What is the Disadvantage to doing it the way I suggest?

It is bad coding practice. You force an object to be ONLY a tech application. The person coding whatever it is may have VERY good reasons for having it extend something else. And Java does not allow multiple inheritance.

Laurent's view is the correct approach, though I would call the interface an Application, and the implementation an AbstractApplication in line with standard Java practice.

On the other hand I have a much more serious problem. See my next post.

Cheers

[Gary Thomas]

For some time now I have been uneasy about the tech application concept. It wasn't until I revisited the code that I realized what the problem is. The important impact of an application is the "effect" value that it can calculate. This, in turn, means that a tech Application is atomic, in the sense that it can calculate only a single effect. Up to this point I have no problem.

The problem arises when something like a trireme UNIT is alleged to be a tech Application. This it is not. It is a complex combination of tech Applications, with a variety of effects.

To produce an example, consider a Parthian cataphract unit. We dismiss the argument about whether these were actually effective in historical terms.

The cataphract unit will have the following parameters (amonst others):

1. Shock attack strength, depending on the lance, war horse and stirrup tech applications.
2. Missile attack strength, depending on the composite bow tech application.
3. Defense, depending on the bronze scale armour tech application, and perhaps the war horse application.
4. Tactical ability, depending on the coordinated charge training tech application.

Note that these tech applications may depend on a variety of technologies.

Each of these items has a different parameter in the resulting unit, which is therefore clearly not an atomic tech object.

Accordingly I recommend that units (actually unit archetypes) include atomic tech Application objects (such as those mentioned in the example) as parameters which return the values such as attack strength.

So, instead of UnitArchetype extending AbstractApplication, the parameters within it could be objects which are (Defense in the example) tech Application objects, or which contain a combination of them which produce a single value (Shock attack strength in the example).

Cheers

Gary

[Mark_Everson]

Hi Gary, your analysis sounds reasonable to me. That will make the Application list shorter. My only worry is that it will make the connection between tech and what the player can build tenuous. I'm burnt out now, will think more about the issue later.

[Richard Bruns]

I have no idea what you mean by atomic, but is you look at the new xml file you'll see that each required tech has a different effect. In the example I typed, the warhorses tech improves one thing and the tactics tech improves different things. Isn't that what you wanted?

I'm afraid that I can't use the spreadsheet on this computer. So I can't come up with exact numbers. But I think the only "test case" that really matters now is the end result.

Test Case 1: Put money into the "Food" activity and see if you grow more food.

Test Case 2: Put money into the "Production" activity and see if your stuff gets cheaper to make.

That ought to do until we decide on a format for applications and military units and I update the XML file to reflect whatever we decide.

Right now I'm burned out from exams and am quite tired and my net conenction is as slow as molasses, so I'm sorry I can't be more helpful.

[Mark_Everson]

Hi Richard:

We can use my test case, or whatever fraction of it Gary feels like doing... First we need to figure out the Application thing Gary's brought up anyway...

I am a little blurry, but I think we need to figure this out soon, so I'll take a shot at it. If it is incoherent pls tell me and I'll try again later...

I have had a little more time to think about the 'atomic' application issues. I believe the items that Gary decided should be Applications:

1. Shock attack strength, depending on the lance, war horse and stirrup tech applications.
2. Missile attack strength, depending on the composite bow tech application. etc.

Are what Richard called Skills (level 3 techs) in the model from of old. I also have become more convinced that the player will want a firm boundary where they can make an Element. (Gary, you used unit above, but IIRC the idea was to have the elements be the Applications) Then units are assembled from the elements that are available.

What we had before this issue came up:
Skill and other appropriate techs had their levels rolled together to produce an Application effectiveness.

Example: Application Legion derives its effectiveness from levels of Metallurgy and Military Tactics. Right now it is that simple because its from the test tech thing. In the fullness of time it would have perhaps had Skills like Swordmaking utilized.

The old system is logically consistent if not necessary a good object model (I bow for the moment to Gary's judgement of such things here).

Advantage: Player knows they can make a Legion when the Legion Element becomes available, as determined by the minimum tech levels of Metallurgy, etc.

Disadvantage: effectivenesses are created in an arcane way. It may be hard for the player to estimate how effectiveness changes.

Summary: Availability of Element easy to figure, effectiveness not really intuitive

Gary's proposal: Well you can read it for yourself up above.

We take Gary's word that his is a better object model at least for now.

Advantage: effectiveness is more concretely stated than before as something like a weighted sum of effectivenesses of components. Although if they are all as complicated as the example above in Gary's post nobody will ever figure anything out anyway since there are too many factors to keep track of!

Disadvantage: We now have two levels of the model, Skills and Applications, with essentially the same model function. There is no Legion Application, and I guess whether a Legion exists needs to be figured out by (my guess) seeing if its effectiveness is a certain minimum. We need to figure this out if we're to go in the direction of Gary's model.

An idea for how to reconcile these...

[edit] I withdraw this proposal since I think it would upset things too much at the moment. But I'll leave it here in case anyone wants to see the idea.

It pretty much maintains the scaling properties etc of Richard's model, although it does bend the model a bit. May be too radical a change.

Level 1 and 2 techs are as before. Skills (Level 3) take on the characteristics of Applications in Gary's approach. Skills are now 'atomic' capabilities of the civ that return an effectiveness. Players don't care about levels for skills, because effectiveness is the key thing. What was level 4 (Applications) I will call Artifacts for now, just to *try* to avoid confusion. Artifacts are things the player can Build They have an effectiveness that is a combination of skill effectivenesses. Artifacts can be built when a given effectiveness level is reached. The nice part about this definition IMO is that it gives the player something they want to know anyway... How to compare element fighting power. So if a 1903 rifle element has an effectiveness that starts at 30, you Know its about twice as good as the rifled musket Element that becomes available at 15.

Well I think you've got the idea, maybe something a lot less wrenching can be done to reconcile Gary's point and our previous system.

See you all later, and hopefully with fewer fatigue poisons in my system. I hope I haven't made things worse!

[LDiCesare]

I'm totally lost now, so I'll just describe how I integrated tech with miltary and you can tell me which approach that fits, if any, and how it should be done:
First the military xml file displays the following:
{element} charger (...)
{requirement}
{name}Military Tactics{/name}
{startlevel}10.0{/startlevel}
{effect}
{type}Attack{/type}
{addPerLevel}1{/addPerLevel}
{factorPerLevel}0.03{/factorPerLevel}
{/effect}
{effect}
{type}Defense{/type}
{addPerLevel}1{/addPerLevel}
{/effect}
{/requirement}
{/Element}
You can have many requirements per element and effects per requirement.
Second, the code looks for each requirement, the related tech (a string now), retrieves the tech level from the civ, and adjusts the stat accordingly.
To me, each effect in the xml example here is a skill in the evolving vocabulary.
So, I can have my MilitaryTechEffect class adhere to Application or Skill, but the element and unit above it should also implement the interface, although they won't have any modifier associated to them, just to be able to say "I need this tech to be built".
So I have an Application interface which states only required techS , and maybe a Skill interface with one tech and effect methods/stats. I am not sure I need the lower level interface to accomplish anything, though. Am I missing something?

[Mark_Everson]

Yeah, on balance I think your approach is good. Certainly good enough that we can test it before considering completely rejiggering the system.

I withdraw my idea from last night!

For now I guess it could be coded Gary's way, and the effectiveness for Laurent's cases would for now just be the level. Then we could refine later if needed. Everyone ok with that?

[Gary Thomas]

What worried me was seeing Horde and War Band in the tech xml file. Horde and War Band are not technologies, they are unit types (elements if you like), and may have many "effects" not just one as implied bythentech model.

By "atomic" I meant irreducable - in this case, having only a single effect, not the multiple effects required by elements.

It seriously worried me that we have element archetypes in both the military data and the tech data, apparently meaning quite different things.

My proposal was simply that tech applications should single faceted (that is, having only one effect). If they have more than one effect, they are not tech applications.

However, if I were designing the architecture in this area I would probably provide a multiple effect object, using a variety of tech single effect "applications" to be used for all built entities, whether military, civil engineering or whatever. These would be implemented both as an interface and as an abstract object, giving the coder the choice of which to use.

However, as long as there is a clear distinction between "element" (military model) and "application" (tech model) I do not really have a great problem, but would really prefer that the objects do not have the same names in the different areas.

Cheers

[Mark_Everson]

That's ok by me. Is everyone content doing it this way?

[Richard Bruns]

I'm still confused about what is going on, so I'll try to explain from the start and hope I help the situation.

Originally posted by Gary Thomas
What worried me was seeing Horde and War Band in the tech xml file. Horde and War Band are not technologies, they are unit types (elements if you like), and may have many "effects" not just one as implied bythentech model.

I think understand this problem. I tried to put too much information in the tech model xml file. There should probably only be the following:

Required tech level
Tech level for obsolescence (optional)
Change in effeciveness due to changes in tech levels

That last seems to have caused confusion. There are many techs that affect the application's effectiveness, and many different effects of the application. In the example above, the element "light cavalry" had attack, defense, health, and movement points, each of which could be affected by multiple technologies.

I do not think it would be good to make each of these a seperate application. I don't know anything about the object model, but in the interface the player should see light cavalry as a single application that is made available as a certain tech level.

The military xml file would determine all of the relevant stats for the unit, and the tech file would only determine the rate of change of those stats. Is this good?