Grobots Wiki
Advertisement

Notes on game balance in Grobots:

Theory[]

For a game to be fun, it needs variety. In particular, it needs difficult decisions, which means it needs many options that are equally good.

Play usually ends up in strong Nash equilibria. To preserve variety, this means it needs mixed-strategy strong Nash equilibria. (Strong means the equilibrium strategy is better than any other strategy, not just equally good. Mixed-strategy means it involves a mixture of more than one option.)

In addition to being balanced with other options, a game feature should make fun challenges. A feature whose usefulness is predictable, or which is not interestingly different from other options, doesn't stay interesting for long. The best games balance their options in simple (and therefore robust) ways, but have so many interactions that it's complex to figure out exactly when to use them.

And of course features should be cool. But that's not enough to make them good, not without balance.

Approximate balance[]

It's tempting to try to balance a game by adjusting it until the options are approximately equal. This is a good start, but it doesn't usually create mixed-strategy equilibria. If one option is slightly better than the others, players will figure this out and play only that one option.

Frequency dependence[]

To prevent this, options should be self-balancing: they should be arranged so that if one becomes more popular, that automatically reduces its effectiveness. I know two ways to do this:

Cycles[]

Cycles are a simple and reliable way to make options self-balancing. They're easy to use, and often happen by accident, so they're the most common way to balance games. The canonical example is the game of Rock-Paper-Scissors, where three options create a cycle.

While the simplest examples have three options, most real examples use two interacting choices, giving four options, where A1 > A2 > B2 > B1 > A1. It's the existence of cycles, not their length, that matters.

Grobots weapon ranges are (slightly) balanced by a cycle: medium range beats short (by staying out of range), long beats medium (maybe?), and short beats long (because it's cheaper for the same damage rate).

It's best to avoid cycles with very large effects when sides can't play mixed strategies, because they can overwhelm the rest of the game. Rock-Paper-Scissors is safe even if the RPS effect is very strong, as long as a player can easily play a mixture of the three moves. But if it's difficult to use more than one (as in Grobots, where having multiple types costs seed size), battles can be decided largely by predetermined choices of hardware, leaving little room for cleverness to matter.

If different steps in the cycle have different strengths, this can have surprising effects on the equilibrium. For example, if you improve Scissors to beat Paper twice as soundly as Paper beats Rock or Rock beats Scissors, the resulting equilibrium is 50% Rock, 25% Paper, and 25% Scissors. Improving Scissors makes them less common, and makes Rock more common.

Specific countermeasures are a particularly easy way to create cycles. To balance an option, add an independent feature that works well against it and badly against other things. For example, a game could have armor that reduces damage, and armor-piercing weapons which cost more but ignore armor. If armor is common, armor-piercing becomes more valuable, and therefore more common, which makes armor less valuable and therefore less common.

Scarcity[]

An option can be restrained by scarcity, so sides compete for a fixed quantity. An auction is a simple way to do this: rather than making the value of each option equal, this adjusts their cost: if the resource is underused, it will be cheaper; if it's overused, it will be more expensive. In equilibrium the marginal value of the resource equals the cost of competing for it.

This is how Grobots balances manna with solar cells. Manna is much better, but there's a fixed supply of it, so solar cells remain useful.

Circumstance dependence[]

Variety can persist even in the absence of balance if the options depend on varying circumstances. For example, if cavalry works better on open ground, but infantry works better on rough ground, both will be used. This may not create difficult decisions, though.

This is (partly) how Grobots balances blasters with grenades. Blasters have a friendly-fire problem in disordered mobs, and grenades have a friendly-fire problem at short range, so different choices of army organization cause different choices of weapon. They're also balanced by RPS: grenades are more effective against groups, and blasters are more effective against single targets.

Extant balance issues[]

Grobots has several sets of choices that are supposed to be balanced but aren't.

Cell size[]

Cells are supposed to cost about 1000 energy, with most between 500 and 2000. However, there are several effects that favor large cells, especially for fighters:

  • A damaged fighter's effectiveness doesn't decrease until it dies. This makes one large fighter work better than several small ones, especially in small armies. Doubling the size of a solo fighter quadruples its value against solitary enemies, because it survives twice as long doing twice the damage, and more than doubles it even in large groups, because its effectiveness doesn't decrease until it dies. (A fighter of size can defeat fighters of size 1 sequentially, or (about , for large ) simultaneously.)
  • Large fighters automatically concentrate force.
  • Large fighters reduce friendly fire.
  • Large constructors have shorter latency.

There are some weak frequency-dependencies, but they're not enough to overcome this:

  • Large shots (especially missiles) are inefficient against small cells. If your shots do 50 damage each, it takes two to kill a 100-armor cell - and it still takes two to kill a 51-armor cell. So there's a potential weak RPS of cell size and shot size.
  • An explosion hits several small cells at once, so in theory there's an RPS of cell size and blaster vs. grenade, but this doesn't matter much in practice because they're usually not clumped tightly enough. (Also, we correct for this by making explosions do more damage to larger cells.)

There are some attempts to limit extreme cell size, but they're not self-balancing:

  • The fixed cost of hardware that doesn't scale with cell size (e.g. brain, chassis, sensors) hurts small cells.
  • Cooling cost hurts large cells.
  • Large cells (mass over 25) take extra damage, in an imprecise attempt to compensate for quantization.

Possible balances:

  • Fix quantization by making damaged cells' weapons reload slower or do less damage. (The latter has been tried, and was effective but distasteful to intuition.) This makes repairs more important.
  • Change the extra damage for large cells to more precisely compensate for the effect of quantization.
  • Stunners that disable a cell for a time independent of its side balance size by rock-paper-scissors: stunners beat large cells, large beat small, and small beat stunners. However, this is a very stark RPS.

A more radical approach is to eliminate size variation: fix cell size at 1000, with hardware only affecting the mix. This destroys interesting variation, but also solves the problem of small cells being illegible.

Weapons[]

Grenades do less damage than blasters of the same cost against a single target. Blasters may be balanced for sides that aren't smart enough to avoid friendly fire, but that makes them too strong for smarter sides. On the other hand, grenades are harder to dodge.

Missiles are no longer used much.

Enemy-syphons are used as an auxiliary to other weapons, but that's not very interesting.

War and peace[]

Most sides attack anything they see, but it's more fun if they maintain an uneasy peace which breaks down in elaborate wars.

Gases vs. colonies[]

A gas is a side that expands to fill available space. A colony is a side that forms a single (usually stationary) group. Most gatherers are gases, and most colonies are solar-heavy, but there are colonial gatherers (e.g. Commune).

Gases have more volatile scores, because their growth depends on their ability to win battles: if one gas is slightly better than another, it grows rapidly and takes over the world. This means the best sides tend to be gases, even if they're balanced relative to colonies on average.

However, it seems to be hard to write a good colony. Gases do better than colonies of similar complexity.

Mobility[]

There should be both stationary and mobile cells, but small engines are cheap, and immobile cells are useful only for solar cells and construction, so currently there are very few immobile types.

Fighters have a strong reason to be mobile: concentration of force (and also dodging). Stationary fighters are useless (except for defending colonies, and maybe for very long-range guns). A *combat-specific* advantage to immobility could correct for this.

We could create the option of immobility by allowing sides to trade mobility for cost. Some possibilities:

  • A 'miniaturization' option that adjusts the mass/cost ratio of all hardware.
  • Increase the variation in mass/cost ratio of hardware. We already have heavy (solar cells, grenades, armor, weapons range, bombs) and light (cpu, sensors, shields) hardware, for reasons of flavor (except for solar cells and bombs), but we could create light/heavy pairs.
  • Hardware (wheels? maglev?) that decreases drag (with the current value at the fast end). This supports variation in top speed, and has the interesting side effect of decoupling speed from acceleration. (But watch out for very fast missiles.)
  • Sandbags: cheap armor that greatly increases drag, making the cell practically immobile. This is a good combination of combat-specificity and immobility. (But watch out for super-armored cells that ignore attackers.)

Speed of fighters[]

There should be (and are) fighters of various ranges, from point-blank fighters like Commune's Revenge to long-range siege guns (although there are few of those, and the ones that exist are used mostly for indiscriminate offense). There should also be a variety of speeds, but currently almost all fighters have huge engines.

There are two effects here:

  • Range control: A fighter is completely helpless against a faster enemy with longer range, so short fast beats long slow beats long fast beats short fast, and short slow is useless.
  • Closing time: In the absence of range control, this creates a cycle: slightly shorter range wins because it's cheaper, but much shorter range loses because you die before you get in range. With range control, the longer-range side gets free shots for the difference in range divided by the difference in speed; it's not obvious that there is a cycle.

The effect of successful range control is overwhelming, even with small differences in speed, and larger engines also help with movement and dodging, so all but the longest-range fighters normally have huge engines. There may be a balance cycle here, but I suspect the equilibrium involves mostly fast cells, because high speed usually helps a lot and occasionally hurts a little.

To restore variety:

  • Raise the marginal cost of moderate speed. Currently the cost of engines is quadratic in speed (because drag is quadratic), so marginal cost increases rapidly. This reduces variation; maybe quadratic or linear cost would be better.
  • Make high speed hurt more, perhaps by making its hardware conflict with armor.
  • Reduce the effect of range control, perhaps with a feature that resists long-range shots. (Dodging already somewhat does this; sufficiently efficient dodging would let gatherers ignore long-range shots.) Maybe a shield that blocks shots from outside a certain range but not inside it? A

Repair or replace?[]

If repairs are cheap and fast, they can be used as a kind of shield: cells can effectively absorb damage with their energy by repairing in combat.

Countermeasures:

  • Make repairs inefficient. Currently, repairing armor costs twice as much as buying it in the first place. (Cyclops' decoys are more than half armor, so they're cheaper to replace than repair.) This also creates variety in whether sides even buy repairers, but maybe we don't care.
  • Make repairs too slow to have a significant effect in combat. (This often means they're too slow to be useful.)
  • Make repairs incompatible with combat, by making hits while repairing do extra damage, or making hits stop repairs for a while, or making repairs interfere with shields or weapon use.

Maybe we don't really want variety in whether cells repair. If we make repairs cheap but safely unusable in combat, we could remove the hardware and take repairs for granted.

Shields[]

Shields were originally intended to be an alternative to armor: some types would have shields (and blasters and large engines), and others would have heavy armor (and grenades and small engines). But there was no balance mechanism, and shields turned out to be overwhelmingly powerful, so they were repurposed to protect noncombatants, but this required them to be ridiculously strong (and still lacked a balance mechanism).

If shields were revamped again, they'd need to leave ordinary vulnerabilities (to e.g. massive damage) to reduce stark RPS. But they should have an RPS vulnerability, perhaps to syphons.

Complexity[]

There should be simple one-type sides and complex sides with many types. However, pregnant cells are currently so disadvantaged in combat (because of their extra mass) that one-type sides are impractical, so all good sides separate economy from combat.

We tried to correct for this by reducing the seed by 100 per type, which is inaccurate (it charges the seed, but the benefit comes later) and too linear (the second type is worth far more than the third) and anyway not self-balancing.

More generally, there should be simple 50-line sides and complex 1000-line sides; types are only one form of complexity. Limited human effort limits complexity, and there's a token charge for code to discourage very complex sides, but should we try to keep one-type sides competitive with medium-complex ones?

Advertisement