After the release of World Expansion III for The Riftbreaker and the Heart of the Swamp DLC, we got to work on the Endgame update. It is going to be extensive - so extensive, in fact, that we have started referring to it as The Riftbreaker 2.0. This update allows us to implement what we learned over the years to improve the game. A lot of these changes are going to be functional, but there are still other areas where we can improve. One such area is the design of boss creatures, which did not stand out from the crowd. We have already talked about the functional changes and the new features we intend to give our boss creatures. Today, however, we will focus on the visual aspect. Our artists have been working on making these creatures extra special. Let’s see how they’re doing.
We have been using regular creature models as a base for our boss system prototypes. They work fine for our use case, but they can always be better. This is why we decided to give our bosses a rework.
Up to this point, the boss creatures in The Riftbreaker appeared sporadically during randomized side objectives. They could also be met as Bioanomaly “guardians,” spawning around the battlefield in certain biomes after activating a Bioanomaly. Additionally, Survival players could meet them on the highest difficulty levels during the final attack waves. Initially, we planned to have way more variety among our bosses, but due to time constraints, we couldn’t see all our plans to completion. This also means that in most cases, our “boss” variants are simply scaled-up ultra strains of Galatean creatures with a special texture, which is also one of the reasons why we didn’t show them off more often.
Adding special abilities like the Necrodon's resurrection and creature spawning worked well gameplay-wise, but we wanted more.
On top of all that, we didn’t have a real name for them. Sometimes, we referred to them as elites; other times, they were bosses or guardians. This changes today. Our most powerful creatures are the Omega strain. As we described in one of our previous articles, the Omega strain will receive a functional overhaul, receiving a set of abilities that will make them stand out against the crowd. The frequency of their attacks will also increase, both in Campaign and Survival modes, giving you an opportunity to test your skills, equipment, and the defensive setup of your base. Get ready for a new level of challenge!
The Arachnoid Boss was larger and looked more menacing than its regular counterpart. We wanted to emulate that for other creatures as well.
Previously, only the Arachnoid Boss got a different model for its boss variant. If you compare the Ultra strain to the boss creature, you can see distinctive differences in the body shape. The boss’ head is adorned with large horns, making you feel that it is the leader of the swarm. The creature’s body is also protected by layers of thick carapace, which breaks off piece by piece as you fight the boss. We decided to give similar treatment to the new Omegas we are working on, following a couple of rules. Each Omega will have unique features that set them apart from regular creatures, making them instantly recognizable.
The creature's anatomy must remain relatively the same—no extra limbs or chainsaws sticking out of the forehead. This allows us to use the same skeleton for animation purposes and saves us days of additional work.
No simple re-coloring. The Omega must be recognizable next to a regular creature, even if it were the same size. Adding features like spikes, horns, or protruding flesh is the way to go.
Since we wanted to create an Omega variant for every major damage type in the game, the designers were also requested to prepare elemental versions for each creature. There are a couple of individual exceptions.
Optional—if possible, don’t work on models you originally created. Switching models between artists provides a fresh look and innovative ideas.
This set of preliminary constraints ensured that the end result would align with the game designers’ vision for the intended use of these creatures.
The first step in our workflow is sculpting a draft version of the model. We call it a blockout. It is not made literally from blocks but uses simple shapes to convey the general direction the artist wants to follow. Artists don’t spend any time adding details since blockouts are meant to be discarded or used as a base for the final model at best. This time, however, our artists didn’t have to start from scratch and used the existing models as their canvas. This allowed them to save a lot of time and start with the improvements right away.
This is the proposed idea for the Krocoon Omega strain. Its armor features much more aggressive styling. Additionally, you can see strange, flesh-like corruption taking hold of its body.
Krocoon Omega on the right, compared to the regular version on the left. We were happy with the differences between them, so we moved on to texturing.
The first textured version of the Omega. Our artist suggested giving the entire body a red tint, but we felt that it sugggested that the creature's body is made of flesh. It is not. The flesh growing on the Krocoon is an intruder, and we wanted that to be clearly visible. We made the decision to stick with the original color.
The final version of the Krocoon Omega. Clearly distinct from the original, but at the same time it is unmistakably still a Krocoon. This is precisely what we were aiming for.
Our graphics designers decided to try to focus on one aspect of the creature’s physique they would change. This way, they could make the new models instantly recognizable and resist the urge to let the creativity flow and remodel the creature entirely. Pictured below are a couple of blockouts from this process. We use these pictures for the initial round of feedback within our team. When everyone is happy with the general idea, the artist can move on and breathe life into the creature by creating a detailed, high-poly model.
Now let's compare the regular Phirian and its Omega counterpart. In this comparison the scale of the models is the same, which is not accurate, but enough for preview purposes. The changes in the body and armor are highlighted with a different color material.
The first version of the texture. Taking inspiration from the color palette of the Fungal Swamp biome, the Phirian Omega is rocking a neon-pink mohawk. Since the creature also appears in other biomes, we decided it was not the best choice and asked for a less flashy version.
This is the version we landed on for the baseline Phirian Omega. The yellow tint still screams 'danger,' but the creature can now blend with the environment of other biomes much easier.
The full family of Phirian Omegas. Please take note that these are just the creature models with their textures. The elemental versions will have some additional particle effects attached.
After the initial blockouts had been approved and turned into detailed sculpts, it was time to create the new textures. As mentioned previously, we wanted each Omega to appear in several flavors. The first would be the baseline variant. These creatures do not get any additional damage resistances that need to be highlighted, which leaves room to showcase their individual quirks and features. Stregaros became a brain-crab-demon that would fit without any issues on the Doom Slayer’s victim list. Krocoon started showing some fleshy parasitic growth on top of its metallic body. Phirian leveled up and got an epic hand blade and armor.
A personal favorite of mine - a very smart Stregaros Omega. Because more brain = more smart, obviously!
The last step was creating additional texture variants for the elemental version of these creatures. Some of our Omegas gain protection from one of the damage types present in The Riftbreaker. We wanted you to be able to tell which resistance type the creature got in an instant. For that reason, the elemental variants feature significant amounts of emissive textures, which are really easy to spot. Apart from that, we made sure to add details that align with the creature’s “home” element. The ones with protection from fire damage are singed and covered with ash. Cryo-resistant creatures look as if their body parts were made out of ice. Acid Omegas seem to be dripping poison everywhere they go. This attention to detail is what makes the difference between a reskin and a rework.
Nerilian Omegas of various flavors at the bottom, with the regular, Alpha and Ultra variants at the top for comparison. We're very happy with how this creature turned out!
Improved Omega-class creatures will make their way into the base game, along with our endgame expansion, where they will play a significant role in the combat challenge. Get ready - they won’t be easy to defeat!
Some new Omega variants are already in the game. Others will join them very soon.
As much as we would love to continue discussing the exciting process of the Co-Op mode development, it is not the only thing on our plates now. We are introducing many changes to the game, most of which will benefit both the single-player and multiplayer game modes. These changes include improvements in the mission design, various objectives, balancing changes, and quality-of-life tweaks. Today, we want to show off some elements we are reworking and expanding alongside the co-op mode development. Many of these features have been planned for quite a while - and it is finally time to make them a reality.
Not a day goes by without at least one playtesting session. We're making sure that we test all scenarios - 2, 3 or 4 players. It's tempting to always go max on the player count, but in reality, we know that this is going to be the rarest case.
Our multiplayer testing has revealed areas where the game could use a bit more functionality. Take the minimap, for instance. Currently, it's only useful for spotting enemies and unexcavated resources. But we believe it can do so much more. During our co-op runs, we often find ourselves asking, ‘Have you built X already?’ This is something we can easily convey through the minimap. We're planning to assign icons to critical buildings and resources, so you can keep track of your base's status with just a glance at the minimap. If you prefer a simpler map, we'll also provide filtering options to filter the displayed items. And this is just one of the many upgrades we have in store for you.
CLICK TO ENLARGE! This is the work-in-progress mockup of the minimap we came up with. It features toggleable filtering options on the left, more icons for the most important game elements on the map itself, as well as a symbols legend on the right. This is going to evolve and change over time, but we want you to have a rough idea of what wer'e working with.
Our game already features a lot of content. If you’re not speedrunning, completing the Campaign Mode with all the expansions will take a few days to finish. To fill such a lengthy campaign with content, we added many ‘dynamic events’ that can occur between the regular mission objectives. These range from sudden weather condition changes to native creatures’ incursions. For instance, a sudden sandstorm might reduce visibility, or a swarm of creatures might attack your base. We’ve been systematically adding these events with the release of each World Expansion. Each biome in our game comes with a range of side objectives that give you chances for additional rewards or temporary bonuses.
Some random events are more... volatile than others. But there is always a bright side - more wind power during the tornado, for example.
Unfortunately, as we were focused on fleshing out the central points of the campaign storyline, we did not have as much time to focus on the side missions as much as we would have liked to, and there were simply not enough of them implemented fully in the game. This led to side missions repeating often, especially in the Survival Mode. How often can you study the unusually large creature in the lab after it turns out to be unexplainably aggressive? Initially, we wanted to have way more variety in these objectives. Luckily, we now have time to improve on that.
Bosses that spawn as a result of a random encounter will also be picked from the new boss creature pool. They will get the new skills and HP bonuses. It also means more loot. The bigger they are, the harder they fall.
We are working on an overhaul of the side objectives and randomized events. The existing ones will receive new dialogue lines and other improvements. For example, our favorite “unusually large creature” will no longer be destined always to be the same species. Instead, we will use our new Boss Creature system, a feature that introduces powerful and unique creatures as challenges, to keep you on your toes and give you a real challenge according to the difficulty level. We are also adding entirely new objectives - for example, you will have to face attacks from swarms of Kermons and Phirians. Formations of resource-rich minerals will pop up in the Crystal Caverns biome. Acidic Yeast will be more aggressive and actually pose a threat. We have lots of improvements to make. We will share more information on these as we progress with their development.
A creature that is able to resurrect other enemies on the battlefied is always the number one priority.
While adding more events and side objectives is fun, we haven't forgotten about the existing missions. We've learned a lot about what’s possible within The Riftbreaker’s gameplay rules, and we've gained access to many new tools and technologies as our engine evolves. We're actively working through the entire campaign flow, introducing improvements wherever possible. These include failsafe mechanisms, more precise progress indicators, new markers, and logic fixes. After we're done with this round of improvements, the game’s missions should feel much more robust and stable. We're dedicated to making The Riftbreaker the best it can be, and we're excited to share these improvements with you.
Baxmoth drones have always been deadly. Baxmoth drones on a boss creature - even more so.
Updates will also improve the balance of the game. The past couple of months have been filled with playtesting, both for us internally and for our closed beta playtesters. Playing the game for hours on end with the years of experience we now have under our belts was an exciting experience. It allowed us to reach some conclusions that eluded us beforehand. We realized that some of us have been engaging in play patterns that are not very fun but painfully effective - self-sacrifice bombing formidable enemies in multiplayer, for example, or using Cryo Stations instead of walls in the Volcanic Area biome because of their higher HP/cost ratio. We want to give you an incentive to avoid these techniques but leave them intact in case you really want to stick to them.
Our resurrection mechanics have proven quite effective and encourage players to keep each other alive instead of simply blowing up in the face of enemies. Sometimes others even want to help a bit too much and get destroyed in the process. You live and you learn.
Apart from conclusions related to gameplay mechanics, we also had some thoughts about the stats on some of our buildings, weapons, and resource costs - both when it comes to construction and upkeep. We want to make sure that if we decide to make any changes here, they are thoroughly tested. Our closed beta is the perfect playground for us. Thanks to the expertise of the beta testers, we will be able to test the changes we want to make and see their implications in practice. These things are often very hard to predict, so real-life testing is the best way forward.
Wherever we end up going with these changes, we want to make sure the game stays fun. This is why testing is a priority for us.
We hope you’re excited about all the new content and improvements we’re preparing for you. We would like to remind you to sign up for our Co-Op closed beta test, a crucial step in ensuring the quality and balance of the game before its full release, right here:
We have just released a sizeable update for The Riftbreaker. It features all the improvements and optimizations we introduced during the preparations for the Heart of the Swamp expansion console launch. A very large portion of the adaptations we had to make to launch the game on other platforms is compatible with the PC build and will result in performance improvements - especially on machines with less than 16 GB of RAM. We have also introduced plenty of gameplay fixes and improvements.
We hope this update improves your experience with The Riftbreaker. The full changelog can be found here:
The Riftbreaker Maintenance Update, October 16th, 2024. EXE: 1018 DATA: 617 Changelog:
Changes:
Reduced the number of building cubes spawned when building long wall sections, which should improve performance.
After completing some objectives in the Fungal Forest Outpost the water surrounding your base should turn clean.
Optimized OGG sound file playback mechanism. If you experienced sound stuttering or dialogues cutting off it should now be fixed.
Added attack waves containing the enemies from the Fungal Forest biome to the Headquarters attack wave pool after the Heart of the Swamp storyline is completed.
Optimized 'emissive' textures for many models by removing blank black areas, reducing memory and disk space usage.
Reworked the 'Phirian attack' in-game event. Phirians now arrive as a group, coming from the edge of the map. Their strain and wave size depend on the difficulty level. The event is accompanied by new sound lines.
Stregaros shield is now resistant to all types of damage, doesn't break immediately after the first shot.
Player's repair drone has been buffed - it has longer range, travels faster and repairs buildings much quicker.
Chainsaw movement speed penalty has been reduced.
Replaced small bioanomaly models in all biomes with their new, regional variants.
Buffed Cryo Sentry, Holo Decoy and Bioscanner Turret consumables - higher levels now have much better stats.
Holo Decoy now has a bigger and stronger explosion on higher levels.
Acid Cluster Grenade now has increased radius and added damage over time.
Gas Grenade now has increased duration and damage on higher levels.
Grenade now has a bigger splash damage radius on higher levels.
Gravity Grenade now deals physical damage, increased area of effect and duration on higher levels.
Sonic Grenade now has a bigger splash radius on higher levels.
Mini Miners now get more HP on higher levels.
Proximity, Cryo and Nuclear Mines now have a bigger splash damage radius on higher levels.
The Antimatter Ball will no longer disappear outside the camera view.
Acid, Cryo, Fire and Energy Trails now have increased damage trail lifetime on higher item levels at a cost of a bigger cooldown.
Acid, Cryo, Fire and Energy Dash now have increased damage trail lifetime on higher item levels.
Flamewave now has more range on higher levels.
Repeater Rifle ammo consumption increased.
Bouncing Blades ammo consumption increased.
Reduced the strength of some camera shake effects.
Added shooting sound for Minigun Towers.
Changed shooting sounds for Laser Towers, as it used the same sound as the Flamer Tower.
Reduced the size of the Rift Station minimap icon.
Changed the layout of the Great Tree tile slightly to prevent unit navigation issues.
Changed unit behavior to prevent them from walking over the Flammable Gas Vents.
Added a 'cheat_remove_wave_units' command that will kill only the creatures that were spawned in the attack wave, allowing you to clear any blocked units without wiping the entire map.
Tornados will now always cause enemies to turn to gibs to prevent the 'flying dead bodies' phenomenon.
Traveling to other outposts is now blocked during the final Rift Station charging procedure.
Added new objective markers - circles and arrows.
Added Steel Floor to the Bioanomaly unlock pool. The item was present in the game, but was left out from the prize pool by mistake.
Fixes:
Introduced many performance optimizations.
Significantly reduced runtime memory usage.
Fixed the game flow getting stuck if the canceroth lair was destroyed before the canceroth attack was defeated.
The canceroth lair objective will start if the player reaches the canceroth lair before defeating the canceroth attack.
The canceroth lair objective will be skipped if the canceroth lair is destroyed before the player reaches the canceroth lair.
The canceroth attack may start sooner if the player progresses with other objectives faster to prevent out of order objective execution.
Heart of the Swamp main campaign objective will now be removed after the campaign ending.
Fixed the slow-spawning wingmite attack wave in the final wave of the Metallic Valley Survival Mode mission on Easy and Normal difficulty levels.
Fixed some issues with the Metal Terror's "Manufacturing Plateau" familiarity mission objective flow.
Fixed the Metal Terror storyline starting trigger. The DLC story will now start if you complete two scouting missions on other biomes OR if you set up a Cobalt Mining Outpost.
Introduced some optimizations to the saving process. By reducing the amount of data copied during saving, the hiccup on save should be less noticeable and the saving process should be much quicker.
You should no longer get announcements about the base being under attack when Sentry Turrets are being attacked and destroyed.
Fixed an issue that prevented players from restoring options to default values in the options menu.
Fixed an issue in Phirian sword attack that caused it to miss the player sometimes.
Fixed the damage over time values in all variants of the Crystal Gun.
Fixed the Firestorm event voice lines not matching the appropriate character avatars.
Fixed issues with updating resource limits after an Outpost with resource storages is removed.
Fixed an issue that caused the build mode selector to always appear in the top-left corner when using the gamepad.
Fixed multiple issues with Liquid Compressors and Decompressors usage across multiple maps.
Fixed issues with the menu navigation on the Custom Difficulty Screen.
Fixed an issue that caused some units to get stuck while navigating through liquid pools.
Fixed an issue that caused Mudroners to sometimes get stuck in one spot.
Fixed an issue that caused some main menu localizations to overlap.
Fixed a crash in lift.lua when the object you're trying to carry gets destroyed.
Fixed hitboxes on the Weapon Modding screen.
Fixed an issue that caused the mission flow to get stuck in the 'Destroy the Fungor Spawning Mound' mission.
Fixed the achievement trigger for 'Indecisive.'
Fixed collision boxes for the Alien Towers in the Metallic Valley biome.
Fixed the achievement trigger for the 'Treasure Hunter" achievement.
Fixed an issue that caused many sounds to play at once when loading into the game.
Fixed several issues with minimap item visibility.
Fixed an issue that prevented players from flipping pages when using a gamepad.
Fixed multiple issues with the 'interact' button not working properly.
Added missing resources to the global precache system - you should no longer experience stutters when encountering something in the game for the first time
Fixed several issues with Power Well powerup HUD symbol visibility.
All relevant stats for Mech Upgrades, Skills and Weapons should now be visible in the inventory screen tooltip.
Fixed an issue that caused Power Rod Towers and HCM Launchers to reload ammo after loading a save file.
Fixed the damage over time display in the inventory screen - it now displays that it is measured in seonds.
Fixed GUI usability issues on the Orbital Scanner screen.
In last week’s article, we answered one of the most prevalent questions about the Co-Op mode in The Riftbreaker: “Will the campaign be playable in co-op?” Today, we will focus on the second most popular topic in the community: “Why is the game in closed beta? Make it open beta!” We will try to explain to the best of our ability why we chose the closed beta route, how it benefits the development process, and why we can’t transition to open beta just yet. We will also give you a rough estimation of when said transition could happen and when you can expect to receive your beta key.
Our playtests have led us to several conclusions. One of them is: we have too many effects on our screen and we need to fix that,
First of all, let’s clarify why we chose the closed beta model. We had no idea what to expect when we started our testing. We have never played The Riftbreaker with anyone outside of our office. There was a slight chance that everything would go well, but honestly, we were expecting failure. In our experience, nothing ever goes right the first time. Only a handful of people were given access since we were ready to spend the next few weeks diagnosing connectivity issues, game-breaking bugs, and crash reports. In such unknown conditions, it is often the case that more than half of all common problems are caused by one or two bugs. We were prepared for things to bomb and didn’t really need hundreds of reports about the same couple of issues.
When you have friends along doing work, it is easy to fortify your base to the fullest.
To our surprise, none of that happened. Of course, the game had its fair share of issues, and it still does, but nowhere near what we had expected. We instructed our small group of players to focus on functionality first and report all the bugs and broken features. They co-operated and created cohesive lists of issues with as few duplicate error reports as possible. This allowed us to identify the critical problems and assign people to solve them quickly. Having a detailed list of issues and assignments without a vast, nebulous backlog looming over on Discord allowed us to push out patches rapidly. As we mentioned in our previous article - a small team like ours works best when we can focus on a smaller fragment of the game and work toward the ‘big picture.’ In other words, we try not to bite more than we can chew. Working with a small community allows us to set goals and work efficiently.
Big hammerroceros came prepared with personal bodyguards in the form of small hammerroceroses. It didn't help at all.
The closed beta period also allows us to test very specific game elements in a controlled environment. Each update that we release adds a couple of new features or gameplay changes. Our beta testers are informed about the upcoming changes in advance. By staying up to date with what’s happening within the dev team, they know what to expect from each update, which areas they should focus on, and what kind of bug fixes they can expect in the future. Not everyone has the time, and perhaps more importantly, not everyone is willing to put as much time into this project, which is completely fine. Keeping the beta and the testing group under key and lock for a little longer will allow us to continue this iterative development cycle. It has produced good results for us so far.
Playing with friends allows you to get a strong economy and build massive bases in a couple dozen minutes.
Now, let’s discuss what we still need to do to take The Riftbreaker to Open Beta. As you know, we utilize the peer-to-peer connection architecture. This means that people playing together are virtually linked, and all file transfers happen between their PCs, with no servers in the middle. Of course, that is a giant simplification, but the point is that we don’t have any matchmaking services or world servers to maintain. However, that doesn’t mean that the network side is completely maintenance-free. We have a server running 24/7 that acts as a central hub for the server search screen in the game. If the server went down, you could only connect to friends using the Steam friends list or by directly specifying the IP address that you want to connect to. At present, our server is more than capable of running the server search, but we have no idea what the maximum capacity is. If we opened the beta to everyone, we would likely find out the hard way. Before we do so, we need to implement more scalable and robust tools.
To compensate for the stronger economy, attacks get more dangerous as well.
Another disadvantage of open beta is that people will most likely get bored with it too quickly or get the wrong impression. We don’t want people to rush in and try The Riftbreaker in its unfinished state and form the first impression that it is broken and plagued by technical difficulties. We also don’t want you to get burned out by playing the same survival map for a couple of weeks before we add another biome to the list. The beta is not the full version experience. We want to make this distinction very clear.
Some things, however, are still dangerous, even in co-op. Meet the canceroth boss. It's nasty.
Some of you have been asking questions about the rate at which we’re releasing keys to the public. Generally, we try to release between 50 and 100 keys a week. At present, we give priority to those, who signed up earlier and who are present on Discord. Discord is our preferred method of instant communication with the community. It allows us to quickly address concerns and offer workarounds to issues before we can patch them. If you do not have Discord, you’re still eligible for a key. In fact, we will get keys to everyone who signed up for the test. As the game gets better, we will increase the pace at which we send out keys. It is going to take some time, and we are sorry about that. Please believe us when we say that we are not gatekeeping out of spite - we are gatekeeping to maintain an efficient process.
Perhaps we can't see things well yet, but it's still very fun!
As for when the transition from closed to open beta might happen - we don’t really know, but it won’t be this year. It is quite likely that the open beta will last for only a couple of weeks as a final rehearsal before the release. We are looking into several additional options to let you try out the game early to some capacity, though. We will share details about them in advance so that you can schedule around those events. In the meantime, we will do our best to keep you in the loop about everything on the development front.
One of the most common questions you ask in the comments section of our articles is, ‘Will we be able to play the Campaign Mode in Co-Op?’ The short answer is - yes. However, it’s a great question that demands a longer explanation. Most of our posts talk about the technical details of the multiplayer mode or the conclusions we have reached while playtesting the Survival mode. Today, we would like to tell you why we hardly spoke about Campaign Mode, our experience with it, and what kinds of problems we have faced and solved.
The playtest we will discuss today was held quite some time ago, so we have no footage of it. Instead, we will share some shots from today's Metallic Valley playtest. Suffice it to say, it's a bit harsh!
We usually fill these articles with as much knowledge and fresh information as possible. We most often choose the topics we have recently worked on. When working on a single element of the game, like the death sequence we discussed last time, you can focus clearly and speak in more detail than weeks after the fact. Remembering all the small details and reasoning behind our design decisions is much easier. Lately, we have been occupied with implementing improvements based on the feedback we got from the Closed Beta playtest. The playtest allows players to play Survival Mode, which naturally steers our focus in that direction, also when choosing the topic for our articles.
Players now get notified when someone falls on the battlefield. Look at the team rushing to help their downed friend!
We plan to have the entirety of The Riftbreaker playable in Co-Op mode. We chose Survival as the target Beta experience because it is a one-time-limited and self-contained mission. People are much more likely to finish a survival mission within a single session and give us meaningful and actionable feedback. The above does not mean we forgot about the Campaign Mode. On the contrary, we conducted playtests long before the Beta went live. Sometime ago, we gave two of our programmers the task to try and play through the entire Campaign in Co-Op, fixing any issues they found along the way. They played on the internal office network, using their own PCs in the personal server mode. Here’s our best recollection of what happened during that time.
The visibility of deactivated mechs was one of the key issues in the previous builds. To combat this problem, we have attached some additional effects to the wreckage and added a "repulsor" that prevents the creatures from covering the mech.
The scope is the most significant difference between the Campaign and Survival Modes in The Riftbreaker. The Campaign takes place across multiple maps, and players can teleport between them at any point. In Survival, the entire mission takes place on one map only. Unsurprisingly, one of the first problems our boys encountered was traveling between maps. Initially, the game would just crash when trying to change maps. Additionally, only the owner of the server could decide when and where to travel. The programmers quickly fixed the technical side of things and were able to travel without issues. However, we still need to add a way for players to vote for map travel. We will likely do that via a pop-up window, asking whether you would like to travel to any given map and count the votes.
Moving between maps also created many problems when it came to resources - especially ammunition. It is very common that your ammo-producing Armories are located on the HQ map while you are out and about saving the rest of the planet from imminent doom (which you may or may not have brought yourself). When players travel to another map, we take a snapshot of the world state, taking note of how much resources they can produce. Since all players share the resource economy, it was not an issue. However, since ammo is separate for both players, the game got a bit lost when it had to produce ammo remotely for more than one player. Depending on the situation, the game would either refuse to produce ammo altogether or produce it at an insane rate - x^n, where x is the base production value, and n is the number of players. Luckily, that was also an easy fix.
New biome means new boss combinations. Magmoth is resistant to area damage, and Canceroth scoffs at physical. You have to pick your weapons well to fight a creature like this.
Not all problems were quite that easy to figure out. You might already know we always maintain backward compatibility for our saved files. Everything would work fine if you loaded saved games from the 1.0 version in the current public build. However, those saves wouldn’t be usable in the 1.0 version anymore. That turned out to be a problem for us. When our playtesting programmers encountered a bug, they immediately got working on a fix. Then, they had to test if their solution worked by loading a saved file right from before the crash. If everything went well, they could progress further. Unfortunately, it wasn’t always the case. sometimes, their attempts at fixing the initial issues generated new ones… and corrupted their saves as a bonus. Since the entire campaign couldn’t be completed in one session, you can imagine how often they had to salvage their save files and start the entire campaign from the beginning.
Undeterred by all the errors and crashes, our brave heroes pressed on, fighting Galatean bugs and software bugs at the same time. At some point, they stumbled upon one of the exploration missions in a new biome. During those missions, you are not required to build an outpost, so you have no place to respawn. If Mr. Riggs is destroyed, you see a ‘defeat’ screen with the option to reconstruct your mech and start the mission anew. It didn’t work as intended when there was more than one player. If anyone died at any point during that mission, all players would see the ‘game over’ screen, regardless of how many mechs were alive and operational. This actually led us to the first prototype of the revive mechanics. A dying mech would drop a holo beacon that others could interact with to bring them back. This, coupled with the fix for the premature ‘defeat’ screen popping up, solved the issue. The team's problem-solving skills were instrumental in overcoming this and many other challenges, instilling confidence in the game's development.
We also increased stats for some creatures to make them more effective in the boss form. Behold - the Roid Rage Krocoon. Faster, stronger, more angry than ever.
Our team's persistence was evident as they continued to test not only the main Campaign storyline but also the DLCs we had available at that time - Metal Terror and Into the Dark. Both of them had their fair share of issues, but Into the Dark was far worse. For example - the system that clears the objects in front of the camera so that you can see your mech didn’t work at all, which made exploration, combat, and building way more difficult than it should be. Additional problems arose when our playtesters got around to fighting the Anoryx Worm. That fight is the only place in the game where we take away the player’s controls and move the camera elsewhere. Having more than one player and more than one camera was an exception that the game didn’t know how to handle. As a result, the camera would jump from one player to the other without end. Our crew fixed such errors case by case, finally drawing closer and closer to the end of the game.
More bugs awaited as our playtesters came close to the end of each of The Riftbreaker’s storylines. The end of each DLC and the main campaign is marked by a video cutscene that shows you the consequences of your choices. The game logic would hang completely after playing back any of those cutscenes. It was strange because there was an intro cinematic at the beginning of the game, and it worked fine. Digging deeper, we soon figured out that the problem lay not in the cinematic itself but in the operations we carried out after that movie finished playing. After each of our final mission cinematics, we teleport the player to a different map. This also happens in stage transition cinematics in the Crystal Caverns biome. The logic structure of the mission demanded the game to transfer the player after the video finished playing, but the game had no idea which player. It was an unhandled exception that caused the entire thing to stop in its tracks and halt the game’s progress, which could only be fixed by loading a save file.
Our boss creatures will also receive a visual overhaul to make them look more distinct from the rest of the horde. Here's an improved version of the Baxmoth boss.
Most of the issues that we faced were straightforward and easy to fix. However, without playing the game from start to finish, we wouldn’t have been able to catch a large portion of these bugs. Features often work in isolation or a controlled testing environment but fall apart at the seams when tested in real-life scenarios. The fact that we were able to complete the campaign some time ago does not mean we would succeed today. Rest assured that we are working on making onlince coop work in campaign mode. However, each full playthrough of the entire campaign can take weeks when we include the time that is required to fix some problems. Hence, the Survival mode is a much better tool for quick iteration and resolving all of the issues that are common for any type of gameplay.
All of the things we mentioned above can be summarized as follows: we are working on Campaign Mode coop, but it’s a much more difficult process than working on Survival mode and much more difficult to share because of the length of the game Conducting the Closed Beta test in Survival Mode allows us to work through the issues of each biome one by one, but more work will need to be done on top of that. We are planning to run an open beta of the campaign mode online coop experience using the experimental branch of the game. However, it will have to wait until we are sure that it’s mostly functional and that you won’t have to restart your progress due to architectural changes that invalidate your save file. As usual - we don’t want to promise when that is going to happen.
Today, the playtesters were no match for the Lesigian army, lead by Lesigian Omega with healing ray.
That is why, rather than talking about hypotheticals that you won’t be able to verify for months, we prefer to talk about facts that you can get access to - just sign up for our Closed Beta test at:
We hope that this article clarifies the situation and allows you to set your expectations accordingly. If there are any other aspects of the game you would like to learn about, any details that we might have skipped, or if you simply want to tell us to stop picking our noses and release the game already, the comment section is yours!
Another week, another portion of updates to the Multiplayer Beta. As always - more keys will be sent out on Monday.
The Riftbreaker Closed Co-Op Beta, October 4th, EXE: 9559 DATA: 62 Changelog:
All players should reconnect automatically when a save file is loaded on the server.
If you are the host of a multiplayer game, the game will now use localhost data loopback that avoids TCP/IP data transmission to reduce performance load and perceived latency.
Changed and improved the weapons, projectiles, effects and stats on Arachnoid, Nurglax, Nerilian, Baxmoth, Gnerot, Mudroner and Magmoth Bosses.
Improved the tile randomization parameters for Volcanic Area Survival mode - you should have more free space now and more lava pools that you can utilize.
Fewer Geothermal Vents will spawn in the starting area of the Volcanic Area Survival missions.
The starting area radius in Volcanic Area is now smaller, which should guarantee Carbonium and Ironium deposits near the spawn location.
Opening the small bioanomalies will no longer cause the nearby creatures to go aggro.
Changed and improved the sounds and effects for the Team Boost buff activation.
Changed the volume sliders from geometric to logarithmic, fixed saving settings.
Changed and improved the Phirian Boss model and skins.
The respawn timer starts blinking faster and faster the closer you are to the reactivation 'deadline'.
Improved mech wreckage visibility by dissolving corpses around the wreck and not allowing enemies to come close to it.
The mech wreckage is now lightly highlighted on the screen to make identification easier.
Added new placeholder voiceover lines for mech deactivation, destruction, and reactivation.
Added new voiceover variants to the Canoptrix Nest objectives.
Added new voiceover lines to Shegret attacks.
Added new voiceover lines for the dynamic boss encounter objectives.
Fixed an issue that caused the player's Teleport skill to sometimes send players to the [0,0,0] coordinates.
Fixed problems with players being unable to switch pages of the menu.
Fixed multiple problems with player actions on the Research Screen.
Fixed the Geoscanner sounds being played for all players when anyone activates it.
Fixed the 'Confirm' button on the Customize Controls menu screen.
Fixed a crash in the Building System.
Fixed a crash in the Custom Difficulty Screen.
Fixed an issue that caused some liquid pools to be unusable and invisible on the minimap.
Fixed multiple problems with dropping player input data.
Fixed a crash that occurred when switching equipped weapon mods.
Another day, another portion of updates to the Multiplayer Beta. We will send out more keys on Monday. Stay tuned!
The Riftbreaker Closed Co-Op Beta, September 27th, EXE: 9522 DATA:59 Changelog:
Gameplay Changes and Additions
The Magma Biome is now a part of the Coop Playtest. It's a much more challenging area than the Tropical Zone, so tread carefully. We'd love to hear your feedback in regards to difficulty balancing boss skills in this biome and any bugsthatt you might encounter along the way.
Added phirian attack to magma survival
Added elemental version of Phirian boss entities with attacks and skills (effects skins and meshes still missing)
Reworked Mech deactivation and activation sequence with improved effects and sounds. This is still work in progress, but feedback is very welcome.
Improved canoptrix, granan, morirot and mushbit nest spawn rules
Added new voice lines to the multiple canoptrix nests objective
Creeper: separate, much more agressive creeper for survival objective (probably too agressive)
Fireflies event - triggers solar panels(15% power), brighter light and fireflies, weak wind has been removed from this event
The sound of a Bioanomaly being opened should be heard by all players in the game
Changed effects for multiplayer boost
Changed enemy health modifiers per player above 1 in Coop to:
normal 0.15
hard 0.3
brutal 0.4
Multiplayer Server and UI improvements
Added a debug pause server option - debug_pause_server 0/1
The game server will now pause gameplay when there are no players present on the server
Multiplayer_game.gui: add option to disallow 'Streaming integration`
This week, we will expand on one of the topics we covered in our last Co-Op Status Update articles. More specifically, we will discuss the mechanics of a player’s avatar’s death in multiplayer. For the past couple of weeks, we have debated over this feature and what we can do to make it more meaningful in the multiplayer context. In the latest build of the Multiplayer Beta, we have introduced meaningful changes to this gameplay aspect. This article will explain what’s changing, our reasoning behind the changes, and the goals we’re trying to reach. Enjoy!
Up until now, "dying" in multiplayer worked exactly like in single-player, with the exception of not losing any weapons (due to technical reasons).
The Riftbreaker was never supposed to be a highly-punishing game. While it is true that the enemy attacks can get overwhelming and the player might have to fight very hard to defend their base, we don’t punish the player for failure. At least - not severely. When a player’s health drops to zero, the mech explodes with a high-damage blast that covers a large radius. After a few seconds, the mech is reconstructed and returned to the HQ at full health. You are free to get back into the fight almost immediately. If you play on normal difficulty and above, you only lose one weapon, which you can later pick up. This is precisely what we were aiming for. We want to keep you engaged and give you the tools to fight back.
This led to players developing a sel-sacrifice strat, as it allowed them to get more DPS.
When we started testing multiplayer, however, some problems began to surface. At the beginning of the survival run, the players are quite underpowered compared to the creatures they fight, especially on the higher difficulty levels. This led some players to the adoption of the ‘self-sacrifice’ strategy, where dying and exploding next to the most powerful creatures in the wave often resulted in a higher DPS output than any of the basic weapons could provide. This strategy, while effective, was not the intended gameplay and led to some imbalance in the multiplayer mode. We didn’t want to take away the death explosion. That would feel like slapping our players on the wrist for not playing the way we intended. We didn’t like that and had to figure out a solution - preferably one that would reward players for staying alive rather than punishing them for dying.
We decided that encouraging players to stay alive, rather than introducing punishments for dying was the way forward.
We put our thinking caps on and got to work. We knew we wanted to center our new ‘death’ mechanics around reviving fallen players and started experimenting. When the player’s health reaches zero, their mech enters a new, temporary “deactivated” state, accompanied by a small explosion. This state serves as a window for other players to come to the rescue, allowing for a more strategic and cooperative gameplay experience. The mech can stay up to 30 seconds in that state. During this time, any player can walk up to the deactivated mech (or teleport to it; your avatar is a permanent rift portal even when you’re down), press “interact,” and pick you up. If you do not want to wait 30 seconds, hold the interact button to speed the timer up. Once the time limit is reached, the mech explodes with the well-known self-destruction blast and gets sent back to the HQ.
We utilized some of the mechanics that we developed for the Multiplayer Deathmath test a couple of months ago. It was a good starting point for the system we currently have in place.
We immediately found a couple of sore spots when testing this solution out. First, when players get to zero HP in The Riftbreaker, they are likely surrounded by an army of aggressive and powerful creatures. Other players had a lot of difficulty reaching their downed comrades. Moreover, the reactivation took a couple of seconds in the first version of this system. During that time, the player helping their friend was essentially defenseless. More often than not, we ended up with two mechs down instead of both players surviving the ordeal.
Reactivating a fallen mech takes only a fraction of a second and grants you temporary invincibility. Thanks to this, you can jump in and out of the battle zone with your buddy in one piece.
The first thing we changed was the reactivation time. Instead of making the player wait a couple of seconds with the “interact” button held, we decided that the process should be almost instant. After all, you’ve already done the hard part—actually getting to your buddy’s wreckage. Additionally, we decided to give a temporary boost to both players involved. After successfully rescuing a teammate, both of you get 5 seconds of invincibility and a 200% damage boost to get out of the danger zone safely. With these changes, we saw that players were more eager to help their fallen friends without fear of risking their own skin.
When you get picked up by your co-op partner, you both get a temporary 200% damage boost. Take revenge on those who wronged you!
Since players can now pick each other up and speed up the destruction timer to use the death explosion more strategically to prevent the abuse of death mechanics, it is the right time to bring back weapon dropping. For the past couple of months, this feature has been disabled in multiplayer for technical reasons. Our tech problems have been solved, and the new death mechanics prompted us to reactivate it in multiplayer once more. The weapon they dropped is visible to all players, but only the owner can pick it up. The lost weapon is gathered automatically when you touch it with your mech and is automatically re-equipped in the slot from which you dropped it.
When your own mech is inactive, you can spectate other players. We are thinking about adding the spectator mode as a standalone option - you would be able to watch others play without joining the session as a player.
The biggest issue we are currently fighting is the mech’s visibility in the deactivated state. We all know what the screen looks like during a battle in The Riftbreaker. It contains bodies, blood, explosions, and other particle effects. At the moment, it is tough to notice the wreckage of your teammate among all the carnage. We are trying to combat this by adding various icons, markers, and effects to distinguish the mech from the surrounding objects. However, at this point, it is still a bit difficult to notice, especially when your focus lies elsewhere.
Even when the mech is inactive, you can still teleport ot its location.
Remember, this is a collaborative process. Since this is the first time we have introduced this set of mechanics to the multiplayer mode, nothing is set in stone at this point. All the timers, buff values, and visuals are subject to change. We're eager to hear your thoughts and suggestions. The more issues we can identify at this early stage of testing, the better the game will be for all players when we finally reach the open beta and, eventually, the public release.
If you prefer it, here’s the TL;DR of the new death and resurrect mechanics in bullet points:
When a player's HP drops to zero, and no other mechs participate in the game, the character blows up and is respawned in the HQ, just as usual.
When a player's HP drops to zero and other mechs are present, the mech enters a 'disabled' state. The mech can spend up to 30 seconds in that state.
During the 30-second countdown, other players can walk up to the downed mech and 'reactivate' it by pressing interact. The reactivation is almost instant.
After reactivating a player, both mechs receive a "Reactivation Boost" - temporary double damage, health regen (up to 50% HP, more or less), and invulnerability for 5 seconds. These values are subject to change.
The player can opt out of waiting to be reactivated. They can press and hold the spacebar to speed up the 30-second timer. After the timer expires, the mech blows up and reconstructs at the HQ.
If a player is reactivated from the downed state, they don't lose any weapons.
If a player is not reactivated in time, they will drop one equipped weapon.
The dropped weapon is visible to all players but can only be picked up by the player who lost it. Upon pickup, the gun is automatically re-equipped.
Players can enter all menu screens except the inventory screen in the downed state.
When your mech is down, you can spectate other players participating in your session.
The downed mech is marked on the minimap, and players can teleport to it anytime.
These changes have been introduced to discourage the self-sacrifice strategy of dealing with bosses and increase player interaction during gameplay. This mechanic needs more work and careful consideration. Try playing around with it and see how you like it. We are open to making any necessary changes to make it feel good and natural.
And that’s about it! Let us know what you think about the new mechanics we’ve introduced. We’re open to all kinds of feedback. Tell us what other changes you think would make the co-op play a more sociable experience. We await your comments here and on our Discord at https://www.discord.gg/exorstudios. Also, don’t forget to sign up for our beta test by following the link below. More invites go out every week!
Another day, another portion of updates to the Multiplayer Beta. We will send out more keys on Monday. Stay tuned!
The Riftbreaker Closed Co-Op Beta, September 19th, EXE: 9485 DATA:52 Changelog:
Reduced the boss aura skill radiuses from 25-28 metres to 12-15 metres.
The maximum number of players on the server has been limited to 4 in the menu. It is possible to override this with the server_max_players_available_count variable.
Added HP scaling for enemies. The amount of HP on creatures spawned during the attack will now adapt to the number of players on the server. 2 players give the creatures a 50% boost. 3 players - 100%. 4 players - 150%.
Added audio announcements when the player's HP goes down to zero and when a mech explodes.
Volume sliders in the options menu are now logarithmic, not geometric.
Added overcharge symbols to HP and shield bars on the HUD when the players are boosted.
Fixed the Z-order of the player icon on the minimap to make teleporting to a downed player easier.
Fixed some voice announcements not being properly played in multiplayer.
Fixed dynamic music system not changing playlists when it should.
Fixed several crash bugs.
Introduced memory and network optimizations.
Known issues:
Using a shared weapon will deplete the original owner's ammo.
Thank you for your patience and all the testing sessions that you have conducted over the course of our break! We have cooked a new build up for you, introducing some much-needed fixes and changes. We're already working on the next one - we have a couple of cool tricks up our sleeves so stay tuned!
We will send out a new batch of beta keys tomorrow. Please make sure to sign up here:
The Riftbreaker Multiplayer Closed Beta, September 18th, 2024. DATA: 49 EXE: 9463 Changelog:
We reworked the game's behavior after the player's mech is destroyed. This is the biggest change in this build. Your feedback on this is very welcome.
When a player's HP drops to zero, and there are no other mechs taking part in the game, the character blows up and is respawned in the HQ, just as usual.
When a player's HP drops to zero, and there are other mechs present, the mech enters a 'disabled' state. The mech can spend up to 30 seconds in that state.
During the 30-second countdown, other players can walk up to the downed mech and 'resurrect' it by pressing interact. The resurrection is almost instant.
After resurrecting a player, both mechs receive a "Revive Boost" - temporary double damage, health regen (up to 50% HP, more or less), and invulnerability for 5 seconds. These values are subject to change.
The player can opt out of waiting to be resurrected. They can press and hold the spacebar to speed up the 30-second timer. After the timer expires, the mech blows up and resurrects at the HQ.
If a player is resurrected from the downed state, they don't lose any weapons.
If a player is not resurrected in time, they will drop one equipped weapon.
The dropped weapon is visible to all players, but can only be picked up by the player who lost it. The weapon is automatically re-equipped upon pickup.
In downed state, players can enter all menu screens, except the inventory screen.
When your mech is down, you can spectate any other players taking part in your session.
The downed mech is marked on the minimap and players can teleport to it at any time.
These changes have been introduced to discourage the self-sacrifice strat of dealing with bosses and to increase the amount of player interaction during gameplay. This mechanic needs more work and careful consideration. Try playing around with it and see how you like it. We are open to making any necessary changes to make it feel good and natural.
Players can now heal each other. Walk up to another player's avatar, press and hold the 'interact' button, and wait. The healing rate is 30HP per seconds at the moment, and it is possible to overcharge the player beyon their current max health.
Added overcharged health and shields icons to let players know they are above the maximum values.
Naturally occurring creatures on the map will now respawn faster after being killed. the respawn speed is increased with the number of players on the server.
Added a loading progress bar with descriptions of loading stages. Thanks to this it will be easier for us to identify any errors during loading. For multiplayer mode, the progress bar is replaced with a 'spinning' bar, letting you know that an operation is in progress.
The localization of the proximity boost has been changed from "Apes together strong" to "Team Boost". Riot in the comments.
Tweaked the "Team Boost" activation parameters. The players still have to be close to each other to start charging the boost, but can now move away from each other significantly further before the connection is broken. We also added a cooldown display.
Added support for enemy damage scaling. It is currently disabled for all difficulty levels, but if you fancy a bigger challenge, you can increase the enemy damage by X percent per player using the 'enemy_damage_factor_per_player x" modifier when starting a new server.
The first wave on all difficulty levels will not be accompanied by a boss creature to give players more time to build up defenses.
Tweaked the Hammerocerros boss and Krocoon boss units to make them more effective in combat.
Added a new boss skill - damage wave. After a melee attack, a small directional shockwave appears, dealing damage to everything in a small arc.
Your Steam avatar should now appear next to your nickname in the main menu screen.
Changed the disconnect message from "You have been kicked from the server" to "The server has been shut down".
Optimized the number of entities that liquid resource volumes generated, reducing their impact on system memory.
Solved multiple issues with the engine's way of handling OGG Vorbis audio files.
Renamed 'cheat_{win,lose}_game` to `debug_{win,lose,end}_game` and moved it to debug.lua.
Fixed an error that could occur when restarting a server.
Fixed the starting position of the cursor when entering the build mode. It will no longer jump to the upper left corner of the screen when entering the build mode for the first time, which was especially painful when using a gamepad.
Fixed a crash that could happen when players were browsing their inventory.
Fixed a problem that caused the depleted shield bar to never disappear from above the player's avatar.
Fixed a problem that prevented the "Don't show again" checkbox in the maim menu intro pop-up message to not work properly.
Fixed a crash in the BuildingService system.
Fixed a crash in gather_resource.lua function.
Fixed an error that prevented users from switching the menu screens using the right and left shoulder buttons on gamepads.
Fixed a crash that could occur in the menus due to custom action mappers.
Fixed a crash in GUI that occurred when interacting with tooltips and slider/scroll by pointer mouse drag.
Fixed an issue that could cause the player to spawn in without equipment,
We have introduced a ton of memory usage optimizations in the game, which should result in quicker loading times, shorter saving slowdowns and general improvements in performance.
We have also fixed a ton of smaller issues with the game's network code, which should result in greater connection stability.