Tweet
Since the tech model will soon be coded (I said that a year ago, but hopefully it's true this time) it is time to bump and update this thread. The following additions and modifications have been made to the system since the last post in this thread:
RP generation:
Tech Tags:
Helper Tech Changes: These were already been put into the spreadsheet.
For the full derivation of these equations, see this post.
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?
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?
. So lets forget the possibility of VB and stuff like that... 
. What have I forgotten that invalidates this argument?
Comment