· Updated
BITS OVERLOAD — From Prototype to Release Candidate
By SRADRAVEN
BITS OVERLOAD — From Prototype to Release Candidate
When I started working on BITS OVERLOAD, the core idea was fairly simple: create a sci-fi card game where the real enemy wasn't just the opposing ship, but also a reactor that the player had to learn how to control.
From that idea, the project grew far more than I expected.
Today, BITS OVERLOAD has reached version 0.65.0, with a release candidate build intended for Steam, and looking back, it's interesting to see how much the game has changed without losing its original core.
The Heart of the Game: Taking Risks with the Reactor
Every battle revolves around two problems at the same time.
On one side, there's the fight against the enemy ship. On the other, there's the reactor, which must reach a specific target.
Cards allow you to attack, generate shields, repair the hull, modify the reactor, and use special effects. But what makes everything more interesting is the order in which they are played.
A combo can be perfect — or turn into an overload.
This pushed me to design the game not just around the question:
“What is the strongest card?”
but more importantly:
“In what order should I play what I have in my hand?”
Your hand is also persistent. Cards you don't use stay with you, meaning every turn also affects the next one.
Over time, the card pool expanded to include mechanics such as STEAL, SWAP, LOCK, SHIELD DISTORTION, DECK DRAW, positive and negative Reactor cards and, eventually, one very unusual card.
BITS
Sooner or later, the game needed a card that truly represented its name.
That's how BITS was born.
It's an extremely rare card, it can appear at most once during a run, and it works almost like a small event inside a battle.
It modifies the reactor, interferes with the enemy's hand, resets the opponent's shield, deals a large amount of damage, and activates BITS OVERCLOCK, temporarily making the other cards in your hand free to play.
The important part was making sure it didn't simply become an “I win” button.
Because of that, BITS' direct damage cannot defeat the enemy by itself, and the card doesn't automatically hand out a huge amount of points. It creates an absurdly powerful situation, but the player still has to know how to take advantage of it.
Making the Action Easy to Understand
One of the areas I've worked on the most isn't the rules themselves, but the way those rules are communicated.
In the early versions, the system worked — but simply working isn't enough.
If I play ATTACK, I want to see the action move toward the enemy.
If I play SHIELD or REPAIR, the effect should return toward my own ship.
If I modify the REACTOR, the card should move toward the central core.
That's where a long process of presentation work began: cockpit elements, side panels, the central core, card animations, impacts, pulses, screen shake, particles, glow, shield feedback, and reactor variations.
Victories also became a small sequence of their own.
When the reactor is stabilized, the SUPERNOVA begins, with flashes, particles, bonuses, and the transition to the next sector.
This was one of the most important stages of development: turning numbers and rules into something the player can actually feel.
From a Single Battle to a Galaxy
At some point, finishing a battle and simply loading another one was no longer enough.
That's how the Galactic Map was born.
After a victory, the ship leaves the completed sector, moves toward the next destination, and begins a hyperspace jump.
I added a full FTL sequence with a space tunnel, charging phase, jump, and exit.
Later, procedural worlds were added as well.
Planet and colony names are generated based on the run, producing destinations such as VORAX-7, ELYNTH PRIME, or AXION DELTA.
The idea behind the structure is that the galaxy is endless.
There is no predefined final sector.
The run continues for as long as the player can survive, while reactor targets, opponents, decks, planets, and other variables continue to recombine.
The question simply becomes:
how far can you go?
100 Ships and 18 Classes
Progression is another system that grew considerably during development.
The Hangar now contains 100 playable ships.
But I didn't want them to be nothing more than one hundred different images.
In the current version, ships belong to 18 classes, including Scout, Interceptor, Corvette, Raider, Frigate, Dreadnought, Corsair, Specter, Leviathan, Seraph, and others.
Each class introduces a small, controlled bonus.
For example, one class might start with additional shields, another might begin with an extra card in the opening hand, while another could reduce the first hull damage received.
I deliberately kept these bonuses small: the ship should slightly change the way you approach a battle, not become the difference between a possible run and an impossible one.
Progression also takes into account both performance and player dedication, tracking runs, distance reached, scores, ship usage, and achieved results.
And Then There's Lord SradRaven
Not everything in the galaxy could be predictable.
One of the more unusual events is Lord SradRaven, a rare rival who can appear during advanced runs.
He has a dedicated ship, far more HP than a normal opponent, his own audiovisual effects, and a series of taunts.
Most importantly, Lord SradRaven doesn't die permanently.
When defeated, he escapes.
And he can come back.
I wanted his appearance to feel less like “a stronger enemy has spawned” and more like an anomaly suddenly entering your run.
The Less Visible Part: Balancing Everything
The more BITS OVERLOAD grew, the harder it became to understand how much an apparently small change could affect the entire game.
Because of this, I also built internal balance simulation tools.
The release candidate uses simulations to compare different play behaviors, anomaly curves, ship classes, reactor combinations, and sector progression.
But one thing I've tried to keep in mind is that a simulation does not replace a player.
It can find statistical anomalies.
It can show that a difficulty curve seems too aggressive.
It can run hundreds of simulated runs.
But it can't tell me whether a defeat feels deserved or frustrating.
For that, playtesting is still essential.
The Bugs That Only Appear Once the Game Becomes Complicated
Working on RC16 also reminded me of a fairly universal rule of game development:
the most interesting interactions are often the same ones that break everything.
For example, during a combo it was possible to destroy an enemy ship while simultaneously triggering an overload. The game needed a clear rule for which event should actually take priority.
In another case, a 5,000-point jackpot earned on the final hit could be lost during the post-battle transition.
And then there was the BITS + SWAP combination: because BITS temporarily makes the cards in your hand free, swapping hands at the wrong moment could literally allow the AI to inherit those zero-cost cards.
These are very small problems to describe, but they're exactly the kind of problems that start appearing once many systems finally begin interacting with one another.
RC16 has mainly been about this: fewer new features, and more work to make sure everything that already exists always follows the same rules.
Audio, Localization, and Polish
Meanwhile, the project also received an original sci-fi soundtrack, with different music for menus and exploration versus combat, crossfade transitions, and a dedicated layer for encounters with Lord SradRaven.
The interface has gradually been rebuilt and cleaned up, eventually becoming the current battle cockpit.
BITS OVERLOAD also supports 15 languages, meaning menus, HUD elements, cards, tutorials, guides, and many dynamic texts had to be designed with very different string lengths and structures in mind.
These are all things that initially seem secondary.
Then you reach the point where you realize that these details are exactly what separates a prototype from something that feels like a finished game.
Where the Project Is Now
BITS OVERLOAD is currently at version 0.65.0, developed with Godot 3.5.3, and RC16 represents the closest the project has come so far to a public Steam build.
The game now includes card-based combat, reactor management, combos, AI, progression, 100 ships, 18 classes, anomalies, procedural worlds, an endless galaxy, maps, hyperspace, statistics, medals, special events, music, and localization.
But the part I find most interesting is that the core is still the same as it was at the beginning:
you have a few cards in your hand, a reactor that's getting out of control, and you have to decide how much you're willing to risk.
Now, the most important work is continuing to test, refine the balance, and find all those absurd edge cases that only a real player can create.
Because if developing BITS OVERLOAD has taught me anything, it's that the moment you think you've accounted for every possible combination…
someone plays BITS, then SWAP, then STEAL.
When I started working on BITS OVERLOAD, the core idea was fairly simple: create a sci-fi card game where the real enemy wasn't just the opposing ship, but also a reactor that the player had to learn how to control.
From that idea, the project grew far more than I expected.
Today, BITS OVERLOAD has reached version 0.65.0, with a release candidate build intended for Steam, and looking back, it's interesting to see how much the game has changed without losing its original core.
The Heart of the Game: Taking Risks with the Reactor
Every battle revolves around two problems at the same time.
On one side, there's the fight against the enemy ship. On the other, there's the reactor, which must reach a specific target.
Cards allow you to attack, generate shields, repair the hull, modify the reactor, and use special effects. But what makes everything more interesting is the order in which they are played.
A combo can be perfect — or turn into an overload.
This pushed me to design the game not just around the question:
“What is the strongest card?”
but more importantly:
“In what order should I play what I have in my hand?”
Your hand is also persistent. Cards you don't use stay with you, meaning every turn also affects the next one.
Over time, the card pool expanded to include mechanics such as STEAL, SWAP, LOCK, SHIELD DISTORTION, DECK DRAW, positive and negative Reactor cards and, eventually, one very unusual card.
BITS
Sooner or later, the game needed a card that truly represented its name.
That's how BITS was born.
It's an extremely rare card, it can appear at most once during a run, and it works almost like a small event inside a battle.
It modifies the reactor, interferes with the enemy's hand, resets the opponent's shield, deals a large amount of damage, and activates BITS OVERCLOCK, temporarily making the other cards in your hand free to play.
The important part was making sure it didn't simply become an “I win” button.
Because of that, BITS' direct damage cannot defeat the enemy by itself, and the card doesn't automatically hand out a huge amount of points. It creates an absurdly powerful situation, but the player still has to know how to take advantage of it.
Making the Action Easy to Understand
One of the areas I've worked on the most isn't the rules themselves, but the way those rules are communicated.
In the early versions, the system worked — but simply working isn't enough.
If I play ATTACK, I want to see the action move toward the enemy.
If I play SHIELD or REPAIR, the effect should return toward my own ship.
If I modify the REACTOR, the card should move toward the central core.
That's where a long process of presentation work began: cockpit elements, side panels, the central core, card animations, impacts, pulses, screen shake, particles, glow, shield feedback, and reactor variations.
Victories also became a small sequence of their own.
When the reactor is stabilized, the SUPERNOVA begins, with flashes, particles, bonuses, and the transition to the next sector.
This was one of the most important stages of development: turning numbers and rules into something the player can actually feel.
From a Single Battle to a Galaxy
At some point, finishing a battle and simply loading another one was no longer enough.
That's how the Galactic Map was born.
After a victory, the ship leaves the completed sector, moves toward the next destination, and begins a hyperspace jump.
I added a full FTL sequence with a space tunnel, charging phase, jump, and exit.
Later, procedural worlds were added as well.
Planet and colony names are generated based on the run, producing destinations such as VORAX-7, ELYNTH PRIME, or AXION DELTA.
The idea behind the structure is that the galaxy is endless.
There is no predefined final sector.
The run continues for as long as the player can survive, while reactor targets, opponents, decks, planets, and other variables continue to recombine.
The question simply becomes:
how far can you go?
100 Ships and 18 Classes
Progression is another system that grew considerably during development.
The Hangar now contains 100 playable ships.
But I didn't want them to be nothing more than one hundred different images.
In the current version, ships belong to 18 classes, including Scout, Interceptor, Corvette, Raider, Frigate, Dreadnought, Corsair, Specter, Leviathan, Seraph, and others.
Each class introduces a small, controlled bonus.
For example, one class might start with additional shields, another might begin with an extra card in the opening hand, while another could reduce the first hull damage received.
I deliberately kept these bonuses small: the ship should slightly change the way you approach a battle, not become the difference between a possible run and an impossible one.
Progression also takes into account both performance and player dedication, tracking runs, distance reached, scores, ship usage, and achieved results.
And Then There's Lord SradRaven
Not everything in the galaxy could be predictable.
One of the more unusual events is Lord SradRaven, a rare rival who can appear during advanced runs.
He has a dedicated ship, far more HP than a normal opponent, his own audiovisual effects, and a series of taunts.
Most importantly, Lord SradRaven doesn't die permanently.
When defeated, he escapes.
And he can come back.
I wanted his appearance to feel less like “a stronger enemy has spawned” and more like an anomaly suddenly entering your run.
The Less Visible Part: Balancing Everything
The more BITS OVERLOAD grew, the harder it became to understand how much an apparently small change could affect the entire game.
Because of this, I also built internal balance simulation tools.
The release candidate uses simulations to compare different play behaviors, anomaly curves, ship classes, reactor combinations, and sector progression.
But one thing I've tried to keep in mind is that a simulation does not replace a player.
It can find statistical anomalies.
It can show that a difficulty curve seems too aggressive.
It can run hundreds of simulated runs.
But it can't tell me whether a defeat feels deserved or frustrating.
For that, playtesting is still essential.
The Bugs That Only Appear Once the Game Becomes Complicated
Working on RC16 also reminded me of a fairly universal rule of game development:
the most interesting interactions are often the same ones that break everything.
For example, during a combo it was possible to destroy an enemy ship while simultaneously triggering an overload. The game needed a clear rule for which event should actually take priority.
In another case, a 5,000-point jackpot earned on the final hit could be lost during the post-battle transition.
And then there was the BITS + SWAP combination: because BITS temporarily makes the cards in your hand free, swapping hands at the wrong moment could literally allow the AI to inherit those zero-cost cards.
These are very small problems to describe, but they're exactly the kind of problems that start appearing once many systems finally begin interacting with one another.
RC16 has mainly been about this: fewer new features, and more work to make sure everything that already exists always follows the same rules.
Audio, Localization, and Polish
Meanwhile, the project also received an original sci-fi soundtrack, with different music for menus and exploration versus combat, crossfade transitions, and a dedicated layer for encounters with Lord SradRaven.
The interface has gradually been rebuilt and cleaned up, eventually becoming the current battle cockpit.
BITS OVERLOAD also supports 15 languages, meaning menus, HUD elements, cards, tutorials, guides, and many dynamic texts had to be designed with very different string lengths and structures in mind.
These are all things that initially seem secondary.
Then you reach the point where you realize that these details are exactly what separates a prototype from something that feels like a finished game.
Where the Project Is Now
BITS OVERLOAD is currently at version 0.65.0, developed with Godot 3.5.3, and RC16 represents the closest the project has come so far to a public Steam build.
The game now includes card-based combat, reactor management, combos, AI, progression, 100 ships, 18 classes, anomalies, procedural worlds, an endless galaxy, maps, hyperspace, statistics, medals, special events, music, and localization.
But the part I find most interesting is that the core is still the same as it was at the beginning:
you have a few cards in your hand, a reactor that's getting out of control, and you have to decide how much you're willing to risk.
Now, the most important work is continuing to test, refine the balance, and find all those absurd edge cases that only a real player can create.
Because if developing BITS OVERLOAD has taught me anything, it's that the moment you think you've accounted for every possible combination…
someone plays BITS, then SWAP, then STEAL.