Down with the 512 city limit!

If you really wanted more than 512 cities, then you'd have to atleast hope for something that does automatic micromanagement very well (like a script, maybe). Each city has a series of tasks inbetween turns:

In no particular order:

1 - Corruption algorithms (that thing is huge as it is, with distance algoritms <-- a time-consuming algorithm, usually involving recursion.).
2 - Food/Commerce/Shield calcuations (add it to the city, and civ totals, and check to see if a unit/improvement/wonder is built. It seems that when a wonder is built, it immediately goes to all other cities that were building a wonder, and checks those).
3 - culture and culture borders. (I do know that culture borders is based on the culture level of the city, civ (possibly), and when the cities were built).
4 - happiness check (probably checks for rioting, city growth, recalculates happiness, WLTKD, which readjusts corruption).
5 - Governors (the AI has to pick build queues too, and they're mostly static, which is why you always see a warrior-warrior-settler build at the start of the game).
6 - Laborer re-allocation (if a city is captured/borders change/city grows, things need to be readjusted).

And there's probably other things, too. Plus, this is just one part of the AI turns.

Even if you did have a limit of 2,048 cities, or even 64,000 cities (on a 2,048x2,048 map), it's gonna take a LONG time, even on the most decent computers.
 
Originally posted by Chieftess
If you really wanted more than 512 cities, then you'd have to atleast hope for something that does automatic micromanagement very well (like a script, maybe). Each city has a series of tasks inbetween turns:

In no particular order:

1 - Corruption algorithms (that thing is huge as it is, with distance algoritms <-- a time-consuming algorithm, usually involving recursion.).
2 - Food/Commerce/Shield calcuations (add it to the city, and civ totals, and check to see if a unit/improvement/wonder is built. It seems that when a wonder is built, it immediately goes to all other cities that were building a wonder, and checks those).
3 - culture and culture borders. (I do know that culture borders is based on the culture level of the city, civ (possibly), and when the cities were built).
4 - happiness check (probably checks for rioting, city growth, recalculates happiness, WLTKD, which readjusts corruption).
5 - Governors (the AI has to pick build queues too, and they're mostly static, which is why you always see a warrior-warrior-settler build at the start of the game).
6 - Laborer re-allocation (if a city is captured/borders change/city grows, things need to be readjusted).

And there's probably other things, too. Plus, this is just one part of the AI turns.

Even if you did have a limit of 2,048 cities, or even 64,000 cities (on a 2,048x2,048 map), it's gonna take a LONG time, even on the most decent computers.

Sorry, but I cannot agree. At least I can't completely.

1. There is no need to recalculate the distance any turn. Distance calculation should be triggered just when a capital/FP/SPHQ is placed/moved/destroyed. In any way, it will be a rare incident.

2. As far as the given city is concerned, even that is not that much to calculate. Wonder creation will cause some calculations, though. But it happens not very often (29 GW's and 11*#of_civs SW's, from which some are unlikely to be built often/ever)

3. Cultural expansion should be easy, if expansion goes to open (free) land. In case of cultural conflict over a certain tile, this will happen
a) when your city expands culturally (max. 6 times a game)
b) when the opponents' cities expand (max. 6 times a game, as well)
c) when the overall cultural value of a civ rises (may happen every turn [but there are rather few tiles for which this has to be calculated])

4. I agree

5. if not 6) then this happens not that often, either.

6. I agree

Nevertheless, there are a lot of values which wouldn't have to be calculated per turn - although they currently are, as it seems.

So, the urge for an updated/improved engine is without any doubt.
Nevertheless, given the fact that when the engine was developed (3 years ago) the most modern personal computer nowadays just qualifies for a technical museum :p , it would be a nice move to give the player a chance to go for extended limits, or not.
What will cause a 1 GHz, 128 MB RAM, 10 GB hd, Win95 system to sink into the dust, shouldn't be that great problem for a 3.3 GHz, 1024 MB RAM, 280 GB hd, WinXP system, should it?
 
Look in the Civ3 Conquests forum. You'll see the corruption code somewhere. It loops through each city to get the distance from the capital. Inefficient? Probably, but that's the way it was programmed. Maybe they'll make a better one in Civ4.
 
Originally posted by Chieftess
Look in the Civ3 Conquests forum. You'll see the corruption code somewhere. It loops through each city to get the distance from the capital. Inefficient? Probably, but that's the way it was programmed. Maybe they'll make a better one in Civ4.
As I wrote before:
Just another evidence that Civ3 was never designed to be a "big" game.
Let's hope, that they are re-engineering the game for Civ4.
The Civ3 engine is old-fashioned, although we have to stay with it for the next two years.

I hope, that they do not optimize Civ4 for high-end systems, but that they will prepare it to make the best use of those.
 
We've been shown a bit of Civ's code in this post by Tavis.

That bit of code is interesting in that it shows the cost of the corruption calculation to be proportional to NumberOfCities squared. I.e. if there are twice as many cities, the time to recalculate corruption will be multipled by four.

It wouldn't surprise me if there are many other areas where the cpu time required for things is worse than a linear relationship. How much worse? Can't guess without seeing the code. There could well be cases where the cost is worse again than just NumberOfCities squared.

This kind of problem is probably what is stopping Firaxis from simply increasing the limit. If a game with 2000 cities just took four times as long per turn as a game with 500 cities, they could make the limit very high and people generally wouldn't mind. If 500 cities takes 1.5 minutes for a turn, people would expect 2000 cities to take 6 minutes and would either accept that or not use such a large map. But if those 2000 cities were to take over an hour per turn, well, that's another story :)

That this problem exists does not necessarily mean the design or implementation were bad. Some of the code probably goes a long way back. At the time it was written there might have been memory constraints which made thinking of more than a 100 or so cities silly anyway. Or the game might have been limited to small numbers in other areas and there was no need to worry about whether these algorithms had exponential costs or not.

In any case, I doubt that the problem is very hard to fix at this point. The example we've seen for the corruption code would be fairly easy to fix. These days we can assume people have a fair bit of memory available (compared to when the code was first written.) Adding a couple of new class members would make it possible to change the corruption code from exponential to linear in expense. And as a side effect it would run much faster on all maps. That kind of work would have to be done in a number of key areas. I don't know how many - all those which contribute a lot to inter-turn times, would need the source code to find them all.

I would bet that with a few days of work the game could be sped up significantly and also made much more linear in the relationship between increasing various table sizes (e.g. max cities, units) and the computing time required.

Presumably the real problem is prioritizing that work. It would have to be considered important enough to get done. Obviously fixing bugs is more important - the game is fast enough as it stands to at least be generally acceptable. Is this work more important than adding new features? (Which ones is it more important than?) Personally I'd put it very high on the enhancement list, because it affects almost everyone. I think almost every player has played on large enough maps that they'd have liked the inter-turn time to be quicker. Even if it wasn't a problem to them, they'd enjoy it faster. So it seems a good thing to do, a crowd-pleaser. And as a side effect (if done properly) it should largely eliminate the current problems of increasing maximum limits. At the same time as making the game faster it would make it reasonable to increase max cities to some very large number. :)

All this is theoretical though unless Firaxis can be convinced that speeding up the game is an enhancement which many players would appreciate and worth treating as a high priority vs. other enhancements.
 
@Chieftess:

As I just noticed, the f/s/c-addition is performed during YOUR turn.
I just got the completion message for an improvement and could see on both, map view as well as city view, one of my towns producing the Sixtine Chapel. While I was adjusting the production of that first town, the wonder producing city was at 5 turns.
When I had cycled through all my cities with completion notifications, it had changed to 4 turns.

So, the f/s/c-calculation isn't performed "inter-turn", but "intra-turn". Which makes sense.
 
@SirPleb:

Very good statements! Could you please send this directly to Firaxis? :)

(And I would be #2 to appriciate any improved speed and enhanced limits, if this wasn't already made clear *g*)
 
I don't understand why we discuss speed here. The inefficiency of some parts of the code is not a reason to set limits. There are players who could deal with that problem because they have a fast computer.
 
I for one just can't wait until they remove that ridiculous 2048 city limit. It should not be less than 10,000, because, as you know, I have no life :groucho:
 
Top Bottom