Solaris game mechanics - a history of cheese, and a future rework

2025-12-18

Hey everyone!

It is certainly no secret that the history of Solaris' game mechanics has been filled with exploitable mechanics, cheese tactics, and weird edge cases. This post aims to construct an overview of these problems, analyze their underlying causes and serve as a foundation for discussing the planned overhaul(s) that aim to tackle them.

First, we shall examine the different game mechanics problems faced over the past few years.

Broken game mechanics

In this section, we will list the game mechanics exploits of the past, explain them and the adjustments made to solve them. Readers who are familiar with these may skip this section or use it purely for reference.

Worldbuilder/Research station cheese

This was perhaps the most prominent of these broken tactics.

World builder specialists apply a 5 weapons malus to the star they are on. Therefore, they are problematic to defend. The exploit aimed at forcing the attacker into becoming the defender. This would then cause the advantage to rapidly swing against the original attacker, thus making a position extremely hard to take. There was little direct counterplay to this possible.

Other specialists with a weapons malus were usable, like the Research Station.

Player A owns star X
Player B attacks star X
Player A abandons star X
Player A schedules a carrier with sufficient forces (but less than B's largest carrier) to land the same tick as B
Player B claims the star X without combat due to having the largest carrier
Combat ensues, with B now being the defender and hit with a -5 weapons modifier

Later variations, after star abandonment was disallowed, made use of a (formally neutral) third party to take over the star instead of abandoning it:

Player A owns star X
Player B attacks star X
Player C unallies A
Player C captures star X
Player A schedules a carrier with sufficient forces (but less than B's largest carrier) to land the same tick as B
Player A and B capture the star from C together
The second round of combat happens, and B is now the defender

Adjustment to game mechanics

First, this issue was mitigated by disallowing stars from being abandoned.

However, with sufficient coordination, an ally of the defender could be temporarily neutral and take over the star to trigger the behaviour anyways.

To solve this a mechanic was introduced where star specialists (except war machine) would be destroyed in combat if a second round of combat happens on a star.

Single-ship interception

Maybe the first exploitable mechanic ever discovered.

The way combat works, ship numbers are essentially health points and weapons level is attack.

Therefore, a single ship carrier with weapons N does N damage, although it dies immediately.

As a result, sending out carriers with 1 ship on them would kill N ships in carrier-to-carrier combat. This only works in carrier-to-carrier combat. In carrier-to-star combat, the defender fires first and would destroy the carrier before it can attack.

Adjustment to game mechanics

Combat was changed so that a carrier with x ships and y weapons level, where x < y, would be destroyed immediately.

Offensive explorer cheese

This was offensive usage of the explorer weapons malus.

First, this was achieved by gifting:

Player A owns star X
Player B attacks X
Player B sends an explorer to X to land with the attack, converts it into a gift
Player A gains the explorer
Combat ensues and A is hit by the weapons malus

Adjustment to game mechanics

The behaviour of gifted cariers was changed so that specialists get destroyed if the receiving player is hostile.

Defensive explorer cheese

Using the explorer weapons malus to defend against an attack.

This was usually achieved with the help of a third player, formally allied to the defender.

Player A owns star X
Player B attacks X
Player C is allied with A
Player C sends an explorer to X, scheduled to arrive simultaneously with B's attack
Player C unallies A
C and B get grouped up during combat against A, their collective weapons level reduced

Adjustment to game mechanics

The calculation of weapons level was changed. The malus (here of -3) would only be applied if the specialist was on the largest carrier participating in the attack.

Arguably, this creates the opposite problem, where it is possible to reinforce an attack with an explorer (as long as it is not the largest carrier) without a downside (while still gaining the speed bonus).

War hero cheese

Based on star abandonment/takeover by a third player, a war hero can be used "defensively" so that it's offensive bonuses apply anyways. This is not fixed at the moment and requires significant coordination, so it is very situational. It has been nerfed in impact by limiting the maximum bonus a war hero can provide.

Carrier-to-carrier combat

Carrier-to-carrier combat is known to be highly unpredictable.

Here is an attempt at an explanation, it may not actually be 100% accurate:

Let's assume there are 2 stars, StarA and StarB.
Let carriers A, B, C, D, constructed in this order.

A, B are in the same position on StarA => StarB and owned by Player1.
C, D are in the same position on StarB => StarA and owned by Player2 (who is hostile with Player1).
The positions of A, B and C, D are below 0.2ly in distance, which will be crossed within a tick.

C2C combat is computed:

1. A list of carrier positions is constructed, collecting metadata about the carrier, the current position and the predicted position next tick. 
This list is ordered in what MongoDB calls "natural order", practically likely equivalent to insertion order/age.
2. A carrier graph is constructed, mapping (destination, source) to the carrier position objects traveling between source and destination. The graph looks like this:
(StarA, StarB) => [C, D]
(StarB, StarA) => [A, B]

3. The graph is traversed, in order of insertion of the key. This means that the paths are sorted ascending by the oldest (by natural order) carrier traveling on them.
For each carrier X traveling on that path (in natural order, starting with oldest), all other carriers are checked if they will collide head-on or be overtaken by X within the next tick.
Gift carriers and carriers with combat-avoiding specialists are filtered out.

4. Combat ensues if one of the carriers collected in 3 is not allied to X's owner.

In this example, it means that A will fight the group of C, D.

In conclusion, it is hard to estimate:

  1. Which carriers will engage in C2C combat at which point
  2. For >2 carriers, how will they be grouped up? Will there be multiple rounds of combat?
  3. Due to the latter, how will weapons levels/specialists behave?

C2C doesn't seem to specifically allow mechanics abuse (or at least no one has figured them out), but it is at least confusing.

N + 1 interception

Essentially, this is a variant of the single-ship interception.

If someone has a weapons level n, attacking them with n or less ships will result in no damage being done. Attacking with n + 1 ships will result in full damage being dealt to them.

It is open to discussion whether this should be considered a broken mechanic yet.

Towards a new combat system

In this section, we will discuss several aspects of the new proposed combat system and list points that remain for discussion.

2-sided combat and shared weapons levels

In a situation where more than two players are involved in combat, they need to be grouped. Besides grouping by alliance, Solaris can only resolve combat with two sides. Therefore, if after grouping by alliance more than two parties remain, attackers are grouped together into one attacking team.

The consequence of that is the mechanics of sharing weapons levels (and also sharing specialist bonuses and maluses) within one combat side, exploits like the explorer cheese or the world builder cheese become possible.

Therefore, a combat system that can acount for more than two parties must be developed.

Finding combat groups

For this purpose, first, players must be grouped according to their diplomatic relations. For games with diplomacy disabled, everybody will be assumed to be non-allied automatically.

Groups can be formed by a simple algorithm: A and B are allied if:

  1. They are directly allied or
  2. There is a player C that is allied (directly or indirectly) to both A and B

C2C is generally hacky

While C2C properly handles cases of combat with two carriers involved, the collision behaviour of higher numbers of carriers is highly unpredictable. This is very much fixable especially once the >2-sides problem is solved.

Instead of the current error-prone grouping, all carriers that collide with each other will end up in one large group, and then combat gets resolved between all of them. This means that allied carriers travelling stacked on each other will fight together too.

Turn-based combat resolution

Solaris has a turn-based combat system. Essentially, weapons are the attack and the ship numbers are the health points.

Fleets take turns shooting at each other until one is dead. Even an almost-dead fleet still does full damage (which causes some problems above), however, if at the very first turn a fleet has less ships than the other fleet has weapons level, it gets eliminated immediately.

Additionally, if there is a defender (so only in C2S combat), the defender gets to shoot first, essentially giving them a minor advantage. In C2C combat, this does not apply.

In general, this turn based system seems desirable. It mirrors combat systems players are already familiar with, it allows for a degree of extensibility, and most importantly, it produces (usually) reasonable results. For sufficiently large numbers, ship combat approximates to Lanchester's linear law.

Options for the future

There are some things to be considered for adjusting this combat system:

  1. Lanchester's square law is arguably more realistic, at the cost of making everything more prone to Snowballing. Other 4X games whose combat system abide to this have more complex mechanics to combat snowball effects. This is probably not desirable for Solaris.

  2. Should fleets with low healthpoints/ships still do full damage?

  3. How should the combat system behave when there are >2 participants? Should the damage be distributed equally?

Especially for the last question, some prototyping may be necessary. There have been some algorithms developed in the past that partially cover this but especially question 2. remains unanswered (and thus unaccounted for in these experiments).

Star capturing

Currently, it is possible for a star to be captured multiple times within one tick, thus causing multiple rounds of combat. This will be avoided in the future, the star capture should only happen at the very end of the tick, by the largest remaining carrier (once only one group remains).

Attack-only bonuses

Specialists like the siege breaker and the war hero have bonuses that should only apply when they are the attacker. We want to prevent them from being used defensively, and they need to be adjusted for >2 fleet combat.

For the latter, the obvious choice is to make the attack bonus only apply against the defending fleet.

How exactly we can mechanically prevent them from being used in defence remains an open question.

Back to main page