Guide to Incrementals/Balancing

Scaling

Incremental games often involve large numbers, and naturally high production and high costs can “balance out”, but depending on how fast the growth is, there can still be significant impact on how the game feels. For example, if the growth is fast enough, at a certain point the mantissa doesn’t matter that much, and the player will mainly be focusing on the exponent. At that point, “costs” are also largely irrelevant - they’re requirements that must be hit, but you will not notice the currency actually being taken away.

Of course, upgrades being costs vs requirements isn’t forced based on the number scaling. You can still have slow scaling and requirements by just not making upgrades consume the currency, and you can have fast scaling that still acts as costs by doing things like increasing the cost of other upgrades or (depending on how the scaling works) dividing the currency instead of subtracting.

Faster scaling does force some things on your design, however. First, and most obviously, it means you can’t give small bonuses and still have them feel meaningful. It also tends to mean idling can’t enable the player to progress as far, as each upgrade essentially becomes a hard requirement before you can start working towards the next. In a way, that safeguards against players “skipping” content, but it may force a more linear gameplay experience.

Common scales of growth in incremental games include the following, sorted from slowest growth to fastest:

linear: when something grows a constant absolute amount with its input (e.g. number of purchases). For example, an upgrade that adds +1 to how many resources you gain per click. , where is a constant.

polynomial: when something grows faster than linear, but slower than exponential. .

geometric/exponential: when something grows a constant relative amount with its input. For example, an upgrade that multiplies your gain per click by 1.2x each time. .

factorial: when something grows by multiplying its previous effect by an ever increasing factor. . In incremental games you’ll often use the gamma function, which is a continuous approximation of the factorial function.

Naturally, formulas can mix and match different operations, and to a degree you’ll need to just build up an intuition for the growth of functions that achieve the effect you’re going for. Your intuition and preferences will refine over time and create a unique “feel” for your game. For example, once formula pattern I’m a fan of . That means every time goes up by an order of magnitude, becomes times stronger (e.g. 1.2x).

All that said, I’m not a googologist and I don’t think you need to be one to make incremental games. You can make very strong senses of progression with mechanic unfolding and other techniques, rather than just making numbers get really large really quickly. Indeed, I think there’s points where dealing with notation and weird math operations can get in the way of the actual gameplay. Once you have a handle of polynomials, exponents, and logarithms, you should be set.

Interaction with Previous Mechanics

One decision that can drastically impact how a game and its progression feel is how new upgrades/mechanics interact with the previous: namely, whether they are additive or multiplicative.

Additive bonuses essentially create new lines of progression, and which line is contributing most to the overall production can fluctuate over time. This has become especially popular in nodebuster-likes, where new mechanics will involve things like new weapons that perform alongside the previously unlocked weapons. The effect of doubling the effect of a single additive mechanic will have a varying realized impact depending on how much that additive mechanic was contributing to the overall production.

Multiplicative bonuses augment the existing line of progression, without diminishing the impact of previous mechanics. Doubling the effect of a single multiplicative mechanic will always double the overall production. This has been very common in web-based incrementals stretching from antimatter dimensions (where each dimension is an additional multiplier on overall production) to the various TMT mods (where each layer often involves multiplying the production of a previous layer, and so on).

Controlling Inflation

Inflation is the term for when the effects of available repeatable purchases impact production more than the cost scaling of those purchases. This creates a positive feedback loop where additional purchases come increasingly frequently towards infinity. If you have effect and cost scaling with similar asymptotic growth (for example, an upgrade that costs 3x each time and doubles production), you can run the risk of inflation. Particularly, you might fall in this trap if you have multiple upgrades that both have similar growth (for example, if you had two of the previously described upgrades, that would inflate forever).

The most effective way to avoid unintentional inflation is to ensure the effect of any repeatable purchase has a higher asymptotic growth than the cost. For example, an effect that grows linearly but a cost that grows geometrically (e.g. 1.2x cost each purchase).

Another sure-fire method to stop inflation is to cap the number of times the purchase can be repeated. This is essentially controlled inflation - one that has a definitive endpoint. This is useful for giving players a temporary sense of rapid progression, as they see what used to be a rare purchase become very common, and then once it caps they can move on to some other mechanic.

Lastly, and most controversially, is changing the growth functions. This is often called “softcapping” an upgrade. It can refer to either nerfing the effect growth after a certain point (e.g. raising it to a <1 power after a certain point) or buffing the cost growth (e.g. raising it to a >1 power). I think buffing the cost growth does a much better job at allowing the player to still intuit the impact of their decisions, but better yet (in my opinion) would be to hardcap the upgrade and introduce a new one with the slower growth. That completes avoids the controversiality of softcaps, which in my experience stems primarily from how it obfuscates the impact of buying (since you either don’t know the realized impact, or don’t know the price of the next purchase).

Difficulty in incremental games

Most incremental games have no lose state, with “difficulty” typically coming from timewalls/clickwalls if the player acts suboptimally, and how tricky it is to act optimally. Well known "difficult" games basically just require following a guide, like ng+++ or OM or synergism.

Non-linear gameplay (as in, gameplay more complex than having the player just wait for the next upgrade to become affordable) does not mean it's not balanced nor developer controlled. The player feeling like they have more agency is almost always desirable, even if behind the scenes things are still tightly controlled. And, ultimately, there's a whole spectrum of how much agency a player might have.

You should make mechanics easy to understand unless you have a really good reason not to. This allows for pick-a-paths to increase difficulty without quickly ballooning to "I need a guide to play this" levels.

Relatedly, multipliers to other effects that are also multipliers are usually the same as just having a new multiplier, which is easier to understand as a player. "Based on X" multipliers, on the other hand, make things harder to follow and make it unclear the actual effects of player's actions, as they get filtered through an increasingly nested web of effects upon each other. This can balloon the difficulty so high people resort to guessing and checking or using a guide, which isn't very difficult at all.

Note

This isn't a hard and fast rule (nor are any in this document, really). Having multipliers based on amounts of prestige currency is common and fine, just try to limit how big of a web is woven. It's fine to encourage theorycrafting and designing around the expectation of people spending a lot of time hyper-optimizing.

Increlution is one of my favorite incremental games and a wonderful example of how small but compounding multipliers can be satisfying and intuitive.

A way of powering difficulty is adding parallel progression systems, so that "suboptimal progress" in terms of which systems they're progressing down still means they're making progress and don't feel like they're wasting time. This only works assuming you have slow enough growth that any progress done on the "wrong" progression systems feels pointless, though.

RNG is used to add difficulty in rogue likes. Not by requiring good luck (ish), but by making the player use their skill to succeed under slightly different conditions each run. Incremental games using RNG don't typically have a skill component, and that causes the player to have less agency.

Other developer's opinions

I’ve asked some other incremental developers for their advice on balancing, and reproduced it below with only minimal editing for formatting purposes.

Jacorb

FORMULA OPTIONS (where is the variable it's based on, & are constants)

RULES (not strict, just recommendations):

• DO NOT mention both on an exponent and below (i.e. ) This can make it almost impossible to invert the formula for buy max purposes
• DON'T use break_eternity.js's built-in slog function It's laggy as heck
• Keep track of polynomial function exponents Can cause inflation if you aren't careful, it's always okay to add a " " in there if you're unsure (or just softcap like me)

1. Linear ( ) As basic as it gets, pretty self explanatory
2. Polynomial ( ) Stronger than Linear when Keep in mind that you need to keep track of the value of if you boost an upgrade later (i.e. raising an upgrade's effect to a power can cause inflation)
3. Exponent Polynomial ( ) Stronger than Polynomial when If you use this, should probably be a logarithmic variable (it should increase logarithmically relative to what it's boosting, although that's just a suggestion) Variation:
4. Exponential ( ) Stronger than Exponent Polynomial when If you use this, MUST be a logarithmic variable You could replace with another formula to make an even stronger function (i.e. or smt like that)
5. Logarithmic ( ) If you use this, can be exponential when compared to what it's boosting, or not, that's up to you, this one's pretty flexible Variations: , , etc.
6. Inverted ( ) can be any of the previously mentioned functions (although ) Decreases with higher values of Can be used for some interesting formulas, although isn't that useful
7. Limited ( ) can be any of the previously mentioned formulas (although ) This limits the result between & , which can result in some interesting formulas (maybe you want a percentage between 0 & 100, which you could do by setting & both to 100)