New Improvement Tags: <FeatureChange> & <BonusChange>

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.)
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.

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.
 
The python code for determining the type of forest being placed is
Code:
		if  lat > 60 or -60 > lat: ## region=="POLAR":
			if (pPlot.getTerrainType()==gc.getInfoTypeForString('TERRAIN_TUNDRA')):
				pPlot.setHasfeature(iFeatureForest, True, [B]2[/B]) ##snowy forest
			else:
				pPlot.setHasfeature(iFeatureForest, True, [B]1[/B]) ##evergreen forest
		elif lat > 25 or -25 > lat : ## region=="TEMPERATE":
			if chance <= 50:
				pPlot.setHasfeature(iFeatureForest, True, [B]0[/B]) ##leafy forest				
			else:
				pPlot.setFeatureType(iFeatureForest, [B]1[/B]) ##evergreen forest
		else: ## region=="EQUATOR":
			if chance <= 30:
				pPlot.setFeatureType(iFeatureForest, [B]0[/B]) ##leafy forest				
			elif chance <= 60:
				pPlot.setFeatureType(iFeatureForest, [B]1[/B]) ##evergreen forest
			else:
				if (pPlot.getTerrainType()==gc.getInfoTypeForString('TERRAIN_GRASS')):
					pPlot.setFeatureType(gc.getInfoTypeForString('FEATURE_JUNGLE'), [B]0[/B]) ##jungle
				else:
					pPlot.setFeatureType(iFeatureForest, [B]0[/B]) ##leafy forest
		pPlot.setImprovementType(-1)
It is the parameter in bold that determines the forest variant and it is just done on latitude or at least it should be.

Note it is the variant of the same feature that is selected. Some features have variants others don't.
 
The python code for determining the type of forest being placed is
Code:
		if  lat > 60 or -60 > lat: ## region=="POLAR":
			if (pPlot.getTerrainType()==gc.getInfoTypeForString('TERRAIN_TUNDRA')):
				pPlot.setHasfeature(iFeatureForest, True, [B]2[/B]) ##snowy forest
			else:
				pPlot.setHasfeature(iFeatureForest, True, [B]1[/B]) ##evergreen forest
		elif lat > 25 or -25 > lat : ## region=="TEMPERATE":
			if chance <= 50:
				pPlot.setHasfeature(iFeatureForest, True, [B]0[/B]) ##leafy forest				
			else:
				pPlot.setFeatureType(iFeatureForest, [B]1[/B]) ##evergreen forest
		else: ## region=="EQUATOR":
			if chance <= 30:
				pPlot.setFeatureType(iFeatureForest, [B]0[/B]) ##leafy forest				
			elif chance <= 60:
				pPlot.setFeatureType(iFeatureForest, [B]1[/B]) ##evergreen forest
			else:
				if (pPlot.getTerrainType()==gc.getInfoTypeForString('TERRAIN_GRASS')):
					pPlot.setFeatureType(gc.getInfoTypeForString('FEATURE_JUNGLE'), [B]0[/B]) ##jungle
				else:
					pPlot.setFeatureType(iFeatureForest, [B]0[/B]) ##leafy forest
		pPlot.setImprovementType(-1)
It is the parameter in bold that determines the forest variant and it is just done on latitude or at least it should be.

Note it is the variant of the same feature that is selected. Some features have variants others don't.

Ok, I'll look more closely and see if I can't determine how to best handle that variant in the dll coding. Thanks for sharing that! I may even be able to figure out how to get this more generically handleable in the xml.
 
Could you keep the first post updated with the changes made to the file(s).

Something like:

CIV4ImprovementInfos.XML
Tag|Description
FeatureChange|Feature placed on the plot when the improvement is finished being built
BonusChange|Bonus placed on the plot when the improvement is finished being built

It will make it easier for later rather than having to read through the whole file.

I am thinking I may convert all the stuff we inherited from RoM:AND and elsewhere into the same format so that we have something similar to the modiki for C2C.
 
So, these new tags would it make acutally possible to start a game with no resources on the map, right? To achieve this and make it more playable, we would need to:

- Change animal spawnes to not require resources
- Add a new tag iDiscoveryChance that determines how often they will "find" / place a bonus
- Define "groups", so that if you send your (for example) Prospector looking for minerals, here could find (=place) any mineral that you can see.
- Add some improvements that are limited in a ways that you can only find / place resources were it makes sense.

This would be definetly a cool option to the normal "all resources are placed while map creation".

* Subdued animals could be places as Herds on the map
* When you plant a forest, there is a small chance that it places Prime Timber
* When you build a Farm you WILL place a random crop bonus; if the farm is destroyed, the bonus is removed. What crop is placed is strongly depending on the crops you already have, with like 90% chance of being a crop you have and only 10% of discovering a new one. It could be depending on where on the world you are if you have no crops yet. (to increase diversity).
 
If "full of resources" is enabled, and indeed every bonus is equally incompatible with these terramorphous improvements, then indeed the configurations I'm proposing can't be used. But the player also is knowingly starting these builds on tiles that almost certainly have hidden resources. Seems like a different problem, different fix.

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.

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?

I'm glad we're moving towards a common understanding. (Not that I'd be overly upset if my work went to waste - I had a lot of fun computing it.)

That fact is precisely the obstacle my mechanism is meant to solve. Indeed, you must make it so that the worker build doesn't do anything if there is an unseen bonus on the tile. You can't replace that bonus - gameplay balance can't handle that yadda yadda. That is the restriction within which this mechanism is designed to operate.

So suppose you tell the worker to do a build. The build completes and then goes poof and doesn't work as advertised. (This is possible if the bNotOnAnyBonus tag is not used, IfIUnderstandCorrectly.) If these mechanics are deterministic, the player now has 100% knowledge there is a hidden bonus, and perhaps equally important, has paid a lame cost that he likely doesn't feel too great about. These two things cancelling, if they do, is not net-neutral in fun terms.

If there is a random chance of the build going poof independent of any other factor causing poofing, then the player doesn't have 100% knowledge of a hidden bonus (in fact, we can precisely bound his certainty according to my math, if valid), and also, IMO, the game can offer the player an in-context interpretation for the failure which is at least acceptable as any suspension of disbelief going on.
Come to think of it, this may be the final loose end addressed by Dancing Hoskuld - the hidden resources appear over the course of the game, making the probability y not a constant. I'll avoid introducing changes to the proposal for the sake of the flow of this post, for now.

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.

The first one. The worker 'wastes his time', this is a cost we have to face. All I've proposed is a way to change the information learned from that, by making these terraform builds also fail for another reason. When they fail, you don't know if it was because of a hidden bonus or because of the inherent failure chance.


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.

Indeed I may be wrong about the accessibility of this design; but I was under the impression that there was an existing markup tag for "random chance of revealing a bonus" - mines have this , and have a tiny, tiny, tiny chance of finding gold or other ores. This code must be available to any improvement we want, and by using it with, instead, a large (but not total) chance of success, the mechanism proposed as the combination of the OP + random baffling, can be achieved with minimal reprogramming.

===============
So, the loose end. What if the random chance of failure decreased as a function of technological prowess? Specifically, as the resources are revealed, this goes into the random failure factor calculation as an updated y, legitimizing higher x values. It's just an option, a sugarcoating if technically feasible. And it has a plausibility we can tie into the realism.

The other remaining challenge to validity was the interpretation of the bonus probability/prevalence. I need to know: for a given map which has a known "type" or seed, obviously there is an absolute measure of the number of a specific bonus on the map. Also clearly, there is a known probability distribution for that number, given the map type (without a specific map). What I wonder is what is the answer to the question: What is the chance that a given tile on a given map seed has a given bonus? This is a question about map scripts.

I only care about the nature of that chance insofar as it depends on the probability distribution for a map script. Things like resource clumping are incidental to me. The distribution might be:
  • a "constant" - exactly p% of the tiles are guaranteed to have the bonus (with rounding obv.), p is a function of the map seed.
  • a proper distribution - binomial or poisson or something, the number of tiles with that resource can be considered a random variable X, i.e. P(X = k) = p(k) for some p given by the map seed, 0 < k < N number of tiles.

If the distribution depends on something else not specified, I have a hard time seeing those hidden factors can't be modelled as something random.

It is specifically of interest to me if the distribution is poisson or not. Is there a chance v%, so that with v% probability, a given tile has the bonus, independently of each other tile? At the other extreme is the constant p% of tiles having the bonus. In between are any distributions where the tiles with the bonus might vary in number , but are still entangled.

I may not have to deal with this answer, as in actual fact, either you know where all the resources are, or none of them, so their prevalence can still be treated as having some fixed x% probability at any tile. But it might matter, I need time to figure out if so.
 
So, these new tags would it make acutally possible to start a game with no resources on the map, right? To achieve this and make it more playable, we would need to:

- Change animal spawnes to not require resources
- Add a new tag iDiscoveryChance that determines how often they will "find" / place a bonus
- Define "groups", so that if you send your (for example) Prospector looking for minerals, here could find (=place) any mineral that you can see.
- Add some improvements that are limited in a ways that you can only find / place resources were it makes sense.

This would be definetly a cool option to the normal "all resources are placed while map creation".

* Subdued animals could be places as Herds on the map
* When you plant a forest, there is a small chance that it places Prime Timber
* When you build a Farm you WILL place a random crop bonus; if the farm is destroyed, the bonus is removed. What crop is placed is strongly depending on the crops you already have, with like 90% chance of being a crop you have and only 10% of discovering a new one. It could be depending on where on the world you are if you have no crops yet. (to increase diversity).

Quite a bit more would need to be built out to enable this sort of thing and I can see a number of considerations to hurdle there but I did suggest something similar once so I do like the idea in theory.
 
If "full of resources" is enabled, and indeed every bonus is equally incompatible with these terramorphous improvements, then indeed the configurations I'm proposing can't be used. But the player also is knowingly starting these builds on tiles that almost certainly have hidden resources. Seems like a different problem, different fix.



I'm glad we're moving towards a common understanding. (Not that I'd be overly upset if my work went to waste - I had a lot of fun computing it.)

That fact is precisely the obstacle my mechanism is meant to solve. Indeed, you must make it so that the worker build doesn't do anything if there is an unseen bonus on the tile. You can't replace that bonus - gameplay balance can't handle that yadda yadda. That is the restriction within which this mechanism is designed to operate.

So suppose you tell the worker to do a build. The build completes and then goes poof and doesn't work as advertised. (This is possible if the bNotOnAnyBonus tag is not used, IfIUnderstandCorrectly.) If these mechanics are deterministic, the player now has 100% knowledge there is a hidden bonus, and perhaps equally important, has paid a lame cost that he likely doesn't feel too great about. These two things cancelling, if they do, is not net-neutral in fun terms.

If there is a random chance of the build going poof independent of any other factor causing poofing, then the player doesn't have 100% knowledge of a hidden bonus (in fact, we can precisely bound his certainty according to my math, if valid), and also, IMO, the game can offer the player an in-context interpretation for the failure which is at least acceptable as any suspension of disbelief going on.
Come to think of it, this may be the final loose end addressed by Dancing Hoskuld - the hidden resources appear over the course of the game, making the probability y not a constant. I'll avoid introducing changes to the proposal for the sake of the flow of this post, for now.



The first one. The worker 'wastes his time', this is a cost we have to face. All I've proposed is a way to change the information learned from that, by making these terraform builds also fail for another reason. When they fail, you don't know if it was because of a hidden bonus or because of the inherent failure chance.




Indeed I may be wrong about the accessibility of this design; but I was under the impression that there was an existing markup tag for "random chance of revealing a bonus" - mines have this , and have a tiny, tiny, tiny chance of finding gold or other ores. This code must be available to any improvement we want, and by using it with, instead, a large (but not total) chance of success, the mechanism proposed as the combination of the OP + random baffling, can be achieved with minimal reprogramming.

===============
So, the loose end. What if the random chance of failure decreased as a function of technological prowess? Specifically, as the resources are revealed, this goes into the random failure factor calculation as an updated y, legitimizing higher x values. It's just an option, a sugarcoating if technically feasible. And it has a plausibility we can tie into the realism.

The other remaining challenge to validity was the interpretation of the bonus probability/prevalence. I need to know: for a given map which has a known "type" or seed, obviously there is an absolute measure of the number of a specific bonus on the map. Also clearly, there is a known probability distribution for that number, given the map type (without a specific map). What I wonder is what is the answer to the question: What is the chance that a given tile on a given map seed has a given bonus? This is a question about map scripts.

I only care about the nature of that chance insofar as it depends on the probability distribution for a map script. Things like resource clumping are incidental to me. The distribution might be:
  • a "constant" - exactly p% of the tiles are guaranteed to have the bonus (with rounding obv.), p is a function of the map seed.
  • a proper distribution - binomial or poisson or something, the number of tiles with that resource can be considered a random variable X, i.e. P(X = k) = p(k) for some p given by the map seed, 0 < k < N number of tiles.

If the distribution depends on something else not specified, I have a hard time seeing those hidden factors can't be modelled as something random.

It is specifically of interest to me if the distribution is poisson or not. Is there a chance v%, so that with v% probability, a given tile has the bonus, independently of each other tile? At the other extreme is the constant p% of tiles having the bonus. In between are any distributions where the tiles with the bonus might vary in number , but are still entangled.

I may not have to deal with this answer, as in actual fact, either you know where all the resources are, or none of them, so their prevalence can still be treated as having some fixed x% probability at any tile. But it might matter, I need time to figure out if so.

Right. I'm following you but thinking of some alternative options as well. When I do get around to working on prospectors, the way they operate may well become a model for the manner in which great farmers, or perhaps simply 'farmers' may operate as well. There's much to consider in terms of things that have been proposed for the last few years on this subject and the end result may well be similar in nature to what you're suggesting.

At the moment, this is a fairly 'quickfix' project and has mostly been designed to work for the feature placements with the bonuses being given a method as well that is somewhat similar in nature.

Consider this - another approach entirely that I've always wanted to consider is to enable and allow multiple bonuses on a given plot which would force the player to choose which bonus to actually access with his improvement selection for that plot. In such a multi-bonus on the plot environment, one would need no consideration for trying to conceal the plots that may already have an unseen bonus because the plot could still be given the new bonus even though the unseen one remains there to still be found... particularly when we consider that we're generally talking about farmers here and planting where I would think a plot could have both a plant/animal resource AND a mineral resource (which are usually the ones that remain hidden for a long time in the game.) (I'm thinking something like this would be critical to Faustmouse's suggestion working as well.)
 
* Subdued animals could be places as Herds on the map

Some already do. Where they can and what they place depends on their tech level so at iron working (I think) they not only place the resource they give a trail and correct improvement as well.

Consider this - another approach entirely that I've always wanted to consider is to enable and allow multiple bonuses on a given plot which would force the player to choose which bonus to actually access with his improvement selection for that plot.

Except that some resources can be co-used. Shaft mines to get the coal below the ground and vineyards to get the grapes on the ground for example. Then there are mines that get multiple metals eg silver, lead and zinc from the same mine.
 
Some already do. Where they can and what they place depends on their tech level so at iron working (I think) they not only place the resource they give a trail and correct improvement as well.

Yes I know, and I like it :goodjob: A while back when I did the event review I already thought of a game where you start with nothing. Most of it could be done right now; resources are discovered by mines, farms, camps or can be settled by subdued animals.
 
Gah! I was just about to do the changes for the sea features coral reef and reef and the improvements beacon and lighthouse only to realise that there is only one improvement for both. So now I need to make two so that coral does not become reef with beacon.

edit Thinking on it would not these tags be better on the builds rather than the improvement?
 
I don't think so. This is primarily to make it possible for upgrading and razed improvements to make adjustments like these. Placed on builds, this is still kinda referenceable but it's a pain, it's slower to process, and with multiple potential builds for the same improvement it complicates things further.
 
OK and Argh I just updated from the SVN and lost all the work I had done on this. :( Obviously I need a to go out and visit someone.
 
You're saying you updated from a version control repository and lost your work.



Spoiler :
I offer the preceding rageface for lulz, not at your expense. I'm sorry if it is offputting; please let me know if so, such that I can update my sense of humour. It has been veering toward "dickish" of late.
 

Attachments

  • jackiesmall.jpeg
    jackiesmall.jpeg
    8.8 KB · Views: 134
Yes, I was supposed to be updating the version control repository with my work not the other way around. I have almost redone all the work now.
 
I have changed the XML but it is not working in game.
Code:
		<ImprovementInfo>
			<Type>IMPROVEMENT_BECON_CORAL</Type>
			<Description>TXT_KEY_IMPROVEMENT_BECON</Description>
			<Civilopedia>TXT_KEY_IMPROVEMENT_LIGHTHOUSE_PEDIA</Civilopedia>
			<ArtDefineTag>ART_DEF_IMPROVEMENT_BECON</ArtDefineTag>
			<PrereqTech>TECH_SAILING</PrereqTech>
			<YieldChanges/>
			<bActsAsCity>0</bActsAsCity>
			<bHillsMakesValid>0</bHillsMakesValid>
			<bFreshWaterMakesValid>0</bFreshWaterMakesValid>
			<bRiverSideMakesValid>0</bRiverSideMakesValid>
			<bNoFreshWater>0</bNoFreshWater>
			<bRequiresFlatlands>0</bRequiresFlatlands>
			<bRequiresRiverSide>0</bRequiresRiverSide>
			<bRequiresIrrigation>0</bRequiresIrrigation>
			<bCarriesIrrigation>0</bCarriesIrrigation>
			<bRequiresFeature>0</bRequiresFeature>
			<bWater>1</bWater>
			<bGoody>0</bGoody>
			<bPermanent>0</bPermanent>
			<iAdvancedStartCost>30</iAdvancedStartCost>
			<iAdvancedStartCostIncrease>0</iAdvancedStartCostIncrease>
			<iTilesPerGoody>0</iTilesPerGoody>
			<iGoodyRange>0</iGoodyRange>
			<iFeatureGrowth>0</iFeatureGrowth>
			<iUpgradeTime>5</iUpgradeTime>
			<iAirBombDefense>5</iAirBombDefense>
			<iDefenseModifier>0</iDefenseModifier>
			<iHappiness>0</iHappiness>
			<iPillageGold>5</iPillageGold>
			<bOutsideBorders>0</bOutsideBorders>
			<TerrainMakesValids/>
			<FeatureMakesValids>
				<FeatureMakesValid>
					<FeatureType>FEATURE_CORAL</FeatureType>
					<bMakesValid>1</bMakesValid>
				</FeatureMakesValid>
			</FeatureMakesValids>
			<ImprovementPillage/>
			<ImprovementUpgrade>IMPROVEMENT_LIGHTHOUSE</ImprovementUpgrade>
			<FeatureChangeTypes>
				<FeatureType>FEATURE_CORAL_WITH_BEACON</FeatureType>
			</FeatureChangeTypes>
			<TechYieldChanges/>
			<RouteYieldChanges/>
			<bGraphicalOnly>0</bGraphicalOnly>
		</ImprovementInfo>

The reason I suggested the build as a better place is because it is there that existing features are removed or not.
 
Hmm... could it be:
IMPROVEMENT_BECON_CORAL is misspelled? (BECON vs BEACON)

This might be a special case... Coral makes valid sooooo... I'll have to take a further look into the processing of this. You might have to include the same improvement as makes valid but I'm not sure. Again, will take further looking into. Also make sure that there isn't anything that would invalidate the Coral with Beacon improvement on that plot.
 
It is building the beacon/lighthouse it is just not replacing the coral with the feature. I thought I copied and pasted the feature names but will look again given the mistakes I have been making today.
 
Top Bottom