Late game end turn

[Nanuk]

This will be my first time firing up a map larger than the game's huge (150x150). This game is pretty old now, but does lack the 64-bit architecture exploits, so memory is still limited.

How does wait times in the late/end-game go for those exceptionally large maps? I was originally going to make out a 222x222 map, but now I'm thinking 300x300.

Any other bugs that affect giant maps?

 

[tjs282]

This will be my first time firing up a map larger than the game's huge (150x150). This game is pretty old now, but does lack the 64-bit architecture exploits, so memory is still limited.

How does wait times in the late/end-game go for those exceptionally large maps? I was originally going to make out a 222x222 map, but now I'm thinking 300x300.

From what I've read on CFC, the main factors that increase (late-game) interturn-times are:

• (Re)calculation of city maintenance costs
• (Re)calculation of possible sea- and air-trade routes
• (AI) unit-movement processing

...and these factors will clearly increase in magnitude with number of civs and total number of towns (hardcoded limit is 512 towns per map: this is usually only reached on larger map-sizes) and units. Magnitude-increases can be minimised by modding the game-rules, and/or adjusting the game-preferences (Ctrl-P):

• Remove the maintenance costs from some/all buildings
• Reduce the total number of trade-enabling buildings per civ:
  • Add (much) more restrictive prerequisite conditions to Harbours (e.g. Needs freshwater/ a river) and Airports (e.g. Needs Factory/Mfg.Plant and/or Aluminium in the BFC)
  • Remove Sea- and Air-trade flags from generic buildings, and add them to the Palace, FP, and/or other Small Wonders instead
• Reduce the number of possible city locations
  • Remove the 'Allow city' flag from additional terrain-types, e.g. Desert, Tundra, Jungle (Forest?)
• Minimise unit-movement calculations:
  • In game-prefs, turn off some/all 'Animate/show [enemy] unit moves' options up to/including 'Animate battles'
  • If you already inserted the 'AIPatrol=0' line into your conquests.ini file, then remove it (caveat: will make early-game Barbs less dangerous)
• Restrict late-game unit production (to reduce stack-sizes)
  • Increase shield-cost per unit
  • Make some/all units autoproduced
  • Allocate pop-costs to some/all units, to reduce number of worked (shield-)tiles per unit produced per city (caveat: may/will strangle the AI)
• Make (large) militaries more expensive to maintain (least effective: when treasury hits zero, only 1 unit over the 'free-unit' limit will be disbanded per turn):
  • Increase unit-maintenance costs for some/all govs
  • Reduce AI bonus-units per difficulty
  • Reduce free-unit allocations per town/ city/ metro (for some/all govs)

EDIT: I'm sure the hardcore pro-Modders can give you even more useful tips than these

Any other bugs that affect giant maps?

Not really bug per se, but obviously on larger maps, you're going to have a lot more Ocean tiles, and wider Oceans between any two landmasses. This can make global exploration and overseas invasions take a lot longer than they 'realistically' should, and/or become (a lot) more tedious to manage.

If that bothers you, you might want to consider significantly increasing naval movement rates to compensate. More radically, you could give Ocean-tiles a movement-cost = zero, but use the 'Impassable to Wheeled' terrain-flag in combination with the 'Wheeled' unit-flag to make Oceans inaccessible to the earliest ships in your mod.

 

[Lanzelot]

My knowledge here may be outdated, as I havn't really kept up-to-date with these topics since Windows XP, but I'll add it anyway, perhaps it is still of use with today's Windows versions...

In the standard 32bit Windows system there used to be a default upper limit of 2 GB memory per process, even though in theory 32bits suffice to address 4 GB memory. As RAM got cheaper, people realised, that this was a bit too restricting, so starting with Windows 2000, Microsoft introduced an operating system flag that allows to increase this upper limit to the full 4 GB for special processes. Can't remember the details, but I think you had to set a certain registry key, giving the name of your executable (C3CConquests.exe in this case).

So assuming that this is still the case for the "32bit backward compatibility mode" of today's 64bit Windows systems, you could set this flag and double the available RAM for the C3C process. That should definitely help...

But of course it could be, that today's 32bit backward compat mode already uses the 4 GB limit by default... Then we wouldn't get an improvement. You can check this, if you start a really huge game and then in the TaskManager watch the "VM Size" parameter of your C3CConquests.exe process. If it never goes beyond 2 GB, then this limit is probably still in place on your machine.

 

[Nanuk]

Thank you, both. Also kudos on post 777, tjs282.

I had done some things opposite of what you suggested, tjs282. I did not realize maintenance cost of buildings, for example, affect the end-turn time. I'll have to scale this back and think of other ways to balance things out for the economy of my scenario. So thanks for mentioning it.

I also did not think of monitoring memory usage spikes for the game, so thanks for the suggestion. I'll look into how to make the game use the extra memory if it does indeed cap at 2.

 

[Nanuk]

A new question - let's say I have 31 civilizations in a scenario, will the speed between turns and loading of the save improve as the civilizations reduce in number over the course of the game, or does the game still count them with every turn and include them in various checks?

 

[tjs282]

A new question - let's say I have 31 civilizations in a scenario, will the speed between turns and loading of the save improve as the civilizations reduce in number over the course of the game, or does the game still count them with every turn and include them in various checks?

AFAIK, game-state is calculated using only the extant civs.

So e.g. if you've reduced the total number of buildings with the sea/air trade-flags (e.g. removed the flags from the generic buildings, and applied them to the Palace/FP instead), then as the number of civs is reduced (i.e. fewer Palaces still standing), that should make an increasingly substantial difference to the interturn trade-route calculations, e.g. assuming that only the Palace gives land/air/sea trade, then no. of (potential) trade routes = (n^2 - n) / 2
2 civs = 1 trade-route
4 civs = 6 trade-routes
8 civs = 28 trade-routes
16 civs = 120 trade-routes
31 civs = 465 trade-routes
In practice, obviously you won't have the maximum number straight away, since all civs won't be in contact. On a Pangaea-Map, you will hit max. fairly soon after the game begins, likely within 100-120T (depending on how fast the civs can get in contact with one another, i.e. map-size, how many starting units they have, and how fast those units can move).