05-01-2002 12:05									#61
	Support Apolyton buy from Amazon

I'd rather have the tech requirements of the military units in the military file. If you want to add/mod a unit/element, you are able to do it in a single place instead of editing two files. I know that, to add a tech, you now have to edit two files, but I'd rather have a tech xml describing its tech tree and requirements and several application xmls that refer to the techs if an application needs additional information. It is also simpler for me to have in a single file because I do not have to repeat the name of the element in several files, which is important when it comes to parsing: Having separate files doesn't make any supposition on which is parsed first, whereas having unit definitions in one and tech for these in another requires parsing military stuff first, which I feel awkward should any more models come around. Currently, nobody outside the military model even knows it parses a file, I'd rather not change that.

	05-01-2002 22:40									#62
	Increase the size of your Attachments

So Techs and Activities will be in the tech file and all Applications will be in their own files? That should work well. It makes the editor a lot easier to deal with, since only one type of application will be in each xml file. I was dreading the creation of a tech editor that could handle all the different applications.

	08-01-2002 00:33									#63
	Get a bigger avatar today!

The possible applications will include a great deal of data that is of little relevance to the technology model so the data should, as Laurent says, be in their own files.

Also, as I said before, a single entity that uses the technology model may have a number of applications in it.

Cheers

	10-01-2002 06:58									#64
	Support Apolyton, buy Call to Power 2

Ok, it seems like we've got some level of agreement. Let me state where things seem to be to me, and fill in a few details. Then we'll see if everyone's happy.

The top 3 levels of the tech hierarchy haven't been discussed much here, and I assume they stay as-is. There we have Theories thru Skills. Each of these evolve as previously stipulated by adding RPs and using the tech model equations. Each type can tell you what its level is. I note here that Skills seem to already fit Gary's definition of providing 'atomic' characteristics from which to build more complicated things link military elements. Laurent and Richard have derived complicated multi-dimensional elements using levels of skill as the input. This approach seems versatile enough to be able to support virtually anything we care to do.

It is possible that we need one or more tech areas (in the three upper tiers) that directly provide effectiveness (as opposed to tech level), but that doesn't seem to be needed at least at the moment.

At the Application end is where we have the train wreck.

As to what were Applications... I'll still call them Applications here, but they seem to have evolved a bit. It appears there is consensus that Applications should be handled mostly within the scope of individual models (military, etc.) which seems eminently reasonable. The tech interface will need to know what the Applications are, so it can inform the player as to how to achieve them, etc. but otherwise shouldn't play a role in their existence other than providing the technological context via tech levels of involved technologies. Since the model leads/coders are figuring out effectiveness for various things like unit elements on the side, the old Application effectiveness formulae are no longer relevant.

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:

A name and description

A condition when it becomes Active/Useable. This can be as previously stated in terms of levels of various techs, or perhaps overridden by the model owner in some TBD way. For now lets just stick with tech levels. The former list of helper techs is now a list of required techs, and the levels those techs need to have for the Application to turn on.

Optionally a similar function for when the Application becomes obsolete.

Some sort of registration with the tech model, or the tech model can go out and find them after initialization. Purely for use in the tech GUI.

Additionally we should IMO have an object called Effect that handles turning levels into effectiveness. I suspect Laurent already has something similar from the xml snippets he's posted. Effect would hold the formula for one particular attribute, like a military element's attack strength.

The applications definition would be altered to:

Name: Bombard Cannon

Description: blah blah blah, and if you want something more detailed take a look into this here cannon fella.

Techs and levels required:
Chemistry--Level 40
Metallurgy--Level 50
Physics-Mechanics--Level 30
The isActive is trivially derived from the techs.

Obsolete: Insert techs/levels for Artillery here, or some such.

And a container to hold an arbitrary number of Effects the Application will have.

I also think an Overall effectiveness value, figured in a way of each model's choosing might be of use for players learning the ropes. Just so they know a Clipper Ship is better than a Cog. But this is not essential, and an easy retrofit.

To sum up, the Tech model itself IMO should only have a specification of minimal characteristics for a generic Application. Beyond that the individual model lead takes over. The users of Applications and Richard will need to get together and amass some rules of thumb as to what all the tech levels Mean, so that the people familar with cataphacts can translate the levels into effectivenesses in an historically reasonable way.

In coding terms, as was I think consensed to earlier, Application would be supported as an interface, and also a base object Application that handles the requirements above. To use it the model coders either implement the interface, or inherit from Application.

Based on what I have read, I don't think this is controversial, just a summary with a little bit of synthesis. Let me know if this looks ok to everyone, and if not where I've blown it.

	10-01-2002 13:03									#65
	Help yourself to an AD-FREE life

quote: I suspect Laurent already has something similar from the xml snippets he's posted.

Yes, I have. It is currently a class called MilitaryTechEffect. I am not sure whether there is much to share betwen this class and others, but maybe it can adhere to an interface if we need it.
On another topic, how many RPs should "Military Tactics" get after a fight? I bet it depends on successful or not and other factors, but I have no idea of the amount to put in right now.

	10-01-2002 22:40									#66
	Support Apolyton, buy Call to Power 2

There is one thing I'm not clear on. Does the tech model run the effectiveness equations or does it simply feed a tech level to the other model?

Case 1: Tech model determines application effectiveness and gives that data to the other models (The original plan)

Case 2: Tech model passes the tech levels to the other models, and they calculate application effectiveness. (New proposal)

If it is the first case, the equations for effectiveness change due to tech level change will have to be in the tech xml file. In the second case, these equations will all be in the other file.

In the first case, the processing is centralized but the data and definitions are split between two files. In the second, the data is all in one place but the tech model has to pass tech levels to all the other models.

If the tech model passed out all the tech levels anyway, then we don't even need to list the applications in the tech xml file at all. Everything, including creation, obsolescence, and growth, could be defined in the other files and run in the other models. The tech model would not worry about things like units, but would simply pass out tech levels to the military model and let it worry about what to do. This would seem to be more in line with the "black box" design philosophy.

This would require more work for the other model leads. They have to determine how their stuff changes with tech level. But it also allows much more flexibility, in that each model lead could handle tech change as they choose.

Is that what we want to do?

	11-01-2002 01:39									#67
	Full PM-box? Change here!

Laurent: Me either. It should actually go to an Activity rather than straight to Military Tactics. Richard, any ideas?

Richard: I believe we should do case 2. When the other models need them, they get the levels from various techs to calculate effectivenesses. The Applications should not be listed in the tech xml file. I thought you and Laurent had already basically agreed to that...

I think this is what we want to do. But you tell me if it seems ok by you.

One alternative that I mentioned above, is that instead of levels, every Tech object (Theory thru Skill) would provide an effect number to the other models. The model leads could then use the effect numbers, which should be easier to manage since they should be more similar to Application effectiveness numbers and not require as much in the way of formulas. Then the tech requirements for an Application would be listed in terms of effect number rather than level. Laurent has already started down the "use Levels" route, and I am not sure that all that much is gained by using effect numbers, so I haven't pushed this approach further.

	11-01-2002 15:10									#68
	Inflate your Upload Space

I also vote for case 2 as it is what I already coded. The main reason to do it that way is that there are several effectivenesses for one application (e.g. attack and defense). And the xml tags are those we agreed about. It's just they are in the military file.
If there is a need for the tech model to know the activities, they will just register to the tech model from where they are created.
I see it from a modder point of view: If you just want to change or rearrange a few units, it is better to manage all units in the same file, as you have the figures handy.

	12-01-2002 05:06									#69
	Tired of ads?

Ok good. I shall remove applications from my tech editor.

	19-01-2002 01:23									#70
	Support Apolyton or Terrorists Win

Am I supposed to be doing anything with tech now? Until the tech test is implemented, it seems that all I can do is wait and see what has to be tweaked.

	19-01-2002 03:44									#71
	Inflate your Upload Space

Hey Richard:

Thanks for checking up on this.

Last I heard from Gary he was expecting to finish up tech soon, this weekend IIRC. I don't know it that'll include the player input GUI bit or not. My guess is not.

About the only thing you can do at this point is get us a crude map of Metallurgy Level 3 = Bronze Working; 7 = Iron Working sort of facts to us, so we know how to convert the levels into effects.

	19-01-2002 11:44									#72
	Support Apolyton, buy Galactic Civilizations

Richard, there is one point for which I would need an answer: How many RPs are gained from a battle, and where do they go (which Activity?)? I know the tech/military code works, but only as far as tech influences military values.

	19-01-2002 19:56									#73
	Support Apolyton, buy Galactic Civilizations

I can't give an answer to that one. That is one of the values that will have to be tweaked by playtesting. For starters, let's say that the civ gets one RP for the battle plus one for each of its elements involved in the battle, whether the civ wins or loses. Defeats are instructive as victories.

So if the Romans use a 6 element TF to stomp a Carthaginian 2 element TF, the Romans get 7 RP's and the Carthaginians get 3.

Somewhere in the GUI we should have an option to multiply this value by a user-input value like .5 or 3, so as to experiment with different values. So if the user input a multiplier of 3, the values from that example battle would be 21 and 9.

	19-02-2002 23:12									#74
	Increase Your PM Length

I have gone over the technology code carefully, and corrected an omission which prevented research points being noticed.

The actual calculations are reproduced here so they can be checked. Even without knowing Java they should be reasonably clear.

The helper calculation:

code:

  public float calculate(float level) {
    return effect * (level - levelOffset) / GlobalData.getHelperWeight();
  }

code:

    // Globals
    float multiplier = GlobalData.getMultiplier(); // MV
    float growth = GlobalData.getGrowthFactor(); // GV
    // Adjusted by multiplier
    float growthRate = GlobalData.getGrowthRate() * data.getGrowthRate(); // m
    float upkeep = GlobalData.getUpkeep() * data.getUpkeep(); // c
    float diminishingReturns = GlobalData.getDiminishingReturns() *
                             data.getDiminishingReturns(); // DR
    // Not adjusted by multiplier
    float startLevel = data.getStartLevel();  // Ts
    // Helper effect
    float helperEffect = technology.getHelperEffect(data);
    // Independent variables
    float levelValue = getLevel();
    float rps = getResearchPoints();

    float k  = (float)Math.pow(multiplier, (levelValue - startLevel)/growth);
                                               // k = MV^((Tn-Ts)/GV)
    float V = (float)Math.pow(rps, diminishingReturns) *
                            growthRate * helperEffect -
                            upkeep * k;        // V = (RP^DR)*m*H*I - E*c*k
    float newLevel = growth / (float)Math.log(multiplier) *
                                  (float)Math.log(k) + V + startLevel;

code:

<xml>
  <globals>
    <growthrate>0.01</growthrate>
    <upkeep>0.02</upkeep>
    <diminishingreturns>1.0</diminishingreturns>
    <helperweight>1.5</helperweight>
    <multiplier>2.0</multiplier>
    <growthfactor>10.0</growthfactor>
  </globals>

  <technology>
    <name>Biology</name>
    <tier>1</tier>
    <growthrate>1.0</growthrate>
    <upkeep>1.0</upkeep>
    <diminishingreturns>1.0</diminishingreturns>
    <startlevel>0.0</startlevel>
  </technology>

  <technology>
    <name>Farming</name>
    <tier>2</tier>
    <growthrate>1.0</growthrate>
    <upkeep>1.0</upkeep>
    <diminishingreturns>1.0</diminishingreturns>
    <startlevel>0.0</startlevel>
    <helper>
      <name>Biology</name>
      <startlevel>0.0</startlevel>
      <leveloffset>0.0</leveloffset>
      <effect>0.5</effect>
    </helper>
  </technology>

  <technology>
    <name>Warhorses</name>
    <tier>2</tier>
    <growthrate>1.0</growthrate>
    <upkeep>1.0</upkeep>
    <diminishingreturns>1.0</diminishingreturns>
    <startlevel>0.0</startlevel>
    <helper>
      <name>Biology</name>
      <startlevel>0.0</startlevel>
      <leveloffset>0.0</leveloffset>
      <effect>0.5</effect>
    </helper>
  </technology>

  <technology>
    <name>Production</name>
    <tier>1</tier>
    <growthrate>1.0</growthrate>
    <upkeep>1.0</upkeep>
    <diminishingreturns>1.0</diminishingreturns>
    <startlevel>0.0</startlevel>
  </technology>

  <technology>
    <name>Metallurgy</name>
    <tier>2</tier>
    <growthrate>1.0</growthrate>
    <upkeep>1.0</upkeep>
    <diminishingreturns>1.0</diminishingreturns>
    <startlevel>0.0</startlevel>
    <helper>
      <name>Production</name>
      <startlevel>0.0</startlevel>
      <leveloffset>0.0</leveloffset>
      <effect>0.5</effect>
    </helper>
  </technology>

  <technology>
    <name>Military Tactics</name>
    <tier>1</tier>
    <growthrate>1.0</growthrate>
    <upkeep>1.0</upkeep>
    <diminishingreturns>1.0</diminishingreturns>
    <startlevel>0.0</startlevel>
  </technology>

  <activity>
    <name>
      Food
    </name>
    <description>
      Put cash here to make farming more effective.
    </description>
    <recipient>
      <name>Biology</name>
      <percentRP>0.2</percentRP>
    </recipient>
    <recipient>
      <name>Farming</name>
      <percentRP>0.8</percentRP>
    </recipient>
  </activity>

  <application>
    <name>Chariot</name>
    <description>null</description>
    <longtermgrowth>2.0</longtermgrowth>
    <shorttermgrowth>5.0</shorttermgrowth>
    <lossmodifier>0.0</lossmodifier>
    <requirement>
      <name>Warhorses</name>
      <startlevel>5.0</startlevel>
      <leveloffset>0.0</leveloffset>
      <effect>0.3</effect>
    </requirement>
    <requirement>
      <name>Military Tactics</name>
      <startlevel>5.0</startlevel>
      <leveloffset>0.0</leveloffset>
      <effect>1.0</effect>
    </requirement>
  </application>

  <application>
    <name>Trireme</name>
    <description>null</description>
    <longtermgrowth>2.0</longtermgrowth>
    <shorttermgrowth>5.0</shorttermgrowth>
    <lossmodifier>0.0</lossmodifier>
    <requirement>
      <name>Production</name>
      <startlevel>5.0</startlevel>
      <leveloffset>0.0</leveloffset>
      <effect>1.0</effect>
    </requirement>
  </application>

</xml>

	20-02-2002 04:58									#75
	Support Apolyton buy from Amazon

Something's wrong. Those numbers for tech growth are too low. I ran those values on the spreadsheet and got 8.32 for farming and 2.39 for biuology. I must run now; I'll analyze this and post more later.

	20-02-2002 08:14									#76
	Help yourself to an AD-FREE life

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?

	20-02-2002 12:11									#77
	Browse Apolyton AD-FREE

quote: multiplier (MV) startLevel (Ts)

How do I interpret these lines?

The helper effects are summed over all the helpers

Cheers

	20-02-2002 12:16									#78
	Support Apolyton buy from Amazon

Here is the missing bit of code:

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;
  }

	20-02-2002 18:02									#79
	Avatar Enlargement: We've got the solution

quote: 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

	21-02-2002 04:50									#80
	Remove this text

quote: 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.

	21-02-2002 23:59									#81
	Support Apolyton, buy GURPS/ Alpha Centauri

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

	22-02-2002 00:23									#82
	Enter the AD-FREE zone

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.

	22-02-2002 05:28									#83
	Support Apolyton, buy Alpha Centauri

quote: 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?

quote: 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?

	22-02-2002 05:49									#84
	About Becoming Obsolete Support Apolyton buy from Amazon

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.

	22-02-2002 11:22									#85
	Avatar Enlargement: We've got the solution

Richard:

quote: 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.

quote: 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

	22-02-2002 21:19									#86
	Tired of ads?

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

	22-02-2002 22:57									#87
	Put an end to popups!

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?

	22-02-2002 23:15									#88
	Lose 30 kilos (of popups)

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:

code:

<Element>
  <name>Charger</name>
  <Image>Light Cavalry</Image>
  <default>Warrior</default>
  <category>horse</category>
  <attack>80</attack>
  <movement>30</movement>
  <Distance>20</Distance>
  <Mobility>6</Mobility>
  <Morale>11</Morale>
  <Cost>
  <Food>4</Food>
  <Production>20</Production>
  <Services>1</Services>
  <Decay>0.03</Decay>
  <Training>5</Training>
  </Cost>

  <requirement>
    <technology>Warhorses</technology>
    <startlevel>10.0</startlevel>
    <effect>
      <type>Mobility</type>
      <addPerLevel>.1</addPerLevel>
    </effect>
    <effect>
      <type>Attack</type>
      <addPerLevel>1</addPerLevel>
    </effect>
  </requirement>

  <requirement>
    <technology>Military Tactics</technology>
    <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>

code:

  <Mobility>
    <technology>
      <name>Warhorses</name>
      <startlevel>10.0</startlevel>
      <addPerLevel>.1</addPerLevel>
    </technology>
  </Mobility>

  <Attack>
    <technology>
      <name>Warhorses</name>
      <startlevel>10.0</startlevel>
      <addPerLevel>1</addPerLevel>
    </technology>
    <technology>
      <name>Military Tactics</name>
      <startlevel>10.0</startlevel>
      <addPerLevel>1</addPerLevel>
      <factorPerLevel>0.03</factorPerLevel>
    </technology>
  </Attack>

  <Defense>
    <technology>
      <name>Military Tactics</name>
      <startlevel>10.0</startlevel>
      <addPerLevel>1</addPerLevel>
    </technology>
  </Defense>

	22-02-2002 23:46									#89
	Browse Apolyton AD-FREE

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:

quote: 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:

quote: 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.

	23-02-2002 01:07									#90
	Got spare money?

quote: 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