Firaxis: Corruption Breakdown

[SirPleb]

Originally posted by TedJackson
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?

It is as Justus II described - RCP and the Palace rank bug are two separate issues. The ranking of all cities vs. the Palace causes the Palace rank bug, not RCP.

 

[Qitai]

Originally posted by SirPleb

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.

I am stepping beyond my boundaries since I had not done any programming for many years. But Sir Pleb, it looks to me that the above definition would be somewhat similar to what we have in C3C V1.00 or what Yeti proposed in Method 1 (i.e. There is only one unique rank list, not two).

 

[Grille]

Qitai,
I think it's not a general definition; it is just valid for having only one rank list (method1).

The destinct lists method has (necessarily) another definiton for a city's rank, i.e. define city's list affiliation first [->min distance (P, FP, ...palace_structure_n)], than assign rank(list) (#of cities closer to P-structure in same list).
Ranks not 'unique': Cities belonging to different lists can have the same rank, cities belonging to he same list mustn't (->RCP).

 

[SirPleb]

Originally posted by Qitai
it looks to me that the above definition would be somewhat similar to what we have in C3C V1.00 or what Yeti proposed in Method 1 (i.e. There is only one unique rank list, not two).

Hmmm, I don't think so. Suppose we have six cities laid out like this:

  .   .   .   .   .   .   .   .   .   .   .   .   . 
.   .   .   .   .   .   .   .   .   .   .   .   .   .
  .   a   .   .   .   .   .   .   .   .   d   .   . 
.   .   .   .   .   .   .   .   .   .   .   .   .   .
  .   .   P   .   b   .   .   c   .   F   .   .   . 
.   .   .   .   .   .   .   .   .   .   .   .   .   .

P and F are Palace and FP.
a is distance 2 from P
b is distance 3 from P
c is distance 3 from F
d is distance 2 from F
a's rank using the above definition is 1 because there is 1 city closer to the nearest Palace/FP - the Palace is closer to itself.
b's rank is 2 because there are two cities closer to the nearest P/FP - a and the Palace itself.
c's rank is 2 because there are two cities closer to the nearest P/FP - d and the FP itself. (The FP is the nearest P/FP to c.)
d's rank is 1 because there is one city closer the nearest FP - the FP itself.
P and FP both get rank 0 because there are no cities closer to them than themselves.
So the result is P,a,b have rank 0,1,2, and F,d,c have rank 0,1,2.
Does that make sense?

If P and F were very close then the two lists end up overlapping and some rank numbers end up being represented just once, which is my understanding of why overlapped Palace and FP have always been weaker than separated ones.

 

[Yeti]

Originally posted by SirPleb

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.

Your code is slick - nice and simple - I like it. As long as those variables exist and are already calculated, that should work great.

But to support a variable number of capital flagged buildings the code would still need to do a complete search of cities, or step through a capitals array, to assign values to the variables that we need in the ranking code (iClosestCapitalDist and pClosestCapital). Unless I'm missing something?

At this point it looks like the problem isn't as much solving the problem, as identifying the problem. We ned to define our requirements.

?? - Should there be one rank list, or one rank list per capital?

?? - Should a city's rank be based on the closest capital, or the capital that would give it the lowest rank?

I believe PTW uses separate rank lists, with the rank being based on closest capital - correct?
** edit - duh... I wasn't thinking here - see my later post down a couple **

I believe the initial goal was:

- Fix RCP and remote palace exploits (both rank numbering issues).
- Support additional "FP type" buildings in C3C (SPHQ) (I'm not sure how this became a problem since the SPHQ only comes into play in Communism, in which ranks aren't calculated anyway).
- Change nothing else with how corruption works vs PTW.

Due to time constraints and an apparent lack of consensus, perhaps we should leave it at that for now?

 

[SirPleb]

Originally posted by Grille
The destinct lists method has (necessarily) another definiton for a city's rank, i.e. define city's list affiliation first [->min distance (P, FP, ...palace_structure_n)], than rank(list).

That's what is required for the lists to be distinct regardless of overlap. The English definition I used for rank results in distinct lists if the Palace and FP are far apart, semi-distinct lists if they are close together. Since that is what I think we all understood to be happening in CivIII and PTW (and initially we expected in C3C ), that's the fix I recommended with just two changes.

The third change I mentioned, inserting a line, should accomplish everything you described Grille, making the lists fully distinct.

 

[SirPleb]

Originally posted by Yeti
But to support a variable number of capital flagged buildings the code would still need to do a complete search of cities, or step through a capitals array, to assign values to the variables that we need in the ranking code (iClosestCapitalDist and pClosestCapital). Unless I'm missing something?

I assumed (inferred from Tavis's attempt previously to solve the problem by substituting pClosestCapital) that this has already been done. I.e. that for each city object, the member pClosestCapital has been previously set based on comparing distances to the Palace and to all Forbidden Palaces. That must be confirmed of course.

Originally posted by Yeti
At this point it looks like the problem isn't as much solving the problem, as identifying the problem. We ned to define our requirements.

For sure! I've been assuming that the problem is the one you describe. I.e. restore the distance and rank behaviour to what it was in PTW, fix the Palace rank bug, and eliminate RCP.

To me that seems a good definition because:
1) It seems to be what Firaxis intended for C3C, i.e. that anything else we've seen so far is from bugs. Something which has ended up confusing the issue a bit is that some people (a vocal minority? ) like some of the results of the bugs.
2) It seems to be what the majority want according to the poll.
3) It is simpler and therefore safer than implementing a new definition.
4) As TedJackson said in another thread: "I've voted for the old Civ3/PTW style FP. Not because it's necessarily better but because I think it more important that the codebase gets back onto it's original track. Once the Corruption and Ranking functions are demonstrably working as (originally) intended then perhaps the introduction of alternative FP "modes" could be attempted."

The only part I'm a tad uncertain about is the precise meaning of "restore the distance and rank behaviour to what it was in PTW". Because Tavis has said the code has changed very little, and because of how the game felt, I've assumed that PTW's behaviour was the semi-distinct lists which would result from the definition of "rank" I've been using. To be certain about this would require analyzing the PTW code in this area.

 

[Yeti]

AARGH! I'm a moron.

I wrote that and went to bed, and then started thinking and realized I've got the PTW rank handling wrong. It bugged me enough to drag my butt out of bed

In PTW:

A city's rank is the number of cities closer to THE Palace than that city is to its nearest capital.

Right?

And that causes both the RCP and remote Palace exploits.

So it isn't a simple case of "fix the bugs and change nothing else" because the strength of the FP in PTW was largely due to those bugs. There was one rank list, but it had lots of duplicate entries.

So what reproduces that most accurately? A single list with no duplicates, or one list per capital? Neither really...

So this is quite complex. I'll need to ponder this further. I don't think I'll be falling asleep too soon

 

[SirPleb]

Originally posted by Yeti
A city's rank is the number of cities closer to THE Palace than that city is to its nearest capital. Right?

Yup, that's my understanding of pre-C3C in the absence of seeing the actual code.

Originally posted by Yeti
And that causes both the RCP and remote Palace exploits.

No, it causes only the Palace rank bug.

RCP is from a different cause altogether. Essentially, in a programming sense, it is because the code does not directly use an ordered list at all. Instead for each city it counts the number of closer cities. That bug is now fixed by the code:
"|| ((iTempDist == iRealCapitalDist) && ((pLoopCity->getDateFounded() < getDateFounded()) || ((pLoopCity->getDateFounded() == getDateFounded()) && (pLoopCity->getID() < getID()))))"
That code in effect creates an ordered list (and thus eliminates RCP's power) by making the order of cities at the same distance predictable. It is a safe bet that that code was added in C3C.

Originally posted by Yeti
So it isn't a simple case of "fix the bugs and change nothing else" because the strength of the FP in PTW was largely due to those bugs. There was one rank list, but it had lots of duplicate entries.

I don't think so. If you plot out a sample on paper I think you'll see that it essentially resulted in two distinct lists, except where there was overlap due to the Palace being near FP. What was wrong was that the rank numbers in the FP list were wrong. They were sometimes too high, sometimes too low, due to being compared with other city distances from the capital. And that resulted in the Palace rank bug.

 

[Grille]

Cleared.
Though I prefer fully destinct lists (obviously...), I would certainly not stop playing C3C with if the other change applied.

by Yeti:
A city's rank is the number of cities closer to THE Palace than that city is to its nearest capital.

Yup basically (at least it seemed like...), if the rank could have the value '0'


edit: beaten; X-posting got me ranked '2'

 

[Qitai]

Just to be sure. What is the definition of pClosestCapital? Closest Capital to pLoopCity or Closest Capital to "this"? If it is the later, then it would be fine I think. But if it is the former, then it will run into the problem I mention earlier. Let me know if I am wrong.

 

[SirPleb]

Originally posted by Qitai
Just to be sure. What is the definition of pClosestCapital? Closest Capital to pLoopCity or Closest Capital to "this"? If it is the later, then it would be fine I think. But if it is the former, then it will run into the problem I mention earlier. Let me know if I am wrong.

I don't think it can be the former because Tavis tried using it in the first line to be fixed and didn't mention any other code. Therefore it is not recalculated in the "cLoop" loop which iterates through pLoopCity values. And therefore it is constant relative to them. And that only makes sense if it is your second definition, closest capital to "this". I think it is probably a member variable of the "this" class which represents a city object. It is possible it is a variable set in an outer loop but that wouldn't make a difference regarding this problem.

 

[Tavis]

I tested the overlap code with PTW FP effects as Communists (CORRUPTION_COMMUNISTS) with the SPHQ. It's obvious why people enjoy it so much - you have the producing power of 2/3 civilizations!! How about just allowing players to enter a game controlling multiple tribes?

The current plan is to return it to pre-C3C w/ the fixes outlined above. I'll post the final early next week.

Heh, I added No Corruption to the Editor - now that's insane on higher difficulty levels - heheh

 

[Grille]

Originally posted by Tavis:

The current plan is to return it to pre-C3C w/ the fixes outlined above. I'll post the final early next week.

Thanks for the info.

Heh, I added No Corruption to the Editor - now that's insane on higher difficulty levels - heheh

You mean the AI can generally handle somehow altered corruption levels?


Or do I get anyways insane about their totally uncorrupted production capacity?

 

[The Last Conformist]

Originally posted by Tavis

Heh, I added No Corruption to the Editor - now that's insane on higher difficulty levels - heheh

Is thes a global toggle, affecting all civs equally, or is it settable for individual gov'ts?

 

[akots]

After some analysis and thinking and experimenting, there are two points which I think must be addressed.

Distance corruption in C3C beta 1.12

First, by focusing on rank corruption, distance corruption must not be neglected. And there are some indeed important changes made to that. To check how the system works, I did the following experiment with two cities (capital and another city), tiny map.

1) Varied distance from Palace to the second city to get corruption.
2) Varied government
3) Varied difficulty level

Some data are posted in the end as plots. The following were conclusions that were made:

1) For distance corruption purposes, the distance from the Palace is measured in increments which are seen in Plots 1 and 2. The distance is more conveniently tabulated as a “grade” (to make it different from rank).
“grade” distance
1 2
2 3
3 4-5
4 6
5 7
6 8-9
7 10
8 11
9 12-13
10 14
11 15
12 16-17
13 18
14 19
15 20-21, etc.

Distance corruption is proportional not to the distance but to this grade to encourage OCP and flexibility in building cities. Same goes for RCP 8-9, 12-13, etc.

2) Distance corruption is calculated as percentage of total corruption.

3) Difficulty level has no effect on distance corruption.

4) For each grade at distance less that half of map size, distance corruption is increased by 3.3% in Democracy, by 4.0% in Republic/Feudalism/Fascism/Monarchy (R/F/F/M), and by 6.4% in Despotism. Also, in Despotism, Corruption reaches maximal 96% earlier. See Plot 3.

Rank corruption in C3C beta 1.12

Second thought is about rank corruption. If getting abstract from how to determine rank, it looks like having corruption proportional to rank or rank/2 is a bad idea. It rapidly reaches 95% even in rank<OCN layout even if production is as high as 20 shields. In another words, you get to 95% corrupt cities even if you did not reach OCN when distance corruption is added. The distance component is added to rank component (I don't know if there is more complex relationship in these), there is obviously either some typo in Tavis posted code or some misunderstanding. To check it out, I have done RCP9 ("grade"6) on a tiny map (default OCN 14 was changed to 7 by switching to Sid level). Knowing the distance component of corruption, and assuming that total corruption is sum of distance + rank corruptions, it is possible to calculate impact of rank corruption.

Results for tiny map size/Democracy are shown in plot 4 for Chieftain and Sid levels. At Chieftain, player has corruption increased by 2.26% for each rank. At Sid, loss is 4.54% per each rank.

To see the effect of OCN, similar study was then performed for Standard map size with OCN 20. Map contained plains modified to produce 25 shields/tile. Population 5 towns were used for overall production 150. 32 cities were placed and connected by roads to the capital. Results for Chieftain and Sid levels are shown in plot 5. For Chieftain, rank corruption increases before OCN at 2.28% per rank and soon after OCN, at 3.3%/rank. For Sid level, corruption increases before OCN at 4.5% per rank and after OCN, at 9.0%/rank.

It is evident that 75% maximum is not indeed the maximum because it has added 20% distance corruption component to give total 95% corruption. Thus, total corruption is apparently not asymptotically reaching some limit, it just continues to grow to some unlimited number. That is why corruption-fighting improvements have no effect. Corruption can be as high as 200% or 2000%.

The mostly striking is that rank does not depend on map size. This is indeed a thing which unbalances the game. Also, as it was noted before, rank corruption is the major component versus distance corruption at non-OCP built cities. Even in OCP-built cities it is rapidly overwhelming.

Is this intentional? Does it have to be fixed?

It seems reasonable that rank corruption coefficients have to depend on map size. Also, this results in extremely unbalanced game on higher levels. Not only cost of production is decreased for AI, but human player gets a huge corruption penalty. This penalty is unrelated to map size, however. It is also evident that playing on tiny/small maps is more easy than on huge maps mostly because of this.

For files and Excel spreadsheet with extensive description and numbers please e-mail me.

 

[TedJackson]

Thanks to SirPleb & Justus II for pointing out that I was mixing my bugs

Re-reading my original post I realise that I wasn't as clear as I should have been

I wasn't (intentionally) suggesting that all first ring cities at the same distance should have rank 1 but rather that those cities should have the same rank (possibly arrived at as the average of the sum of the number of cities at that particular distance, rounded up) not simply give them different ranks based on the founding date.

So, using my ranking method above, for 4 first ring equidistant cities the rank of each city would be 2. Similarly if there were 5 equidistant cities then each would have rank 3 and six equidistant cities would each have rank 4.

The point I was trying make is that it seems intuitive (to me ) that cities at equal distances should suffer similar corruption rather than arbitrarily ranking them by founding date.

Apologies for confusing the issue with the Palace Rank bug.


Ted

 

[nihil8r]

fight the power!

 

[akots]

Originally posted by Qitai
There is only one unique rank list, not two

This is exactly the case.
Total corruption=distance component + rank component.

It would be nice to have a slightly more complicated equation like
Total corruption=distance from Palace component - 1/(distance from FP) component + rank from Palace component - 1/(rank from FP component).

This requires some additional parameters. Distance from FP and rank from FP can be determined similar as they are for the Palace. However, the functions and coefficients of FP distance and rank would have to be balanced for difficulty, government, map size, etc.

It seems also reasonable to change the linear function of especially rank component into something less rapidly advancing to 95%, for example, logarithm. This would give essentially same corruption close to the Palace/FP and significantly more balanced results in distant areas. Also, in this case, improvements decreasing corruption would always work.

 

[Qitai]

For those of you not yet familiar with the corruption model since Civ3/PTW, please read Alexman's Thread on "Do you think you udnerstand corruption?" in the strategy article forum. Many suggestions here are very good, but I do not think Firaxis is looking for a major overhual here, but just plucking loopholes in the current model. Perhaps those can be ideas for Civ4.