Thunderbrd
C2C War Dog
The C2C Alternative Improvement Upgrade Mechanism
Some new dynamics to handle improvement upgrades have been officially introduced and awaiting xml development to support them. This thread is to explain these new dynamics, to discuss them, and to discuss the new xml adjustments they call for. So without further introduction, I'll get right into explaining the new dynamics and how they work. This description of the algorithms may be a bit dry and it infers what can be done more than flat out expressing it in many cases. It is drawn from a walkthrough of the code itself so should be 100% accurate to the function dynamic.
Here goes:
As normal, if any of your improvements have a primary upgrade setting that you've tech qualified for, if that improvement is worked (or if it is manned in the case of the fort improvements) the improvement will begin the upgrade process, accumulating points each round towards the upgrade threshold it requires to trigger the upgrade. (We have these amounts set very low by the way - so low that some of the leader trait abilities to reduce them is made moot.)
Once the upgrade threshold is triggered, the improvement enters into a new evaluation set that can have a few varied reactions. Previously it would've just upgraded the improvement to the primary upgrade. Now...
And that pretty much covers it. This has just been optimized for much faster performance with some caching mechanisms that make the most common upfront evaluations be remembered until a tech that might have changed things has been learned. That should make things work a lot faster here in general.
The xml for improvements now has a lot of work to do to recreate the primary upgrade paths that should now behave in a more fair manner and to provide some alternatives if we want to take advantage of some of the new features of this mechanism. I'm REALLY hoping we can get this taken care of before the end of the freeze because the single most annoying thing in play right now are these broken upgrade chains.
This should solve all of our problems that have currently led to many improvements having no upgrade potentials and forcing workers to come back to selectively patch your lands.
Note: The basic portion of this was added to the SVN about a week ago to help find problems my extensive testing couldn't find and I've now debugged those found since and that's just about to hit the SVN now.
Any questions, comments, concerns? Are we leaving the rebuilding of the upgrade paths to 001 or can we do this as a team effort?
Some new dynamics to handle improvement upgrades have been officially introduced and awaiting xml development to support them. This thread is to explain these new dynamics, to discuss them, and to discuss the new xml adjustments they call for. So without further introduction, I'll get right into explaining the new dynamics and how they work. This description of the algorithms may be a bit dry and it infers what can be done more than flat out expressing it in many cases. It is drawn from a walkthrough of the code itself so should be 100% accurate to the function dynamic.
Here goes:
As normal, if any of your improvements have a primary upgrade setting that you've tech qualified for, if that improvement is worked (or if it is manned in the case of the fort improvements) the improvement will begin the upgrade process, accumulating points each round towards the upgrade threshold it requires to trigger the upgrade. (We have these amounts set very low by the way - so low that some of the leader trait abilities to reduce them is made moot.)
Once the upgrade threshold is triggered, the improvement enters into a new evaluation set that can have a few varied reactions. Previously it would've just upgraded the improvement to the primary upgrade. Now...
- If the primary upgrade would be something the player could build there (this also now means that there must be an existing BUILD definition the player is ALSO qualifying for by tech!) it will capture that information and move on to further evaluations.
The Qualifications it looks for are:- The plot is not a city (duh).
- The plot is not impassable to the team in general.
- The plot is a water plot if the improvement upgrade requires it.
- If there is a feature requirement for the improvement upgrade TO UPGRADE, the feature exists.
- If a Bonus type must exist to validate the improvement upgrade, the bonus exists on the plot.
- If the improvement upgrade requires NO freshwater that freshwater access not exist.
- If the improvement upgrade requires flatland it makes sure the plot is indeed flat.
- If the improvement upgrade allows the movement of ships onto land that the land be coastal.
- If there is an outright any feature requirement for the improvement upgrade, that there is an existing feature.
- If the improvement upgrade requires it be placed on a hill that the plot is a hill.
- If the improvement upgrade requires it be placed on a peak that the plot is a peak.
- If the improvement upgrade requires access to freshwater and freshwater access does exist.
- If the improvement upgrade requires being on a riverside and the plot is a riverside plot.
- If the improvement upgrade requires a particular terrain and the plot is that terrain.
- If the improvement upgrade requires it be on a particular feature type that feature type exists on the plot.
- The normal complex evaluation for desert farms if the upgrade adheres to the same expecations as a built improvement.
- That there exists in the xml somewhere a build definition that the player tech qualifies for that would allow the player to potentially build this improvement upgrade.
- If any of the above noted qualification factors are disqualifying the primary improvement, it will then immediately check the <AlternativeImprovementUpgradeTypes> tag which is formatted as:
Code:<AlternativeImprovementUpgradeTypes> <ImprovementType>IMPROVEMENT_X</ImprovementType> <ImprovementType>IMPROVEMENT_Y</ImprovementType> </AlternativeImprovementUpgradeTypes>
- If it finds any alternative improvement upgrade definitions, it will check them all to find the first one that is fully qualified for upgrade according to all the qualifications it checked on the primary upgrade. If it does find a valid alternative that is fully qualified to upgrade, it will capture this information and move on to further evaluations.
- If the primary and all alternatives fail to be found valid, the upgrade process on the plot will be automatically frozen. This frozen status can be repaired by deselecting the plot from being worked by the city and the reselecting the plot to be worked by the city at any time in the city screen. Obviously not valid for unworkable plots outside any city's reach, but the frozen status doesn't stop a plot from being re-improved by workers in the field.
What this means is that, for example, a seed camp that can upgrade to a farm but doesn't require irrigation while the farm does can be placed on a plot that isn't irrigated then when will NOT upgrade to the farm right when farms are unlocked but will only be able to do so when the plot is finally given access to freshwater by irrigation technology allowing a nearby farm to channel water to the plot. If the city was working that non-freshwater accessed seed camp plot when farms became available, the upgrade process would countdown but then freeze when it finds it can't validate the farm for upgrade due to the lack of freshwater access and once canal tech is discovered the player can reset the plot by going into the city screen, deselecting the plot as worked then reselecting it as being worked. Often, with real farms around, that plot will probably be ignored and unworked after the farms are unlocked so it may never hit such a frozen status anyhow. This method to freeze/unfreeze can have a few applicabilities for strategic choices as well...
The plot hoverover information will show this freeze status in place of the normal round to upgrade countdown or other message that indicates what the improvement will need to do to upgrade. Should be very visible.
- If a valid improvement upgrade was found it will then check all builds that can create that improvement that the player has tech qualified for. If any of those will not destroy the feature on that plot then it will move on to go ahead and set the plot to have the new improvement upgrade and remove the old improvement.
Note: THIS aspect of the adjustment allows us to automatically allow one improvement that's validated by a wide set of bonuses to properly select whichever improvement upgrade is appropriate to the type of bonus that it's on by which alternative is validated by that bonus if the primary improvement upgrade is not.
- However, if it finds that all qualified builds will destroy the feature on the plot then it will select the build that would produce the most production in the process and define that as the production that would be derived from the upgrade. It will then, if an AI player, go ahead and upgrade to the new improvement, send the resulting production to the nearest city, and destroy the feature. Perhaps some AI improvements to futher evaluate this AS a decision with the options the player will be given will eventually be meaningful but for now we assume what Civ has always assumed, that the AI doesn't care about retaining it's features at all.
- If it's a player, and not an AI, however, it will give you options. The camera will center on the upgrading plot, will shine a light down from the heavens to point out which plot is the subject of the options being given, and send a popup with the options the player has. The main option on that popup is to select, as the AI would default to, the identified improvement upgrade that will destroy the feature on that plot. In the information hoverover on this selection, it will show how much production will be generated based on tech, but not based on any modifiers the city it's heading to may bring to the equation, and will show the city the production would go towards.
- It can also contain other options if other qualifying AlternativeImprovementUpgradeTypes exist. This means we can offer an alternative upgrade path for the player to take his improvements down if he's very feature conscious. If said alternative doesn't destroy the improvement it will let the player know in the information hover.
- Then there's always the 'Don't Improve at this time' option (which would be useful if you're waiting for a more eco-friendly option to become valid some techs down the road for example!) This will immediately place an improvement upgrade freeze on the plot as discussed before with all the same mechanisms for unlocking that freeze. Once the player realizes he has more options he can always go in and unlock the freeze on that plot and the next time the popup comes up as the round is passed, he would then be able to select the newly valid improvement upgrade instead.
- There's also an OK button there but until I get some more playtesting samples I wouldn't just hit that without selecting another option because my last test showed that doing so flat removed the improvement that was there and I've gotta figure out what's up with that.
And that pretty much covers it. This has just been optimized for much faster performance with some caching mechanisms that make the most common upfront evaluations be remembered until a tech that might have changed things has been learned. That should make things work a lot faster here in general.
The xml for improvements now has a lot of work to do to recreate the primary upgrade paths that should now behave in a more fair manner and to provide some alternatives if we want to take advantage of some of the new features of this mechanism. I'm REALLY hoping we can get this taken care of before the end of the freeze because the single most annoying thing in play right now are these broken upgrade chains.
This should solve all of our problems that have currently led to many improvements having no upgrade potentials and forcing workers to come back to selectively patch your lands.
Note: The basic portion of this was added to the SVN about a week ago to help find problems my extensive testing couldn't find and I've now debugged those found since and that's just about to hit the SVN now.
Any questions, comments, concerns? Are we leaving the rebuilding of the upgrade paths to 001 or can we do this as a team effort?