Hi Richard:
Sorry, the mismatch between the xml and the current specification had eluded me. Thanks for doing it, and a least we now have the xml in the bag if you aren't available when Gary can shift gears back to tech. I can hand-edit it if necessary when the xml spec changes.
For later ease of use, we should probably find-replace the {effect} tags with something like {PercentageRP} I didn't do that now since it would mess up your code.
We will probably want to give a lot more subtags to the Activity tags in the future as we add more functionality to them. Can this be done easily?
Hello. I'm new to this site, so please excuse me if this post is in the wrong section, but it was the most appropriate thread I could find.
Reading the info on the implementation in Clash is very exciting, I especialy like the cumulative and interrelated aspects of it. That said, here is my tuppence worth:
One thing I find inaccurate in all Civ-type games, is the way all technologies are researched by default i.e. they are all uniformly 'good' and produce few negative effects on those who research them, bar the odd increase in pollution or somesuch. What would be more interesting is if some techologies had a more significant negative effect, so the player would have to make a real choice about whether to lead their civilization along such a path. A few examples:
Fascism - surely you would not be able to acquire such knowledge without significant risks.
Communism - the benefits of advances like a better wellfare state, production and employment should be countered by a big increase in the chance of revolution amongst your citizens, once they have knowledge of this system.
Religion - I have yet to see a game fully implement the serious effects of making reasearches into religious fields. The decrease in science and toleration in your civilization should be modelled, as well as the power you as the ruler would lose to the heads of religion the more religious your civ becomes (Alpha Centauri touched on this when the Fundamentalism social engineering choice decreased research)
In relation to the cumulative effects in the reasarch fields in the Clash tech model, I would like to see certain penalties for reaching high levels in certain areas. So the better you become at nuclear weapons, the greater the unhappiness amongst your citizens, as your ever larger weapons of mass destruction pose a threat to the whole planet.
Similarly, and depending on whether 'future techs' are implemented, when advances in Cybernetics produce increases in production and research, it would be an interesting twist if the better you became at this, the greater the chance that the machines would achieve consciousness and maybe fight back ala Terminator. It would certainly make the endgame more interesting if you were suddenly faced with a massive new foe who originated in your own cities. Again, it would lead to a choice - do I place restrictions on technology and possibly fall behind other civs, or press on and perhaps risk total destruction by my own technology?
Anyway, that's me done.
Keep up the good work.
Col, I believe most of what you said will be implemented. Check out the social model for more info on religions' side effects, and the modeling of philosophies such as fascism.
On the other hand I don't think Clash will dwelve into the future, that doesn't seem to be a priority. It is first and foremost intended to model history. And even if it does, I don't think it'll go as far as you suggest.
Hi Col, and welcome to Clash!
Thanks for the comments. Thanks for trying to find the right thread. The right one was down a few pages, so I can see how you didn't find it. The best way to find the right thread if its not near the top is to look on the page for that model on the web page. They aren't all current, but usually the end of a thread will tell you where the next one in the chain is. If you want to discuss your ideas further, you should post them here .
Some negative consequences of tech will certainly be there. How far we go is TBD. I have some qualms about your specific suggestions. FE Communism isn't necessary to have a socialist-leaning state, or a modern mixed economy. I don't see the connection you posit.
Mikael didn't know it because we have been focusing on ancient stuff for quite a bit, but there is a decent chance that at player option we will have future techs. I think the Terminator endgame is fairly interesting. We are only implementing the ancient world for now, so I won't discuss it until we get at least into the modern age.
Richard:
Now that Demo 5.1 is in its closing stages I am ready to start fixing up the data editor.
Could you send me the list of things you want changed or fixed or improved in the data editor. I do not at present have access to the emails you sent me before. You can either send them to me at gthomasnz@hotmail.com or post them here in this thread.
Cheers
A question on military applications:
The military model has elements and units. Elements contain actual data, units are groupings of elements. Only units are presented to the player.
A breakthrough in metallurgy would allow a better element to be available, and increase an existing one. Units are more difficult to handle, since they are groupings of elements. They automatically get better if their elements do, but when do they become available? There are 2 reasons why they should:
1) New elements are available, so corresponding units can be nuilt,
2) New tactics are discovered, so one understands it is interesting to have a mixed elements-unit, (like using scouts with infantry, or engineers with infantry to build field defence).
The code is ready to take into account the element-effect, which means xml files provide the figures and are read by the program.
Note that it makes things a little bit more complicated at element-level than at unit-level.
However, how would one say that new units are available? Is it a direct consequence of new element available, or do we also provide starter tech for some units (knowing these tech breakthroughs are only organisational in nature)?
I keep checking this forum, but somehow I missed the fact that this thread had new posts.
Col, what you say is certainly possible in our model. However, we don't yet have the details for tech-social interactions nailed down. If you research both the tech and social model and come up with a plan for linking them, you will be able to help us fix up the game.
For example, we might add a "hidden" application to the Nuclear Weapons technology. Rather than being something that the player builds, it could generate the civ-wide social effects you mentioned.
Gary, making a tech editor seems to be something I can do myself, so you can work on something else instead. But I do have some requests regarding the structure of the XML file. For my editor, I tried to generate a file that is just like the one we use now. But as I mentioned earlier in the thread, this is a bit outdated.
The {multiplier} tag in the CivilizationActivity objects doesn't do anything, and a {description} tag would be nice. Also,the {effect} tag should probably have its name changed to {percentRP} So the file would look like this:
{activity}
..{name}
....{Food}
..{/name}
..{description}
....{Put cash here to make farming more effective.}
..{/description}
..{recipient}
....{name}Biology{/name}
....{percentRP}20{/percentRP}
..{/recipient}
..{recipient}
....{name}Farming{/name}
....{percentRP}80{/percentRP}
..{/recipient}
{/activity}
Also, as LDiCesare and I agreed on earlier, the application tags need to be changed to look like this:
{application}
..{name}Light Cavalry{/name}
..{type}Element{/type}
..{description}Improvements in horse breeds allowed soldiers to ride on the animals instead of relying on chariots, resulting in more mobile and powerful troops.{/description}
..{attributes}
....{attack}480{/attack}
....{health}9{/health}
....{defense}33{/defense}
....{movement}3{/movement}
..{/attributes}
..{requirement}
....{name}Warhorses{/name}
....{startlevel}10.0{/startlevel}
....{effect}
......{type}Movement{/type}
......{addPerLevel}0.1{/addPerLevel}
......{subtractPerLevel}0.3{/subtractPerLevel}
....{/effect}
....{effect}
......{type}Attack{/type}
......{addPerLevel}1{/addPerLevel}
......{subtractPerLevel}10{/subtractPerLevel}
....{/effect}
..{/requirement}
..{requirement}
....{name}Military Tactics{/name}
....{startlevel}5.0{/startlevel}
....{effect}
......{type}Attack{/type}
......{addPerLevel}10{/addPerLevel}
......{factorPerLevels}0.3 10{/factorPerLevels}
......{subtractPerLevel}48{/subtractPerLevel}
....{/effect}
....{effect}
......{type}Defense{/type}
......{addPerLevel}2{/addPerLevel}
....{/effect}
..{/requirement}
{/application}
I can change the editor to deal with this (I hope); can you change the Tech code? Basically the RP's put into the activity object would be split among the listed techs in the percentage listed. The CivilizationActivity objects will get a lot more functionality later, but that should do for 6.2
LDiCesare, the current xml file is old, and does not include any of the changes we discussed. Either you or Gary has to change the code. You said you were already changing some military code; is what I posted above correct? Did you want the attributes like attack and defense to be defined in the tech file or somewhere else?
I assumed that the applications currently in the tech file are elements. Once you get a certain level of tactics and warhorses, you can make a light cavalry element. I assumed that the military model would use those elements to make units as soon as they became available, the #1 option that you listed.
We could add units as new applications. It would be trivial to make such an application that becomes available at a higher tech level than the elements in the unit. Something like:
{application}
..{name}Cavalry Raiding Band{/name}
..{type}Military Unit{/type}
..{description}Generals soon learned how to use cavalry to their full potential, abandoning the old shock-based chariot tactics in favor of a hit-and-run style that increased mobility.{/description}
..{icon}ltcav02.gif{/icon}
..{sound}horse02.wav{/sound}
..{requirement}
....{name}Military Tactics{/name}
....{startlevel}10.0{/startlevel}
..{/requirement}
With proper design, the unit application will never come before the element application, since it has a higher requirement in the same tech.
Am I correct in assuming that units have graphics and sound files attached while elements do not? Also, where do you want the effects of the units to be coded, the tech XML file or somewhere else?
Last edited by Richard Bruns; December 12, 2001 at 11:06.
Richard, I have already coded the parse of the xml military/tech link in the military xml file which contains the definition of units and elements. Instead of application I have element, and I have unit elsewhere. Try to get the unitbuilder.xml file out of the demo 5, and you will see what this file looks like: Just imagine inside the {element}LightCavalry{/element} additional tags like {element}LightCavalry{requirement}(what we said before){/requirement}{/element} In 5.1 you'll have some (unused) tech stuff along in the file, but I cannot attach it from here (I am not at home).
The question unit/element was mainly because you use unit names, so I was afraid there was a confusion. Elements have their image, and units and commands (or TFs) use the image of the most numerous element (or the most numerous image, rather). To make things simple, I agree that having units available as soon as elements are available is good at least to start with. If we realize some units (element combos) are stronger than others, then we can try the other approach.
The next code release (which I want to call D6) is imminent. Right after that I want to rationalize the whole XML data scene so that everything is coherent and read in in a consistent way. The Java code to do this is now available. In doing that, I would extend it to include scenario specifications and saved/loaded games.
Richard: I will go over your post carefully a little later today, and let you know any comments when I get home from work tonight.
Cheers
Hi Richard:
I think the next big push should be on Tech. To make that work, we need some test cases out of you. One involves the XML spec Gary is talking about. Another test case we need is to make sure all the plumbing is hooked up right in the code. It would be something like this:
Using the abbreviated test tech tree (once Acitivities are read in right) Given a set of initial tech levels, Put X points into Y Activity. Crank a turn. Tech change should be Z in Metallurgy, Z1 in ... etc.
Once Gary has that he will know what is supposed to happen, and can get the Tech turn hanler working right. Then Laurent and I can do our respective hookups to Tech. At that point you can test, and we should be close to ready for a demo.
The more I consider it, the more it seems to me that an application (as described in the technology model) should be an interface rather than an object. That way any "client" of the technology model can define their own actual application object as long as it implements the application interface. In that way, a military application could, in other regards, have a quite different structure from a planning application (mass production for example), say, but still use the same interface to the tech module.
How do you feel about that, Laurent?
It may be that activities should be approached in the same fashion. I am not sure about that.
My original interface design allowed technologies, activities and applications to be requested using the same method. I now feel that that approach was incorrect and am recasting it.
Cheers
So long as the tech model also provides a base object for Application and Activity that implements the interface, and is reasonably functional, I've got no gripes with either of these. I think that in many cases in the econ model I can just use the base functionality as-is. At least for the near future.Originally posted by Gary Thomas
The more I consider it, the more it seems to me that an application (as described in the technology model) should be an interface rather than an object. That way any "client" of the technology model can define their own actual application object as long as it implements the application interface. In that way, a military application could, in other regards, have a quite different structure from a planning application (mass production for example), say, but still use the same interface to the tech module.
It may be that activities should be approached in the same fashion. I am not sure about that.
If application was an interface, the various ElementArchetype could adhere to it, which could make things a little simpler, but I must check since I currently have only one ElementArchetype for all civs but don't know whether I can make do with one application object for all civs.
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.
Cheers
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.
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
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
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.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.
What is the Disadvantage to doing it the way I suggest?
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.
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.What is the Disadvantage to doing it the way I suggest?
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
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
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.
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.
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!
Last edited by Mark_Everson; December 22, 2001 at 09:17.
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?
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?
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
That's ok by me. Is everyone content doing it this way?
I'm still confused about what is going on, so I'll try to explain from the start and hope I help the situation.
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: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.
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?
Posting Permissions
Bookmarks