Thunderbrd
C2C War Dog
Yeah, so I wasn't about to try in the small amount of time I had to delve into the math on this to understand the reason you'd put it forward. Your re-explained intro helped a great deal.ABSTRACT: I did some statistical analysis to address the issue of the information a player gains by building an improvement with the described scheme, which subsequently fails to do anything because of an underlying unseen resource or bonus, giving the player unintended inferential power. I propose using the "randomly discover [bonus]" behaviour in the base game in order to baffle a player's exploitive attempts, and provide hard bounds on his certainty about information that is designed to be hidden.
I've made some assumptions about the mechanisms you're talking about, since I'm not entirely sure what they are and cannot possibly be sure without doing the modding you've been doing. I understand you're describing builds which supposedly plant improvements, but with an actual effect of <doing something> and, in some cases, immediately removing the improvement. This is powerful sugar that lets workers modify terrain, however, there is an issue with tile bonuses not compatible with these actions, if those bonuses are hidden to your current tech level. A simple implementation allows a player to learn hidden information by using these terramorphous builds and seeing them fail or do other than standard. What I've proposed is a means to introduce doubt into the system, so that the exploit is minimized - which I've called 'baffling the exploitive player'.
By creating a random chance of failure independent of the likelihood of the incompatible tile, the certainty that the incompatible tile is present given the build behaved oddly can be bounded from above. (The likelihood of the incompatible tile is some prespecified proportion, p, where p*N = number of tiles of that type, N being the number of tiles on the map. I assume p is a constant for any given map seed, but it at least is a constant for any given map simply.)
So here's the issue with this - I understand your intention now and its some good thinking. But how do we get around the fact that if the bonus already exists on the plot it should not be replaced by a worker action ever?
The problem is that it can be very helpful to make it so that (and this discussed modification does just this) some improvements, when they come into being on a tile, should place a bonus (which is in player terms a 'resource') on the plot. When the game is created, bonuses are placed all over the map and they are there whether the player sees them or not. If we allow this process to replace the bonus that is there even though the player doesn't know it, then we may end up causing some game problems as some resources would be potentially eliminated from the game entirely by the time they are revealed. The farmer's current build denies him the ability to do this via python. The bNotOnAnyBonus tag now allows us to set an improvement to not being able to be placed at all on that plot (and by default the build, which is the definition of the worker action that can place the improvement, should also be denied since it should check if the improvement the build action would place would be valid on the plot the worker is on.)
So the problem is this is basically just a boolean. We either:
a) Have the farmer waste his time (and sacrifice himself) to try to build an improvement that does not have the bNotOnAnyBonus tag but does have a BonusChange tag, only to find out that the improvement, when placed when the build finished, didn't add the bonus because the bonus must've been invalid since a bonus was already there.
or
b) Use both tags on the improvement and he can't try to build on the plot since there does exist a bonus there that the player doesn't see.
Anything in between would require that we enable the replacement of a bonus that is hidden on the plot which would then go back to causing the problem of potentially eliminating important later-game bonuses before they're ever revealed.
So while, yes, this kind of math makes my head hurt, more importantly I was not following how this could be a solution.
Seeing how you're looking to introduce doubt into the system, the suggestion may well have some merit. But it would not be simply implemented. So perhaps at some point I'll take a deeper look into perhaps utilizing this approach.