raystuttgart
commented
4 years ago Hi guys,
since I really do not think the feature "Loyalty to the Motherland" is currently or yet accepted, when looking at the poll results, we should not yet invest too much effort in preparing "CivEffects" System for the modifiers proposed.
Most of the events themselves would most likely not need to be handled by "CivEffects" anyways. They will either become Python-Events which already have their own event system or DLL-Diplo-Events, that can be balanced in "GlobalDefinesAlt.xml". (But maybe some few modifiers could be added to "CivEffects" considering chances and amounts - but we will see and do that step by step when actually implementing the features.)
The other feature "Religions of the New World" seems to have much better acceptance - when looking at the poll results - and will most likely be implemented.
Thus we might prepare "CivEffects" System first for "Religions of the New World" and other features already likely too be accepted. Then step by step we can increase capabilities of "CivEffects" System for new features ones they get accepted (or at least are likely to).
Implementation considerations regarding the proposal mentioned in the forum thread.
I started wondering about an implementation and if we can link the effects to CivEffects, then some of the code for this feature will be reusable for other features later. The tradeoff is that it means something will happen in steps rather than a linear calculation based on a value from 0 to 100. One thing to remember about CivEffects is that they are coded to not be looped during the game, meaning the game won't slow down even if we add a lot of them.
Background on how to use CivEffect
First of all, a player can have the same CivEffect multiple times. If it grants a free promotion, adding one more does nothing. If it adds say +1 move to a unit, those units will get +2 moves.
The value a player has is simply the combined number of all owned CivEffects, a number, which is always cached and as such is always fast to use. BTS has an allow system from techs, which I reused, though I simplified it a bit. If we say allowUnit(farmer), then if that score is > 0, then the player can use farmers. If it's 0 or negative, then farmers are disabled. If no CivEffect grants a positive score, all players will get +1 from the start. This concept is used to allow units, buildings etc... well really anything, which should be possible to unlock.
First we create an enum, which lists the CivEffects, which can be granted through loyalty. It grant one at 50% loyalty, another is loyalty / 5 (for a total of 20 CivEffects at 100% loyalty) and so on. The list would likely be an instance of EnumMap (a new class I added. For now, it's a list/array). If we do this really fancy, this function is controllable from xml, but hardcoding at least at first would likely be a good choice. We can always upgrade later if we have something useful we want to expand on.
Make a function, which knows the new and old values of loyalty. Call the list generator for each, subtract the two lists and then call apply CivEffect with the difference. The apply function is designed to handle both positive (add) and negative (remove) and can also handle getting more than 1, as in apply this 3 times.
The result is that we end up with a function, which needs calling when updating(new and old values) and a function to make the list. The rest shouldn't need maintenance.
We likely need somewhere where we can set the enum as in which index links to which CivEffect. There is a setup function right after all xml data has been loaded, which is used to set up caches like that. This allows the setup to be somewhat slow without slowing down the game.
Proposed effects
Loyalty Rate Effects:
Revolutionary Rate Effects:
How to implement using CivEffects
Considerations
3: maybe a custom percentage is more what you had in mind compared to adding a bunch of promotions. It's doable, but not with CivEffects, hence less likely to allow code to be reused.
Alternatively we add combat strength as an option to CivEffects meaning the same CivEffect can be added multiple times to allow the bonus to stack.
4: In theory we can add a building, which adds a multiplier to domestic demands, but if we modify the CvCity code to also read a number from CvPlayer, then we can get away with adding the same CivEffect multiple times.
Units on the dock
One thing you haven't mentioned, but is already implemented in CivEffects is changing how many units are standing on the lower dock. It's currently 4 (number from the default CivEffect in xml. Can be changed). Adding CivEffects, which grants +1 or -1 is allowed, though regardless of how low we go, it will never remove the last unit. There is no hard upper limit either, though when I tested with 15, they were standing a bit too close. It became hard to click on the correct one, but other than that, no issues at all. Just a feature to keep in mind because... well it's already in the dll. Just add the number in xml and it's done.
High code reusability
That would be my take on an implementation, which would maximize code reusability. Doing it like this means we gain other features "for free". Take for instance "Added points to increase likelihood of specific units for immigration" sounds like something civics could also use, possibly for different units, or in some cases let the bonuses stack.