Though it may not initially seem like it (especially as it's very easy to get very large numbers), almost every incremental game has to operate within a finite framework. In particular they have to deal with the limits on JavaScript numbers - being 64 bit floating point numbers their limit is 2^53, or 9007199254740992.

Any incremental game that involves truly exponential growth hits this limit surprisingly quickly, even with growth on the order of 1.01^n. Ultimately there needs to be a countervailing force to bring this growth under control - usually this is a limit imposed by applying a cost to growth (e.g. buying a cursor in cookie clicker costs more the more you have) and this cost can also grow exponentially.

In fact it's quite frequent for this cost to grow much faster than the returns, meaning that the earlier stages of the progression curve are much quicker while the later stages are longer and more grindy. This sort of progression is mirrored in other genres - an RPG character's levelling is an excellent example - and can even be applied to a player's skill progression in skill-based games (where the increase in skill is reduced per unit of time invested in the game as the player progresses).

Growth/progression curves are very important for incremental games, almost moreso than any other genre, because in an essence they are the game. One of the primary hedonic rewards for playing an incremental game is the sense of progression and many games deliberately expose this progression as much as possible to the player in order to maximise this sense.

CivClicker II's finite world presents me with similar issue - a player starts occupying only a single city, and by the time the player has completed a playthrough I want them to feel like they're occupying 100% of the world. I also want them to progressively encounter resistance as they progress through the world. However, left unchecked a player's growth within the world will be exponential, and is likely to render any resistance irrelevant if it's not carefully gauged.

The early Civilization games suffered from this through what was known as ICS or infinite city sprawl. It was more efficient, long term, to just churn out settlers and have them found new cities which could in turn churn out more settlers and... you see the problem. The solutions were manifold - corruption increasing as you spread further from the capital, inefficiencies picking up as more cities were founded, amongst others - but no obvious nod to the traditional incremental game solution of increasing costs until it becomes untenable to just keep making more settlers.

In some ways increasing costs has problems. It's hard for players to understand why the worker they created five minutes ago cost them 20 food, but this new one costs them 22. It can also feel like a very cheap and artificial way of restricting growth. There's also the factor that a player's growth cannot be solely measured by the number of cities they have (though that might be a good indication).

So there's the challenge: presenting a progression curve that grows, but slows before hitting 100%, all while keeping the mechanics involved understandable and seeming like a natural consequence of the game's systems. It's something that I'll need to consider throughout the game's development, and if it's anything like the original game, I'll have to update it after testing and experience.