I will not rederive any of the equations or discuss any of the math here. I will simply trace the path from RP to tech level change, show how tech level change affects things, and describe what the editor needs to do. The discussion of the tech tree is in the Technology System Version 5.1 thread.

These equations are the same for all levels of technologies. The only real difference between Level 1, 2, and 3 technologies is the way the interface treats them.

Constants and Variables for Tech Growth:

Tn: The tech level on the turn before the calculations.

Tn+1: The tech level after the calculations.

m: This constant determines the effect that RP’s have on the growth and maintenance of a certain technology. It will probably be set to about 0.01, but can be changed for each tech.

c: This constant determines the amount of upkeep that a certain technology requires. It will usually be around 0.02, but can be different for different techs.

Ts: This is the level that a technology is at when it is first discovered.

E: This variable influences the difficulty of maintaining a technology. It will be influenced by the social and government model, among other things. It will not be functional for Demo 5, but we should prepare a place for it. For now, it will be equal to one.

H: This variable is the total influence of all helper technologies. It is determined by the following constants, variables, and equations:

HT1 through HTx are the technology levels of the tech’s helper technologies. These would logically have to be the technology levels at the previous turn. A level of technology that was just calculated would not be able to impact something that is theoretically happening simultaneously. For this reason, Tn for every tech should be stored until all of the tech level calculations are finished.

h1 through hx are constants that determine the influence of each helper technology. O1 through Ox are the tech level offsets applied to each helper technology. They give a bonus or penalty to the helper tech levels so that research is easier or harder.

W determines the overall influence of the helper techs. After all of the playtesting is done, we might fix this at a single value, but for now we should keep the ability to alter it so we can test different values.

RHL = (h1*(HT1n +O1-Tn) + . . . + hx*(HTxn +Ox-Tn))/(h1+ . . .hx)

H = 2^(RHL/W)

I: This variable influences the difficulty of raising technology levels. Like E, It will be influenced by the social and government model, among other things. Also like E, it will not be functional for Demo 5, but we should prepare for its inclusion and set it equal to one for now.

DR: This determines what diminishing returns, if any, will be applied to excess RP generation. Like W, it is here for testing purposes and might be fixed in the final model.

The steps from RP to tech change are as follows. V will describe some quantity based on RP’s that is carried over from one step to the next.

1) V1 = RP*m - E*c*(2^((Tn-Ts)/10))

2) If V1 < 0, then V2 = V1.
Otherwise:

V2 = H*I*V1^DR

3) Tn+1 = 10/ln(2)*ln((2^((Tn-Ts)/10))+(V2))+Ts

After this process is completed for every technology, the effects of the technology change must be calculated. Some technologies like Sanitation have direct effects on other models based on their level. These effects will probably not be in Demo 5, but we will have to prepare for that functionality in the tech model.

It might seem like these changes should be calculated in the other models. For example, the disease model could simply import the level of some tech and use that number in calculations of the spread of a plague. This would be easier, but it would cause big customizability problems. A scenario designer would have to remember that slot #87 and no other will affect the spread of disease. Civ 2 had many problems like this.

To ensure flexibility, each technology will have to have "Alter Variable" commands that can be defined in the tech editor. All of the variables in other models are defined independently of the technologies. Each individual technology would have the ability to affect those variables in some way. For example, the disease model might define some variable named CLEAN. The number of new people infected by a disease is divided by his variable. The Sanitation technology would then have an Alter Variable command like, "CLEAN=CLEAN*(.04T)" As the tech level increased, CLEAN would increase and disease spread would slow.

Another effect of technology increase is to allow access to a new technology. If the requirements for some technology are met, then that technology is set to its starting tech level and the player is notified of its invention. On the next turn, the tech level of that technology is recalculated.

The main effect of technology, and the one that will be included in Demo 5, will be applications and application factors. The application factors will be calculated for each application as follows:

E is the application effectiveness factor. If the application is a unit, it changes the unit's power. If the application is an improvement, it changes the effect that the thing has.

T1 through Tx are the levels of the technologies that are requirements for the application. R1 through Rx are the tech level requirements for the application. h1 through hx are constants that determine the influence of each required technology on the growth of the application. L is a constant defined for each application that determines the expected lifetime of the application.

RTL = (h1*(T1 - R1) + . . . + hx*(Tx - Rx))/(h1+ . . .hx)

E= RTL/10 + (10+L)/10 ^ (RTL/10) when RTL is positive or zero.
E = (10+RTL)/10 when RTL is negative.

Applications should also eventually have an Alter Variable command. The effect that the application has on some other thing is determined by the application level. For example, a sewer system would have an Alter Variable equation like, "CLEAN=CLEAN*(.2E)" There should also be a tag that tells how much of the civ is affected by this application. In this case, only a small area is influenced. But that is still pretty far in the future.

I would like the tech tree utility to do the following things. If anything here is not feasible, please let me know.

1. Set default values for m, c, W, and DR.

2. For every technology, input:
a. Technology name and text description.
b. The level of the technology.
c. Technology requirements and Ts.
d. Values for m, c, and DR. It would be a big help if these were defined in terms of the defaults (default c times some value). This way, we can change the default values and not have to redo individual values; they would keep the same ratio.
e. Helper technologies with O and h for each helper tech, as well as a W value defined in terms of the default value.

It would be nice if parts a through e were in different sections. Also, space should be left for the the Alter Variable section and sections dealing with E and I.

3. For every application, input:
a. Application name and text description.
b. The L value of the application.
c. Technology requirements with an h value for each requirement.

Later, the application editor should have much more functionality, but that is all we need for now.

With this editor, we should be able to define a technology like:

a. Farm Machinery and Equipment
b. Level 3
c. Requires: Agriculture 10% Ts: 10
d. c=default*.7 m=default DR=default
e. Helpers: W=default
Agriculture h=3 O=0
Mechanical Engineering h=2 O=2
f. (later) E=default
g. (later) I=default
h. (later) Alter Variable commands (more food, etc.)

The first is the formula for the RHL. Dividing by the sum of the h values hurts the system IMO. Currently, it would be impossible to change the total effect that RP's have. If you assigned a h1 of 3 and a h2 of 6, the H factor would be exactly the same as if you assigned a h1 of 1 and a h2 of 2. Given the stated definition of h, I don't think that is a good thing. So I propose that we stop dividing by the h terms.

This would make the H value larger, but that can be compensated for by changing the other variables. If it turns out that I am wrong, we can fix things so that the sum of h is one, and the system will act the way it currently does. Dividing by the values makes the system a lot less flexible; there is no way to alter the total effect that helper techs have.

The second change is the application effectiveness formula. Currently, it is rather inflexible. The long term behavior is altered by the L value, but there is nothing to change the short term growth of a thing. What if we wanted to have an application that doubles its effectiveness with an increase of 5 tech levels? We currently don't have that flexibility. Also, there is no way to change the rate at which something drops in effectiveness with tech loss.

So I propose adding two more constants to the E equation. G determines the short term growth, and F determines the rate of application drop with tech drop. So the formula would be:

E= RTL*G + (10+L)/10 ^ (RTL/10) when RTL is positive or zero.
E = (10+RTL)*F when RTL is negative.

If it turns out that these additions are not needed, then we can always set G and F back to 0.1 But I think that we should keep things as flexible as possible.

The other idea is a bigger change, but it should be feasable. It involves the current scaling rule that says that the knowledge is multiplied by 2 for every 10 levels of tech increase. Would it be possible to change those numbers for the overall system? Perhaps someone would want to cover a smaller time frame where the tech doubles only four tomes over the course of the game. Or perhaps we might find that the 2x per ten level rule does not work. There should be a place in the editor where we can change both the two and the ten. Let's call these the multiplier variable (MV, currently 2) and the gain variable (GV, currently 10).

These changes would affect the equations in the following ways:

In the H equation, the 2 would be changed to the multiplier variable MV.

The definition of W would be altered. It would have to be defined as something times the gain variable GV.

In the basic growth equation, all of the 2's would be changed to MV and all of the 10's would be changed to GV.

In the application effectiveness equation, all of the 10's in the RTL terms would be changed to GV. Also, G and F would have to be based on GV. Their default would be 1/GV, and each tech that changes G or F multiplies that default by something.

The L value is the only tricky change. It needs to range continuously from 0 to a value where the application grows as fast as the tech levels. Currently, L values go from 0 to 10 and the multiplier value is 2.

We don't want to have to change each L value every time MV is changed, so the use of L in the equation will have to be changed. So, we keep the current L range of 0-10 and change the equation to:

E= RTL*G + (1+.1*(MV-1)*L) ^ (RTL/GV) when RTL is positive or zero.

When GV is ten and MV is two, this is the curent equation.

If MV were changed to 1.5 to compress the time frame, then knowledge would be multiplied by 1.5 every 10 tech levels. To keep up with the rate of knowledge growth, E should be multiplied by 1.5 every 10 tech levels at an L value of 10. This equation does that.

If MV were changed to 3 to expand the time frame, then E would need to be multiplied by 3 every ten tech levels at an L value of 10. This equation will also work in that circumstance.

For any value of L between 0 and 10, the ratio of E to the knowledge level will be constant for any MV. Thus, MV change will not change the proportional longevity of applications.

RHL formula divisor...
I agree with you that the formula that we had before wasn't very good. I knew about the defects, but didn't know of a good way to fix them. I have an alternative proposal now that I hope you will be happy with. It also solves the problem that we may need to make some technologies arbitrarily much harder than others in terms of RP costs. The reason this might happen is if RPs generated in certain areas are always much larger than others. For instance, farming will consume the attention of most of the population for most of the game. Therefore RPs generated in agriculture are always going to be fairly large compared to many other areas. I propose that in the denominator of RHL we put a tech difficulty level D. D would average to be about 10, but could be much larger or smaller depending on the particular technology. Now there is a big difference between (h1 = 3 , h2 = 6) and (h1 = 1 , h2 = 2) for D = 10. The first set are very important helper technologies, that are hard to do without and make any progress. The second set are nice to have for researching that technology, but will not hugely affect the issue one way or the other unless they are way out of line. So now we have a standard where usually a helper strength of 1 is rather insignificant, and those of 10 or above are usually very necessary. In now if agriculture generates 10 times the RPs of everything else we can just make D for agriculture 100 instead of 10 to balance the system. I hate to add more parameters to the system, but this "overall strength of RPs" one is absolutely necessary IMO. What you think?

Effectiveness formula...
I feel that it's a very bad idea to throw more parameters in here. If we can't do it with RTL and longevity, then we simply have the wrong set of parameters or the wrong equation... Every additional parameter we use makes the model more meaningless to the player. I think we really have to be very careful about adding even more parameters, since IMO there are really already too many. I wouldn't even like longevity, except it gets us out of the problem of needing a whole sequence of applications when a single one would do. IMO the only place we should add new parameters is if something is Really Seriously broken. If we can figure out a way to take out some of the ones that we already have IMO that would be a good thing. If it turns out looking like a science project rather than a game we are Toast. So my challenge to you is to simply come up with a formula that uses longevity to get the early boost effect you're looking for, since we're stuck with longevity anyway. I think you could make a case that for high longevity you wouldn't get an early boost, whereas when the longevity is low you should probably get a serious amount of growth out of the application early.

If decreasing m makes upkeep too hard, then we can simply decrease c as well. The current parameters can already handle what you want to do with tech growth.

But there is currently no way to alter short term growth of applications. I think that the G term is needed. Why would it be bad to tell the player that G is short term growth and L is long term growth? Two numbers would allow for much greater flexibility than only one. If too many things depend on only one variable, then things would very hard to debug and customize. What if we decide that we want an application that never gets better? With the effect you are talking about, it would not be possible. But with two independent variables, it is possible to achieve this effect and many others.

I am sure there are similar effect in materials sciences. Wrought hammered steel never gains much in the way of effectiveness (maybe 50%) but the bessemer and open hearth processes (Are these suitable steel working applications, assuming steelworking is level 3 and metal working is 2) start small but rapidly gain effectiveness.

I was planning on tracing the growth of each technology and giving it a starting level based on how many timed it has doubled over the course of history. Otherwise the scales would get really mixed up. We don't have to be that precise for this demo; just assign an approximate starting level and advencement speed.

RP generation:

quote: Let’s consider a sample ancient civ to give context to this RP production. Suppose that the small Snurb Empire has ten simple agricultural provinces. RP’s are generated by each of those provinces, and also by trade within my empire and contact with the neighboring tribes. In addition to this, my capitol has a library, university, theatre, and forum. I am working on building some roads and fortifications as well as maintaining an army to defend myself. Note that these numbers are just meant to be examples. Exact values will have to be determined by playtesting. It is reasonable that my provinces would generate a base average of 400 RP each and split most of it among the techs relating to basic activities of that province. Any techs relating to farming, daily living, and simple crafts are thus supported, as well as social techs and arts. The advanced capitol city makes 1000 extra RP’s that give extra support all the basic sciences and arts. My trading activity generates 700 RP’s and supports transportation, economics, and some production techs. The basic operation of my government and centralized religion makes 500 RP’s for techs related to government and management, literacy, social technologies, and arts. The building of the roads and forts generates another 500 for engineering, masonry, and construction techs. And the maintenance of my army gives me 300 RP for military techs. So I have 7000 RP’s. . . As I continue to develop my civ, the RP production will naturally grow. Those roads and forts will make travel and trading easier and safer, so there will be more RP generation in that area. As the provinces become more developed, they will generate more RP’s. My government will have to get bigger and do more, so I get more RP’s from that. And as I expand my territory, I come in contact with new people and use my military and diplomacy more. My tech should grow at a healthy rate. Note that most of the RP’s are used for specific things. The player would only have control over a small portion of the province RP generation and a larger proportion of the RP’s generated by the advanced cities. Everything else counts as RP’s that come from building or doing something, so they are assigned automatically. ----- The only major change I would make is the implementation of a diminishing returns plan for all of the agricultural provinces. However, I would recommend that these diminishing returns be based on communication and transportation technologies, rather than a fixed scale. So the Snurb Empire would have pretty severe diminishing returns before the roads were improved, and the roads would lessen the effect. I'll assign new numbers to the provinces to better show how I think the diminishing returns should work. To keep the numbers the same so RP generation is proportional, I will multiply all province RP generation by five before applying diminishing returns. This may seem like a lot, but at this point the peasants would be supporting almost half the technologies. For reasons I will explain later, I am assuming that the most productive provinces are the ones closest to the capital. Old system RP generation: 500, 450, 425, 410, 400, 400, 390, 375, 350, and 300. Total: 4000 New system "True" RP generation: 2500, 2250, 2125, 2050, 2000, 2000, 1950, 1875, 1750, 1500. Total: 20,000 New system returns before roads: 2500, 750, 200, 75, 25, 8, 3, 0, 0, and 0. Total: 3561 New system returns after roads: 2500, 1250, 625, 300, 150, 75, 40, 20, 10, and 5. Total: 4975 Note that under this system, the provinces of a large empire with bad roads would produce less RP's than the provinces of a small empire with good roads. Thus good management is rewarded and ruthless expansionism is not. I have a preliminary idea for calculating these diminishing returns: 1) The base RP generation for each province is calculated. RP gain from bordering a neighboring civ is added to the province in this step. 2) This number is modified by a factor that measures the ability of ideas to go from that province to the capital. This represents the ability of people to put their work into the general pool of knowledge. This will have the effect of increasing RP production of provinces close to the capital. 3) The provinces are listed in descending order of RP production. 4) Final RP production is based on the following equation: RPf = RPi * C ^(L-1) where L is the position in the list and C is a communication factor based on the ability to share information among provinces. In the Snurb Empire, the road building changed C from about 1/3 to about 1/2. I think C should be averaged over the entire civ. If it was calculated by province, the player could concentrate on building up only the best provinces and leave the rest in the stone age.

Tech Tags:

quote: To help the AI and serve as a way to navigate the tech tree, we had planned for each tech to be assigned one or more interface tags. Each tag would be the name of the civ activity that the tech helps, and a number representing how much that tech helps. For example, a tech might be tagged with Agriculture:7 and Mining:2, meaning that it helps agricultural production a lot and mining production a little. The AI and the players can sort technologies by their tags, investing research in what is needed most. For example, a player would click on the Agriculture button in the tech interface, and all techs with an agriculture tag would be listed in descending order of the tag number. Rather than simply being a description, the interface tags can also have a direct impact on production using this new econ model. The ideal tech value T for some economic field can simply be a weighted average of the knowledge levels of all techs with that tag. --- The basic system hasn't changed much I posted it in the 5.1 thread, but some of the minor points have changed as the various models have evolved. To make sure we all know and agree on the system, I'll detail it here. Tags are the description of the tech's purpose and a number telling how important the tech is for that purpose. This number, known as the Z value, goes from one to ten, with one meaning minimally useful and ten meaning vital. If a tech is useless for something, it simply isn't tagged for that thing. Tags are used for the following purposes: They are the AI's primary method of dealing with tech growth. Other civs, you governers, and the people in a free society will use tags to decide what to research. Once the AI determines what areas needs to be researched, the tags are an easy way of telling it what specific techs to research. For example, if the computer is having chronic problems with rebellious provinces it invests in Happiness and Control technologies. Tags determine the fate of RP's generated by particular activities. These RP's are called Tagged RP's and are automatically spent on the techs relating to the activity that generated them. They provide the user interface for the technologies. The first layer of the interface is the tag, and the second layer is the name of the technology. It makes sense that to access a tech, players click on the tech's function. Note that one tech can be found in many places using this system. Alternately, a player that didn't want to get too involved with technology could just give RP's to the first layer if interface, and the RP's would be split among all the techs with that tag. In all of the previous three uses, the amount of RP's given to the technologies would be weighted by the tag number. A preliminary idea for distribution or RP’s would be to give each tech a percentage of the total RP spent as follows: For every tech, raise 2 to the power of Z/2 and then subtract one. Call this the Y value. Add up all of these values to find the X value. Each tech gets a percentage of the total RP’s spent equal to Y / X. When splitting RP's among tagged techs, some preference should be given to techs that are lagging behind. Not only will these techs be easier to gain and keep up, but they are also the techs that are probably holding things back. So there should be a temporary adjustment of the Z term for techs that are behind. It should be multiplied by some factor for every five tech levels that the tech is behind the average tech level of your techs with that tag. Tags are the main way that technology influences the other models. The economy model already has a way to make tagged techs impact the production outputs of a province. Other models can also use the weighted average of tech levels with the proper tag to influence things. I still think there is a need for an Alter Variable command to allow techs to fine-tune some specific part of another model, but the tags will be used for the changes in the big picture. Currently we have the following tags: Agriculture Disaster Prevention and Ecology Education Cash Flow and Economics Exploration/Movement (includes mobile communication) Government and Politics Happiness and Social Control Health Infrastructure (includes fixed communication systems) Military Production Prospecting and Extraction Pure Science Religion and Philosophy Standard of Living

Helper Tech Changes: These were already been put into the spreadsheet.

quote: The assumption in the current system is that a low level of a helper technology will hurt the tech growth of a tech. I recently realized that this is not a good assumption. Consider computers. Even when compuer technology was very primitive, say tech level 30, it was able to help research in much more established disciplines with a tech level of around 70. The presence of computers, even simple ones, is a lot better than the absence of computers. Yet the current RHL and H formulas would severely penalize tech growth as soon as early computers were added to the RHL formula. In fact, the current RHL and H formulae do not work whenever the helper technology and the technology being helped are not the same level. If the scaling rules are obeyed, technologies will rarely be at the same levels. I don't know why I dodn't catch this earlier. .... In earlier discussion, we agreed that the difference between helper and vital techs would simply be the magnitude of the h constant for that tech. But we have seen that that is not possible. For any h value, a system of techs that help each other has the possibility to rise without bound. So I propose that the formulas for helper and vital techs be differentiated. Vital techs would retain the formulas described above so that their benefits outweigh their upkeep, and helper techs will use a formula that eliminates the possibility of an infinite tech rise. Taking the square root of knowledge will work well, and it would be reasonable. We can assume that helper techs can only help so much, and at a higher knowledge level they cannot provide as much benefit. So: THL = h1(T1-Ts1+O1) + . . . hn(Tn-Tsn+On) where T1 through Tn are helper technologies H = MV^(THL/2W) TVL = h1(T1-Ts1+O1) + . . . hn(Tn-Tsn+On) where T1 through Tn are vital technologies V = MV^(TVL/W) H and V will multiply the excess RP's like H did before. Because these values will result in a larger V2 than before, I will have to change the numbers. c will have to be larger and m a bit smaller. The h1 through hn values will be smaller. W will have to be about 1.5 times the MV.

For the full derivation of these equations, see this post.

quote: While building the spreadsheet, I found a couple things that need to be changed. Previously, H and I only affected the excess RP's, the ones not needed for tech upkeep. I found that this can create problems. The marginal tech gain per RP will change a lot at the point where the tech change is zero. This creates instability, so I changed the equations so H and I affect all RP's produced. Tech growth is a lot more smooth now. Also, I needed to introduce a change in the naming system. Previously there were two things that were called Levels. The most common use referred to the tech level that changed based on RP input. However, a tech's place in the 3-layer tech hierarchy was also called its level, as in "Level 2 Technology." To avoid confucion, the tech's place in the hierarchy will now be called Tier, as in "Tier 2 Technology."

This brings us up to the point where OO coding and design was introduced by F_Smith. That whole episode is nothing more than a dreamlike blur in my memory, and I get the definite impression that I did something horribly wrong and/or disruptive in my attempt to understand that syetem. So I'll leave the tech model at that and refer the coder to my spreadsheet, which as far as I know is still the working system for turning RP's into tech levels.

Out of curiosity, has anyone else played with those spreadsheets? I went over them, but I might have missed something.

On a side note, I think that the week I spent making the spreadsheet resulted in more advencement and correction of the tech dynemics than anything else I have done. While they may not be useful for a coding standpoint, they were a good way to help detect several important bugs in the model. Would it help if I made a Visual Basic program for the tech model? I might be able to come up with something decent, but would it be useful as a guide for Java coding?

Thanks for the recap Richard! That will be useful. BTW I still really don't like the by-province diminishing returns idea. I think the general diminishing returns idea is sound but... The theme I'm trying to stick with is that changes in provincial configuration should have only very small game effects, and your model violates that. Could you try and consider something that just applies diminishing returns on the total RP generation without considering how RPs are bundled into provinces? Anyway, in trying to keep with my code more / discuss less philosophy I will leave it there.

I have not checked out your spreadsheet at any length. I would happily do it, but think I should stay focused on coding. If we don't turn up a team member that's happy to do it, perhaps you could put an advertisement thread up and see if a lurker is interested. If no one else gives it a good going-over I will try to do so before I start the coding.

By the way, I made a suggestion for reconstructing Axi's visitor thread, it's now about three posts from the end of that thread. If anyone is interested in starting a new visitor's thread (my suggestion is discussed in more detail there) I think it's a good idea.

Your VB idea is intriguing! I think such an exercise would definitely be of value. Just as an estimate off the top of my head, I think if you did the whole thing (say taking a month) it would save me at least a week of the month it would take me to do it. That's is in addition to what ever improvements come out of the model from having the testbed available. However, I think Laurent's point about trying it in Java merits just a bit more discussion... if you were to take a stab at it in Java, it would make my progress when I start much faster. Allow me to suggest that you were too easily shot down by F. Smith's notions of the way things Must be done. If we were to work on the tech model interactively together in Java, it probably still wouldn't meet those specs of his, but it would Work, and allow fairly rapid testing of the Tech model. Just let me know which way you're inclined to go and I'll give you my thoughts on the best way we can collaborate whichever way you choose.

Richard, can you go over your spreadsheet one more time, with almost-fresh eyes since you haven't probably looked at it in a while? It might be worthwhile to update the spreadsheet with the final versions of the equations (if its not already) so the global variables MV and GV are used etc. That way I could just use the spreadsheet as a guide, and compare my numbers to its numbers as a check for bugs. (I'm assuming you can do turns and RP use in some fashion.) I built the econ model that way, using my econ spreadsheet as a sanity test, and it was quite useful in the early going.

Right now it has ten techs that can be linked in any way via helper and vital techs, privided the user knows how to edit a couple equations. It would be trivial to copy-paste more techs in.

The smallest bit I can think of is a program that duplicates the functionality of the spreadsheet.

RP idea:

It ocurred to me last night as I was planning the VB project that RP should be based on labor input, not product output. If it was based on output, the system could easily reinforce itself too much and spiral out of control, as higher tech level led to more output, ad infinitum. Besides, it is logical to base it on labor input, sonce that is the amount of thought that perople will put in to the technology, so it wouls be distinctly related to the amount of ideas generated.

Duplicating the spreadsheet for a first step sounds fine. BTW, could you email it to me, just to make sure I have the current version...?

It would be good if you could simulate Tech growth from a given number of RPs in the spreadsheet. But if its too much work, don't bother.

I haven't actually done any coding yet, but I am thinking about this stuff. I have a few questions, and to make life easier on myself I will just quote where they come from...

quote: Originally posted by Richard Bruns on 02-29-2000 05:14 PM I would like the tech tree utility to do the following things. If anything here is not feasible, please let me know. 1. Set default values for m, c, W, and DR. 2. For every technology, input: a. Technology name and text description. b. The level of the technology. c. Technology requirements and Ts. d. Values for m, c, and DR. It would be a big help if these were defined in terms of the defaults (default c times some value). This way, we can change the default values and not have to redo individual values; they would keep the same ratio. e. Helper technologies with O and h for each helper tech, as well as a W value defined in terms of the default value. It would be nice if parts a through e were in different sections. Also, space should be left for the the Alter Variable section and sections dealing with E and I. 3. For every application, input: a. Application name and text description. b. The L value of the application. c. Technology requirements with an h value for each requirement. Later, the application editor should have much more functionality, but that is all we need for now. With this editor, we should be able to define a technology like: a. Farm Machinery and Equipment b. Level 3 c. Requires: Agriculture 10% Ts: 10 d. c=default*.7 m=default DR=default e. Helpers: W=default Agriculture h=3 O=0 Mechanical Engineering h=2 O=2 f. (later) E=default g. (later) I=default h. (later) Alter Variable commands (more food, etc.) [This message has been edited by Richard Bruns (edited February 29, 2000).]

On the tech builder, unfortunately I think I can do it quicker by starting from scratch than by using what Garth has, and figuring out everything he is doing. You say just after section 2 in the quote above "It would be nice if parts a through e were in different sections." If that is really the way you want it, I can try and do it that way. But it seems to me it would be much more functional to have everything for a single tech laid out on one editing screen so to edit the tech you don't need to push a zillion buttons and click OK as many times just to enter an exit all the different fields. What I have in mind is to put everything on one big editing console with something like three slots each for helper and vital technologies. (Maybe better would be to give five or six total slots and just have each one have a check box for whether it's a helper or vital, since the parameters are the same in either case.) So basically let me know if you are comfortable with the way I'd prefer to do it. I know I personally hate opening and closing lots of little things when a simple screen can give you all the information.

Also, in reef familiarizing myself with the model, I find out I still don't understand exactly what you are doing in the distinction between helper and vital tech's. Here's what you have:

quote: THL = h1(T1-Ts1+O1) + . . . hn(Tn-Tsn+On) where T1 through Tn are helper technologies H = MV^(THL/2W) TVL = h1(T1-Ts1+O1) + . . . hn(Tn-Tsn+On) where T1 through Tn are vital technologies V = MV^(TVL/W) H and V will multiply the excess RP's like H did before (snip)

The final effect comes from multiplying H and V. So HV = MV^(THL/2W) * MV^(TVL/W) = MV^( (THL/2 +TVL)/W)
So all you appear to be doing is rescaling the already arbitrary h1...hn in the THL formula by dividing them by 2! So as far as I can tell the distinction between helper techs and vital ones is arbitrary, and we should just use differences in the weighting factors as before . What have I forgotten that invalidates this argument?

---

Mark's point about the helper and vital techs let me to do a large amount of math and testing in an attempt to learn about the nature of indefinite rises in technology. The point was quite simple and valid, but it led me to backtrack several assumptions, mess with a lot of equations, and run many tests. I won't go into details unless someone asks for them, but a small math error in my initial calculations has come back to haunt me. The distinction between helper and vital techs is in fact arbitrary, but the scenario designers must know several caveats about helper techs:

In certain situations is is definitely possible for the system to go "critical" and take off, with the same amount of RP input leading to an ever increasing rise in the knowledge level. This contradicts the assumption that higher tech levels should result in more upkeep costs and therefore lower tech growth. This effect is more likely to occur when large numbers of RP's are being put into the system; it is hardly noticeable at lower tech levels and low levels of RP input.

There are several things to do to prevent this:

The W multiplier must be at least 2 times as large as the sum of the h values. 3 times as large or more is preferable.

c*E must be approximately ten times as large as m*I.

Adding a diminishing returns effect to the base RP's is a powerful way to restrict this growth. (Note that this is different from any diminishing returns scheme in calculating RP production.)

Interestingly, the course of technology in the past 200 years is quite similar to the behavior in the model that occurs to this 'bug'. I wonder if we could take advantage this thing and aim for rapid tech growth once a certain point is reached. That would be risky, but if it works, it would be great.

---

OK, then we had similar ideas about the tech designer. If we make it . XML is like HTML, but the tags can be anything. I given example at the bottom of this of what things might look like both using simple text files, and XML. The ordinary text files just specify in a rigorous format what the name of the technology, and all its parameters and helpers etc. are. My real XML knowledge is basically nonexistent, so I'm kind of faking it in the example, but I think you can get the general idea. I had to use ' (' instead of ' < ' in the pseudo-XML because otherwise the BB software thinks it's HTML.

But the most important point is figuring out what to do to get this stuff going as efficiently as possible. You have to trade off your effort involved in cutting and pasting together a large text file with just entering values into the Tech builder. At a guess the tech builder will take me six to eight hours to put together. And we do need one eventually, so my take at this point is I should probably just buckle down and to do it. The software builder could also have useful features such as automatically figuring out a one-turn tech gain for the tech entered given a set of tagged RPs. You could even eventually add a feature to check for "criticality" of the existing system automatically.

[this para edited for clarity (said could when meant couldn't... 3/10/10]
Thanks for digging in and doing all the re-checking on the system. In addition to the rules of thumb you suggest to prevent criticality, I think there are possible "global" solutions. For instance we could put a limitation in the system that H couldn't have an effect larger than x2. Any larger effect would be simply treated as X2 Some limit like that could well kill the criticality for all likely sets of inputs and helper tech values.

Here is what I meant on tech tags...

quote: For every tech, raise 2 to the power of Z/2 and then subtract one. Call this the Y value. Add up all of these values to find the X value. Each tech gets a percentage of the total RP’s spent equal to Y / X. When splitting RP's among tagged techs, some preference should be given to techs that are lagging behind. Not only will these techs be easier to gain and keep up, but they are also the techs that are probably holding things back. So there should be a temporary adjustment of the Z term for techs that are behind. It should be multiplied by some factor for every five tech levels that the tech is behind the average tech level of your techs with that tag.

Rather than having numbers like 7 in 2 for the tags respectively, you could just use percentages and skip your whole thing with Y. But in retrospect to given the other numbers in the system are mostly on a 0-10 scale, I've changed my mind in think we should just leave it the way you have that for the moment.

Examples referred to above for various types of input file:

Text file:

Tech: Farm Machinery and Equipment, Level 3
Requires: Agriculture 10%, Ts: 10
c=default*.7 m=default DR=default
Helpers: W=default
Agriculture h=3 O=0
Mechanical Engineering h=2 O=2
(later) E=default
(later) I=default
(later) Alter Variable commands (more food, etc.)

Tech: Small Animal Abuse, Level 3
Requires: None, Ts: 10
c=default*.7 m=default DR=default
Helpers: W=default
Agriculture h=3 O=0
Herding h=8 O=2
(later) E=default
(later) I=default
(later) Alter Variable commands (more food, etc.)

End text file

Pseudo XML:

(Tech)
Farm Machinery and Equipment
(Level) 3 (/Level)
(Ts) 10 (/Ts)
(Requires)
(Req) Agriculture (ReqLevel)10% (/ReqLevel) (/Req)
(/Requires)
(/Tech)

Perhaps we can go with the xml now, and then later we can generate an editor that writes the xml automatically. That way 'power users' would still have the option of using the xml directly, and others will have a friendly interface. But for now, it seems that I can certainly use xml without a problem.

---

quote: Originally posted by Mark_Everson on 03-09-2001 05:59 AM Pseudo XML: (Tech) Farm Machinery and Equipment (Level) 3 (/Level) (Ts) 10 (/Ts) (Requires) (Req) Agriculture (ReqLevel)10% (/ReqLevel) (/Req) (/Requires) (/Tech) [This message has been edited by Mark_Everson (edited March 09, 2001).]

Actaully, XML can be even simpler. The above is valid, but I show what it can be below.
I want to stress that the advantages of XML are:
-You can change the order of tags (attributes) the way you like
-You don't have to specify values which are all worth the default value.
(e.g. in civ2 armies usually have tags of special properties like: 00000000, which are repeated always every line - you can just omit them in XML)
-You can enrich the format without breaking all existing files.

Mark's example rewritten:
<Tech>
Farm Machinery and Equipment
<Level l="3" />
<Ts t="10" />
<Requires>
<Req> Agriculture <ReqLevel l="10%" /> </Req>
</Requires>
</Tech>

Cool, we'll try the XML for now, if it doesn't work out, I'll do that tech builder. I'll send you a sample file soon.

I think many players will actually want to see the tag strength that goes into various things. Of course, I could be wrong. But given the amount of micromanagement people are willing to put into Civ...

I still favor using the same scale for all technologies. Some players Will want to see a big readout of all the tech levels. I'm one of them . The reason is that a lot of the effect of the technology Web depends on achieving specific numbers. If I am racing for Gunpowder, I want to know how close I am! It's not historically accurate, but its IMO and important feature in 4X type games. I agree that the kind of more-realistic interface that you are looking for will appeal to many players. But I think there are also many who will want more details. I expect we'll need to do both. Anyway, playtesting and opinions from the public are needed to resolve this IMO.

Two basic tech objects, Tech and Application.

Tech is split into three categories: Theory (level 1), Field (level 2) and Skill (level 3). For now there is really no distinction between these three levels, but I am keeping them separate for possible future use.

Applications really behave differently, so they're a unique object by themselves.

I am also going to have a TechInfo class that holds all the unchanging info about each tech (most of the info in the tech model is of this sort). This will give more efficient memory usage, and allow for easy changing of Tech characteristics on the fly during the game for testing. All the actual Theory etc. objects will have is a pointer to the TechInfo object, a level and whatever else is civ-specific. There will be an analagous ApplicationInfo object.

Are the required techs always going to be the same as the helpers?

Right now I have a container for each of required and helper techs, but if they're always the same then perhaps we just would need to add a 'required level' field to all the helpers. Though it may be safer just to leave the two types in to accomodate the occasional tech that is required but not a helper.

How about this. We unify Required techs and helpers. Helpers remain the same, but have a new value called 'required level'. Where there is a Req tech thats not a helper you can set h=0 and the 'helping' will have no effect regardless of the other parameters. Where there is a helper with no requirement you set Req level = 0. In lots of cases the helper is also a requirement and vice versa, and this will streamline things.

Techs Existing:

Tech: Agriculture, Level 2
Ts: 0.0, cX = 1.0, mX = 1.0, DRX = 1.0, WX = 1.0
Helper: Biology, Weight 3, Offset 0, Level Required 0
Helper: Earth Sciences, Weight 2, Offset 0, Level Required 0
Tag: Agriculture Weight = 10

Tech: Biology, Level 1
Ts: 0.0, cX = 1.0, mX = 1.0, DRX = 1.0, WX = 1.0
Tag: Pure Science Weight = 10

Tech: Earth Sciences, Level 1
Ts: 0.0, cX = 1.0, mX = 1.0, DRX = 1.0, WX = 1.0
Tag: Pure Science Weight = 10

Richard: Is there a time its important for me to get the XML spec to you by considering your workload? I don't want to slow you down, but I'm not experienced with that stuff, and don't want to waste time either. I can get you something immediately if you want to get started, and don't mind potentially redoing a little bit of it in the future. If you wouldn't have much time to work on it in the near future anyway, then I'll definitely wait till like next weekend to get you someting.

There isn't any problem with unifying the required and helper techs that I can see.

I think that we can and should give the players all the tech information they need without using lists of numbers. What should they know?

The civ's tech ability compared to the neighbors.
The ability compared to the past; how much has it improved?
How happy is the populace with the tech level?

These three can easily be displayed with icons, no numbers required. Theae are also things that any ruler could be expected to know. Other things players want to know are not things that real rulers would know, but are important to the game. Here is my idea for displaying this:

The amount the tech level changed since last turn can be displayed with a color-coded list; players do not need to know the actual tech levels:

Tech Change:
Agriculture: +.2
Architecture:+1.2
Astronomy: +.01
Biology: -.2

Clicking on a number in this list could bring up a line graph that shows the recent trends in the tech level. Upcoming developments, like a new application or technology, could be marked on this graph, so the player sees a pictorial representation of where the tech is, where it has been, where it is going, and how long it will take to get there. Note that this graph does no necessarily have to have the actual tceh level marked on it.

Mark, I'll send you a Excel file with an example for this spreadsheet.

On another topic. My coding has made me think about the helper tech level equation: RHL = (h1*(HT1n +O1-Tn) + . . . + hx*(HTxn +Ox-Tn))/(h1+ . . .hx). The problem I've just seen is that, because of the divisor, the following effects of a single helper tech are identical for the FratPranks Tech that helps the CowTipping tech:
h=1 FratPranks
h=5 FratPranks
h=10 FratPranks

All give the same resulting RHL = HT1n +O1-Tn

Also the following two helper tech systems are identical:
h=1 FratPranks
h=1 IntenseBoredom

h=10 FratPranks
h=10 IntenseBoredom

I know you can change W, or the Os to make these various equivalent things have different effects, but its not very intuitive.

I propose that we ditch the denominator in the formula above. That way a helper with an h=10 will directly have the intuitive result of being much stronger than one with h=2. We can rescale W if necessary because of this change.

About your concerns for the graph proposal (in dealing with techs with multiplie requirements) Rich brought up in dealing with tech levels we could do something along the following:

Have the graph show when at current rate, an application will be discovered, when you'll meet the requirements for that particular tech level for it, if it will be earlier (kinda like a dashed line showing the exact date). You can click a button to see what other techs affect it and do the same for those that are required techs. For helper techs it may be a little more difficult.