A lot of games make sweeping changes like we’re going to talk about and describe them as “stability improvements” or “quality of life updates,” but what we want players to understand is that we are currently in the middle of the biggest overhaul Rankbreaker has gone through to date. This is not a redesign of the menus or interface layers. It is a complete reconstruction of the underlying gameplay engine that drives card abilities, location effects, match flow, and gameplay resolution itself. Most players will never directly see the engine itself, but they will feel the difference through improved interaction consistency, cleaner gameplay resolution, stronger long-term stability, and the ability for the game to continue expanding without becoming increasingly fragile over time.
So what is the overhaul we’re making?
We’ll try to keep this as jargon-free as possible, but in order to explain the refactor properly, we first need to explain how Rankbreaker was originally built, why that approach worked, why we are changing it now, and what the new structure is designed to accomplish. The process is extremely large because it touches most of the gameplay systems in the project. At this point the game contains over 100 card effects, nearly 32 location effects, multiple game modes, and a huge number of interactions between all of them. This overhaul affects not only individual abilities, but also the way the match itself understands and resolves gameplay.
At the center of all of this is the game engine.
A useful way to think about the engine is as a combination of a referee, rules judge, and traffic controller for the entire match. Every gameplay action passes through the engine so the game can determine what should happen, in what order it should happen, and what other systems need to react to it afterward. The engine maintains the authoritative game state and ensures that interactions resolve consistently. Without a centralized engine, gameplay systems often end up handling their own logic independently. That can work extremely well early in development because it allows features to be built quickly and individually. But as a game becomes more complex, interactions begin overlapping in increasingly unpredictable ways. An engine creates a shared rules framework that allows the game to scale while remaining understandable, maintainable, and consistent.
how did the game work before?
Before the refactor, Rankbreaker was built in a much more localized and direct way. Individual cards, locations, and gameplay systems were often responsible for handling their own mechanics from start to finish. If a card needed to destroy another card, apply a buff, block a location, react to movement, or trigger a follow-up effect, that specific script would usually perform the entire sequence itself. In practice, this worked very well for building the game quickly. It allowed new cards and mechanics to be implemented independently without needing to rebuild large systems every time a new idea was introduced. That flexibility is one of the main reasons the game was able to grow as rapidly as it did.
The downside only started appearing as the project became larger and more interconnected.
As more mechanics were added, the same types of gameplay behaviors began appearing across many different scripts. Multiple cards might each contain their own version of destruction handling, movement reactions, ongoing buffs, or play restrictions. Instead of one centralized system interpreting those mechanics universally, many scripts carried their own individual understanding of how those mechanics should behave. Over time, that created a situation where gameplay rules became scattered across dozens or even hundreds of separate files. A small change to a shared mechanic could require updates in many unrelated places because the logic was duplicated or tightly coupled to specific abilities. Certain effects also became dependent on individual managers, event subscriptions, or scene objects existing in exactly the correct configuration. As interactions continued growing, guaranteeing that every card and location behaved consistently under edge cases became increasingly difficult.
The game itself absolutely worked, and successfully so. The beta, the live playtests, the large amount of content already implemented, and the stability we achieved up to this point are proof of that. But much of the gameplay complexity lived inside the individual content scripts themselves rather than inside a unified gameplay rules layer. The refactor is fundamentally about moving the responsibility for interpreting and resolving gameplay interactions away from isolated scripts and into a centralized engine designed specifically to manage those interactions consistently.
Where are we moving to?
The overhaul moves the game toward a system where cards no longer directly control the match themselves. Instead of every card individually deciding how to mutate the board, apply buffs, destroy targets, or react to future events, cards now make requests to a centralized gameplay engine that processes those actions according to a shared rules pipeline. A simple way to think about it is that cards are becoming instructions, while the engine becomes the authority responsible for carrying those instructions out.
Previously, a card might effectively say:
“I will destroy this target, update the board, trigger reactions, and manage everything myself.”Under the new structure, the card instead says:
“I want this target destroyed.”
The engine then becomes responsible for processing that request, determining how the destruction resolves, triggering all appropriate reactions, updating the match state, and ensuring that every related system responds in the correct order. That separation is extremely important because it divides gameplay into two distinct responsibilities. Cards define what they want to happen. The engine defines how gameplay actually resolves.
This creates a much more predictable and scalable architecture because interactions no longer depend on dozens of unrelated scripts independently mutating the game state at different times. Another major part of the refactor involves ongoing and reactive gameplay behavior. Previously, a card with a persistent effect might track its own state, subscribe directly to future events, manage timers or listeners, and handle its own reactions internally. Under the new structure, those long-term behaviors are being moved into reusable engine-level systems that operate as part of the match simulation itself. The card effectively registers its gameplay behavior with the engine, and the engine becomes responsible for maintaining and evaluating that behavior afterward.
The overall goal is to make the game behave less like hundreds of isolated scripts interacting independently, and more like a coordinated gameplay simulation where every action flows through the same authoritative rules pipeline. That makes the game easier to expand, easier to debug, easier to balance, and far more capable of supporting complicated interactions without constantly rewriting older systems every time new mechanics are introduced.
But the overhaul it if the game was already working?
The answer is scalability.
The original structure worked well at the scale we originally needed because it prioritized speed, flexibility, and rapid feature implementation. That approach allowed the game to grow from an early prototype into a fully playable beta with a massive amount of content already functioning successfully. The problem is not whether the game works today. The problem is what happens as the game continues growing over the next several years.
As more cards, locations, mechanics, and interactions are introduced, systems built around localized gameplay handling become increasingly difficult to maintain. Small changes begin affecting large numbers of unrelated scripts. Shared mechanics start existing in multiple places simultaneously. Edge cases become harder to reason about because gameplay authority is spread across dozens of independent systems rather than flowing through one consistent rules layer. At a certain scale, development slowly shifts from “building new features” into “patching around old complexity.”
The refactor is designed to prevent that from happening. By centralizing gameplay resolution inside the engine, new content can build on shared systems instead of recreating the same mechanics repeatedly in isolated ways. It reduces hidden complexity throughout the project and allows gameplay rules to exist in one authoritative location rather than many loosely connected implementations. That matters enormously for a content-heavy game like Rankbreaker. The larger the game becomes, the more valuable predictability and consistency become. A centralized engine structure makes it easier to test interactions, reproduce bugs, balance gameplay, introduce new mechanics, and reason about how systems behave under unusual conditions.
More importantly, it changes development from constantly patching individual cases into building reusable gameplay systems. That is what allows a live-service style card game to continue expanding over years without every new mechanic becoming exponentially harder to implement than the last.
Trying to move toward full deterministic gameplay
One of the largest goals of the refactor is moving the game toward full deterministic gameplay. Deterministic gameplay means that the game always produces the exact same result when given the exact same inputs and starting state. If two matches begin from the same situation and the same actions are taken in the same order, the outcome should always be identical every single time. For a card game, that consistency is incredibly important.
Players need to trust that gameplay rules resolve predictably, especially in a game where dozens of effects may be interacting simultaneously. Deterministic systems also make debugging dramatically easier because developers can reliably reproduce issues instead of chasing bugs that only appear under extremely specific timing conditions. Before the refactor, the game was already partially deterministic in practice. Most gameplay interactions already followed structured rules, and many systems resolved consistently enough to support live playtesting, complex card interactions, and large amounts of functioning content. That foundation is one of the reasons this refactor is even possible now.
However, parts of the older architecture still relied heavily on localized script behavior, direct state mutations, independently managed event timing, and isolated gameplay reactions. In many cases, individual scripts were not only requesting gameplay changes, but immediately applying those changes themselves. As the project expanded, that introduced situations where outcomes could depend on execution order, event timing, or overlapping side effects spread across multiple systems.
The refactor moves the game closer to full determinism by centralizing how gameplay mutations are processed. Instead of scripts directly changing the game state whenever they choose, gameplay actions are routed through a unified engine that resolves requests in a controlled and predictable order. Effects no longer independently manipulate the board in isolation. They submit requests into a shared gameplay pipeline that interprets and applies those actions consistently. That distinction is extremely important.
When every gameplay mutation flows through the same system, the engine always knows what caused a change, when it happened, and what other effects should react to it. The match becomes a single authoritative sequence of gameplay events rather than dozens of isolated scripts all attempting to manage the simulation independently.
The value of that goes far beyond cleaner code. Deterministic systems improve replay accuracy, synchronization, debugging, AI testing, balancing, spectating, competitive integrity, and future multiplayer reliability. In many ways, the game was already naturally evolving toward these patterns over time. The refactor is about formalizing that structure so the engine itself becomes the authoritative source of gameplay truth instead of relying on a large network of loosely coordinated scripts.
Advancing the multiplayer side of the game
One of the biggest long-term advantages of deterministic gameplay is that it opens the door to a networking model called lockstep multiplayer. In many online games, the server constantly sends large amounts of information between players in order to keep the match synchronized. Positions, animations, damage values, status effects, gameplay updates, and countless other changes are continuously transmitted across the network.
Lockstep multiplayer works very differently. Instead of constantly sending the full game state back and forth, both players run the exact same gameplay simulation locally on their own machines. The only thing that actually needs to be exchanged is the player input itself, such as:
“Play this card in this lane.” or “End the turn.”
Because the game is deterministic, both clients independently arrive at the exact same outcome from those inputs. If the simulation remains perfectly synchronized, the match effectively plays out identically on both sides without needing to constantly transmit every individual gameplay interaction across the internet. That is only possible if the engine resolves gameplay in a perfectly consistent and predictable way.
If one client processes effects in a slightly different order, or if hidden script behavior creates different outcomes under the same conditions, the two simulations begin drifting apart. Once that happens, multiplayer synchronization breaks. The older structure of Rankbreaker was already moving toward consistency organically, but too much gameplay authority was still spread across isolated scripts and localized systems. As interactions continued growing, guaranteeing exact synchronization between multiple clients would become increasingly difficult because too many systems were independently managing gameplay behavior.
The refactor helps solve that problem by creating a single authoritative gameplay pipeline. Actions are no longer resolved ad hoc by unrelated scripts operating independently. Instead, gameplay flows through a centralized engine that processes requests in a structured and deterministic order. In practical terms, the game is evolving from “a collection of scripts that successfully produce gameplay” into “a formalized gameplay simulation.”
That distinction matters enormously for advanced networking, replay systems, spectating, competitive integrity, AI systems, and long-term scalability. Even if lockstep multiplayer is not implemented immediately, building the engine around deterministic principles now creates the foundation necessary to support those systems later. It is dramatically easier to design for synchronization early than it is to retrofit deterministic networking into a large and highly reactive game years after the content complexity has already exploded.
What this means for the current build
Because this refactor touches such a large portion of the game’s core systems, the refactor branch itself has effectively become the active development branch until the migration is complete and fully validated.That does not mean content releases are stopping.
The current stable build already has scheduled content and staged releases built into it, so players will still continue receiving those planned updates during the refactor process. However, large-scale gameplay fixes and systemic changes are currently being directed into the new engine branch rather than repeatedly patched into the older architecture while it is actively being replaced. In practical terms, this means some reported bugs may not receive immediate hotfixes in the current live build if those systems are already being rebuilt as part of the refactor. Instead, many of those fixes are being resolved directly inside the new engine structure that will eventually replace the current gameplay framework entirely.
That said, bug reports and gameplay feedback are still extremely important during this period. We still need issues reported through the Discord server because those reports help identify gameplay edge cases, interaction problems, unclear behaviors, and systems that need additional validation before the refactor branch becomes the new live foundation of the game. The goal here is not to pause development, but to avoid spending large amounts of time repeatedly patching systems that are already in the middle of being fundamentally rebuilt. The refactor is ultimately about making the gameplay pipeline significantly easier to maintain long-term so future content, balance updates, and gameplay systems can be developed more reliably and with far less technical overhead.