The Social Policy Situation

[PieceOfMind]

@ Celevin

Actually at first I thought Balnor's was the same as mine, but it's a bit different again. With mine (and André Alfenaar's is the same) the percent on the way to a policy will decrease each time a new city is built, but the current culture will remain fixed.

And there is where the problem I have with Balnor's suggestion. Building a city requires a change in the current accumulated culture. Balnor suggests to get around this by not even displaying the current accumulated culture but just the percentage. I think this hides the problem, and becomes less intuitive. In my post I called it 'cheating'.

To produce the same effect as the rate-change by doing a threshold-change instead, and assuming we don't want to instantaneously change the current amount of culture put towards the policy (i.e. we won't just 'cheat'), then we just need to change the threshold to:
(blah)

As for how to handle the situation of someone accumulating enough culture for multiple policies, I haven't given it much thought yet, but I'm confident that it can be made to work exactly the same way as your system but just with a different set of numbers like what I've demonstrated so far.

So my answer is essentially: Do it the same way you've proposed, but with altering the totals instead of the rates. I'll need to go over your posts again to see how you covered it.

I guess I'm basically leeching off your idea. I like the type of thing you're proposing, but think the alternative way of dealing with numbers works better and is closer to the current game.

EDIT... Oh, I remembered you asked about what happens if I sell all but one city. Well again, my response is pretty much "just do whatever your system does", only altering the total instead of the rate.

 

[Hormagaunt]

As far as I can see, there are two possible ways they'll implement this, and I'm wondering if anyone knows which one they'll select:

1) Build 10 cities, culture needed = f(10). Build/capture/buy 2 cities, culture needed = f(12). Lose/sell 5 cities, culture needed = f(12) {it doesn't drop}. Build 4 more cities, culture needed = f(12) {you haven't exceeded your prior highest point}.

2) Build 10 cities, culture needed = f(10). Build/capture/buy 2 cities, culture needed = f(12). Lose/sell 5 cities, culture needed = f(12) {it doesn't drop}. Build 4 more cities, culture needed = f(16).

VERY important difference between them, yes? The first keeps track of the max number of cities you have, the second simply adds 1 every time you gain a city. In the second form, build/raze the same city 5 times and your number goes up 5 times.

Both of these methods achieve the effect that you don't profit by losing cities. The second is actually simpler to implement, as it doesn't need to keep track of your current count and it doesn't need to check that against your "maximum" count.


Any bets?

 

[Celevin]

As far as I can see, there are two possible ways they'll implement this, and I'm wondering if anyone knows which one they'll select:

1) Build 10 cities, culture needed = f(10). Build/capture/buy 2 cities, culture needed = f(12). Lose/sell 5 cities, culture needed = f(12) {it doesn't drop}. Build 4 more cities, culture needed = f(12) {you haven't exceeded your prior highest point}.

2) Build 10 cities, culture needed = f(10). Build/capture/buy 2 cities, culture needed = f(12). Lose/sell 5 cities, culture needed = f(12) {it doesn't drop}. Build 4 more cities, culture needed = f(16).

VERY important difference between them, yes? The first keeps track of the max number of cities you have, the second simply adds 1 every time you gain a city. In the second form, build/raze the same city 5 times and your number goes up 5 times.

Both of these methods achieve the effect that you don't profit by losing cities. The second is actually simpler to implement, as it doesn't need to keep track of your current count and it doesn't need to check that against your "maximum" count.


Any bets?

I'm pretty sure it's going to be #1. They'd have to be completely insane to do #2.

#1 is enough without anything else to make me consider quitting, and I've been a person defending Civ5 since it came out.

 

[alpaca]

Both of these and my proposal are all viable solutions. Considering the damage level of not micromanaging your culture is at the same damage level as science overflow, I would be a very happy person to see any of these implemented.

Well, would you play a mod with it? I don't see it happening in vanilla any time soon to be honest

 

[Celevin]

Well, would you play a mod with it? I don't see it happening in vanilla any time soon to be honest

Probably but I'd rather play it coming from the designer's angle . First, the changes they make I think are impossible to mod out at this time. Second, you start to lose trust in the designers if they make decisions that you greatly disagree with, and lose respect for the game. At any time they might release another patch that could both screw up your mods and be something that you again disagree with.

If this thread has to choose a single goal, it's less to see my proposal implemented, and instead just see their intended change (policy cost depending on your historical max # of cities) eliminated.

 

[Balnor]

I've just now had time to read up on PieceOfMind's version. If I understand it correctly, including Celevin's and my version, all 3 formulas basically do the same thing, what differs is the visual representation.

To put them into simple examples :

Situation :
Let's assume we're at 50/100 culture gained, making 10 CPT (culture per turn).
If we settle another city, the threshold will be multiplied by a factor of 2 => in our example 100*2 = 200 (just to keep it simple here)

Definitions :
culture = 50 (our culture accumulated so far)
threshold = 100 (the threshold to gain a new policy before we apply any formula)
factor = 2 (the factor we use to calculate our new threshold when gaining cities)
CPT = 10 (the amount of culture we are currently making per turn)

Now we settle that additional city and look at what it does to the different versions :

Version A (as it is now in the game) :
Formula : threshold_new = threshold * factor
Example : 100 * 2 = 200

New Culture situation : 50/200 with +10CPT
Next policy in (200-50)/10 = 15 turns.

The next policy will arrive in 15 turns, which disencourages settling at anything other than turn 0 after new policy gain => bad.

Version B (Celevin) :
When gaining/losing cities we do not mess with the total culture values, just changing the culture/turn. To get the new CPT value we calculate :

[Formula : CPT_new = CPT / factor]
Example : 10 / 2 = 5

New Culture situation : 50/100 with +5CPT
Next policy in (100-50)/5 = 10 turns.

Version C (PieceOfMind):
We want only the threshold to change, rest should stay the same. To get the new threshold, we calculate :

[Formula : threshold_new = factor * (threshold - culture) + culture]
Example : 2 * (100-50) + 50 = 150

New Culture situation : 50/150 with +10CPT
Next policy in (150-50)/10 = 10 turns.

I hope this is the way you had intended, otherwise please correct me here.

Version D (mine) :
We try to keep the percentage true while not caring about the change in total numbers. We need both a new threshold and a new value for our accumulated culture :

[Formula: threshold_new = factor * threshold; culture_new = factor * culture]
Example : threshold_new = 2 * 100 = 200; culture_new = 2 * 50 = 100

New Culture situation : 100/200 with +10CPT
Next policy in (200-100)/10 = 10 turns.

The reason why I proposed this one is simply the fact that in my version the percentage progress towards next policy gain stays the same (50% in this example), therefore that % value could be displayed in the UI which I personally would find more intuitive than a whole bunch of numbers changing in a seemingly random way all the time.

In conclusion though it's just a matter of personal preference in how the numbers are displayed, all three versions should function identically in-game.

 

[neptune2000]

Let's ignore the "no policy saving" change right now, and say I have a tonne of culture built up (enough for at least 5 policies). What happens when I sell all but 1 of my cities with your proposed change?

This is where getting a "policy credit" without having to choose it helps. In other words, when you have the points for a new policy, you get a policy pick and you're now accruing points for the next one, however you don't have to choose that policy right now.

As far as I can see, there are two possible ways they'll implement this, and I'm wondering if anyone knows which one they'll select:

1) Build 10 cities, culture needed = f(10). Build/capture/buy 2 cities, culture needed = f(12). Lose/sell 5 cities, culture needed = f(12) {it doesn't drop}. Build 4 more cities, culture needed = f(12) {you haven't exceeded your prior highest point}.

2) Build 10 cities, culture needed = f(10). Build/capture/buy 2 cities, culture needed = f(12). Lose/sell 5 cities, culture needed = f(12) {it doesn't drop}. Build 4 more cities, culture needed = f(16).

VERY important difference between them, yes? The first keeps track of the max number of cities you have, the second simply adds 1 every time you gain a city. In the second form, build/raze the same city 5 times and your number goes up 5 times.

Both of these methods achieve the effect that you don't profit by losing cities. The second is actually simpler to implement, as it doesn't need to keep track of your current count and it doesn't need to check that against your "maximum" count.

Any bets?

It has to be the first one. In programming terms, they're equally easy to implement. In design terms, I disagree with the first one but the second one would be ludicrous.

 

[Celevin]

This is where getting a "policy credit" without having to choose it helps. In other words, when you have the points for a new policy, you get a policy pick and you're now accruing points for the next one, however you don't have to choose that policy right now.

Yeah, this solves it completely.



@Balnor: That's an excellent summary of what goes on. I don't know what version's best either, and I'm wondering if they only differ by UI.

Can yours and PieceOfMind's handle things like the Christo Rendentor (minus policy costs)?

 

[Hormagaunt]

It has to be the first one. In programming terms, they're equally easy to implement. In design terms, I disagree with the first one but the second one would be ludicrous.

Version 1:

gMaxCities form 4
gCurrentCities form 4

AddCity function
entry
gCurrentCities = gCurrentCities + 1
if (gCurrentCities > gMaxCities)
gMaxCities = gCurrentCities
call RecalcPolicyValue
endif
functionend


Version 2:

gMaxCities form 4

AddCity function
entry
gMaxCities = gMaxCities + 1
call RecalcPolicyValue
functionend


Both are simple, but Version 2 is slightly simpler than Version 1. And my personal bet is that they'll implement V2. I really, really hope I'm wrong.

 

[Celevin]

I think even though myself and Firaxis differ philosophically with the game design, they too know as well that everything would fall apart if Version 2 were implemented. It would turn the entire game into "don't you dare ever lose or sell a city".

 

[neptune2000]

Version 1:

gMaxCities form 4
gCurrentCities form 4

AddCity function
entry
gCurrentCities = gCurrentCities + 1
if (gCurrentCities > gMaxCities)
gMaxCities = gCurrentCities
call RecalcPolicyValue
endif
functionend


Version 2:

gMaxCities form 4

AddCity function
entry
gMaxCities = gMaxCities + 1
call RecalcPolicyValue
functionend


Both are simple, but Version 2 is slightly simpler than Version 1. And my personal bet is that they'll implement V2. I really, really hope I'm wrong.

Don't be pedantic The extra time it took for the first was only in the time it took for you to type it.

 

[Dermo]

I think it would also be a good idea to discourage 'with extreme prejudice' too much razing and selling of cities.
How many historical examples are there of empires selling huge tracts of land (settled land that is)
I'm thinking of the Louisianna Purchase, the purchase of Alaska from Russia, but how populated/settled were those territories at the time of purchase (I'm not being dismissive of either region, I'm honestly asking if anyone knows) I'm not aware of too many other large scale land transaction (excluding war reparations and the like)

As far as this particular exploit goes, the problem (to me at least) seems to stem not from the SP mechanism, but from the ability and profitability of selling off large portions of your empire

Aside from that I like the suggestion proposed above for SP costs

 

[Hormagaunt]

Don't be pedantic The extra time it took for the first was only in the time it took for you to type it.

I used to build code hand-tuned to account for individual clock cycles. The internal documentation for my subroutines laid out exactly how many cycles each op would take and why I was using one versus another. (Remember, children, an XOR op is faster than a MOV.)

Why yes, I did code in Assembler. How'd you guess? (I still have that code, of course.)

 

[neptune2000]

I used to build code hand-tuned to account for individual clock cycles. The internal documentation for my subroutines laid out exactly how many cycles each op would take and why I was using one versus another. (Remember, children, an XOR op is faster than a MOV.)

Why yes, I did code in Assembler. How'd you guess? (I still have that code, of course.)

You probably also enjoy 1 line perl scripts that play the towers of hanoi . I'm guessing the Civ devs aren't worried about conserving registers and clock cycles. In fact, based on the time the computer's turn can take, I'm sure of it.

In any case, I'll take you up on your bet, although I'm banking on their competence to do the lesser of two evils (your case #1) not because one is any easier than the other. Now, with my trust in their competence you may have an argument...

 

[Balnor]

Since the final patch notes have been released, we can now assume this problem has sadly been ignored. Now all that's left is to hope for a change in a future patch, though I kinda doubt it...not even the players themselves seem to be overly concerned about this, judging on the amount of feedback in this thread.

@ Celevin :

Can yours and PieceOfMind's handle things like the Christo Rendentor (minus policy costs)?

Yes they could, since our two versions (B and D from my post) are identical. Basically while you divided the denominator of our term (CPT) by a factor, I instead multiplied the numerator (culture threshold - culture accumulated) by the same factor.
As long as you always divide any culture gains in your version by that factor (e.g. Monty UA or goody huts) our versions should be 100% the same, just the display is different.

Mathematically speaking :
t(turns to next policy) = (threshold-culture)/(CPT/x) = x*(threshold-culture)/CPT

Now Version C (PieceOfMind's, if that's what he intended it to be like anyways) is a bit different. It basically works of the same numbers as ours do, but it shifts the display to something closer resembling the system as it is now. The displayed culture threshold will not be "true" though... it can still work, but any % decrease like Cristo Redentor would not be matching what it actually displays.

 

[Misterboy]

I wanted to thank the OP for this post . As I've been analyzing the final patch notes, the changes whereby maximum empire size stays with you has really and truly scared me. Without trying to sound overly dramatic, I feel that I may be severely punished by an attempt to squash an exploit that I would never consider using .

I have had countless situations where I reduced my empire size in an attempt to get control of my unhappiness. And as pointed out by others, this change seems to add salt to the wound of losing cities via conquest.

My only hope is that the patch notes don't fully explain the situation and that the devs are considering these situations. All in all I am extremely happy with the patch, but the changes discussed here are scary.

So kudos to the OP, and your thoughtful analysis of the situation, and for your proposed solution . I too, hope VERY MUCH that the devs have caught wind of this thread.

 

[rastak]

I used to build code hand-tuned to account for individual clock cycles. The internal documentation for my subroutines laid out exactly how many cycles each op would take and why I was using one versus another. (Remember, children, an XOR op is faster than a MOV.)

Why yes, I did code in Assembler. How'd you guess? (I still have that code, of course.)

The MOV did it for me. Ah the fun of moving stuff from register to register.