Why the 32 civ limit?

[yoshi]

It seems to me that if you have 1 civ comprising 100 cities or 100 civs comprising 1 city each, it should make no difference; the CPU time should be the pretty much the same shouldn’t it? That is to say that it shouldn’t make a significant difference how many civs the AI is controlling but rather the total number of units and cities functioning on the map, regardless of ownership. Theoretically, the workload shouldn’t be that different. If that’s the case, why not just allow for an unlimited number of playable civs?

[Rameau's Nephew]

I think that the answer is that the game is built on a rather old engine that has some seemingly-arbitrary limitations because of how it was originally coded.

[Commander Bello]

Well, there would be a difference between 1 civ with 100 cities and 100 civs with 1 city each - just think of the diplomatics.
But, as 32 is just 2^5, I think that Rameu's Nephews explanation is correct and the developers used some bytes for storing information. Obviously, they had just 5 bits left = 32 civs (1 human and 31 AIs)

[Grav]

I never understood that explination. 5 bits left, so they're left with 32 civs? I mean, hello, they put this game on 700 megabyte CDs... what's 5 more bits for another 32 civs? That's like... the size of a 1 by 1 pixel jpeg. Craziness!

[Chieftess]

Originally posted by Grav
I never understood that explination. 5 bits left, so they're left with 32 civs? I mean, hello, they put this game on 700 megabyte CDs... what's 5 more bits for another 32 civs? That's like... the size of a 1 by 1 pixel jpeg. Craziness!

It's not that simple as 5 bits. There's the following:

Cities
Units
Diplomacy


And those are just the basics. There's a city loop, which goes through each city and updates units in memory, then decides what to build next (or where to place the next laborer when the city grows). Then there's deciding what to do with units (Where to move them? What should workers do?). Then there's Diplomacy (What to trade? Is the AI at war? Does the AI need an alliance?).

Then, there's the 10 year old engine. Maybe it *was* efficient at one point. But, adding things, and moving things around tends to break things. Look at it this way - suppose every civ on the map (say there's 10 of them) have 500 cities. The way the AI works is that, every city must have 2 defenders. (1000 defenders * 10 civs - 10,000 units). For each city cycle, the AI has to decide what to do with those defenders. Should they still defend? Attack? Disband? It takes up CPU time. If it takes 1 milisecond for that decision, then that's 10,000 miliseconds for defenders alone! (10 seconds). That's not throwing in attackers, workers, and other stuff.

So, if you have 1 civ with 10,000 cities, this would take awhile.

Now, toss in 100 civs with 1 city. It's not the cities that are the problem, but the diplomacy. The code might look something like the following (in very sloppy psuedo-code).

Civ(currentciv())
Loop Civ[n] to Civ[max]; { DoDiplomacyStuff(); };

Now, it's gonna do that 100 times, checking trades, peace, alliances, war, and a whole bunch of other factors, like what did the other civs do the previous turn? (i.e., did they lose any units? Make any units?). It might look simple, but there's a lot of decisions going on. Just be glad that the AI doesn't take the time to decide how a stack of 100 units should attack (based on conscript-elite, attack, mobility, bombard etc.)!

I'm not sure what the actual city and AI code look like, but remember that its' an old engine (I'm guessing based off of Civ2). Civ3 added a lot of stuff, which means more AI decisions. Adding this stuff in could've affected how well the code runs.


100 civs, 1,000 cities = 100,000 cities = atleast 200,000 units.

The unit limit is now at 8,000+. With 512 cities, you can have an average of 16 units. 1,024 cities, an average of 8 units. It's really a question of CPU time and balance.

[Grav]

Ok I think I get it now. Its a CPU problem, and not a memory one. Right?

[Emp.Napoleon]

Many personal computers (like mine) would not be able to handle more than 32 civs.

[widdowmaker]

I never understood that explination. 5 bits left, so they're left with 32 civs? I mean, hello, they put this game on 700 megabyte CDs... what's 5 more bits for another 32 civs? That's like... the size of a 1 by 1 pixel jpeg. Craziness!

You have to be a programmer ot understand. Bianary code (what the computer reads) only has 6 bits (or was it 8? 4? bah i forget which now). And it cant save real numbers. Example

YOu want to save the number 40, it will either be

40.11111111111111111111111111111111111111111

or

39.99999999999999999999999999999999999999999

Because of the bits it cant save a real number, so in reality there are 32.3333333333333333333333333333333 civs in the game. Typicaly you would just Trunicate that number and be done with it. But due to the age of the engine im willing to bet that they didnt trunicate it, and so to avoid bugs and crashes made that number hardcoded into the engine.

[rychan]

So, the short version is "because a complete graph has O (n^2) edges" (where n is the number of vertices)

But that's not the whole reason, I'm sure. First off 10,000 AI diplomatic exchanges a turn doesn't sound too crazy for a modern processor.

Secondly, that graph probably doesn't need to be explored completely every turn. A human player (unless they're slightly crazy) probably wouldn't check every 100 of the AI.

Hmmm... But the more I think about it, the more I think it should be ok for the computer to just go crazy and explore the whole graph, assuming that the operations during one AI to AI diplomacy are constant time with respect to the number of other AI- no trying out every possible alliance, embargo etc. Because then complexity is potentially getting too high w.r.t. number of civs. Eh, but even then probably not.

I've played a huge map with 16 players and certainly the AI turns do become very slow as the map is developed. I think either the unit or city part of the AI must be much slower than the diplomacy.

Maybe they just couldn't think of a good interface to handle it. Heck, having more than 7 or 8 AI in a game and the interface already gets a bit screwy.

[rychan]

Originally posted by widdowmaker



YOu want to save the number 40, it will either be

40.11111111111111111111111111111111111111111

or

39.99999999999999999999999999999999999999999

Because of the bits it cant save a real number

A computer can, however, store integers like 40 perfectly well-
00101000

So I don't quite see what your problem is

[Oddible]

Also, to process things efficiently - ie, to make them fast enough for you to play reasonably - data is grouped in chunks that can be manipulated as wholes. When you see a program limitation based on a nice round number like 32 (any power of 2 really) its often because it was most efficient to have data moving around in that size. Because of this, adding 1 to 32 does not make it 1/32nd slower, it completely changes the dynamic of the chunk and would affect nearly every system in the game. Lots of coding.

In terms of programming priority, I would personally prefer a diplomacy screen that displays the 32 civs over adding more civs.

[rychan]

Originally posted by Oddible
Because of this, adding 1 to 32 does not make it 1/32nd slower, it completely changes the dynamic of the chunk and would affect nearly every system in the game. Lots of coding.

Well, that would seem reasonable if there were only 32 entities that could own units/land in a game, but there's actually more than that. There can be different barbarian tribes, and then of course unowned lands.

So I'd imagine every tile, unit, city, etc has an "owner" field, and maybe if the engine is really old I'd see how they were hard up for memory and only wanted each of those fields to be 5 bits. But that's not possible with 32 civs. You'd need 6 bits minimum anyway.

Of course nowadays this doesn't matter. We're not that tight on memory. But the diplomacy argument makes more sense, because there you have something that grows exponentially w.r.t. number of civs. memory required to designate different civs grows logarithmically with the number of civs. * assuming # of units and cities is constant.

[LavosBacons]

Personally, I'd be wary of any "programmer" who talks about "bianary code" that only has 6 bits and can only store infinitely repeating decimals "because of the bits."

Just sayin' is all.

[zulu9812]

Why on earth does CivIII use a 10 year old engine?

[toh6wy]

Originally posted by zulu9812
Why on earth does CivIII use a 10 year old engine?

One word: laziness.
Ok, ok, before you all start flaming me, I suppose it could be because they didn't have the resources or time. But I bet if they really wanted to, they could. They'd *better* for Civ IV...

[Commander Bello]

Ok, I think the answer lies somewhere in between.

Whatever the age of a given engine may be, it for sure has to store some data.
This is done in memory places which are organized in bytes or multiples of bytes. Each byte consists of 8 bits. Period.
Currently (IIRC) a socalled integer variable is 2 bytes long, a long integer is 4 bytes long, resulting an integer being 16 bits and a long integer being 32 bits.
Now, let's assume that only tiles are taken into consideration.
We have 16 different terrain types => 16 = 2^4
Those 2^4 terrain types may belong to 32 different civs => 2^4 * 2^5.
So, we already need 9 bits. Then there are the ressources.
There are 27 ressources currently. So we need another 5 bits for the ressources. 5 Bits = 32 chances, from which 5 are currently not used.
Now, we already have 14 bits.
Next, there are the tile modifications as roads, irrigation, mines, outposts, even damage and so on. Again, we need some bits to store this information.
And at least, we have to manage everything, which might be on a certain tile: units, towns, cities, metropols.
Since towns can hold various improvements, this information could be kept either in the string (consecutive sequence of bytes) which is attached to the tile, or there is a link to another structure of bytes in which the information about the improvements is stored. I think, the later is the case.
Let's assume, that for a given tile we will need 24 bits to store any possible combination of information about a certain tile.
24 bits already make for 3 byts. The current max. size of maps is 300+ * 300+ tiles => 90,000+ tiles. This would make for 270,000 bytes already.
And a lot of those (although not all) have to be used for calculations as Chieftess already pointed out.

Now, take into consideration that the engine might not be the most modern one - let's assume the age of 10+ years indicated by Chieftess - and then remember, what kind of computers 10 years ago have been in use.
That was 1994, so a good computer was a Pentium 66 Mhz with 16 MB of RAM. Maybe, the compiler used was not the very best, either. It might have lacked some optimization potential and other things.
And now you have your answer, why we have to face all those limits ...

[rychan]

Bello, that's all very reasonable. But I don't think 5 bits would be enough for the "owner" field anyway. There are 32 civs + X barbarian tribes + null owner. But hey maybe it's 6 bits and it just won't create new tribes if they're all assigned.

Regardless, it's a bit of an arbitrary restriction.

[Lich Lord]

Cause there ar't 33 civs that have had a huge impact on the course of human events.

[warpstorm]

5 bits is enough for the owner field in the city. There are only 31 civs, and one barb 'civ'. There are no unowned cities (although there are unowned tiles).

My best guess is a combination of starting the project with an old engine and pushing to it's stretching point. After a certain point it gets too expensive to make certain changes in the code. Is this laziness? I can't say. The people who built Civ3 were working long and hard. Would it have been faster to not use old code? I doubt it.

[jguy100]

Originally posted by Lich Lord
Cause there ar't 33 civs that have had a huge impact on the course of human events.

And why would you say that? There are hundreds of civilizations that changed the course of histroy that aren't in the game. Mexico, Canada, Brazil, Vietnam, Saudi Arabia (tho I'm sure they fall under Arabians), Cuba, South Africa, Poland, and many more.