Firaxis: Corruption Breakdown

Marlor brings up a good point. I have always hated that corruption could go over 100%. If it were capped before the corruption fighting improvements/workers went into effect, there would be an obvious reason to build courthouses etc.
 
As I have stated earlier, anything like having 150% of corruption (although being capped on 95%) seems to be a flaw in the concept.
At the current moment (it is still new year over here) I am not really able to estimate, if this could be done in a patch, but I strongly would prefer to have an absolute top as of 95% of corruption. That is, as long as there are no corruption fighters (courthouses, police stations, policemen, whatever) are in place. Additionally, the one shield, one gold should be given to the player, regardless of any rounding which might prevent that.
And against those 95% all means which are given to the player then should work.
I guess, that such a concept could
a) be rather easily be programmed
b) be explained with just some words in the documentation
c) would be understandable by everyone, without the need of virtually de-compiling the code
d) for a-c) would be acceptable by the most players
 
@Yeti:
Thank you for explaining this OCN thing. I thought it was just the amount of cities you could have before higher corruption hit. WHich I knew increased with map size. I did not know that it included the city size..... anyways, thanks and it makes sense now so you all can ignore by previous post!
 
I've been digging into the code to try to provide a solid answer. I was incorrect regarding the block of code I posted, changing it to pClosestCity doesn't affect anything (well, it lowers corruption around the FP city by 1.

The Forbidden Palace does not provide a new cityranking Corruption ring so IT and the surrounding cities still receive significant corruption affects (though not even close to what they are without it) <nothing you haven't already posted>.

A corruption option will allow casual and fanatic fans to customize this most vital mechanic and is the solution I'm moving towards right now. A 50% reduction of shields on production switches would help but I get pretty mad when I am beaten to a Wonder :wallbash It would be very necessary to expand on Espionage to allow cheaper and easier intelligence on what your opponents were doing during the early game!


I want to be clear that I'm not trying to change this game system but to create a positive solution for everyone that fits within our designers vision. I consider how it functions right now as acceptable (painful yes, but not broken!!). We'll continue to discuss this until a final decision has to be made for the next update (Monday for any chance to post by the 10th).

I'm going to focus my efforts on other issues that "are" bugs for now.

Thank you for you support!

Jesse


For the coders, here's the expanded section on what was posted earlier - we'll see how things go before dropping code bombs

// city ranking

if (type == CORRUPTION_COMMUNAL)
{
cityRank = leaders[getWho()].getCities() / 2;
}
else
{
cityRank = 0;
for (cLoop = 0; cLoop <= g_cities.getLastIndex(); cLoop++)
{
pLoopCity = g_cities.getAt(cLoop);
if (pLoopCity == NULL) continue;

if (pLoopCity->getWho() != getWho()) continue;
if (pLoopCity == this) continue;

iTempDist = vectorDist(pRealCapital->getX(), pRealCapital->getY(), pLoopCity->getX(), pLoopCity->getY());
if ((iTempDist < iRealCapitalDist) || ((iTempDist == iRealCapitalDist) && ((pLoopCity->getDateFounded() < getDateFounded()) || ((pLoopCity->getDateFounded() == getDateFounded()) && (pLoopCity->getID() < getID())))))
{
cityRank++;
}
}
}

if (cityRank < optimalNumberOfCities)
{
cityCorruption = ((shieldsOrTradeArrows * cityRank) + 1) / 2;
}
else
{
cityCorruption = ((shieldsOrTradeArrows * ((cityRank * 2) - optimalNumberOfCities)) + 1) / 2;
}:wallbash: :o
 
Originally posted by Nexushyper
@Yeti:
Thank you for explaining this OCN thing. I thought it was just the amount of cities you could have before higher corruption hit. WHich I knew increased with map size. I did not know that it included the city size..... anyways, thanks and it makes sense now so you all can ignore by previous post!

Oh crud! I've confused you more by accident :p

No no, I meant to say that OCN goes up with MAP size, not city size.

But anyway - your basic gut feeling was correct :) While OCN goes up with larger maps, it does not increase as much as the map size does, so that corruption usually "feels" worse on larger maps.
 
Originally posted by Tavis
//
Code:
// city ranking
if (type == CORRUPTION_COMMUNAL)
{
	cityRank = leaders[getWho()].getCities() / 2;
}
else
{
	cityRank = 0;
	for (cLoop = 0; cLoop <= g_cities.getLastIndex(); cLoop++)
	{
		pLoopCity = g_cities.getAt(cLoop);
		if (pLoopCity == NULL) continue;

		if (pLoopCity->getWho() != getWho()) continue;
		if (pLoopCity == this) continue;

***		iTempDist = vectorDist(pRealCapital->getX(),
***			pRealCapital->getY(), pLoopCity->getX(),
***			pLoopCity->getY());

		if ((iTempDist < iRealCapitalDist) ||
			((iTempDist == iRealCapitalDist) &&
			((pLoopCity->getDateFounded() < getDateFounded()) ||
			((pLoopCity->getDateFounded() == getDateFounded())
			&& (pLoopCity->getID() < getID())))))
		{
			cityRank++;
		}
	}
}

if (cityRank < optimalNumberOfCities)
{
	cityCorruption = ((shieldsOrTradeArrows * cityRank) + 1) / 2;
}
else
{
	cityCorruption = ((shieldsOrTradeArrows * ((cityRank * 2) - optimalNumberOfCities)) + 1) / 2;
}

That looks good for a 1 core (palace only) ranking algorithm.

The issue I have at this point is that I'm not sure exactly what solution is desired. Given the following scenario:

Palace in City A, City B at a distance of 3, and city C at a distance of 6
FP in City D (far from palace), City E at a distance of 4, and city F at a distance of 5

Should the rankings be:
A = 1, D = 2, B = 3, E = 4, F = 5, C = 6 or
A and D = 1, B and E = 2, C and F = 3 ?

If the first, then:

Code:
...
iTempDist = vectorDist(pRealCapital->getX(),
	pRealCapital->getY(), pLoopCity->getX(),
	pLoopCity->getY());

if (bForbiddenPalaceExists)
{
	int iFPDist = vectorDist(pFPCapital->getX(),
	pFPCapital->getY(), pLoopCity->getX(),
	pLoopCity->getY());

	if (iFPDist < iTempDist) iTempDist = iFPDist;
}
...

if the second, then:

Code:
...
// iRealCapitalDist will have to represent the distance to
// the closer of the existing capitals, and a bool (bFPCloser)
// will need to be set to indicate which is closer.

if (!bFPCloser)
{
	iTempDist = vectorDist(pRealCapital->getX(),
		pRealCapital->getY(), pLoopCity->getX(),
		pLoopCity->getY());
}
else
{
	iTempDist = vectorDist(pFPCapital->getX(), 
	pFPCapital->getY(), pLoopCity->getX(),
	pLoopCity->getY());
}
...

In both cases the new code segments replace the lines in the original preceded with "***".

The first method always uses the shorter distance to a capital, creating a single ranking where the ranks are interlaced between the cities around the palace and those around the FP.

The second method forces all cities (being looped through for comparison) to use the distance from them to whichever capital is closest to the city having its rank calculated. This results in two rankings - one per capital.

I don't believe either one needs to worry about the existance of the SPHQ because that only affects (Communism type == CORRUPTION_COMMUNAL).

Edit:

Oh, and I'm assuming that the second is the desired one. The first method will make some existing cities more corrupt than they used to be (but not increase empire wide corruption) and result in the FP's only benefit be the increasing of the OCN.

This (solution 1) would be, strength wise, the same as the FP is in 1.12, but with the less corrupt cities being around both the palace and the FP (with corruption increasing more rapidly as you move away from them) instead of just around the palace.
 
Regarding the palace jump:

The jump target selection (where the palace will go) is set up to work in the way most advantageous to a civ whose capitol city is captured. It would appear that changing that part of the game would be an incredibly bad idea, because it would cause side effects in military strategy as well. It would be possible to eliminate the "exploit" by disabling the disband command for the palace city.

Regarding prebuilds:

The idea of allowing production to switch to another improvement at 0 shields, and then switch back to the current improvement with the current number of shields restored, is a great idea from the realism point of view. From the programming point of view it is a nightmare because each city would have to store an accumulated shields number for each possible improvement. Since the game can be modded to add an essentially unlimited number of improvements, this is probably not a viable option.

Regarding corruption in general:

The system which is ultimately implemented needs to meet these goals (IMHO):
  • Does not alter the human / AI balance significantly vs. the existing (PTW 1.27) system.
  • Provides a balance between casual players who just want to have fun, and hard core players who need extra difficulty to keep their game fun. Ultimately this means we don't want corruption reduced too much, but it can't be a crushing burden either. Maybe an option should be provided in the startup screen to choose low, medium, high difficulty for corruption. Or maybe the game level should factor into it.
  • The resulting mechanism must be relatively easy to code, so the final patch can be bug-free without negative impact on performance.
 
Originally posted by Tavis
I've been digging into the code to try to provide a solid answer. I was incorrect regarding the block of code I posted, changing it to pClosestCity doesn't affect anything (well, it lowers corruption around the FP city by 1.
I think that changing to pClosestCapital is part of a solution, but it is incomplete. There will still be a problem with the comparison against iRealCapitalDist further down.

Before I can suggest a code fix, I have a couple of questions:

Can "pClosestCapital" be the SPHQ, or is it restricted to being just the Palace or FP?

Is there a variable equivalent to "iRealCapitalDist" called "iClosetCapitalDist", matching pClosestCapital?

BTW, the fix for RCP looks nice.
Originally posted by Tavis
A corruption option will allow casual and fanatic fans to customize this most vital mechanic
A poll on this thread indicates that popular opinion is strongly favoring "corruption classic" :lol: as far as the FP is concerned. At the moment the poll has 71 votes for the FP to "Remain as strong as in CivIII/PTW", and 24 votes for the FP to "Change to be less strong than in CivIII/PTW".

That strongly suggests to me that even if any options are added for the FP's effect, the default settings should be for the original effect. And therefore, I don't think it is important to have any such option for the January release. In also seems to me that if such an option is added, it will take a while to work out what the option should be. The people who want the FP's effect reduced have some different ideas about how it should be reduced. They might need to start by opening a thread on that subject and come to an agreement on what option(s) they'd like.
 
Thanks Tavis for showing us the code. And thanks Yeti for coming up with the proposed code so quickly:goodjob: .

Tavis, please use the second method indicated by Yeti. Since the first would about get us back to C3C v1.00 where building of FP may increase corruption instead of reducing.

Yeti> I do not know if this might be a problem. I hope I am just worrying too much. The proposed code seems to be able to handle one FP only. This is okay for epic games. But it might cause crashes if a scenario is made with multiple FPs.

Also, any possibility you can come up with a version of code which uses the minimum of Palace Rank and FP Rank? I prefer using minimum of the ranks rather than using the distance as the primary determinant.
 
Originally posted by Qitai
Also, any possibility you can come up with a version of code which uses the minimum of Palace Rank and FP Rank? I prefer using minimum of the ranks rather than using the distance as the primary determinant.
I think that's pretty much unavoidable at this point. The structures in the code support easy use of nearest distance as the primary determinant. Using lowest rank (or even better, combined rank/distance corruption?) as the primary determinant would require new structures, a fair bit of recoding, and/or some potentially expensive recursion.

So it seems best to me to just accept that the definition of rank is that "the city is ranked from the nearest Palace or Forbidden Palace." Not a big deal vs. major restructuring :)
 
Please excuse the ramblings of a tired mind. There have been such a lot of posts in too many threads for this tiny brain to take it all in.

Why do we have a city ranking scheme? I can only infer that it is for calculating corruption. If so then surely it makes sense for equidistant cities (from any Palace type structure) to have the same rank.

Please, no cries of RCP rank bug. If the calculation of the distance from the nearest Palace like structure is correct then there will be no bug/exploit that the AI cannot counter.

I would hope that the above would lead to a simpler corruption calculation method which would allow different corruption models to be tested against a proven city distribution calculation and would facilitate the "tweaking" of the corruption model proposed by Travis.


Ted
 
More thanks to Tavis for his incredible (to me, anyway) responsiveness and openness, really working with the community to get this right. I echo SirPleb's comments regarding the next update, if we can get the FP back to pre-C3C, pre-RCP fix functionality, I think it will go a long way to restoring confidence in the corruption model as a whole as well as C3C in general. Whether there "needs" to be any changes to the functioning of the FP (which is obviously the subject of heated debate) there was certainly nothing in the documentation or marketing of Conquests to lead people to believe that there would be any changes. I think most people reasonably expected that the other corruption "bugs" (RCP, etc.) would be fixed without changing the FP. Once that has been accomplished, hopefully with this new update, then I am more than willing to take part in the debate of how the FP could be implemented differently for the future, whether as an option or by default. In the meantime, for those who would argue that the traditional FP is somehow exploitative or unfair to the AI, I recommend they read Qitai's sig for the best "user-defined option" to address that concern!
 
I've thought about it a bit more and I think a good fix is as follows.

Assuming that the answers to my previous questions are:
1) pClosestCapital points to a Palace or an FP, never points to a SPHQ
2) there is a variable iClosestCapitalDist which is the distance of "this" from pClosestCapital

I recommend making two changes in the code:

1) Change the code fragment
"vectorDist(pRealCapital->getX(), pRealCapital->getY(),"
to
"vectorDist(pClosestCapital->getX(), pClosestCapital->getY(),"
I.e. exactly as you intended at the start of this thread.

2) Also change the code fragment
"if ((iTempDist < iRealCapitalDist) || ((iTempDist == iRealCapitalDist)"
to
"if ((iTempDist < iClosestCapitalDist) || ((iTempDist == iClosestCapitalDist)"

I'm assuming of course that the distance element of corruption is handled elsewhere and that iClosestCapitalDist is calculated correctly somewhere before this code.

I believe that making the above two changes will solve all current rank related problems though of course it needs testing. They certainly won't make things worse - the code fragments I'm suggesting replacing are definitely wrong in the current code if "pRealCapital" means what I think it does, i.e. means the Palace.

After making those changes the English definition of rank for the purposes of corruption would be:

A city's "rank" is the number of cities owned by the same Civ which are closer to the nearest Palace or Forbidden Palace belonging to the Civ. If two cities are at the same distance then the one which was founded first is considered to be closer. If two cities are at the same distance and were founded at the same date, one of them is arbitrarily chosen as being closer.

Assuming that the existing calculation of pClosestCapital allows for the possibility of multiple FPs (I would guess that it does) then the new code will work as described above with any number of FPs.

Note that the above definition of rank will cause an effect we've become used to - when the FP is near the Palace, it doesn't gain as much as when it is far away. Cities which are close to both Palace and FP are in effect counted twice, increasing the rank of farther away cities on both lists. I think that's ok for now, that it is how everyone (who cared at all that is :) ) assumed this worked originally.

Finally, a comment for those who would like the FP weakened for the human or strengthened for the AI:
The code Tavis showed us creates an interesting opportunity. If after the line:
"if (pLoopCity == this) continue;"
we insert the new line:
"if (pLoopCity->pClosestCapital != pClosestCapital) continue;"
this would cause the Palace and FP rank lists to become distinct! I.e. non-overlapping. This would not reduce the effect of a far away FP. But it would greatly increase the strength of a nearby FP. And thus would be a big improvement for the AI, and often an offsetting improvement for novice players. I suggest not doing this just now - that one new line might increase AI strength so noticeably that many players would have to drop down a level, I'm not sure. It would need testing and discussion somewhere if anyone wants to pursue this. (Personally I'm happy either way so I don't intend to champion it.)
Tavis, a final thing about that line if you intend to try it internally to see its effect: it will only work if pClosestCapital has been set for all city objects before corruption is (re)calculated for any city. If pClosestCapital is being set in the same outer loop as is calling the code you published, a new loop before that to preset pClosestCapital would be required to make that line work.
 
Originally posted by TedJackson
Why do we have a city ranking scheme? I can only infer that it is for calculating corruption. If so then surely it makes sense for equidistant cities (from any Palace type structure) to have the same rank.

Please, no cries of RCP rank bug.
Rank is indeed for calculating corruption. But although rank is affected by distance, it is very different from distance. Without going through all the gruesome details, the bottom line is that if two cities at the same distance are given the same rank, the RCP exploit exists, like it or not :) I know you don't want that answer but it is the case. Same distance implying same rank is exactly the thing which made RCP powerful.
 
Originally posted by SirPleb

Rank is indeed for calculating corruption. But although rank is affected by distance, it is very different from distance. Without going through all the gruesome details, the bottom line is that if two cities at the same distance are given the same rank, the RCP exploit exists, like it or not :) I know you don't want that answer but it is the case. Same distance implying same rank is exactly the thing which made RCP powerful.
I'm really far too tired to be answering this but I'll give it a shot :)

Surely what made RCP an exploit was the ranking of ALL cities vs the Palace rather than ranking cities vs the nearest Palace type building?

From what I've seen the AI tend to build in a very RCP manner in their initial core and then they go "resource hunting" and end up with some very strange city placement schemes.

If my observations are correct (not a given) then any adjustment to corruption based on ranking via distance will benefit or hurt the AI in a similar manner to a human player.

My concern in this is not to give the human player an easier time but to reduce the complexity of corruption calculations thus allowing future modifications to be based on a solid, well described and understood method.

I should perhaps mention that RCP is not a preferred play style for me and I haven't raised this issue to preserve any particular game plan that I might pursue but only to simplify and demystify the whole corruption issue, which I feel can only benefit the entire Civ community.



Ted
 
I just realized something:
Ummm, Tavis... It's New Years Day! Shouldn't you be relaxing and / or nursing a hangover? We're all fanatics that love Civ III and enjoy talking about things like corruption details, but go ahead - enjoy some well deserved rest!

Originally posted by Qitai
Yeti> I do not know if this might be a problem. I hope I am just worrying too much. The proposed code seems to be able to handle one FP only. This is okay for epic games. But it might cause crashes if a scenario is made with multiple FPs.

It shouldn't cause crashes, but the additional palace flagged structures would only act like the C3C 1.12 FP does - they'd act like a courthouse in the specific city they are in, and increase empire wide OCN, but not result in an additional set of city ranks that would give you a new ring of productive cities around the structure.

To address this would require a variable sized data structure (a vector would work well if Firaxis is using the STL container classes). This structure could be populated either with the coords of the capitals, or with pointers to the city objects that contain the capitals. They may already be using something like this. I'm not sure, for example, if pRealCapital is defined as a special case, determined through a search to locate the capital's city, or is pulled out from an array that would also contain info on the FP, SPHQ, etc...

But anyway :) With whatever data framework they have, the solution would be along the lines of what Tavis posted back on page 1 - calculating the distance from each loop city to whatever capital is closest to the city having its rank determined. Then only those cities closer to that specific capital would increment the rank. This allows every palace type structure to have it's own productive core and separate city rankings.

Originally posted by Qitai
Also, any possibility you can come up with a version of code which uses the minimum of Palace Rank and FP Rank? I prefer using minimum of the ranks rather than using the distance as the primary determinant.

At first I didn't understand what you were saying, but in writing up an explanation of how I understood things to work now (1.12) and how they were going to be changed for the beta patch, I think I figured out what you're asking :)

You mean that in a situation where a city is (for example) closer to the Forbidden Palace than THE Palace, but due to there being a lot of cities around the FP, and not many around the Palace, it's "Palace Rank" would actually be lower than it's "FP Rank", you'd want to use the lower of those two ranks? That would be odd because it would result in situations where a city is using its distance to one capital to calculate distance corruption, and it's rank relative to a different capital to calculate it's rank/OCN corruption.

I see an issue with this.
You're calculating a pair of city ranks for every city, disregarding distance. So now some of the cities between your Palace and FP are "taking" rankings away from other cities. Those cities that are the 7th, 12th, and 19th ranked from your Palace, that would normally have FP ranks because they're closer to the FP than the Palace, are making it so that the 20th and higher ranked Palace cities have ranks 3 higher than they normally would (and 2 higher for 13 - 18, etc...). So every time a single city between your FP and Palace benefits from this, every city further away is negatively affected. To address this I guess you'd have to redo the city rankings one you determined which capital they were going to be ranked relative to. In other words take the rankings 1, 2, 3, 4, 6, 7, 8, 10, 11 and change them to 1, 2, 3, 4, 5, 6, 7, 8, 9.

Contemplating the net effects of this:

With a palace and FP both surrounded by lots of cities, the effect would be minimal - a couple cities between them would have slightly lower corruptions, but another city would have slightly higher corruption.

Now consider a case where the FP is far away on another continent with 2 cities, while the Palace is back home with 20 other cities... Previously (PTW) the FP would have itself and cities ranked 1 and 2, the Palace would have itself and cities ranked 1 through 20. If the lowest rank was used, then suddenly the Palace would have cities ranked 1 through 11, and the FP would have cities ranked 1 through 11 - meaning that many cities suddenly had their rank drop by 9.

Distance corruption would still be higher than with an optimally placed FP, but overall corruption would be considerably lower - meaning that the FP was made stronger.

Hmm - third scenario - FP and Palace in the same city or very close. Well, being in the same city would break this algorithm... Being very close would result in a whole lot of shifting of ranks, which after renumbering, would almost double the size of your productive low corruption core - like you'd like to see.

So it has some definite plusses, but I see some question marks too, plus it would be harder to implement.
 
by SirPleb:
Finally, a comment for those who would like the FP weakened for the human or strengthened for the AI:
The code Tavis showed us creates an interesting opportunity. If after the line:
"if (pLoopCity == this) continue;"
we insert the new line:
"if (pLoopCity->pClosestCapital != pClosestCapital) continue;"
this would cause the Palace and FP rank lists to become distinct! I.e. non-overlapping. This would not reduce the effect of a far away FP. But it would greatly increase the strength of a nearby FP. And thus would be a big improvement for the AI, and often an offsetting improvement for novice players. I suggest not doing this just now - that one new line might increase AI strength so noticeably that many players would have to drop down a level, I'm not sure. It would need testing and discussion somewhere if anyone wants to pursue this. (Personally I'm happy either way so I don't intend to champion it.)
I'd be in favour of exactly this procedure, at least I would prefer it over the FP v1.12 method which has actually some supporters (maybe they will change their view now?). But the latter only gives the option to build FP in a low-ranked (normally Palace close) city.
Seperated rank lists for each Palace-like structure would, however, still leave the door open to maintain different cores. But I'm also not too sure about the effects on the difficulty (i.e. step down a level) - it depends on the given OCN-benefit of an additionally built Palace-like structure (atm the benefit is: +0.1*OCN for FP if I understood correctly); maybe an improved benefit could balance things out here. Another question is if each rank list should be able to maintain a constant number of cities, e.g. equally distributed for each Palace-like structure like [improved]OCN/#_palaces, or advantageously biassed towards Palace like 66%OCN maintenance for Palace rank list (33%OCN FP).
 
@TedJackson: I'm not a true expert myself, but here is how I understand the difference.

There is a difference between the Palace Rank exploit, in which cities closer to the FP took advantage of the fact that they were assigned ranks based on the ranking of cities closer to the actual Palace and the RCP exploit/bug, in which cities that were the same distance from the palace were given the same rank. With RCP, it was possible by carefully placing all your first-ring (or second-ring, etc.) cities at the SAME distance (rounded down to the integer, i.e. 4 or 4.5 was considered the same) they would all get the same corruption rank, that of the first in the ring. So if you carefully placed your first 8 cities around your capital at exactly 4 or 4.5 tiles distance, all 8 cities were treated as Rank 1 cities for corruption calculations, leading to a huge advantage over the AI or casual players who might have some of that first "ring" at distances of 3, 4, and 5, resulting in those cities getting higher ranks for corruption. This could be done before/without the FP, and could also be done again with cities in rings around the FP, if the player is careful enough with city placements.
 
Originally posted by Yeti
To address this would require a variable sized data structure
I don't think so, simple code such as the two line changes I proposed should handle it as well as fixing the underlying rank bug.
 
Back
Top Bottom