From Mathematical Stability to Cinematic Destruction
By SRADRAVEN
From Mathematical Stability to Cinematic Destruction
September 2026
Over the last few development cycles, RUSTWAKE has changed significantly. The work has not focused only on adding content: we have revisited fundamental systems such as balancing, Endless, the economy, environments, audiovisual feedback, and enemy destruction.
The goal remains the same:
> turn RUSTWAKE into an extremely polished indie game, with a visual and audio presence much closer to a premium production.
We are not there yet, especially when it comes to combat feedback, but the project’s structure is now much more solid than it was a few versions ago.
---
1. BALANCING AND ENDLESS
One of the biggest issues was the mathematical scaling of Endless mode.
The previous version kept increasing all of the following at the same time:
- enemy HP
- damage
- speed
- spawn density
- Director pressure
- boss power
The result was a progression that, once you reached hundreds or thousands of waves, became mathematically unmanageable.
The Endless system has therefore been redesigned using capped and asymptotic curves.
This allows difficulty to keep increasing without turning into absurd numbers or creating situations that are technically impossible to render.
Limits have also been introduced for:
- enemy density
- maximum speed
- minimum wave duration
- HP scaling
- damage scaling
- Director budget
- projectile load
The goal is not to make Endless easy.
The goal is to allow the game to theoretically reach:
500 / 1000 / 2000 / 5000 / 10000+ waves
without the formulas themselves being what “breaks” the run.
---
2. ECONOMY, SCRAP, AND RELICS
The economy has also been realigned with the new progression system.
Previously, some costs would practically stop increasing while difficulty continued to rise.
We revised:
- relic prices
- rerolls
- rewards
- Endless inflation
- the relationship between scrap income and increasing pressure
We also reviewed:
- components
- relics
- fusions
- pilots
- difficulty protocols
using statistical simulations across thousands of runs.
---
3. PROGRESSION BUGS
Several logic issues emerged during QA.
Among the main ones:
BRAWLER
The unlock condition required destroying structures that no longer normally existed in the arena in the modern version of the game.
The condition has been replaced with a requirement that can be achieved during normal gameplay.
Endless unlock
We fixed a case where dying during the final wave could cause unintended progression behavior.
Protocols
Some Industrial and Apex requirements were corrected so that they actually match the intended progression.
Bosses
Boss HP is now correctly linked to the difficulty protocol.
---
4. FIVE SECTORS — NEW ARENA BORDERS
One of the largest visual revisions has been the reconstruction of the arena perimeters.
The five sectors now each have their own identity:
SCRAP WASTES
Scrap, welded metal sheets, chains, scaffolding, and improvised structures.
INDUSTRIAL FOUNDRY
Heavy piping, machinery, furnaces, thermal energy, and extreme industry.
AUTONOMOUS NETWORK
Industrial servers, data nodes, relays, circuitry, and cyan lighting.
WAR MACHINE TERRITORY
Armor plating, bunkers, ammunition, military modules, and red warning signals.
MACHINE CORE
More advanced and symmetrical structures, reactors, cyan/purple energy, and architecture belonging to the machine civilization.
A total of 50 modules have been created, ten for each sector.
---
5. UNIFIED ART DIRECTION
After creating the five kits, we did a second pass to prevent them from looking like they had been produced at different times.
We standardized:
- visual wall thickness
- corner scale
- pylon scale
- ground contact
- glow
- light intensity
- readability relative to the player and enemies
The goal is to have five distinct locations that clearly belong to the same universe.
---
6. SECTOR ATMOSPHERE
We then added a first environmental pass.
Each sector now has its own signature:
Scrap Wastes
dust, sparks, and warm industrial lighting.
Foundry
steam, embers, and furnace glow.
Network
electronic haze, pulses, and cold lighting.
War Territory
ash, beacons, and tactical lighting.
Machine Core
energy motes, reactor pulses, and cyan/purple accents.
These effects were designed to stay behind the combat layer and avoid interfering with readability.
---
7. AUDIO — FIRST MAJOR REWORK
The old sound design turned out to be one of the weakest aspects of the project.
In particular:
- vehicle movement lacked impact
- gunfire did not have enough weight
- explosions felt too small
- the electric turret was not aggressive enough
- weapon categories lacked sufficient separation
We therefore began several experiments aimed at creating a heavier sound design.
New sounds have been produced for:
- kinetic
- plasma
- railgun
- missiles
- demolition
- thermal
- beam
- crusher
- smart weapons
- ballistic turret
- electric turret
- explosions
- movement
During this work, we also discovered major regressions, including an issue that prevented the game from launching.
This forced us to significantly improve our diagnostic process as well.
---
8. REGRESSIONS AND DEBUGGING
An important part of recent development has been learning from issues introduced during the reworks.
We encountered cases involving:
- a black window on startup
- Godot 3.5.3 parser errors
- reserved identifiers being used as variables
%operations incompatible betweenintandfloat- the graphics pipeline falling back to procedural fallbacks
- assets not loading correctly
- incomplete music rotation
These issues were identified using actual Godot diagnostic logs.
This also changed our development methodology:
> fewer assumptions, more runtime verification and real logs.
---
9. MUSIC
A regression affecting the soundtrack also emerged.
The music files were still present, but only some of the tracks were actually being added to the rotation.
The system was fixed to restore all 30 intended music tracks.
We also reduced the automatic ducking, which was lowering the music too aggressively during intense combat.
---
10. EXPLOSIONS — THE BIGGEST PROBLEM
This is probably the most important part of the dev log.
Despite several attempts, explosions continue to be the game’s main weakness.
We introduced:
- longer sequences
- fireballs
- smoke
- shockwaves
- secondary explosions
- camera shake
- hit-stop
- layered audio
but the result still has not reached the quality level we want.
The main problem was investing too much in the technical system and too little in the artistic quality of each individual asset.
In other words:
> more code does not automatically mean more spectacle.
---
11. CHASSIS DESTRUCTION
We therefore began working on a more physical enemy destruction system.
The system can eject:
- chassis parts
- panels
- body sections
- modules
- fragments
with:
- rotation
- independent velocity
- simulated height
- shadows
- falling
- bouncing
Technically, it works.
But during playtesting, another major issue emerged:
> the pieces still look too “cut out” and two-dimensional.
So here too, the next step will not simply be adding more fragments.
We need to create dedicated debris art.
---
12. NEW GOAL: HEAVY DESTRUCTION HERO PASS
The next major pass will focus on a single heavy enemy.
We no longer want to produce hundreds of mediocre assets at the same time.
First, we want to create one truly spectacular destruction sequence.
The test includes:
- pre-damage state
- internal flash
- chassis beginning to break apart
- main explosion
- cannon being ejected
- separated panels
- detached tracks/modules
- micro-debris
- secondary explosions
- heavy smoke
- embers
- wreckage
- scorch mark
- metallic impacts as pieces fall back down
If this single kill finally reaches the desired level, it will become the reference point for the rest of the roster.
---
13. NEW VFX PHILOSOPHY
The new goal is no longer:
> “how many frames do we have?”
or:
> “how many assets are there?”
The new criterion is much simpler:
Is it impressive?
Does it have weight?
Does the enemy actually look destroyed?
Is it satisfying to kill?
Is the quality consistent with the cover art?
If the answer is no, the effect is not finished.
---
14. UNITY MIGRATION EXPERIMENT
At the same time, I am beginning to test a possible migration of RUSTWAKE to Unity.
This does not mean that the migration has already been definitively decided.
The current project still runs on Godot 3.5.3, but the engine’s age and some limitations of the current pipeline are becoming increasingly apparent as we try to improve the game’s visual quality.
I am therefore experimenting with Unity to determine whether it can provide concrete advantages in terms of:
- particle systems
- VFX management
- 2D lighting
- shaders
- post-processing
- audio mixer
- debris management
- animations
- tooling
- profiling
- asset workflow
The purpose of the test is not simply to change engines because “Unity is more popular.”
The real question is:
> Can Unity make it easier for us to achieve the visual and audio quality we want for RUSTWAKE without compromising gameplay and performance?
If the answer is yes, we will consider a gradual migration.
If the answer is no, we will continue improving the current Godot implementation.
---
15. WHAT A MIGRATION WOULD MEAN
A potential migration would not automatically mean rebuilding everything from scratch.
A large portion of the work can be reused conceptually:
- Endless formulas
- economy
- component data
- enemy statistics
- pilots
- relics
- wave logic
- sector design
- graphical assets
- music
- sound design
- progression design
The parts that would primarily need to be rewritten are:
- rendering
- input
- runtime audio
- UI
- scene management
- runtime AI
- combat code
- pooling
- VFX
- save system
For this reason, the migration is being treated as a technical experiment, not an impulsive decision.
---
16. CURRENT PRIORITIES
The project’s immediate priorities are now:
1. Heavy Destruction Hero Pass 2. real debris art 3. better volumetric explosions 4. heavy destruction audio 5. enemy death animations 6. improved impact readability 7. Unity testing 8. Godot vs Unity performance comparison 9. defining the final pipeline 10. extending the new standard to the entire roster
---
17. WHERE RUSTWAKE STANDS TODAY
Today, RUSTWAKE has:
- a much more stable Endless system
- a redesigned economy
- five distinct sectors
- dedicated arena borders
- sector-specific atmosphere
- 30 music tracks
- an enemy roster
- pilots
- relics
- components
- fusions
- progression systems
- Endless mode
- early chassis destruction systems
- a much more robust QA pipeline than a few versions ago
But one fundamental element is still missing:
> combat needs to be more satisfying to watch and hear.
That is where we are focusing our work.
---
CONCLUSION
RUSTWAKE is entering a different phase of development.
The foundations are now advanced enough that the main problem is no longer simply “making the game work.”
Now the problem is:
> making it look, sound, and react like the game we truly want to build.
The next few weeks will focus mainly on combat feel, destruction, and audiovisual quality, while testing of a possible migration to Unity will continue in parallel.
I do not want to promise that the engine switch will happen.
I want to understand which pipeline will truly allow RUSTWAKE to reach the visual and technical level I am aiming for.