 |
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:15
|
|
quote: Originally posted by Gary Thomas
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 think actually the differences are largely purely semantic, although that may just be the fever. IMO the problem was you were calling the mono-effect thing Application, whereas Richard is using the longer-standing "Application is a multi-effect thing like a Legion" definition.
Here is something I said before, that to the best of my knowledge Richard agreed with when we were talking about Laurent's approach.
quote: 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 . | (from my post of 09-01-2002 20:58 in this thread)
With the exception that I specified the mono-effect things as gotten from Skills etc. in the post above, it is basically what you are doing. My thought was if you call your mono-effect things FE Attributes (I like that better than Parameters), and let the interface that ElementArchetypes implement be called Application, that may be enough to close on a deal asap. So Application (perhaps AbstractApplication in the code) would have a collection of Attributes that can define its multidimensional effects. An Application still has required tech levels that make it turn on per the old model. This is completely consistent with what Richard already said was ok AFAIK except some things may have been moved back from other models to tech in the code. I don't think he cares about where the code goes.
I hope I"m representing everyone's point of view correctly here! But it seems like everyone should be happy and we should have an agreed-to spec. 
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:15
|
|
I wholehearedly agree with Gary's rearrangement of the xml file so it is organized around properties. It does make more sense to do things that way. My version was just sort of cobbled together, and only meant as an example of the things that might go in the file. Feel free to rearrange it as needed.
And yes, my idea of "Application" is a complete thing that the player wants to make or do. Sort of like a semantic object. We can arrange the code so that this object as as many or as few attributes as desired. I can see how a programmer might refer to each of these attributes as an "application" but that's not the language I was using. An application like Legion will have attributes such as speed, health, and power.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:15
|
|
One thing to be noted: I called them Requirements because they are used both to know if the application is available and how values increase. It could be good to have both requirements (needed in order to build the unit) and helpers, which are not mandatory, but provide a boost to abilities if they go beyond a certain level.
|
|
|  |
 |
|
LDiCesare
|
|
La Ferté sous Jouarre France
Jan 2001 time: 05:15
|
|
quote: Laurent, do you have a way to do this already that is reasonably general? |
There is a way to add RPs to an existing activity by
civ.getTechnology().addToResearch("Activity name",float)
The problem is you need the activity to exist in order to avoid a null pointer exception.
However, this translates the fact that e.g. a unit when it wins a fight gives better knowledge of tactics. It doesn't explain how to get better legions. Legions require a set of helper techs, so when registering these, it should be logged so that if the player wants to get a legion or a better legion, they can find the information. I am not sure a new interface is needed.
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:15
|
|
Well, I'm trying to hook up some economic-tech intereffects. I have run into two problems so far.
As I think Gary has already mentioned, some techs are not active because they fall below zero (their start value) as soon as a tech update cycle is run without any RP inputs. When I get access to the code Farming is already at a level of -0.29 or some such, presumably because of an initial tech update cycle where no RPs go into Farming. Since it is below its start level, Farming does Nothing. Without unusual repairs, it effectively doesn't exist.
This is a flaw that IMO must be remedied. Sure I can arbitrarily Set it to become active, but that is not the economics code's job.
What is worse, as currently handled it appears that RPs don't even go to inactive Techs, or at least don't produce a change in level. So once Farming falls below the critical level there is no easy recovery without special action by the programmer. (I guess Biology might eventually pull it out, but Biology has the same problem!)
Potential solution:
I propose that a tech that starts at 0 should Never become inactive, and that RPs can be added to, and have effect upon the level of an inactive tech. These may not be the best solutions, but we need something, or there's going to be train wrecks galore in the Dawn scenario.
I also feel the need for some Specifics about what technological levels, in terms of the real world, these levels represent. IIRC Richard above states that "everything is supposed to start around 10". That was never my understanding. I thought that 1 for the general techs like Farming and Mettalurgy was supposed to be basic stone-age technology, on the verge of taking off toward things like copper metallurgy, etc. So, Richard, can you tell me roughly what a 5 in metallurgy means? Similar for Farming? What about 10 or 20? I can make guesses in terms of my mental yardstick cited below, but I don't want to have a standard that is different from others.
I wanted a single, crude, unified scale a long time ago, where a level 1 always meant late stone age, and a level 100 always meant contemporary technology. Presumably on that scale most techs in late classical antiquity would be around 10. I lost that argument, and so now levels are arbitrarily defined per the individual technology. So what do the levels mean? I really think its time for some first stabs at answers...
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:15
|
|
Sorry for the delay; I lost the first reply I composed.
quote: Originally posted by Mark_Everson
I propose that a tech that starts at 0 should Never become inactive, and that RPs can be added to, and have effect upon the level of an inactive tech. These may not be the best solutions, but we need something, or there's going to be train wrecks galore in the Dawn scenario.
|
I thought this was how all techs operated. Falling below the start value does not mean they disappear; it just means that they are less effective. RP's are still added to them, and a minimum level should be all it takes to get them back up again. Things don't disappear until they drop down to about ten levels below their starting level. For that to happen, they would have to have zero RP input for at least five consecutive turns. Since the player would still have farms in operation, there would still be RP generation after the tech fell.
Besides, an easy way to solve the problem would be to run the econ model before the tech model. That way the RP's can be applied even on the first turn.
quote: I also feel the need for some Specifics about what technological levels, in terms of the real world, these levels represent. |
Right now we get crop yields per acre that are about 50-60 times what they were for the first primitive argiculture. Rounding to a 64-fold increase gives a change of 50 tech levels. So the starting farming tech would be level 40. Level 50 would be a doubling of crop yields to 1/32nd of modern agricultural ability.
quote: IIRC Richard above states that "everything is supposed to start around 10". |
I didn't say that. What I said was that almost all techs would end up being at least level 10. Lower than ten would mean that things are less than 1/(2^9)th as good as modern techs. Like farming above, the change will rarely be so large. It will be rare to see a thousandfold change.
But even so, the model doesn't break down if the starting tech level is -40. Tech level is nothing more than an interpretation of the Knowledge variable, so can be fairly arbitrary. I've been saying this for a while:
quote:
Note: These equations and their related values are a mathematical ‘kernel’ that the players do not have to see. It would be a simple matter for the interface to interpret these values so that “Gunpowder level 50” is presented to the player as a “Gunpowder level 40” or possibly “Gunpowder AD 1720.”
|
The knowledge variable is the key to the model. If you don't like tech levels, you can use some other way to interpret knowledge. But as I look back, I see that I have failed to deliver equations that match what I have been saying.
I probably made an error in the way that I presented the equations. I see now that it complicated things. What I forced the computer to do is store the tech level, run an equation to unpack it into knowledge, apply the RP's to that knowledge, and then pack it back up into tech level. This is bad design. I should have just had it store and run all equations on knowledge itself, and have a seperate object to read that number and give it to the player in some other form
I am not asking you to make changes. But if you want to, here's what I recommend:
Strip the tech level out of the processing. Pseudocode:
quote:
float k = (float)Math.pow(rps, diminishingReturns) *growthRate * helperEffect - upkeep * k; // V = (RP^DR)*m*H*I - E*c*k
Call Display (k)
|
Display () can then be changed to whatever the designer wants. It could be as simple as:
or it could apply the tech level:
quote:
float Level = growth / (float)Math.log(multiplier) *(float)Math.log(k) + V + startLevel
Print Level.
|
Or we could get fancy:
quote:
Select Case k
Case 1-2 Print "Your" & techname & "is Stone age technology"
Case 2-4 print "Your" & techname & "is Bronze age technology"
Case 4-7 print "Your" & techname & "is Iron age technology"
|
I suggest that for the next demo, we simply output the knowledge level k to the player. So all techs start at 1 and then grow.
As for linking the two models, it should (theoretically) be a matter of plugging k into the economic equations somewhere:
Food produced = k * farming inputs
The number that the player sees is thus the same number that multiplies the investment for economic activities.
I hope that helped. I may have just muddied the issue further. The basic idea is to make sure we are thinking of k as the core of the model, and that the tech level is simply one possible way of interpreting it for the player. All our disputes seem to be in that interpretation; the core change of knowledge equations seem to be universally agreed upon so we should focus on those. If you need a review of exactly what k is, look at the first post of the thread.
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:15
|
|
Hey Richard, thanks for the detailed comments. Yes, they did help, at least for me!
quote: Originally posted by Richard Bruns
Sorry for the delay; I lost the first reply I composed. |
Arrgh, I hate that. Hope it wasn't too painful.
quote: I thought this was how all techs operated. Falling below the start value does not mean they disappear; it just means that they are less effective. RP's are still added to them, and a minimum level should be all it takes to get them back up again. |
I just wanted to get the effect out in the open, so that it could get fixed 
quote: Besides, an easy way to solve the problem would be to run the econ model before the tech model. That way the RP's can be applied even on the first turn. |
I'm not sure that would work, the fix above is better. The problem is that a very small economy, as the model now works, might not generate enough RPs to avoid some backsliding. So I wanted a general fix. We need to consider issues like "so small you backslide" at some point, but I don't think its vital now.
quote: Right now we get crop yields per acre that are about 50-60 times what they were for the first primitive argiculture. Rounding to a 64-fold increase gives a change of 60 tech levels. So the starting farming tech would be level 40. Level 50 would be a doubling of crop yields to 1/32nd of modern agricultural ability. |
Thanks, this is what I was looking for. I'd forgotten the general approach. BTW I fixed one typo in the quote above the 60 in italics used to be 50. We may need to post a table for how to get these for the less mathematically literate can understand where the numbers come from.
quote:
quote: IIRC Richard above states that "everything is supposed to start around 10". |
I didn't say that. |
Sorry for misquoting you, hazards of being too lazy to find the original post!
quote: I probably made an error in the way that I presented the equations. I see now that it complicated things. What I forced the computer to do is store the tech level, run an equation to unpack it into knowledge, apply the RP's to that knowledge, and then pack it back up into tech level. This is bad design. I should have just had it store and run all equations on knowledge itself, and have a seperate object to read that number and give it to the player in some other form
(snip)
I suggest that for the next demo, we simply output the knowledge level k to the player. So all techs start at 1 and then grow. |
That might be more straightforward, allowing easier connection between effects and what the tech model gives as a number. What do others think?
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:15
|
|
I need to change some existing equations. In the first post of this thread, I said that tech level was required for helper calculations, and that this was the reason for using tech levels in calculations. In an effort to remove the tech level from the core calculations, I have reformed these equations so that they focus solely on knowledge. As far as I know, helpers have not been coded yet, so hopefully this will make the task easier.
Previously, helper effects were based on the current level of the helper tech minus the level of that helper tech that was required for the other tech to exist. (By the way, this is why helper and required techs are the same. We need to know what level is required in order to know how much it helps.)
Old equations:
quote:
So each helper tech adds its effect as follows:
HelperTechEffect * ( Current level – TechRequirement + HelperLevelOffset )
This equation is run for every helper tech, and the results are added together to form a working variable called RelativeHelperLevel. This value is then run through the following equation to determine the TotalHelperEffect value used in the RP to knowledge equation:
TotalHelperEffect = MultiplierVariable^( RelativeHelperLevel / (Growth Variable * GlobalHelperEffect))
|
Note: We have abandoined the HelperLevelOffset value
So if Engine level 60 was required for Airplanes and we now have Engine level 70, there were ten excess levels that helped the airplanes tech. We can't simply use the full tech level or knowledge amount. If Engines started at level 30, those first 30 levels are not helpful, since they represent knowledge too primitive to put in planes. But mainly, it would makes the math do bad things and create system discontinuities.
Translating into knowledge, this means that an engine knowledge of 16 is required to build planes, and we now have knowledge of 32. The civ now knows twice as much about engines as the Wright Brothers. So it is logical for each helper tech to add its effect as follows:
HelperTechEffect * ( Current knowledge / Required knowledge )
Then these numbers for each helper are all added together to form RelativeHelperLevel, and then the TotalHelperEffect is simply:
GlobalHelperEffect * RelativeHelperLevel
Note that these equations are exactly the same as the previous ones. They simply strip the tech level out of the picture. The relationship between knowledge and helper techs should now be a lot clearer. The GlobalHelperEffect number now does a very different thing, but that is a problem for the designer (me) and not the programmer.
Does this sound good to everyone?
Another change is still needed: the Application equations. These are more closely tied to the tech level, and so will take more thought to reform. But since they won't be programmed for a while, I have some time to think about them.
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:15
|
|
I have to do an analysis project for a computer class, so I sent the tech model description at the beginning of this thread to my professor for him to proofread. My intention was for him to analyse my writing style and critique it so I would have a better chance of getting a good grade on the real project. But he responded to the model itself instead of my analysis. I don't understand a lot of what he said, but you all might. I got his permission to post it here, so:
quote:
Mr. Bruns:
Unless I'm mistaken your "tiers of technology" are probably analogous to objects.
The fact that the "technologies" influence each other seems to suggest a level of interaction and interdependencies.
There does appear to be a level of unpredictability associated with the interactions. However, objects do influence other objects.
Where a civilization might "gain" strength with experience in certain technologies - I don't think there would be a direct analogy to listing objects in a model, recording attributes, interactions, and describing how the work flows.
The turning of data into RP points and their "distribution" is roughly analogous, I think, to the behaviorial characteristics of objects in an object oriented analysis model or OOA.
The linear nature of your model is roughly related to the concept that each "transaction" or turn of the clock in the object model is the same as the one before it. In other words, ten transactions are roughly equal to ten times as much volume, work, etc. The volume is the driver though rather than the "application of the knowledge" in OOA. I think that re-deploying the objects (maybe eliminating some and tweaking others during the design phase) moves the Object Oriented concepts toward the "application of knowledge" in your model.
Learning how information or data is used for decision making is the key to Objective Oriented Analysis. Forming a model of the object and its data elements lets you know "what is" being used. Following the data set and asking "how" it is used in establishing behavior and actions so that you understand "why" it is done is the point in OOA. "Why" would be directly related to a business requirement. Either that or the object may be a candidate for elmination.
I think that your technologies would tend to be more like "variables" and the objects in an OOA might tend to be more like "constants". I don't see natural equating of the OOA with the weighting and distribution of RPOBjects. (If I expressed that correctly).
I love your "bench marking" concepts (i.e. 1/50th the production capacity in 1750).
Does the programmer set the "Other Technologies" that come?
Relative to OOA, I've never seen numerical relationships etstablished among objects within a real world object oriented analysis. It may be possible to do such and that it have meaning. I've never seen it done. I've seen studies on volume and correlation but never accumulated strengths within systems. Neural net software is getting close to that concept but neural nets have more to do with prediction rather than description.
Your model is fascinating and I think the objects or technologies (and the elements in the equations) do qualify as having characteristics, traits and "inter-relatedness". However, your model or civilization morphs according to an infinite number of possibilities within a mathematical model. Your model might be compared to a dynamic user determined story line or movie.
OOA or Object Oriented Analysis would tend to be drier, less dynamic and focused more on the concept of "who" needs the information, "when" do they need it and in "what" form do they need it. OOA is more like a snapshot of what is going on for the purpose of determining what you have to leave alone in the design phase. All the analyst/designer would do is re-deploy objects (which may be procedures) into a more efficient means for supporting decision making.
Thanks for sharing your sophisticated and "mind stretching" overview of the game.
WPerry
|
|
|
|  |
 |
|
roquijad
|
|
Santiago
Nov 1999 time: 05:15
|
|
I'm putting here something I said in the "From CIV3 to Clash" thread.
quote:
Technology
I find it very boring in the Civ series all civs have almost the same technological evolution. You're technologically advanced or backwards in all fields. It's too "flat". The game experience regarding techs is IMO extremely poor. Every time you play you face almost the same tech evolution and that's, at least for my taste, very boring.
One of the things that impresses me the most about world history is the sometimes gigantic technological difference between cultures in specific fields. FE, it's amazing the Incas didn't have writing, while other peoples developed it literally thousands of years before. However, Incas were in no way behind in, FE, construction. They actually had really good techniques to protect buildings from earthquakes. Or, while in Europe the use of steel is constrained to modern times, in China it was discovered pretty much at the same time iron working was discovered, and used ever since.
You all know I worry a lot about historical accuracy, but in this case in particular it's only a matter of fun for me. I think a game where tech evolution can be substantially different each time you try it, would be much more interesting. If a player can't control exactly how techs evolve (which, as far as I know, is already a characteristic of our tech model) then he'd have to adjust his strategies and his decisions to the particular "mix" of techs he has available. That's entertainment.
Can our tech model do something like this? |
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:15
|
|
I believe that the tech model can do what roquidad said.
What do I need to be doing with the tech model now?
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:15
|
|
From the Planning D 7&8 Thread...
quote: Originally posted by Gary Thomas
Just a realistic very ancient tech tree, up to the bronze age. Things like:
Biology:
Agriculture
Plant breeding (at some primitive level)
Animal domestication
Animal breeding
Horse domestication
Cattle domestication
Sheep domestication
Cavalry horse
Goat domestication
Vegetable growing
Fruit growing (quite a late development)
Metals:
Mining
Copper smelting
Bronze alloy
Casting
Military:
Ritualistic battle
Close order combat
Chariots
Cavalry
Naval:
Dugout
Canoe
Sails
Oars (as opposed to paddles)
Bireme or penteconter
Trireme
Social:
City administration
Writing
Numeracy
Schools
These are just some off the cuff ideas, not meant to be exhaustive - that is your job! |
Gary, I think you are looking for something that is far too detailed for a start at a whole-history tech tree. Specifically I think all the X animal domestication techs are going rather overboard.
Animal domestication
Animal breeding
Horse domestication
Cattle domestication
Sheep domestication
Cavalry horse
Goat domestication
IMO Horses are a sufficiently important animal to have their own domestication tech. Altough I think that Cavalry horse should be an Application that works off the Horse Domestication technique. That might be what you intended, but since there is no labelling as to what is a regular tech and what is an application, I assumed they are all regular techs.
Everything else in the short list I copied above should just be covered by the single "Animal Domestication" tech IMO. I don't think players will really care if they have domesticated goats, pigs, sheep, cattle, oxen, chickens or anything else. These will all vary depending on geographic location. the way I envision we might do the individual animals simply is that if your discover a source of an animal (mechanism TBD) you would get a bonus to your "Animal Domestication" tech, indicating that some new animal is in your civ's package of animals. Perhaps to get the bonus Animal Domestication would have to be at a certain level already. This bonus would be one advantage to exploration.
How we might handle different animals and their domestication, however is a secondary point of my post. (I think we may have discussed this before too, but the discussion got Way out of hand in terms of detailed modeling of numerous animal species). I think the level of detail in the quote at top is just too high for a whole-history tech tree, which is what I thought you were after. Perhaps that level of detail would be appropriate for a scenario that focuses solely on developments from 7000 to 1000 BC or so.
Cya,
Mark
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:15
|
|
I apologise for my remporarily dropping out of sight. I had two major projects due and several exams to study for. But that's all over now, so I have time to get back on the project. I have been asked to make a detailed tech tree covering ancient times.
I had thought that we would be using the tactic of testing small steps, and then making incremental changes based on that feedback. I was under the impression that Simple_Tech_Test.xml would be used for the next demo to hunt for bugs or odd interactions. So I thought it would be safe to drop out until the demo with that tree was created and it was time for me to test it, debug it, and then make a different tree based on that knowledge.
I was, and still am, worried that if a large tree is implemented all at once, it will be next to impossible to find bugs. But now I apparently need to jump right ahead with something bigger. I need to know a few things before I start hacking out the numbers:
Are Activities (Farming, Transportation, etc.) implemented yet, and should I add them to the tech tree?
Do you want Applications in there, and are they coded?
Has the XML spec been changed any, or should I use the one that my online tech editor was programmed around?
Have there been any tests run with Simple_Tech_Test.xml that would guide me in the creation of a more complete system?
What do you think of the knowledge-based interface I presented in the posts above?
Also, I still don't understand why Simple_Tech_Test.xml is unsuitable for the very first foray into tech. I know it isn't big or comprehensive, but that's the whole point. It provides the minimum framework for scenario goals like "Make light cavalry units and take over the neighbors." It is supposed to be the minimum tech that fits into the game that I saw when I played demo 6.
Is it that the xml format is bad, or that my creation system is incomplete? In that case, making a bigger file with the same format would be foolish. I need to know what I did wrong with that file so I can make one that is suitable.
|
|
|  |
 |
|
Mark_Everson
|
 |
Canton, MI
Jan 1970 time: 00:15
|
|
Hi Richard, thanks for the response.
quote: Originally posted by Richard Bruns
I had thought that we would be using the tactic of testing small steps, and then making incremental changes based on that feedback. I was under the impression that Simple_Tech_Test.xml would be used for the next demo to hunt for bugs or odd interactions. So I thought it would be safe to drop out until the demo with that tree was created and it was time for me to test it, debug it, and then make a different tree based on that knowledge.
I was, and still am, worried that if a large tree is implemented all at once, it will be next to impossible to find bugs. |
I think this approach makes a lot of sense.
Gary, I feel there's a lot of risk in making things a lot more complicated before we know if the basics even work sensibly. Perhaps if you don't like the simple techs in the original test we can figure out a very-constrained tech tree with four to six techs (and a few Activities, etc) that is more like one sub-area of your tech tree post above. One obvious example would be your Military or Social sub-trees. That would maintain the important property of being a relatively simple test, and yet be more realistic in terms of real-world effects and relationships.
|
|
|  |
 |
|
Simon Loverix
|
|
Tongeren, Belgium
Apr 2001 time: 05:15
|
|
When designing the tech tree, we should have some idea what function the techs will have. Techs should have a clear use for the player. Animal breeding, for example, should therefore not be split up by species, but by output products: meat & milk production, leather & wool production. So when the player wants to get more trade material, he tries to increase his leather & wool production and vice versa for a healthier population.
We should also allow regional variation, either implicitly by catch-all techs or explicitly by several techs that lead to the same advanced tech. For example, the material used for boats differs significantly: reed in swampy areas, logboats in the tropics, skin boats in the northern area's. The difference in available/used material expresses itself in very different building techniques (in this case, shell-built and skeleton-built). So we should either have one catch-all tech (primitive watercraft) or two techs, leading to the same advanced tech. (In this specific case it would be more historically correct to require development in both shell-building and skeleton-building to advance.)
Optionally, by using general names for technology it is easier to change units, specials etc. without also having to change the technology name. This is useful both in designing and scenario building.
|
|
|  |
 |
|
Richard Bruns
|
|
NC, USA
Nov 1999 time: 06:15
|
|
I have been using general names in the tech trees. For example, the "Metalllurgy" tech includes everything from the most basic copper pounding (k=1) to advanced aluminium/composite spaceship parts (k=200 or so). The detail is all in the applications, so there is plenty of room for variation. "Boat Building" would probably be a single level 3 tech that covers everything from coracles to an Aegis cruiser (although you also need a lot of other tech levels for that.)
|
|
|  |
 |
|
Gary Thomas
|
 |
New Zealand
Mar 2001 time: 17:15
|
|
From Richard:
quote: I had thought that we would be using the tactic of testing small steps, and then making incremental changes based on that feedback. I was under the impression that Simple_Tech_Test.xml would be used for the next demo to hunt for bugs or odd interactions. So I thought it would be safe to drop out until the demo with that tree was created and it was time for me to test it, debug it, and then make a different tree based on that knowledge. | Unfortunately there is nobody doing this incremental testing, so it doesn't get done. The problem with incremental testing of this kind is it requires a release every few days, since, typically, the code is updated that often. On the other hand, almost none of this code relates to the tech model. Essentially the tech model is not used. There are several reasons for this.
In the first place the technologies available in the current data file do not relate to the the actual elements in the demos to date. They are not sufficiently realistic.
Secondly there is no tech gui, to allow assignment of research points.
In fact, there is no provision for the production of research points.
Finally, there has to be a semantic connection between actual operating elements in the game (units, social elements, economic infrastructure) and the named technologies. This does not presently exist. In some cases the name of a technology has been hard coded into the program. This is particularly true of the social mode. Unfortunately the technologies referred to do not exist in the data.
It is my view that there should be a way to refer to technologies ONLY from data. No technology should be hard coded. Laurent has gone some way to implementing such an approach, with his requirements specifications. I do not think that the technologies in his military file exist in the tech file though.
quote: I was, and still am, worried that if a large tree is implemented all at once, it will be next to impossible to find bugs. | I am unclear on what kind of bugs are meant here. They cannot be programming bugs since the tech tree is simply data. If it can read one tech it can read them all. Refining the parameters is play-testing, not debugging.
Every technology referred to in other data files (military, economics, social, or geographic) MUST be present in the tech tree. This is why I want a comprehensive tech tree.
quote: But now I apparently need to jump right ahead with something bigger. I need to know a few things before I start hacking out the numbers:
Are Activities (Farming, Transportation, etc.) implemented yet, and should I add them to the tech tree? |
These have been coded and working for about a year. I have not changed over to the new system because I had no indication that the code that I had written was ever going to be used - it seemed to me that changing a system (which means many hours of work on my part) when the original system had never been used was unproductive.
quote: Do you want Applications in there, and are they coded? | Applications, as specified in the tech model, are coded.
However I cannot see how applications can possibly be part of the technology model - they are provided by the other models which use them. The application part of the model is coded and will work, in the limited sense that the tech model specifies. They will then be disregarded by the rest of the system because they are far too simplistic, for example, the main examples of applications are, at present (and probably forever), military elements. A military element has hugely more information that a single effectiveness value. At present, without specifically checking, I would say that a typical element has around a hundred numbers specifying its base and current state. There is also the consideration that application have two incarnations: as prototype (or archetype) and as an actual instance. Each prototype may have hundreds of instances. However, it is the prototype that connects to the tech model, the instance connects only through the prototype, and hence must pass its own technology model instance as a parameter. This is also not provided for in the tech model.
Also, in many (or even most) cases, the tech concerned will be referred to directly. This is particularly true in the social model, which is concerned with technologies like "writing", "bureaucracy".
For these reasons I do not see applications as being a useful concept.
quote: Has the XML spec been changed any, or should I use the one that my online tech editor was programmed around? | As far as I am aware there have been no changes. However, check the technology.xml file that comes with D6.
quote: Have there been any tests run with Simple_Tech_Test.xml that would guide me in the creation of a more complete system? | Again, it is not a thing that is "tested". As far as fine tuning the parameters, that is not a coder's job, and so it has not been done at all. In fact, I believe, none of the techs in the the simple test tech (which MUST be called technology.xml for the program to find it) are used by anything. I might be wrong here - Laurent may use some of them.
quote: What do you think of the knowledge-based interface I presented in the posts above? | As I said above, I am not prepared to modify code until I have some indication that the code is being used usefully. On the other hand, from looking at the posts, it does seem to me to be a significant improvement on the presently coded model. However, relating the tech model to the rest of the code is hugely more important that relatively minor fine-tuning of the tech model.
quote: Also, I still don't understand why Simple_Tech_Test.xml is unsuitable for the very first foray into tech. I know it isn't big or comprehensive, but that's the whole point. It provides the minimum framework for scenario goals like "Make light cavalry units and take over the neighbors." It is supposed to be the minimum tech that fits into the game that I saw when I played demo 6. | We need much more infrastructure before such goals are possible.
What we really need is some kind of forum in which a coder can say things like "We want to mount our settlers on horses so they can colonize faster, what technology do they need? And what prerequisites are there for this?" or "I want to establish a new province with a viceroy. What technology structure do I need for this?"
While I could make up such a list, I really do not have the time to do so, and would like to foist it off on others.
quote: Is it that the xml format is bad, or that my creation system is incomplete? In that case, making a bigger file with the same format would be foolish. I need to know what I did wrong with that file so I can make one that is suitable. | We just need more, and more relevant technologies. If each person who is going to use a technology could give you a list, perhaps you could organize them into a tree. If I, in coding road-building, require a technology, that is what I require. However, such a thing has antecedents, perhaps like masonry and engineering. While the road-building tech is not available, I can't do much about applying the tech model to road-building. So, at present, there is no restriction at all on the ability to build roads.
From Mark:
quote: Gary, I feel there's a lot of risk in making things a lot more complicated before we know if the basics even work sensibly. Perhaps if you don't like the simple techs in the original test we can figure out a very-constrained tech tree with four to six techs (and a few Activities, etc) that is more like one sub-area of your tech tree post above. One obvious example would be your Military or Social sub-trees. That would maintain the important property of being a relatively simple test, and yet be more realistic in terms of real-world effects and relationships. | See my comments above. The tech tree is data, and does not require debugging. If it isn't used by anything it doesn't even get play-tested. The size of the tree is not, in my view, a significant issue, provided it includes every tech that the program requires at that point.
From Simon:
quote: When designing the tech tree, we should have some idea what function the techs will have. Techs should have a clear use for the player. Animal breeding, for example, should therefore not be split up by species, but by output products: meat & milk production, leather & wool production. So when the player wants to get more trade material, he tries to increase his leather & wool production and vice versa for a healthier population. | This is very much to the point, sa afr as it goes. However, not all technologies have an output. Writing, for example.
From Richard:
quote: I have been using general names in the tech trees. For example, the "Metalllurgy" tech includes everything from the most basic copper pounding (k=1) to advanced aluminium/composite spaceship parts (k=200 or so). The detail is all in the applications, so there is plenty of room for variation. "Boat Building" would probably be a single level 3 tech that covers everything from coracles to an Aegis cruiser (although you also need a lot of other tech levels for that.) | Each technology should have a properly specified description (provided for in the code) with this sort of information in it. As an aside, the existing xml file had, as descriptions, <description>null</description>. Because of the way Java works, this will ALWAYS cause the program to crash. If a null description is important, just omit it, though this should never happen because EVERY technology must have some reality, and hence a descripion. The player and the coder cannot do without this information.
Cheers
|
|
|  |
 |
|  |
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
|
|
|
|
|
|