Project

Profile

Help

HostedRedmine.com has moved to the Planio platform. All logins and passwords remained the same. All users will be able to login and use Redmine just as before. Read more...

Feature #771900

Does update_city_activity need a fundamental behavior change?

Added by Zoltán Žarkov almost 4 years ago. Updated 2 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Server
Sprint/Milestone:
Start date:
Due date:
% Done:

0%

Estimated time:

Description

I will start with this thought experiment- open t12.png attached and predict what the city will look like immediately after clicking turn done. Now look at t13.png- are you surprised? If not, you're a wizard of game mechanics, I bet you've read update_city_activity. I apologize to the lt.org veterans for giving up their biggest early-game exploit, I just found out about it independently.

Are we happy with this state of update_city_activity? This city effectively got +17 (-3 waste) shields, +5 food, and +11 trade by taking the shields of iron mountains for one phase of the turn, then a bunch of grassland, fish, and spice tiles for the next phase. This is because production of the migrant happens first, using the mountain and forest tiles, which shrinks the city by 1. Workers are then auto-arranged to high food tiles in time for the code path for computing food and trade, where the city gets the food from 5 tiles, grows one size, auto-arranges again, then gets the trade from 6 tiles.

I've been discussing this with others on a discord channel and I think we should surface it here for visibility. Some have been proposing major changes to update_city_activity, a function that has had the same behavior for over a decade. Some of the proposed new behaviors follow:

  • Lock all citizens to their assignments for the entire turn change, even if a city grows or shrinks that turn. That means when a city grows, it will not get the additional output of the extra citizen. The rationale here is that the auto-arrangement of workers that happens when a city grows completely overrides whatever workers and specialists the player has set.
  • Some have even suggested that all city outputs should be exactly as the city screen showed immediately before turn change. Buying a harbor, marketplace or a temple would only be effective the next turn. This is a pretty major change, and I do not personally advocate it.
t12.png (532 KB) t12.png Zoltán Žarkov, 2018-09-01 04:57 AM
t13.png (542 KB) t13.png Zoltán Žarkov, 2018-09-01 04:57 AM
0005-Freeze-citizen-assignments-in-update_city_activity-u.patch (1.41 KB) 0005-Freeze-citizen-assignments-in-update_city_activity-u.patch Zoltán Žarkov, 2018-09-03 11:01 PM
0005-Freeze-citizen-assignments-in-update_city_activity-u.patch (1.95 KB) 0005-Freeze-citizen-assignments-in-update_city_activity-u.patch master Zoltán Žarkov, 2018-09-09 04:49 AM
freeciv-26-new-city-turn-v1.patch (28.6 KB) freeciv-26-new-city-turn-v1.patch Anonymous, 2020-10-23 03:49 PM
250
250

Related issues

Blocks Freeciv - Bug #874511: Don't suggest throttling growth if Granary appears on the growth turnNew

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>

History

#1 Updated by Lexxie L almost 4 years ago

You have brought up a lot of issues here. Discussion of all of them might make too much smoke and result in inaction.
I propose we look only at the heart of the key issue and elephant in the room, and discuss others only after this one big issue is tackled. I'm going to make a long post on this because it's SUPER important and it's ULTRA-broken, creating a bad game, where insider players are exploiting behaviours and frankly, ruining the game for new players and stymying the community and the entire freeciv culture.

Background:
1. Changes in city population occur rather frequently, especially during rapture, settler waves, and late game when there is much gold to do 'population forcing'. In a typical multiplayer game, from early-mid-game to late game my cities are changing population around 40% of the time.
2. It is fundamental to the constitution and concept of any strategy game, freeciv included, that human players be allowed to adjust their strategic inputs to create strategic outputs, rather than have a 'forced auto-pilot' behaviour that overrides human decided manual inputs. Put another way, it's dirty. Everyone EXPECTS the very heart of strategy to be manual human decisions to create the different effects of those decisions. That's what strategy is. Not the deceptive illusion of making strategic decisions that get overridden NEEDLESSLY by a computer auto-pilot decision. THIS IS ESPECIALLY TRUE WHEN THE INTERFACE PROVIDES THE PLAYER THE OPTION TO MAKE ADJUSTMENTS WITH NO KNOWLEDGE THOSE INPUTS WILL BE COMPLETELY DISCARDED AND IGNORED. For these overrides to be happening nearly half the time is 1-unnecessary and easily changed, 2-atrocious, 3-needlessly confusing and complex to new players, 4-exploited against new players by insiders, 5-terribly bad vibe for growing a community of enthusiasts in a fair competitive strategic medium.
3. The entire reason for specialists is for micro-managing and controlling the economy. Need just a little more gold to buy an important 'whatever' to avoid catastrophe next turn? Need a little more science to discover a key technology to save your alliance? How about fine tuning a little more trade in that city to keep it celebrating? It's absolutely criminal that nearly half the time, when population of cities change, control over these things is silently discarded without players having any idea they won't get the output that is advertised.
By changing end-turn to be intuitively what it should be and EXPECTED to be, ALL of the following scenarios are avoided:
a. Players can be forced to discover technologies which obsolete their barracks or their Wonders prematurely-- tax collectors got overridden into scientists.
b. The player who needed gold badly to buy city walls, got scientists instead, had his key geographic city taken, and his whole alliance lost the game.
c. The player who was trying to take advantage of Monarchy, which is hard enough to do considering advantages of Republic, carefully invested lots of luxury and/or production into Wonders to keep cities happy to get the +1 trade bonus to not lose ground as fast to someone who went fast Republic. Obviously, one of the ONLY advantages to Monarchy is ability to populate settlers slightly better. But no, every time the size 3 city makes a settler, city happiness is calculated for the one microsecond the city was size 2, even though it grows back to size 3 a nanosecond later and has 3 bright shiny green happy citizens again. Sorry, we showed you "celebrating" and showed you three happy, but we lied, we calculated happiness for the split second AFTER you made the Settler and re-arranged your tiles, then grew your city again and re-arranged your tiles once again and voila, you're happy again, but that one microsecond at turn change pissed your people off. Don't say "no problem, just make settlers at size 4 in Monarchy", ayfkm, don't even say that.
d. The player who builds a Settler in Republic/Democracy, (or starves the city, or had a food surplus going past full granary), carefully arranged the tiles to maintain celebration, and was shown in the User Interface that her city would keep celebrating. But no, a computer is going to re-arrange your tiles after population change, and would ya look at that, it didn't choose the silk you were using and now you lost celebration. Wasn't that nice of us to let you choose what tiles you wanted, let you think they were going to be used, show you how many happy citizens and how much luxury you were going to get, but then re-arrange everything and calculate your output and happiness differently from what we showed you? Are you happy that we totally ignored what you carefully arranged it to be and let the computer choose for you?
e. I can and will, on request, list countless other disastrous examples, some of them even worse than these, but I'm getting too verbose already.
____________________________________________________________
Conclusion:
I say that it is a NO-BRAINER and intuitively assumed by everyone who plays and doesn't know better, that the tiles selected by the human will be the ones that make output at turn change. When things happen with turn change that force the computer to not give human control, these things should be 'suggestions' that are then surrendered back to the human to decide how to control once again. No one assumes that the tiles and specialists you choose will be overridden during a population changing event. They assume the computer was forced to make a suggestion because the population is different, and that you now have control again. Few people know that there are strange little exploits in the turn change order that should be memorized, and that in order to be competitive one must carefully study turn change code and realize that x happens before y and after that z takes place, in a counterintuitive way that seems deliberately constructed to create exploits. IS THERE A REASON WE OVER-RIDE the manual selection of tiles a human made WHEN IT'S NOT NEEDED? Even worse, is there a reason that the actual output will not represent any one state of the tile arrangements, but instead represent a strange case where tiles can go through THREE DIFFERENT STATES at turn change, and output is computed from all 3 different states at different times? No, no, and no. This is bad, just really bad.

PS. A separate subject was brought up. We should not let focus on that subject distract us from the importance of the above. The subject of whether we should 'freeze' the output calculations prior to production of things such as wonders, harbors, and so on. This is a separate issue that I think everyone agrees, the effect of something should occur the instant it is manifested into existence, and not one turn after. It would be needless agony to make a new tc sequence where now everyone always has to plan 2 turns ahead of time for when they need things, because things mysteriously have no effect for the first turn of their existence. No one wants that and such an idea would be voted down. Let's focus on the real issue here. Is there a reason to needlessly force everyone to use the same auto-arrange cma/governor type behaviour in output and have all humans play with the same auto-pilot algorithm, overriding the wonderful diversity of human decisions and strategic thinking, when it is just as easy to order the end-turn in the proper, unbroken, intuitive way that gives the control back to the human?

So back to the main point. Should a computer needlessly override a human's manual tile selections that they thought were valid, and create unpredicted random effects and sometimes disasters, and FLATTEN the ability for humans to follow diverse strategies and make diverse choices from each other, or should we offer the illusion of having manual control while silently forcing everyone into the same auto-pilot without knowing it? Please admit the NO-BRAINER answer. Don't disagree and admit that 1) you have an uncreative play-style that prefers exploiting a backdoor hidden exploit and that you prefer this to humans actually having control over strategic decisions.

#2 Updated by Charlie Galik almost 4 years ago

I completely agree that this would be great to change to preventing auto auto-arrange from happening for all the reasons listed above. I could list them again, but probably never as long as Lexxie. :)

#3 Updated by Dalibor Perkovic almost 4 years ago

That is effectively a semi-bug. I think the wisest thing to do would be a two-step TC:

1. All resource gain/loss is calculated, possibly resulting in numbers like 12/10
2. Then and only then change happens: city growth/shrinking, production end etc., followed by adjusting numbers, 12/10 becoming 2/10 etc.

With this it would be irrelevant if workers are arranged automatically because the next production happens next turn anyway.

#4 Updated by Lexxie L almost 4 years ago

As far as a simple description goes, the 2 step solution description above is good except for one thing. People produce things to react to situations. They produce a unit or a temple to force contentedness. This 2 step sequence proposed makes all production suffer one turn of semi-nonexistence before it takes effect, and I believe this would be unpopular. Nevertheless the simplicity of the solution would probably avoid countless bugs creeping up over the years.

I am assuming we have a mandate to fix the fact that the computer overrides player selected specialists and tile output, but I am not assuming we have a mandate to make produced improvements and units have semi-non-existence for one turn. (In fact everyone I know except Dalibor is against this idea, and the solution might even be worse than the original problem!)

The reality is that the end-turn sequence is really nitty-gritty in detail and we risk unintended consequences if we don't carefully analyze how it should be in finer detail. Yay, that's what I'm about to do now! First, let's acknowledge that the current sequence is totally broken, and believe me, in more ways than people have listed above--I spared you all pages and pages of game ruining disaster situations that this broken TC can cause, has caused, and would continue to cause.

#5 Updated by Lexxie L almost 4 years ago

The Situation:
For improvements to take effect on the turn they are produced, this means production happens first. That's good and proper. Before outputs are calculated, completion of production queue happens first. Because a Temple, Marketplace, Wonder, or Supermarket might be completed and alter all possible outputs (Happiness, Food, Luxury, Bulbs, Gold, Shields). _ The tricky part about this is that Settlers, Migrants, and other population-reducing units also get produced first, which is what turns the TC into a complex puzzle and has caused all these bugs._

From my current understanding, I believe the current mandate to fix this will result in other unintended bugs unless the solution is coded to follow the logic below, which I will write in "English code."

1. Luxury/Bulbs/Gold, Food surplus, and Happy state are recorded as they stand prior to Turn Change.

2. Production is completed for everything except Settlers (and other population-reducing units, which I will just refer to as Settlers from here on out).

2a. If production was NOT a Settler, Luxury/Bulbs/Gold, Food surplus, Shield output, and Happiness, are recalculated since there might have been a Factory, Supermarket, Granary, Wonder, or Temple produced, which will alter some of those outputs.

3. If completed production is a Settler, outputs from #1 above are accumulated, otherwise outputs from #2a are accumulated.

4. Production of Settler and all the things that go after that, takes place. Happiness/Celebration and other outputs are not under any circumstances calculated during the brief microsecond a city has shrunk, since it might have enough Food in storage to not really shrink. If the code is written in such a way that recalculation must happen, then extra code is written so that Happy/Celebrating is reset to the former state we recorded in #1 above. Keep in mind the way Turn Change currently computes ongoing Celebration is a BUG. A city's Celebration status is a function of whether it is Happy according to how the player arranges the city during the current turn AND whether it was Celebrating/Happy PRIOR to Turn Change, and what takes place during Turn Change should not be factored in except in the case of an Improvement made just in time.

5. a. Growth from Food surplus take place. b. Rapture growth takes place.

[OPTIONAL extended fix].

The order of 4 and 5 could also be switched, and I argue they should be switched. The consequences of this I will say below.

a) A celebrating size 3 city will rapture on the same turn it makes a Settler and remain size 3. This is logical and any argument against this seems invalid since this is actually a BUG which goes counter to what the manual says should happen and how Sid Meier (bless his soul) programmed it to happen in The Original. Let's face it, we are fixing a completely broken Turn Change sequence and making it harmonious and logical--there is no need to keep things broken just because it "always was broken." Besides it being more intuitive, natural, logical, and common sense, another decisive argument in favour of this change is that it very subtly helps game pace: there is almost universal consensus that any "buggy" configuration that is unintuitive, ambiguous under the rules, unnatural, AND slows the game pace unnecessarily, is a no-brainer to be switched to a configuration that is more intuitive, logical, natural, and subtly improves the game pace. This is especially the case when the rules and manual say it should be the latter case or it's ambiguous which way it should be, in which case we shouldn't pick the counterintuitive configuration that hinders game pace.

b) This allows a Settler to be created on the same turn a city grows to size 2. The argument in favour of this is that it's logical and common sense. The argument against it is that it's "change." But I will point out current behaviour comes from a broken and buggy sequencing, and is illogical, unintuitive, and slows game pace. Also, this behaviour has flip-flopped before. (Please refer above to general consensus about ambiguous cases where an unintuitive option is unnatural, illogical, and slows game pace, whereas the other option is natural, logical, and doesn't obstruct game pace.)

#6 Updated by Lexxie L almost 4 years ago

The Situation:
For improvements to take effect on the turn they are produced, this means production happens first. That's good and proper. Before outputs are calculated, completion of production queue happens first. Because a Temple, Marketplace, Wonder, or Supermarket might be completed and alter all possible outputs (Happiness, Food, Luxury, Bulbs, Gold, Shields). _ The tricky part about this is that Settlers, Migrants, and other population-reducing units also get produced first, which is what turns the TC into a complex puzzle and has caused all these bugs._

From my current understanding, I believe the current mandate to fix this will result in other unintended bugs unless the solution is coded to follow the logic below, which I will write in "English code."

1. Luxury/Bulbs/Gold, Food surplus, and Happy state are recorded as they stand prior to Turn Change.

2. Production is completed for everything except Settlers (and other population-reducing units, which I will just refer to as Settlers from here on out).

2a. If production was NOT a Settler, Luxury/Bulbs/Gold, Food surplus, Shield output, and Happiness, are recalculated since there might have been a Factory, Supermarket, Granary, Wonder, or Temple produced, which will alter some of those outputs.

3. If completed production is a Settler, outputs from #1 above are accumulated, otherwise outputs from #2a are accumulated.

4. Production of Settler and all the things that go after that, takes place. Happiness/Celebration and other outputs are not under any circumstances calculated during the brief microsecond a city has shrunk, since it might have enough Food in storage to not really shrink. If the code is written in such a way that recalculation must happen, then extra code is written so that Happy/Celebrating is reset to the former state we recorded in #1 above. Keep in mind the way Turn Change currently computes ongoing Celebration is a BUG. A city's Celebration status is a function of whether it is Happy according to how the player arranges the city during the current turn AND whether it was Celebrating/Happy PRIOR to Turn Change, and what takes place during Turn Change should not be factored in except in the case of an Improvement made just in time.

5. a. Growth from Food surplus take place. b. Rapture growth takes place.

[OPTIONAL extended fix].

The order of 4 and 5 could also be switched, and I argue they should be switched. The consequences of this I will say below.

a) A celebrating size 3 city will rapture on the same turn it makes a Settler and remain size 3. This is logical and any argument against this seems invalid since this is actually a BUG which goes counter to what the manual says should happen and how Sid Meier (bless his soul) programmed it to happen in The Original. Let's face it, we are fixing a completely broken Turn Change sequence and making it harmonious and logical--there is no need to keep things broken just because it "always was broken." Besides it being more intuitive, natural, logical, and common sense, another decisive argument in favour of this change is that it very subtly helps game pace: there is almost universal consensus that any "buggy" configuration that is unintuitive, ambiguous under the rules, unnatural, AND slows the game pace unnecessarily, is a no-brainer to be switched to a configuration that is more intuitive, logical, natural, and subtly improves the game pace. This is especially the case when the rules and manual say it should be the latter case or it's ambiguous which way it should be, in which case we shouldn't pick the counterintuitive configuration that hinders game pace.

b) This allows a Settler to be created on the same turn a city grows to size 2. The argument in favour of this is that it's logical and common sense. The argument against it is that it's "change." But I will point out current behaviour comes from a broken and buggy sequencing, and is illogical, unintuitive, and slows game pace. Also, this behaviour has flip-flopped before. (Please refer above to general consensus about ambiguous cases where an unintuitive option is unnatural, illogical, and slows game pace, whereas the other option is natural, logical, and doesn't obstruct game pace.)

#7 Updated by Lexxie L almost 4 years ago

The Situation:

For improvements to take effect on the turn they are produced, this means production happens first. That's good and proper. Before outputs are calculated, completion of production queue happens first. Because a Temple, Marketplace, Wonder, or Supermarket might be completed and alter all possible outputs (Happiness, Food, Luxury, Bulbs, Gold, Shields). The tricky part about this is that Settlers, Migrants, and other population-reducing units also get produced first, which is what turns the TC into a complex puzzle and has caused all these bugs.

From my current understanding, I believe the current mandate to fix this will result in other unintended bugs unless the solution is coded to follow the logic below, which I will write in "English code."

1. Luxury/Bulbs/Gold, Food surplus, and Happy state are recorded as they stand prior to Turn Change.

2. Production is completed for everything except Settlers (and other population-reducing units, which I will just refer to as Settlers from here on out).

2a. If production was NOT a Settler, Luxury/Bulbs/Gold, Food surplus, Shield output, and Happiness, are recalculated since there might have been a Factory, Supermarket, Granary, Wonder, or Temple produced, which will alter some of those outputs.

3. If completed production is a Settler, outputs from #1 above are accumulated, otherwise outputs from #2a are accumulated.

4. Production of Settler and all the things that go after that, takes place. Happiness/Celebration and other outputs are not under any circumstances calculated during the brief microsecond a city has shrunk, since it might have enough Food in storage to not really shrink. If the code is written in such a way that recalculation must happen, then extra code is written so that Happy/Celebrating is reset to the former state we recorded in #1 above. Keep in mind the way Turn Change currently computes ongoing Celebration is a BUG. A city's Celebration status is a function of whether it is Happy according to how the player arranges the city during the current turn AND whether it was Celebrating/Happy PRIOR to Turn Change, and what takes place during Turn Change should not be factored in except in the case of an Improvement made just in time.

5. a. Growth from Food surplus take place. b. Rapture growth takes place.

[OPTIONAL extended fix].

The order of 4 and 5 could also be switched, and I argue they should be switched. The consequences of this I will say below.

a) A celebrating size 3 city will rapture on the same turn it makes a Settler and remain size 3. This is logical and any argument against this seems invalid since this is actually a BUG which goes counter to what the manual says should happen and how Sid Meier (bless his soul) programmed it to happen in The Original. Let's face it, we are fixing a completely broken Turn Change sequence and making it harmonious and logical--there is no need to keep things broken just because it "always was broken." Besides it being more intuitive, natural, logical, and common sense, another decisive argument in favour of this change is that it very subtly helps game pace: there is almost universal consensus that any "buggy" configuration that is unintuitive, ambiguous under the rules, unnatural, AND slows the game pace unnecessarily, is a no-brainer to be switched to a configuration that is more intuitive, logical, natural, and subtly improves the game pace. This is especially the case when the rules and manual say it should be the latter case or it's ambiguous which way it should be, in which case we shouldn't pick the counterintuitive configuration that hinders game pace.

b) This allows a Settler to be created on the same turn a city grows to size 2. The argument in favour of this is that it's logical and common sense. The argument against it is that it's "change." But I will point out current behaviour comes from a broken and buggy sequencing, and is illogical, unintuitive, and slows game pace. Also, this behaviour has flip-flopped before. (Please refer above to general consensus about ambiguous cases where an unintuitive option is unnatural, illogical, and slows game pace, whereas the other option is natural, logical, and doesn't obstruct game pace.)

#8 Updated by Dalibor Perkovic almost 4 years ago

Let me put it this way. Yes, everybody would like for an improvement being built on TC to have effect on that TC. That's normal. Everybody would also like unlimited amount of free candy. Unfortunately, it doesn't make sense.

Suppose you start building an improvement. Officially it takes 1 turn to build it. Now, if that improvements comes into effect on that same TC when it is built, then, in effect, it didn't take "1 turn" to build. It took ZERO turns.

Like I said elsewhere, this is a computer game and you can do anything you want with the code. Coders' and players' choice. But if you decide to disregard reality, things like that turn a historical simulation into a game of checkers.

#9 Updated by Lexxie L almost 4 years ago

I apologize that HRM crashed while I was editing the draft of my post. None of that was even meant to be posted but somehow it did it three times. It is not giving me the option to delete them nor edit the draft. If someone has the ability to delete that I will post a shorter edited version of it.

#10 Updated by Lexxie L almost 4 years ago

Dalibor Perkovic wrote:

Let me put it this way. Yes, everybody would like for an improvement being built on TC to have effect on that TC. That's normal. Everybody would also like unlimited amount of free candy. Unfortunately, it doesn't make sense.

Suppose you start building an improvement. Officially it takes 1 turn to build it. Now, if that improvements comes into effect on that same TC when it is built, then, in effect, it didn't take "1 turn" to build. It took ZERO turns.

Like I said elsewhere, this is a computer game and you can do anything you want with the code. Coders' and players' choice. But if you decide to disregard reality, things like that turn a historical simulation into a game of checkers.

Hi everyone! ;)

Dalibor, I appreciate your valid reasons for this solution. If we were designing this game from scratch, this would be the way to go. But there is a community and an expectation of how the game mechanics are. A change this massive would lead to many cases of "OMG I never thought of that consequence!"

There's an ongoing tradition of what the rules and mechanics are. We have to work within a "tradition" and politically navigate community consensus. There is implied conservatism that we don't make massive changes to rules and mechanics without a massive justification. People want the bug fixed, not a revolutionary reworking of mechanics, and not a mathematical skewing of the pace of the game's economic growth rates.

Economic growth behaves like a compound interest formula. What is the consequence of changing everything produced to take effect one turn later? It cascades into staggering consequences. Take the case of something that takes 5 turns to build and go into effect. Add one turn to that=6 turns. 6/5 = 1.2. Factor 1.2 anywhere you like into any kind of compound interest formula and watch what happens after 20 iterations of growth cycle. Massive! But it gets worse. Stretching out the timeline of production improvements while keeping their costs the same will have more than the effect described above. There is the concept of "lift-off costs", similar to the business concept of operating expenses. You see, the cost of Improvements is priced relative to the bonus effect they have on the timeline of accelerated economic growth. Delayed production has the real effect of creating a relative increase in the cost in the Improvement, which means diminishing of the ratio of its bonus effect per economic unit invested to produce it. Consider someone in business making $5 million a year on a 20% margin... operating costs of $20 million. A 10% increase in operating costs does not reduce profit by 10%. It reduces it 40% to $3 million. We're talking about a massive push-down on the entire economic growth rate in the game. My own experiments in ruleset creation have confirmed this is a significant effect! Should we really be playing the role of Minister of Economics and experimentally lowering growth rates and game pace, just to fix a quirky auto-arrange bug? On the contrary, the argument could be made that removing the so-called auto-arrange trade bonus takes away some micro growth rate and game pace. What we should be wondering is if we should do some ever-so-slight re-sequencing in Turn Change to micro-balance that (please refer to the proposed Optional Extended Fix proposed above.)

I mentioned above that in past interactions with devs and expert players that I've put out feelers about "Is freeciv a little too fast or a little too slow?" "How should we decide ambiguous edge cases that would micro-obstruct game pace vs. micro-facilitate pace?" The informal majority on this issue is this: When deciding ambiguous edge cases where one option micro-obstructs game pace, and the other option micro-facilitates game pace, the latter should be preferred. The word 'micro' is key, it's a fancy Greek way of saying "tiny" ;). Dalibor's proposed solution isn't tiny: it creates a significant slowing of economic growth. Is this the right way to fix a bug about auto-arranged tiles and specialists?

A lot of people haven't looked at these issues so deeply, so let's throw out everything about economics and pretend it's not true. Let's analyze this proposed change next to our handy-dandy checklist of other 'good judgment criteria':

1. Is the change popular? NO, it would be massively unpopular. Think of our favourite player, EnthusiastNoobie: "What? I never lost all my shields from Disorder before! Whose genius idea was this?"

2. Is the change necessary to fix the bug? NO, it introduces a change that is 2 degrees of magnitude larger than the scope of the bug it fixes.

3. Does the change quietly fix the bug while conserving the existing mechanics, rules, and traditions of the game? NO.

4. In the case of ambiguous edge cases that can go either way, did we choose the option that micro-improves mechanical pace of the game, or the option that makes game pace more hindered/obstructed? NO, the bug fix would have a compound-cascading recessionary effect on the entire economic pace of the game.

5. Is the solution elegant, simple, and does it make logical sense? YES.

We could argue this into a sinkhole, but here is the Elephant in the room: no arguments change the fact that the list above is 80% deal-killers. I could bring up more things against it, like a developer just told me that infinite recursion issues might be problematic when production doesn't happen first. The unpopularity of the proposed solution should be a warning to stay away from this sinkhole. I propose we immediately avoid the sinkhole scenario and instantly switch the focus back to other proposed solutions.

Cheers,
Lexxie
Discord ID: Lexxie#9952

#11 Updated by Lexxie L almost 4 years ago

UPDATE

I have been informed that the "English psuedo-code", as posted above, could be done without too much difficulty. The result would be that production remains essentially similar as always, while the auto-rearrangement bug would be fixed and render outputs back into human control. That's what we want, isn't it?

If we go this route, the issues up for decision and debate are the "optional extended fix" I proposed above, as well as any others people bring up. My own belief is that "optional extended fix" as described above, intuitively fixes a few unnatural edge cases and partly re-balances the slight loss of game pace suffered by the elimination of the "auto-arrange trade bonus". Lose a tiny bonus in the TC sequence, gain a tiny bonus in the new to make up for it.

Thoughts?

#12 Updated by Zoltán Žarkov almost 4 years ago

It is simple enough to freeze workers until all their outputs have been added. This is nearly equivalent to Lexxie's pseudocode proposal. I've maintained the status quo where factories and other improvements that increase shield output do not take effect for the same turn change they are built. This takes care of hrm #771536 as well.

#13 Updated by Lexxie L almost 4 years ago

That's great news, keep us posted where we can maybe do some testing on patch, if you think that's helpful.

If it weren't for the fact that the prior way of doing it created some excessive exploits and eliminates any kind of control over specialists, there was one nice thing about it. Which was the micro-boosting of game pace and mechanics.

So I want to re-open the discussion that eliminating the slight auto-arrange food/trade bonus introduces micro-slowing, and if there might be some way to remove exploit and the bug of having no control over specialists, while still preserving a bit of that nice 'micro-boost'. Because what we'll find when we play it now is this slightly uncanny subconscious feeling of greater scarcity and harder to pull everything off, never quite having enough prod/trade/food to pull off what we were formerly able to do.

I suggested flip-flopping the #4 and #5 steps in the pseudo-code as a way to partially alleviate some of this, but to be honest, in a size 1 city, a Settler is produced on the same turn as growth only in a city with +2 food and +4 prod, which is rather rare and very nano-boost compared to the mini-slowing caused by the bug fix. I'm now wondering about scenarios where we fix the buggy unfair parts of it while changing even less about the original behaviour. Thoughts?

#14 Updated by Zoltán Žarkov almost 4 years ago

Disables city_refresh in city_reduce_size when workers are frozen. This takes care of #771536.

#15 Updated by Marko Lindqvist almost 4 years ago

Those log_error()s don't look like they log an error.

#16 Updated by Alexandro Ignatiev over 2 years ago

Granaries and Aqueducts, at the current state of affairs, do have their effect on the turn they are built (right because growing/shrinking is considered after producing).

Actually, I "vote" for harvesting exactly those outputs that you can see on the city screen before tc (with the inevitable exception of changes in traderoutes/wonders in cities processed before). Reason: simplicity. Then we calculate all the events (production, celebration, plague etc.) based on these values and track them during the turn in separate variables applying them to the city object only at the end.

This, while simple to a player, would be though more treacherous for a game designer (especially at the ruleset level), since the requirements for disasters etc. won't know what is happening around. E.g. you won't kill a citizen in rebel in cities up to size 3, the disaster sees that the city is s4 and happens, but it does not know that we have just produced a settler and the city is already going to be size 2.

So, a more stable solution: we calculate only city outputs and city happiness state in the initial state (by game logic, persisted during the taxing year) but apply the changes in the order we already do and test the rest from the intermediate states. The celebrating status still may "appear" in cities too small to celebrate but it can be easily handled by explicit size requirement if severely needed; it's just too important to leave it obscure.

#17 Updated by Alexandro Ignatiev about 2 years ago

  • Blocks Bug #874511: Don't suggest throttling growth if Granary appears on the growth turn added

#18 Updated by Edward Cree almost 2 years ago

I hacked together one possible solution at https://github.com/freeciv/freeciv/compare/S2_6...ec429:wonkypop — basically the idea is that we delay both grow from foodbox and shrink from pop_cost until after anything that could care about city outputs, happiness etc. AFAICT this should always mean that 'what you see is what you get' (except that buildings still take effect straight away), but I haven't tested every possible combination, only the trade-across-growth and trade-and-food-across-settler-prod cases, so there could still be some unintuitive interactions with celeb/revo etc.

#19 Updated by Marko Lindqvist almost 2 years ago

  • Tracker changed from Task to Feature
  • Sprint/Milestone set to 3.1.0

You should work on master (development) branch. This is not a bugfix to get introduced to stable release branches.

Your patch ignores the possibility of more than one City_Build_Slots. Population cost for just one unit gets eventually decreased. Looking at it, City_Build_Slots never have worked flawlessly in respect to population cost. There's bugs to fix in that before trying to introduce this new feature.

#20 Updated by Edward Cree almost 2 years ago

You should work on master (development) branch.

Sorry; when I wrote the patch, I was thinking in terms of longturn folks (who drew my attention to this FR) who are still using 2.6 (and who I suspect will end up backporting the feature if it gets merged).

AFAICT from a quick read-through of the master branch code, the semantics of the patch should still apply, though there might be a few textual conflicts. If the behaviour/design of my approach is agreed to be the right thing then I'll gladly port the patch to master and re-do my testing there.

Your patch ignores the possibility of more than one City_Build_Slots

See city_production_build_units in common/city.c, which already does:

if (utype_pop_value(utype) != 0 || utype_has_flag(utype, UTYF_UNIQUE)) {
    /* unit with population cost or unique unit means that only one unit can
     * be build */
    (*num_units)++;
    return FALSE;
  }

so AIUI my code's assumption of only one unit built is valid.

#21 Updated by Marko Lindqvist almost 2 years ago

  • Category set to Server
  • Status changed from New to In Progress

Edward Cree wrote:

my code's assumption of only one unit built is valid.

Ok, then the principles of the patch seem solid to me.

For the coding style the very last 'if' should have space between "'if' and '(', and the block following it should have '{' and '}' despite it being just one line.

#22 Updated by Marko Lindqvist almost 2 years ago

Edward Cree wrote:

If the behaviour/design of my approach is agreed to be the right thing then I'll gladly port the patch to master and re-do my testing there.

I can't promise that nobody rejects the patch before final version has passed its review period, but at least nobody has had comments against current version in over 36h.
Can you provide the patch as a file ('git format-patch ...')? It would be much easier for me than going getting your tree and digging the commit out of there myself.

#23 Updated by Anonymous almost 2 years ago

Zoltán> Some have even suggested that all city outputs should be exactly as the city screen showed immediately before turn change

Ignatus> Actually, I "vote" for harvesting exactly those outputs that you can see on the city screen before tc

I meant to write this a lot earlier, but better late than never.

As a player, i.e. someone who picked up the game six months ago to play it, and not as someone intimately familiar with the internals, I have to
strongly support Ignatus' viewpoint here.

Cities should produce exactly what the client shows they do (or, the client should show exactly what the city produces).

There are a couple of reasons for this:

First, transparency. Especially a new player will not know about the details of city processing, and I don't think the in-game help helps in understanding it either. A player will naturally rely on the city view showing what happens. Having the behaviour match the "promises" made by the client reduces surprises where a player ends up with less money than they thought they'd have on the second turn, or missing the discovery of a new tech when a research point or two was lost somewhere even though they carefully managed everything to get it on the next turn change.

Second, I think the point of using a computer, is that the computer does the dull job for you. I don't know about others, but not to put too fine a point on it, the reason I play computer games is not so that I get to do tedious calculations to figure out what happens, just because the computer doesn't. (If it's a board game, that's fine, but they also often have somewhat simpler rules.) A game about civilization-building should be about that, not about having to figure out the immediate results of some action yourself. Of course, this does not translate to long-term strategy, that's up to the player. But as long as outside disturbances are absent, the computer should be able to help by showing what the city state will be immediately after a turn change.

Third, is what Ignatus said, simplicity. Committing the outputs as they are shown, and already calculated by the server is simple and straightforward (also implementation-wise, so with what little I know about programming, I agree from that viewpoint, also).

Anyway, regardless of how it's fixed, at least for me, the current behaviour is highly unintuitive, especially the part where some tiles can be worked "partially", where you get production from a tile, but not food or trade.

I don't think I'm the only one with this view, there were some discussions about the unintuitive nature of the current city processing elsewhere, and a mini-quiz that showed that about half the players answering didn't know about how the game auto-rearranges workers when city size changes. The ones who did, were of course the more experienced players, but even there, one of them said they didn't remember all the details correctly.

#24 Updated by Anonymous almost 2 years ago

Because of the above, I made a patch-set to change the city processing to conform (more) with
the "what you see is what you get" idea, i.e. to have the results exactly as shown.

To that end, the patches

1. Store all production surpluses at the start of the turn, and use the stored values when committing production. Hence, changes during the city processing don't take effect on the same turn.

2. Reorder trade (sci and gold) handling to the start of the turn, before building and growth. With the above, this has little effect, but comes from the same principal idea. Also it means that a disbanding city still produces sci and gold (what little it may be).

3. Add a record of build turns for wonders, and make them not take effect until the turn after building.


This (mostly point 1) means that the city growing don't change the output for that turn (the new citizen is there to work on the next). Similarly, when building Settlers/Migrants, the citizens moving away still work shields, food and trade on that turn (they're part of the unit only on the
next turn). Auto-rearranging workers still happens, but has an effect only on for the next turn and the player or their client gets to arrange the workers back, if they so wish. Also, new buildings (Market/Library) don't take effect on the same turn, as e.g. a Factory never has.

I think this also matches with a conceptual idea of the city workers toiling in the fields and mines for some period of time (the turn), and the turn change just being a time when that work is recorded, a new Barracks/Market/Harbor/Factory being opened for use, a new Phalanx leaving the training ground, or Settlers leaving the city. Buildings under construction are not operative yet when the work happens, so they can't affect the output before being finished. (Though, obviously any such comparison to real life will fall flat at some point, since the game is an abstraction, but, anyway.)

The exception, sort of, which I kept is that building happens before growth, so an Aqueduct built on the same turn allows growth past the limit on the same turn, same for Granary. The most important reason to do it like this is that even for new players, it's relatively easy to learn that it's
fine to build an Aqueduct or Granary as late as the same turn the growth happens. Changing that would cause unnecessary confusion.

The third point about wonders removes the randomness about which cities get to benefit from a new wonder. Currently, the city building a wonder might be first to get processed, so all (other) cities would gain the benefit on the same turn, or it could be the last, giving no benefit to other cities, or something in between. In a multiplayer game, one player might get better use of their (small) wonder than another. Even worse, any Great Wonders that affect all players would give a benefit randomly to some players on the same turn, but not to others (*). Having the wonders only take effect next turn removes the randomness, and puts their effects in line with regular buildings.

I know there are some counter-arguments to all this, I'll comment on them separately.


The patch is for 2.6, at least for now. Partly, because that's what I've played with, and partly because that's the version easiest to test against. (I don't see downloadable clients for 3.x on the web site, which makes it harder for me to test, and I was also thinking of running a test game to get comments from other players, which is easier if they can easily get a compatible client.)

The patches are here, in smallish pieces:
https://github.com/ilkkachu/freeciv/commits/S2_6_new_cityturn or
https://github.com/freeciv/freeciv/compare/S2_6...ilkkachu:S2_6_new_cityturn

Right now, the patch-set only guards against intra-player effects, not effects between players (e.g. I have to check the behaviour of trade routes when cities grow), and there may well be situations I've missed and thus haven't checked. Obviously, there may be bugs too, please tell when you find any.

Sorry for sticking this pile here on top of Edward's proposal. This came up elsewhere earlier, and he was quicker than me in getting the idea into code, but I had to finish the thought first before posting it.

#25 Updated by Anonymous almost 2 years ago

As for the counterarguments:

The main one I see is that the game will slow down/mess the game balance if a Market/Library does not take effect the same turn.

- Yes, it'll cause some slowdown, that's true. But it should affect all players equally, and I believe it's something that can be fixed in the ruleset by adjusting the costs of the relevant improvements. Also, looking at the NEWS file in the 2.6 distribution, it's not like changes to game behaviour/rulesets have not been done before. Anyway, it should be possible to make changes like this conditional on the ruleset. (Painful, perhaps, but not impossible.)

- On the other hand, doing it this way puts Market/Library/such on the same line with e.g. Factories, and prevents e.g. accidentally getting a tech too fast, possibly obsoleting your Barracks, or units you still wanted to build next turn. Of course, theoretically, one could change the code so that a Factory would also take effect the same turn, but that kind of back and forth with the production calculations would be a bit less than simple to do, I think.

Similarly one may not like that this means a player can't buy a Temple or a military unit to quench disorder, effective immediately on the same turn.

- Yes, that's right, that wouldn't work. But the player can make citizens entertainers, raise the luxury rate of taxes, or bring units from elsewhere. Or build the unit/Temple one turn earlier, on the same turn the city grows enough to be unhappy again. Again, this could be accounted for in the improvements' costs.

- This is again something where the client doesn't really help the player in understanding what's going to happen. A city will still show the big "DISORDER" sign even with zero outputs even if a Temple finished on the same turn would fix that in the middle. The client doesn't even show that the new building could change things, let alone calculate the correct output. Also, if they player uses the city governor, it'll put workers up as entertainers, which hints even more at that being what you need to do. Also, getting the city out of disorder with a bought Temple would still not make the citizens produce shields, only food and trade, so there's the strange situation where only a part of the tile output happens. (I don't get how that works thematically for a city in disorder, really.)

#26 Updated by Marko Lindqvist almost 2 years ago

Ilkka Virta wrote:

Similarly one may not like that this means a player can't buy a Temple or a military unit to quench disorder, effective immediately on the same turn.

This, at least, would count as incompatibility for civ/2 rulesets. Traditionally bar has been very high for accepting changes that reduce compatibility of those rulesets.

I haven't looked at the patch yet, but your description of the concept sounds promising. Do you think it's possible to proceed in smaller, easier to get accepted, steps, or does this need to be one big patch that changes everything at once?

#27 Updated by Marko Lindqvist almost 2 years ago

Ilkka Virta wrote:

(I don't see downloadable clients for 3.x on the web site

You mean Windows builds?
Some snapshot builds are available from http://files.freeciv.org/packages/windows/testing/cazfi/installer_msys2/snapshots/

#28 Updated by Marko Lindqvist almost 2 years ago

Marko Lindqvist wrote:

Ilkka Virta wrote:

Similarly one may not like that this means a player can't buy a Temple or a military unit to quench disorder, effective immediately on the same turn.

This, at least, would count as incompatibility for civ/2 rulesets. Traditionally bar has been very high for accepting changes that reduce compatibility of those rulesets.

In any case, this is kind of rule change that we don't want to stable branches, so work like this need to be targeted to master only. One of the reasons I asked if it's possible to split this to parts was that maybe some parts would be acceptable also for S3_0 or even S2_6.

#29 Updated by Alexandro Ignatiev almost 2 years ago

Ilkka Virta wrote:

Similarly one may not like that this means a player can't buy a Temple or a military unit to quench disorder, effective immediately on the same turn.

Actually, a mil.unit won't make city more happy unless its size changes. (At least so it was in 2.5).
Really, the shortest and mostly sufficient argument here is "simpler is better". We play in managing cities, not in hacking of an unsmooth code. Just seeing what you get if there is no disaster or sudden assault is a simplicity that is not stupidity. When I thought about it (applied to Longturn) I imagined a patch of 3-way game setting switch: classical, WYSIWYG and an intermediate solution (outputs are collected before city processing but buildings may bring happiness and traderoutes are collected at city processing start, not in a preliminary phase-players-wide cycle). I also thought to leave the processing order as it is, so a disbanding city gives nothing (but for a newer version we can well change it).

The only sane alternative is enforced governors that can understand high-level orders and communicate to neighbour ones to get automatically what player wants best. An even more fundamental change to eliminate any tile management (just get sum of tile outputs * number of citizens / number of tiles, shared tiles counted in parts?) is not bad by itself but makes the game not civ-ish at all.

#30 Updated by Anonymous over 1 year ago

Alexandro Ignatiev wrote:

Ilkka Virta wrote:

Similarly one may not like that this means a player can't buy a Temple or a military unit to quench disorder, effective immediately on the same turn.

Actually, a mil.unit won't make city more happy unless its size changes. (At least so it was in 2.5).

I tested that with at least 2.6, the mil unit does fix disorder the same as a Temple. (If it wasn't done anywhere before it, at least `create_unit_full()` calls `city_refresh()` to set the unit upkeeps, and that probably fixes the happiness, too. But it might not get called if you build a NoHome unit...)

#31 Updated by Anonymous over 1 year ago

I meant to get back to this earlier, but I wasn't getting email notifications, and then, well, other things. Sorry.

Marko Lindqvist wrote:

This, at least, would count as incompatibility for civ/2 rulesets. Traditionally bar has been very high for accepting changes that reduce compatibility of those rulesets.
In any case, this is kind of rule change that we don't want to stable branches, so work like this need to be targeted to master only. One of the reasons I asked if it's possible to split this to parts was that maybe some parts would be acceptable also for S3_0 or even S2_6.

Yes, I know, I know. Edward already mentioned Longturn, and that was the reason I also started with 2.6. But it should still do for testing and figuring out most of the possible gotchas, at least for now.

I haven't looked at the patch yet, but your description of the concept sounds promising. Do you think it's possible to proceed in smaller, easier to get accepted, steps, or does this need to be one big patch that changes everything at once?

I cleaned the patchset up a bit. On LT's tree, though, but should be readable still. It's in five pieces here: https://github.com/ilkkachu/freeciv/commits/longturn-LT2_6-wip-wysiwyg-city

- New city turn: Make wonders only take effect on the next turn after building
- New city turn: Save original city surplus values for use with city processing
- Cleanup: Split plague and disorder handling off of update_city_activity()
- New city turn: Change update_city_activity() processing order
- Cleanup: Invert city_build_stuff() conditional in update_city_activity()

That cleanup stuff is just reordering, similar to what had already been done in master.

Out of the others, saving the surplus values is what does most of the work, I don't think I tested it without a reordered update_city_activity(), but using saved production values should still make Libraries/Markets not take effect immediately, and to make a city in disorder not produce food or gold, even if a new Temple saves it. But it's also a bit annoying change since it touches city_populate(), city_distribute_surplus_shields() and update_city_activity(), and relates to the gold upkeep.

So, with that, reordering update_city_activity() probably doesn't do much with that in place, other than what happens to a disbanding city. Zoltan's patch on freezing workers looks like it'd also go a long way to fixing the greatest weirdnesses, though I didn't test that. Timestamping the wonders is also a relatively simple change in that it doesn't touch much of the other code.

You mean Windows builds?
Some snapshot builds are available from http://files.freeciv.org/packages/windows/testing/cazfi/installer_msys2/snapshots/

And yes, I meant Windows. Thank you. I didn't find that as https://freeciv.fandom.com/wiki/More_distributions only mentioned "freeciv 2.6.0-beta1" next to MSYS2. I took the liberty of editing that page...

#32 Updated by Lexxie L over 1 year ago

Recently we suggested a minor code change that fixed a huge flaw in Airlift affecting 99.9% of all play, rules, and game setups, and had it rejected because someone said they MIGHT one day want to do a game that covered the 0.1% case, even though they never did.

Now comes a suggestion that would permanently divorce and fork and break the rulesets of the largest online multiplayer freeciv community, for every game ever played.

We have an established ruleset and culture and level of expertise to our rules where every element is holistically balanced with every other. I do not have the time to explain why this patch would totally break that, but it would. All the arguments in favour of the change are indeed valid, but are not properly taking into consideration a whole cascade of other spillover consequences. Please contact me on Discord to discuss. Thanks.

Please do not break existing rules of a community that doesn't just "tinker" around but has a classic ruleset more like chess that people take a lifetime to master.

#33 Updated by Marko Lindqvist 2 months ago

Lexxie L wrote:

Recently we suggested a minor code change ... and had it rejected

I guess this refers to a change that needed to be made properly. So it was not accepted as it was, but the support for the requested feature was implemented in a way preserving compatibility.

#34 Updated by Marko Lindqvist 2 months ago

Marko Lindqvist wrote:

Lexxie L wrote:

Recently we suggested a minor code change ... and had it rejected

I guess this refers to a change that needed to be made properly. So it was not accepted as it was, but the support for the requested feature was implemented in a way preserving compatibility.

You lie even about the things I've done myself, as if I wouldn't know what I've done, and then constantly complain that I listen to wrong people to get the idea that you lie (hint: there has been hardly anyone else than yourself who I've been forced to listen about those issues you talk about)

Also available in: Atom PDF