Demo 6 Technology Model

[Mark_Everson]

Hi Richard:

Thanks for pushing on this, I think it probably is the right way to go long-term. But I would hold up on this a bit until we hear whether everyone buys into the change you've proposed. So far only we two are agreed that it might be the right way to go. Also, AFAIK pretty much everything in the guts of the model is already coded. So the things you say may not be coded yet, probably are, and would require changes to go to the knowledge approach. Of course there's nothing wrong with making posts of the sort "if we go the knowledge way, here are the changes that'd need to be made"...

At least that is my take on it. I don't know the complexity of changes that would be needed in the code to support the knowledge-based system. It might be not much, or it could be substantial. So we just have to wait for Gary to make it here. Fortunately he's back home, and his forum access should be much better than it has been recently.

[Gary Thomas]

Although I got back on Saturday, the ADSL link for half of the country has been down since then, so I still didn't (until today) get access to the forum.

I won't be making any changes to the tech coding until I have finished the on-going story of implementing the xml input. In connection with that, I feel that we could have a useful discussion in this thread on the actual list and structure of the technology data. The present file (as I have mentioned before) is far to sketchy to be useful.

Cheers

[Richard Bruns]

Outside Opinion

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:

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

[Mark_Everson]

Hi Everyone:

Richard proposed a new idea, about 5 posts above, of using knowledge in technologies directly in the equations. I also think he suggested that we might be able to use those values as what the player sees. I think its a potentially cool idea, and would like to hear what others think about it! So consider yourself encouraged

The main advantages of using the knowledge variable in the interface is it would give a direct mapping of knowledge to effect that players could learn to use much more naturally than the previous level system.

One problem I forsee if we use knowledge in the interface is the step from knowledge (and so effect) 1 to 2. Although that is an enormous increase (amazingly a factor of two), showing gradiations between would involve numbers like 1.3 which would turn off a lot of people. Any ideas for a way around this?

What do you think?

Richard: I read the prof's thoughts, but really don't know what to make of them. It came through as the OO equivalent of psychobabble to me, but that may just show my ignorance of things OO!

[Gary Thomas]

Well, I do believe that I understand OO very well, but I could not understand the comments at all, except the generally very approving tone, which must be gratifying.

On the other hand, it appears to present the perception that OO objects cannot be used to represent dynamic relationsips. Most of the low level examples for polymorphism use things like bouncing balls as their exemplar. And they do pass information around, rather violently, as they bang into each other.

Cheers

[Mark_Everson]

-Bump-

Trolling for comments on Richard's proposal of three weeks ago to replace tech levels with "knowledge" values. Please see my post two above for further info.

Comments Greatly Appreciated!

[roquijad]

I'm putting here something I said in the "From CIV3 to Clash" thread.

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]

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]

From the Planning D 7&8 Thread...

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

[Gary Thomas]

I did say tha the list was off the cuff. In no way was it intended as a recommendation. I just want something reasonable and useable.

However, you seem to be taking the view that the game will have a single technology tree. I was taking the approach that each scenario could have its own special requirements. So, for a Dawn scenario, one could have objectives like "domesticate goats, sheep and cows, and grow some barley" as well as perhaps some other requirements. It seems to me that these are a bit more realistic and easier to achieve than finding tin to make bronze.

A quote from roquijad:

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

My sentiments exactly.

Cheers

[Richard Bruns]

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]

Hi Richard, thanks for the response.

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]

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]

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]

From Richard:

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.

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.

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.

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.

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.

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.

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.

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.

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:

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:

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:

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, &ltdescription&gtnull&lt/description&gt. 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