 |
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:15
|
|
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?
|
|
| |
|
|
|
Col
|
|
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.
|
|
| |
|
|
|
Mikael
|
|
Rio de Janeiro
Jan 1970
time: 05:15
|
|
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.
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:15
|
|
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)?
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:15
|
|
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 on 12-12-2001 at 21:06
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:15
|
|
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.
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:15
|
|
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.
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:15
|
|
I'm at home now, on a very old computer that can't play any of the Clash demos.
I'm confused; what do you need me to do? Simple_Tech_Test.xml should be the test case you were talking about, and I posted it quite a while ago.
|
|
| |
|
|
|
Mark_Everson
|
 |
Canton, MI
Jan 1970
time: 00:15
|
|
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
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:15
|
|
Let us just make Application an interface, put a default implementation somewhere, and then anybody can adhere to it by either derivating or aggregating the appropriate object.
I'd rather have Application and ApplicationImplementation than ApplicationInterface and Application, because the interface should be used more often than the concrete class, to avoid mistakes by sometimes using the short name instead of the interface name.
|
|
| |
|
|
|
Gary Thomas
|
 |
New Zealand
Mar 2001
time: 17:15
|
|
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
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:15
|
|
I have no idea what you mean by atomic, but is you look at the new xml file you'll see that each required tech has a different effect. In the example I typed, the warhorses tech improves one thing and the tactics tech improves different things. Isn't that what you wanted?
I'm afraid that I can't use the spreadsheet on this computer. So I can't come up with exact numbers. But I think the only "test case" that really matters now is the end result.
Test Case 1: Put money into the "Food" activity and see if you grow more food.
Test Case 2: Put money into the "Production" activity and see if your stuff gets cheaper to make.
That ought to do until we decide on a format for applications and military units and I update the XML file to reflect whatever we decide.
Right now I'm burned out from exams and am quite tired and my net conenction is as slow as molasses, so I'm sorry I can't be more helpful.
|
|
| |
|
|
|
Mark_Everson
|
|
Canton, MI
Jan 1970
time: 00:15
|
|
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 on 22-12-2001 at 19:17
|
|
| |
|
|
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001
time: 05:15
|
|
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?
|
|
| |
|
|
|
Gary Thomas
|
|
New Zealand
Mar 2001
time: 17:15
|
|
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
|
|
| |
|
|
|
Richard Bruns
|
|
NC, USA
Nov 1999
time: 06:15
|
|
I'm still confused about what is going on, so I'll try to explain from the start and hope I help the situation.
quote:
Originally posted by Gary Thomas
What worried me was seeing Horde and War Band in the tech xml file. Horde and War Band are not technologies, they are unit types (elements if you like), and may have many "effects" not just one as implied bythentech model.
|
I think understand this problem. I tried to put too much information in the tech model xml file. There should probably only be the following:
Required tech level
Tech level for obsolescence (optional)
Change in effeciveness due to changes in tech levels
That last seems to have caused confusion. There are many techs that affect the application's effectiveness, and many different effects of the application. In the example above, the element "light cavalry" had attack, defense, health, and movement points, each of which could be affected by multiple technologies.
I do not think it would be good to make each of these a seperate application. I don't know anything about the object model, but in the interface the player should see light cavalry as a single application that is made available as a certain tech level.
The military xml file would determine all of the relevant stats for the unit, and the tech file would only determine the rate of change of those stats. Is this good?
|
|
| |
|
| |
All times are GMT. The time now is 05:15.
Apolyton Time is 00:15. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
02-12-2001 03:33
|