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.
Announcement
Collapse
No announcement yet.
Demo 6 Technology Model
Collapse
This topic is closed.
X
X
-
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.
Comment
-
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.Project Lead for The Clash of Civilizations
A Unique civ-like game that will feature low micromanagement, great AI, and a Detailed Government model including internal power struggles. Demo 8 available Now! (go to D8 thread at top of forum).
Check it out at the Clash Web Site and Forum right here at Apolyton!
Comment
-
I suspect Laurent already has something similar from the xml snippets he's posted.
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.Clash of Civilization team member
(a civ-like game whose goal is low micromanagement and good AI)
web site http://clash.apolyton.net/frame/index.shtml and forum here on apolyton)
Comment
-
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?
Comment
-
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.Project Lead for The Clash of Civilizations
A Unique civ-like game that will feature low micromanagement, great AI, and a Detailed Government model including internal power struggles. Demo 8 available Now! (go to D8 thread at top of forum).
Check it out at the Clash Web Site and Forum right here at Apolyton!
Comment
-
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.Clash of Civilization team member
(a civ-like game whose goal is low micromanagement and good AI)
web site http://clash.apolyton.net/frame/index.shtml and forum here on apolyton)
Comment
-
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.Project Lead for The Clash of Civilizations
A Unique civ-like game that will feature low micromanagement, great AI, and a Detailed Government model including internal power struggles. Demo 8 available Now! (go to D8 thread at top of forum).
Check it out at the Clash Web Site and Forum right here at Apolyton!
Comment
-
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.Clash of Civilization team member
(a civ-like game whose goal is low micromanagement and good AI)
web site http://clash.apolyton.net/frame/index.shtml and forum here on apolyton)
Comment
-
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.
Comment
-
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;
There is also a tech test program which, when I set the Food RP to 100 and ran it, produced the following output:
Fred, Biology research points incremented by 20.0 to 20.0
Fred, Farming research points incremented by 80.0 to 80.0
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 = 0.17999999
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 = 0.78
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.02
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.02
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.02
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.02
Fred, Biology, setting level to 0.17999999
Fred, Military Tactics, setting level to -0.02
Fred, Production, setting level to -0.02
Note that, at the end, Food and Metallurgy are not mentioned. This is because they have helper methods and because of that they have not been activated. This is because the helper methods might be requirements which have not yet been fulfilled.
Anything without helpers (Biology, Military Tactics and Production) are automatically active.
How to distinguish between helpers and requirements has never been clear to me, nor has the mechanism. Richard, if you explain it I will implement it.
The technology.xml file used for this is:
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>
Not particularly relevant for this, but I kept Trireme and Chariot as applications because, as well as being the names of units, they are also specific technologies.
Cheers
Comment
Comment