In our introductory piece on incremental games, we took a look at the history of the genre and examined what makes these games unique, but we didn't delve too deeply into their actual design. While incremental games can appear simple, their design reveals complex and thoughtful intent from their creators. By looking at some successful examples of the genre, we can better appreciate the features of these games, and better understand how we might design our own.



Before diving into the mathematical framework, there are three easily-overlooked but important areas of design that I want to highlight: the quality of exploration and discovery, the difference between 'idle' and 'clicker' expressions of the genre, and the importance of coherent theme and art.



The Joy of Discovery



One of the most important vectors of "fun" in an incremental game is that of discovery. Many of these games begin with a very simple initial setup, but the complexity spirals as the player advances. The process of uncovering this complexity taps into the innate appeal of discovering new and hidden features. Candy Box, for example, can be understood as a game primarily about exploring its system, and the 'incrementing' candy score is simply the mechanism of unlocking further content.

Thus, most incremental games do not make the entirety of the system available from the start, but instead "gate" additional features against tiers of the primary currency. This content may be a "known unknown", as in Idling to Rule the Gods, where certain sections of the game are explicitly empty and specify how and when they can be unlocked, or an "unknown unknown", where the player doesn't even know the features exist until a certain level is reached, like almost all of the content in Cookie Clicker. Some games may contain elements of both: AdVenture Capitalist informs the player about much of its content that they can unlock, but contains numerous hidden features that emerge over the course of play.

I guess we have a long way to go.



Discovery is an important feature to consider in the design of an incremental game because it provides a exploratory reward system to the player while they learn about the game's core mechanics. Presenting everything up front would not only raise the barrier to entry in learning the game, but also remove the joy that comes from gradual familiarization with a system.



Idling or Clicking?



Incremental games tend to focus on two overlapping but distinct primary mechanics:

Autonomous growth that the player gradually increases the rate of.

Active player engagement whose productivity gradually increases.

Games focusing on the latter will generally have either a literal "clicking" mechanic to produce growth, or some other means to require active player participation, like storage caps that necessitate frequent player intervention. In CivClicker, for example, the player must mostly actively manage their town, with only short periods of idle growth. Conversely, games focusing on autonomous growth might include a clicking mechanic, but if it does then its importance gradually wanes in favor of something automated. In AdVenture Capitalist, the player must actively click at first, but quickly unlocks the ability to automate the process, and then is largely free from manual incrementing.



This choice is largely a matter of preference and emphasis of the game's goals. A game requiring active management may be more engaging for the player over a short timeframe, but, if implemented in a way that requires too much player involvement too often, it can come to violate principles of ethical and humane game design. Conversely, a more autonomous or idle approach may require less engagement from the player in any given play session, but can engender a more long-term commitment to the game, which helps explain why "idle" games on Kongregate have such a high retention rate. AdVenture Capitalist even helpfully informs the player what has happened in their absence, emphasizing that it doesn't require your constant attention:

Art Direction and Theme



Incremental games still often benefit from a narrative theme on which the mechanics sit (although this can be easy to overlook because these mechanics are so minimal.)

A sensible theme can help give context to the otherwise abstract exercise of increasing numbers. Likewise, all games benefit from good art direction and design, and incrementals are no exception. Consistent aesthetics help the game feel like a unified experience, and a clean interface lowers the mental cost of navigating the game, so the player can concentrate on the game itself, rather than interpreting bad user interface elements.

The example above from AdVenture Capitalist is a good illustration of this. Its theme is business management and capitalistic expansion (which fits with the gameplay of ever increasing numbers), and it uses a 1950s Googie aesthetic for its art direction. This is used consistently (and with humor), such that even the menus and tutorials are "in character" and reinforce the visual and narrative theme.



Incremental games' need for graphics and writing might be somewhat sparse compared to games of other genres, but its important not to mistake low need for no need.

Numbers Going Up

The most defining mechanic of incremental games is the number increasing. We defined this last time as:

The presence of at least one currency or number,

which increases at a set rate, with no or minimal effort,

and which can be expended to increase the rate or speed at which it increases.

It's that third item that largely affects the feel of the game, and that is the most difficult to design well. Since it's a particularly straightforward example, let's take a look at Number by Tyler Glaiel. It has the three core definitional items and almost nothing else: a number goes up, and you can spend that number to make it go up faster.

When the game begins, the "income rate" of the number increasing is 0.1 per second. The amount of "number" saved up can be spent to make it go up faster. Here are the first five purchases, with their cost in the first column and the new "number per second" rate in the second:



Cost Income Rate

1.0 0.2 1.2

0.4 1.4

0.7 1.7

1.2 2.2 1.8

Even with a handful of observations, we can identify some of the hallmarks of incremental design here. One is the nonlinear increases to both cost and benefit: it takes more and more number to get relatively less incremental improvement.

This makes sense from a practicality perspective: if the cost/benefit stayed the same (for instance, if it always cost 1 number to purchase a 0.2 increase in the income rate), there would no variability at all in the outcome, and the income rate increase would climb at a steady and predictable pace. This would get boring very quickly!

Instead, this is what the cost (in blue) and income rate (in orange) for the first twenty purchases look like:



Blue: Cost of the xth upgrade. Orange: Income rate per second generated from x purchases. For example, the 10th purchase costs 7 numbers, and results in an income rate of 7.6 numbers per second.



(You can download an XLSX of the data used to generate these graphs from this GitHub repo, or view a Google Sheets equivalent.)

We can see here very obviously that these functions are non-linear (even ignoring the cost formula jump at the 12th iteration), and that cost increases quickly outpace the income rate increases. That's an important aspect of the design, because it means that the time spent waiting to afford the next upgrade grows exponentially the longer the game lasts. So the game progresses quite quickly at first, with the player only needing to wait periodically to save up enough for the next purchase, but gradually slows down.

Most incremental games have multiple sources of income rate increase to upgrade, instead of just one as Number does. This is a major source of the discovery and strategy of incremental games, because having multiple vectors of improvement whose costs increase non-linearly introduces interesting avenues of optimization for the player. If the player chooses to invest heavily in a single building or upgrade, the exponentially increasing cost means at some point other options will become relatively cheaper, even if they were initially priced very high. This means the player has an array of options at their disposal, but they must be constantly reevaluated because relative worth to the player is constantly shifting.



Linear Improvements With Exponential Costs



Exponential cost scaling is beneficial for the ever growing resource and time investment they require, but most games don't employ exponential income rate increases. Why not?

In the graph from the last section, it's the gap between the two lines that gives us the ever-growing cost-versus-benefit ratio. To achieve that, we actually only require cost (in orange) to increase exponentially (or polynomially); the income rate could increase linearly, and the gap between the lines would still ever widen.

For example, in Clicker Heroes, one of the first automated sources of number increasing is from a "hero" called Treebeard. Initially, it costs 50, and gives you an income rate of 5 per second. The second level costs 53.5, but still just gives an additional rate increase of 5. The first fifty purchases look like this, again with cost in blue and the income rate in orange:



Please note that for simplicity we're ignoring a number of other cost/rate mechanics in Clicker Heroes.



The "income rate" function here is just a straight line, since each purchase increases it by the set amount of 5, so the formula for it is very simple: the total rate per second is just the number owned multiplied by 5 (so, \(y=5x\)).

The cost, however, is going up at an ever-increasing rate. The incremental cost of each additional level is minimal at first; on the graph we can see for the first twenty the gap between the two is nearly constant. But then it breaks away dramatically, requiring more and more for each subsequent upgrade.

The formula for the cost function here is actually one that's widely used across many incremental games:



\[ Price = BaseCost \times Multiplier ^{(\#\:Owned)} \]

For our Treebeard example, the base cost is 50, and the "Multiplier" variable is 1.07, so the second level costs \(50 \times 1.07^1 = 53.5\), the third costs \(50 \times 1.07^2 = 57.245\), and so on. The Multiplier's value determines the curvature of the line, with higher values meaning steeper cost curves. (A value of 1 would give a linear cost line.)

Clicker Heroes uses 1.07 as the increase multiplier for all 35 of its upgradable heroes, and all the various buildings of Cookie Clicker use a value of 1.15. Interestingly, the 10 businesses of AdVenture Capitalist all use a different multiplier, but each is between 1.07 and 1.15. The common appearance of the same Multipliers across different games suggests that the curves produced between those bounds are balanced and satisfying.

Some games do diverge from there though. Steam's multiplayer incremental game Monster, part of their 2015 summer sale event, uses Multipliers as high as 2.5, which increase very steeply.

As mentioned before, exponential cost scaling has the benefit of balancing multiple upgrade paths by ensuring each follows a path of diminishing returns. This makes some of the tactical balancing innate to the cost formula itself, rather than something the designer needs to explicitly frame. Because even if a given resource is sometimes or even mostly 'better', its exponentially rising cost means it can't be exploited exclusively.

Let's take a look at the list of upgradeable buildings in Cookie Clicker as an example:



Building Base Cost

Base Income Rate

Cursor 15 0.1 Grandma

100 0.5 Farm

500 4 Factory

3,000 10 Mine

10,000 40 Shipment

40,000 100 Alchemy Lab

200,000 400 Portal

1,666,666 6,666 Time Machine

123,456,789 98,765 Antimatter Condenser

3,999,999,999 999,999 Prism

75,000,000,000 10,000,000

We can see several apparent patterns just from this table.

The first is that base cost of every subsequent upgrade is almost five times higher than the previous one (except for the last few). These increases by half an order of magnitude ensure the player has sufficient time to enjoy each newly unlocked resource; lower increases would mean the unlocks might come too quickly, but any longer would risk the player becoming bored before achieving the next unlock.

The income rate (cookies per second, for this game) meanwhile is increasing only by about a third for each additional tier, which means that while the buildings contribute ever larger numerical amounts, they're actually less and less efficient relative to their cost.

However, because each building follows the same cost increase formula \( Price = BaseCost \times 1.15^{(\#\:Owned)} \), every building actually follows a very similar pattern. The chart below shows a line for each of the 11 buildings, graphing their first two hundred upgrades, with log cost along the y-axis and log income rate on the x-axis. (Since these are exponential functions, a logarithmic scale reveals their similarity better than a linear one.)



This Each line represents a different building, with cost on the y-axis and income rate on the x-axis (both logarithmic scales). This is a visualization of the cost to benefit curvature we discussed earlier



So even though these buildings appear very different, since each one nominally produces and costs much more than the prior, their exponential cost formulas produce curves that are inherently similar, while still creating a system that the player can optimize.



Accounting for Efficiency



While incremental games are superficially about making numbers go up, it's how to make them go up as fast as possible that provides depth of play for passionate players. The player always has multiple avenues of improvement before them between the various upgradeable resources (usually along with some additional features we discuss later), and so challenges the player to evaluate these choices. Should you buy the cheaper upgrade you can afford right now, or save until you can afford the next tier?



Since we eventually want to buy all upgrades, the most efficient approach is just to evaluate the optimal order. Imagine a scenario where we're currently producing 5 of our number per second (\(nps=5\)), and we have a choice between two upgrades. The first costs 20 (\(cost_a = 20\)), and will increase our income rate by 1 (\(rate_a = 1\)). The other has \(cost_b = 100\), but also has \(rate_b = 10\). The former is cheaper, but it's also less cost efficient.

Well, let's try buying A then B:

We wait and save for \(20/5 = 4.0\) seconds, then purchase A.

Now we wait \(100/(5+1) = 16.67\) seconds, then purchase B.

We now have \(nps = 16\), and it took us \(20.67\) seconds to achieve.



What if we did the opposite?



We wait and save for \(100/5 = 20.0\) seconds, then purchase B.

Now we wait \(20/(5+10) = 1.33\) seconds, then purchase A.

We now have \(nps=16\), and it took us \(21.33\) seconds to achieve.



So, it looks like buying A first and then B is more efficient, because \( 20/5+100/(5+1) < 100/5+20/(5+10)\). We could generalize this example to get a formula like this:



\[ \frac{cost_a}{nps} + \frac{cost_b}{(nps + rate_a)} < \frac{ cost_b}{nps} + \frac{cost_a}{(nps + rate_b)} \]

But this is only useful for comparisons between two possible upgrades, and so isn't as useful if we had a great deal of choices. We need to simplify the formula to isolate the variables for just a single upgrade (the derivation of which is explained in detail in this fantastic article by Adam Babcock), which yields this:

\[ \frac{cost_a}{nps} + \frac{cost_a}{(nps + rate_a)} \]

Now, we can apply this formula to each possible upgrade, and the lowest result, because of the transitivity of the inequalities, will yield what we should purchase next (with some exceptions not worth getting into for this level of analysis). This greatly simplifies the process of finding the most efficient route to optimization.

This is obviously relevant for the player, but its also useful for the designer. Knowing the most efficient usage of various game elements can identify the existence of unintended spikes in time requirements, and ensure that even optimal play progresses at a rate intended by the creator.



Deriving optimal play scenarios also lets us compare different incremental games, as we can reduce the disparate variables to just the time it takes to reach a given level of number per second. The chart below shows the time required to achieve a given number per second income rate in AdVenture Capitalist (in green) and Cookie Clicker (in brown), if buying buildings in the most efficient manner (ignoring other game aspects for simplicity):



X-axis: time, y-axis: income rate (log scale); green: AdVenture Capitalist, brown: Cookie Clicker.

Remarkably, the two games look very similar here, returning higher rates of nps against an ever increasing amount of time. Both grow incredibly quickly in the first 8-10 hours (around 500 minutes), but the rate of increase is much more marginal thereafter. They eventually flatten out as the number of new buildings is exhausted. As a result, most incremental games include other purchasable resources alongside the main upgradeable buildings, one of the most important being the ability to reset the game, which allows the player to climb this curve all over again.

The spiralling complexity of upgrades in incremental games can make their design a daunting prospect. But the designer doesn't need to precisely calibrate each and every element. The beauty of complex non-linear systems means that engrossing ladders of upgrades can be produced with only high level balancing from the designer. For the player, navigating the system to find the optimal sequence is difficult and fun, whereas the task for the designer is simply to make sure there is such a complex system to navigate.



"New Game +" and Other Features



A "New Game +" feature lets the player reset their progress in exchange for some lasting bonus. So, all purchased buildings and other resources might be returned to zero, but when starting over a flat multiplicative increase is applied to all number per second calculations thereafter.

This doesn't change any of the fundamental formulas of the game; it just means the player will reach the eventual asymptotic plateau quicker and quicker. In essence, this feature acts to extend the core gameplay by allowing it to replayed faster. This can't be kept up indefinitely however, so eventually long-time players will reach an "endgame" of sorts.



In Clicker Heroes, ascending rewards the players with a new currency to buy upgrades with.



Another common feature for extending play is simply increasing the complexity of the upgradeable buildings. So far, we've only examined the most common method of incremental upgrade, which follows the exponential cost function. Alongside those are typically upgrades which either yield one-time flat improvements to the overall number per second, or that alter the underlying cost and income rate variables in some way.

In Clicker Heroes, for example, there are upgrades that increase the base number per second for a "hero", as well as ones that increase the base number per second for all "heroes". While these and similar features don't change the underlying mechanics of an incremental game, they can widen the possibility space for the player to explore, and further challenge their ability to optimize the game. Additionally, like the 'New Game +' mechanic, the volume of upgrades can also act to prolong play before hitting the eventual plateau in progress.



Conspiracy Clicker has three distinct trees of interrelated upgrades.



Go Forth and Multiply (Exponentially)



Although this hasn't been an exhaustive investigation of incremental game design, we've given a thorough look to their fundamental aspects. As a brief summary for prospective designers and developers:



Enable and promote a feeling of discovery.

Consider active and inactive play (and ideally reward both).

Don't neglect a unifying theme and art style.

Make use exponential cost scaling, with the most common form being \( Price = BaseCost \times Multiplier ^{(\#\:Owned)} \) with a Multiplier between \(1.07\) and \(1.15\).

Provide the player with multiple avenues of optimization.

Extend play through the strategic use of resetting and mechanics that increase complexity.

If you're interested in learning more, the incremental games subreddit is a great community of designers and developers to turn to for advice and ideas. If you'd like to dive right into implementing some of your ideas, the developer of Cookie Clicker created an online tool that can easily create similar games, and its a great way to experiment without having to lay all the entire foundation yourself. If you're looking for something a bit more advanced, the creator of CivClicker has an excellent piece on the logic for a HTML and JavaScript implementation as well.

I hope the framework we've examined here serves as an inspiration for exploring your own expression of an incremental game. After all, there is a lot of untapped design space still left to explore:

List of Games Mentioned



While not a comprehensive list (for that, the incremental games subreddit has a great list), here's a list of the games mentioned in our first article or in this one:

Also note: you can download an XLSX of the data used to generate the graphs in this article from this GitHub repo, or view a Google Sheets equivalent.