Hello Riftbreakers!
In game development, almost everything starts as a placeholder. When we look back at the early days of The Riftbreaker, many systems, mechanics, and assets barely resemble what you are playing today. Ideas were tested, broken, reworked, or scrapped entirely. That is normal. Game development is a dynamic process. Almost nothing is good enough on the first attempt, which is why openness to feedback and iteration are key to achieving good results. However, some things surprised us. Some ideas worked almost immediately. They survived prototypes, demos, public playtests, and years of post-launch development. They stood the test of time so well that we barely had to touch them. Today, we want to share a few examples of design decisions and systems that remained largely unchanged from the earliest versions of The Riftbreaker - and why.
There is something hilarious about seeing footage from the prototype, especially when it's proudly proclaiming it's "Riftbreaker Gameplay". It all has to start somewhere!
When Initial Numbers Become the Foundation
Let’s start with something deceptively simple: the early economy. When we began prototyping The Riftbreaker, we worked toward a milestone we called First Playable. It was never meant to be a full game - just a rough proof of concept. The goal was to test basic controls, combat, building, and resource gathering. At that stage, we needed only a handful of buildings:
- Headquarters
- Basic power generation (wind turbines and solar panels)
- A simple defensive tower
- Carbonium and Ironium factories
When creating the first gameplay prototypes, we usually mix old and new assets. It creates hilarious combinations, like Zombie Driver zombie dogs attacking the Riftbreaker Headquarters. Also: lol at 'Headquarters destroyed. You've lost :(". By the way - almost all of the buildings listed above are already present in this clip!
We had no long-term economy model - we knew that it would all change anyway as we added more elements to the game. So we did what many developers do at this stage: we picked numbers that felt right based on the following:
- We wanted the player to constantly see a stream of resource lumps while drilling. Spawning 5 pieces per second seemed to work just fine.
- On the basis of drilling 5 resources per second, we decided that the Carbonium Factory should cost 10 seconds of “manual labor”: 50 Carbonium.
- Ironium Factory cost was also set at 50 Carbonium.
- Headquarters cost: deliberately set slightly above what the mech starts with, so that you learn about digging resources with your mech. On a side note: it is also a clever way of giving you something to do while dialogues happen!
Sometimes, we don't even have placeholder assets that would fit, so we use colorful cubes to represent enemies. Here's the first-ever full-scale Tropical Zone attack, complete with zombie dogs standing in for Canoptrix, blue cubes as Arachnoids, and Orange cubes as Hammeroceroses. Less than perfect working conditions. This is exactly why we want to have some kind of placeholder assets, even if they are going to be decommissioned somewhere down the road.
As development continued - from First Playable, to internal builds, to the public demo shown at trade shows in 2019, these numbers remained the same. They became an anchor point for the game's entire economic structure. Other buildings changed in cost and function, as new systems were layered on top. But the core values for those first couple of buildings remained untouched. Even though it was largely a shot in the dark, deliberate design by numbers turned out to be good enough in the long run.
Assets That Outlived the Project They Were Made For
Early in development, we assume that most assets will eventually be replaced. This applies to visuals and audio alike. Every new project is an opportunity to expand and improve our engine. Early assets are created before we fully understand the potential of new rendering features, lighting systems, or audio pipelines. With experience, we can often achieve better results with less effort. Because of this, we are careful not to get too attached to early assets.
The effect for the nuke explosion is one of the assets that aged fairly well, even though it has come a long way. It was first created with the X-Morph: Defense Germany level boss fight in mind, but ended up never being used. It found its permanent home years later in The Riftbreaker..
Sound design is a great example. Sound is critical for player feedback. Playing without audio feels like losing a sense - because you do. But recording original sounds is expensive, time-consuming, and technically demanding. Equipment, space, experience, planning - it all adds up quickly. As an indie studio, we took a practical approach. We already had a large library of sounds from previous projects: D.I.P.R.I.P., Zombie Driver, and X-Morph: Defense. So we started by mixing and matching what we already had.
...and here's an example of an asset that wasn't made for The Riftbreaker, was used as a placeholder, and turned out to work just fine with minimum tweaking: the railgun shot effect. It traces back all the way to Zombie Driver!
Later, when we contracted composer Marcin Pukaluk to create the soundtrack for The Riftbreaker, we also asked him if he would like to also help us out with some sound design. He agreed to work with us, and together, we began looking for new samples to replace the ones we had scraped together earlier. However, even during this process, not all samples ended up being replaced. Among others, the sounds for explosions, artillery fire, and a couple of weapons remained unchanged. However, the oldest survivor is the repair sound. Every time Mr. Riggs repairs himself or a building, you hear a distinct mechanical buzzing. That sound comes from D.I.P.R.I.P., and it is nearly 20 years old. We never planned for it to last this long, but it simply fit better than anything else. No reason to change it if it works!
Dynamic Objective Manager: Controlled Chaos
You already know we don’t get attached to assets early on. The same is true for entire game systems. Designing them in a vacuum can be very hit-or-miss. A system that works well on paper might be impossible to implement, or simply not fun. Still - some of them are hits! One of the most important systems in The Riftbreaker is the Dynamic Objective Manager, or DOM. This system runs constantly in the background, dynamically generating side missions and events. Its purpose is simple: make each playthrough feel different.
Even though there is still a lot of old stuff in this scene, there are plenty of elements that remained intact over the years! We're glad the 2x2 walls with a raised floor did not make the cut.
We did not want to plan every minute of gameplay. Random attack waves, creature nests appearing on the map, environmental disasters like hailstorms - all of these are triggered by the DOM. It continuously evaluates a mission’s state:
- Are there any major events triggered at the moment?
- Are there any side objectives active at the moment?
- Which difficulty state is the current mission running at?
- How much time has passed since the last event?
Based on this information, the system adjusts its behavior. If you are idle at your base with no active objectives, the DOM may push a side objective - investigating an unusual creature or an anomaly. If enough time has passed since the last attack, it may warn you about an incoming enemy horde. The key is uncertainty. You cannot fully predict what will happen next. The world feels reactive, alive, and slightly hostile - exactly what we wanted. The surprising part is that the core logic behind the DOM has remained largely unchanged since its initial implementation. When an idea is solid, polishing it is often enough.
Click to zoom in. The schematic we used as a blueprint for creating the flow of the entire Story Campaign. It remains largely unchanged until today - if you don't count all the expansions, of course!
The overall structure of The Riftbreaker’s story campaign is another example. Once we understood which biomes, resources, and buildings would be available to players, we created a schematic of all major objectives required to finish the game. This included mission dependencies and progression milestones leading to the finale. While some individual missions changed, and a few ideas didn’t work out as planned, the foundation remained stable. That same foundation allowed us to expand the game through DLCs and endgame updates. With better tools and a deeper understanding of our own systems, we later designed more complex campaign structures.
When Good Ideas Don’t Need Reinvention
Looking back, these examples all point to the same conclusion. Not every part of game development needs endless iteration. Sometimes, a good idea just needs room to grow. Economy values chosen on instinct, sounds borrowed from decades-old projects, systems designed early and refined instead of replaced - They all became permanent parts of The Riftbreaker.
Watch on YouTube
A lot has changed, but a lot has stayed the same. Which elements do you recognize?
Thank you for joining us for this short retrospective. Next time, we will begin previewing World Expansion IV, which is getting closer every day. Keep an eye out for upcoming updates, patch notes, and announcements.If you want to stay up to date with everything related to The Riftbreaker, consider joining our Discord server or subscribing to our newsletter.
We hope to see you next time.
EXOR Studios