The Riftbreaker News

Today we will look at a much-requested quality-of-life improvement that will come to you as a part of the second free World Expansion update - the free part of our upcoming Into The Dark expansion. The feature in question is building ruins. Many of you let us know that rebuilding the base after a large attack is difficult and time-consuming. It is not easy to remember the exact placement of all structures, and setting everything up manually when under time pressure makes matters even less pleasant. We hope that this feature will remedy that.

https://store.steampowered.com/app/2108630/The_Riftbreaker_Into_The_Dark/

You could previously see the prototype of the ruins feature during our developer streams (every Tuesday and Thursday, 3 PM CEST, www.twitch.tv/exorstudios). The premise is really simple - once a building is completely destroyed, it leaves behind a pile of wreckage. The wreckage can be identified either by selecting it in build mode, where it will display the name of the original building, or by the visuals. Each building has a custom-made wreckage model to make identification a little easier - more on that later.

Testing destruction features is always the most fun.

Once a building is destroyed and wreckage spawns in its place, you have two options. You can use the deconstruction tool to remove the rubble completely and recover the space, or you can use the repair tool to rebuild the original structure for its full price. You can also use the mass repair/deconstruction tools to take care of multiple pieces of wreckage all at once. If you want to reconstruct multiple buildings, a tooltip will appear, informing you of the total cost of repairs. If you can’t afford the total cost of repairs, the game will try to repair as many buildings as possible instead, so you can bring your base back into shape piece by piece. Ruins have an unlimited lifetime, so you can simply come back to them whenever it is convenient for you.

Less time spent on repairs = more time spent on upgrades!

Naturally, modeling ruins for all buildings in the game would have taken a long time, and using a generic model for all structures would make identification very difficult. To speed the process up, we used Houdini. It’s a tool suite that uses procedural generation to let artists quickly iterate on their models, create visual effects, and much more. In our case, one of the artists created a specialized setup that can remove large parts of building models from The Riftbreaker in a matter of minutes. Here’s how it works.

We swear, this is work, it's not just fun.

First, we import the Blender building model into the specialized Houdini setup. The base part of the setup is a very large cube (large enough to cover all individual building models we have in the game). The bottom surface of the cube is irregular instead of flat. That is because the bottom surface is where the actual ‘cutting’ process will take place. When the bottom of the cube reaches the top of the building model, polygons are automatically removed.

Before and after the procedurally-generated destruction.

The artist can control at what height they want to cut the building. Houdini automatically generated the new geometry that covers the wreckage surface. That surface is then covered with a ‘burnt metal’ texture. When the artist is happy with the result, they export the new wreckage model to Blender for a final touch-up. Thanks to all this, a monotonous process that would take weeks for all buildings in the game can be completed within a couple of days.

As we slide the cube further down, more parts of the building disappear.

This feature will arrive to you as a part of the next large free game update. It will work even on saved games made earlier, so you can continue your campaigns with this new option available to you. We hope you will enjoy playing with it and that you will suggest even more improvements to us. In fact, this idea came from our suggestion board: https://riftbreaker.featureupvote.com/suggestions/332558/ghost-buildings-to-show-where-destroyed-buildings-were. Don’t hesitate to post your own ideas - we carefully consider all of them! If you want to contact us directly, reach out on Discord: www.discord.gg/exorstudios.


Have a great weekend!
EXOR Studios

When we started developing our games, EXOR Studios had few choices regarding picking the right game engine. In early 2008, the commercial solutions were out of our reach because of their prohibitive costs, while free engines offered only some of the features we needed. Thus, we decided to develop our technology based on multiple open-source solutions, including the OGRE 3D render system. This allowed us to build games precisely how we wanted to. As years progressed and we moved from one project to another, the Schmetterling Engine slowly began to take shape and eventually evolved into the complete framework we use today.

[previewyoutube][/previewyoutube]
A making-of video of our first game, Zombie Driver. You can see how it all started for us those 15 years ago!

Developing your engine comes with many difficulties. You can’t refer to any documentation or expect bugs to be fixed by someone else - you’re on your own. On the other hand, you are free to implement solutions that your game will benefit from. We have already told you about some of the new additions to the Schmetterling Engine we implemented for The Riftbreaker. Raytraced Shadows and Ambient Occlusion, AMD FSR, and Intel XeSS are just a few of them. Today we would like to discuss a significant improvement coming to the engine - Tiled Deferred Shading. This cryptic-sounding technique opens the door for improvements and new features in The Riftbreaker. We’d like to talk about how this new technique works, but first, we need to discuss some basics about shading in general.

[h2]Deferred Shading[/h2]

There are several ways you can approach computer graphics rendering. The available ideas and techniques vary considerably, resulting in unique requirements, advantages, and disadvantages for each one. Our earliest project - Zombie Driver, used forward rendering. In this technique, the scene is rendered by drawing each object in the scene one by one. Each object is rendered with its own set of material properties, such as color, transparency, and reflectivity. Lighting is applied to each object in the scene as it is rendered, calculating the contribution of each light source to the final color of each pixel on the surface of the object being rendered.

In Zombie Driver we used forward rendering. We were limited to using only one light per scene. None of the particle effects you can see in this picture emit any light. We faked the highlights with additive alpha particles - smoke and mirrors ;)

It sounds simple enough, but it has a major disadvantage - to ensure correct results, contributions from all lights need to be taken into account per each pixel on the screen. If the scene is lit by only one light source, it can be quite quick. However, when you add more lights, things can get complicated. Even if a pixel is fully occluded and is not lit by any of the light sources on the screen, the forward rendering method will calculate the lighting for that pixel anyway. We will learn that it is occluded only after computing the lighting for that pixel, and all that computational time will be wasted. This is why we have been using a more efficient technique called Deferred Shading in our later projects, X-Morph: Defense and The Riftbreaker. It excels in handling multiple light sources, which allows us to create scenes with many dynamic lights without sacrificing performance.

The primary advantage of deferred shading is treating the scene geometry and its lighting separately. In the first stage of the shading process, only the 3D geometry of the scene is rendered. The resulting information about each pixel's position, surface normal, and material properties is stored in the geometry buffer - or G-buffer, for short. In the shading stage, the lighting and shading calculations are performed using the information stored in the G-buffer. Lighting is calculated using the previously collected data stored in the G-buffer. With all the geometry data available at this point, lights are computed only for those pixels which they actually affect. We can also calculate complex post-processing effects such as ambient occlusion, temporal anti-aliasing, and upscaling thanks to all the information stored in the G-buffer.

The use of deferred lighting in X-Morph: Defense allowed us to use multiple light sources. In night scenarios, scenes are only lit by additional lights - there is no directional lighting present on this scene.

The current G-buffer layout in The Riftbreaker looks like this:

float3 GBuffer0 // Albedo (xyz),
float3 GBuffer1 // World Space Normal (xyz)
float3 GBuffer2 // Occlusion (x), Roughness (y), Metalness (z)
float3 GBuffer3 // Emissive (xyz)
float3 GBuffer4 // SubsurfaceScattering (xyz)
float2 GBuffer5 // Velocity (xy)
float GBuffer6 // Depth

However, deferred shading also has some limitations. Reading and writing to the G-buffer takes some time, which can be a major downside when it comes to lower-spec hardware. It also does not scale well with high numbers of lights on the scene. Still, the most glaring issue for us regarding The Riftbreaker is transparency. Deferred shading can’t handle transparent objects. The fact that the technique relies on the g-buffer information means that all things that are not opaque can’t be used for lighting calculations since the buffer doesn’t store any information about non opaque geometry. This is one of the reasons why we decided to upgrade our renderer to use Tiled Deferred Shading.

[h2]Tiled Deferred Shading[/h2]

Tiled Deferred Shading is an evolution of the Deferred Shading algorithm. The screen is divided into a grid of tiles, in our case, 16x16 pixels each. Each screen tile holds information about light indexes that affect that tile. This data is later used for light computation for opaque and non-opaque objects.

A debug view of a scene from The Riftbreaker with Tiled Deferred Shading enabled. The tile grid is visible. In this view, the color of the tile tells us how many lights affect the tile. The closer it is to red, the more lights affect a tile. It's essentially a heatmap.

We didn't joke about the heatmap thing.

The benchmark scene we used to test this technique. You can see how lights change in real time.

The algorithm for this process is:

1. G-buffer pass - Draw all opaque geometry.
   
2. Compute tile frustums - prepare frustums individually per tile depending on the buffer minimum/maximum depth.
   
3. Culling lights pass - use frustums to check if the light overlaps the tile and insert its index to the light index list.
   
4. Compute light shading for opaque objects - Use G-Buffer and prepared lights list for a single pass screen space light computation.
   
5. Compute light shading for non-opaque objects - Draw each non-opaque object and compute light shading per pixel only for lights that belong to the tile.
   

In higher resolutions the tile grid becomes more dense, allowing more precise calculations and much greater granulation.

The main advantage of this approach over the Deferred Shading we used up to this point is much higher efficiency. Traditional Deferred Shading has to access the G-buffer individually for each light source during the lighting pass The Tiled Deferred algorithm allows us to read the G-buffer only once for all light sources.

For contrast, in lower resolutions, the grid loses its precision.

The additional processing required for culling lights can add some overhead to the rendering pipeline on scenes with just a few light sources. In The Riftbreaker’s example, this is typically overcome in situations with more lights, such as bases with large numbers of defensive towers. The increased speed of completing the lighting pass becomes clearly apparent in those instances.

[h2]Results[/h2]
In recent tests we conducted on The Riftbreaker, we observed that implementing tiled deferred shading resulted in a significant increase in performance. Specifically, tests we ran on various hardware revealed considerable performance improvements when it comes to scenes with many additional dynamic lights. On average, The Riftbreaker ran 20% faster in scenarios with many towers, explosions, enemy units, and building lights on the screen compared to the traditional deferred shading approach.

[h3]Test case 1: static scene, adding lights manually one by one.[/h3]
Test platform: Ryzen 5600X, 32GB DDR4, Nvidia RTX 3080, Win11, 4K

This is what the synthetic multi-light test scenario looked like.

Synthetic multi-light benchmark scene results. In scenarios with more than 100 lightsources Tiled Deferred Rendering provides an almost 100% FPS boost!

You can see the tiles changing color as we turn sets of lights off.

[h3]Test case 2: In-game CPU benchmark mode.[/h3]
Results presented are the average of 2 runs.

The test scene without the debug overlay.

"Benchmark CPU" testing results on three sample configurations. This benchmark is not perfect for testing this rendering method because it focuses primarily on CPU overhead. However, even in this case, we can report visibly better performance results.

[h2]Conclusions and future works[/h2]
Tiled Deferred Rendering has allowed us to save a lot of CPU processing power in The Riftbreaker. This technique will make it easier to maintain high, stable frame rates, or if you’re already running the game above your monitor’s refresh rate, it will reduce the strain on your GPU and will lower your electricity bill - everybody wins! You will be able to start enjoying its benefits as soon as the World Expansion 2 free update reaches your hard drives.

Thanks to the changes we have introduced to the Schmetterling Engine, exciting new possibilities have become available for use in The Riftbreaker and our future projects. With tiled deferred shading, we can now add support for transparency and particle light shading or even go for something much bigger like volumetric fog support. We believe that these improvements will positively affect the player's reception of the game and give our artists more creative freedom when it comes to designing levels and effects.

We hope you enjoyed this deeper dive under the hood of the Schmetterling Engine and The Riftbreaker. We are really excited with the possibilities unfolding before us, and we hope to start using the new tech as soon as possible. Join our Discord at www.discord.gg/exorstudios to keep up with all the development news. Remember to post your ideas and suggestions at riftbreaker.featureupvote.com!

See you next time!
EXOR Studios

P.S. During the last developer stream on Twitch we managed to finish a full Survival run in co-op, running a dedicated server in headless mode. We're making progress! Join us on Tuesday at 3PM CEST at www.twitch.tv/exorstudios for the next one!

Every week brings us closer to the release of Into the Dark, the upcoming second World Expansion for The Riftbreaker. We can’t wait to hear what you think of all the new content we have prepared for you. In fact, you will have a chance to tell us pretty soon, as we’re going to hold a closed beta test of the Survival portion of the update - join us at www.discord.gg/exorstudios for more details. Today, however, we would like to tell you more about one of the most terrifying and unique threats you will face in the Crystal Caverns biome - the Necrodons. Strap yourselves in - this one is really unique, not only when it comes to appearance but also its ability set.

https://store.steampowered.com/app/2108630/The_Riftbreaker_Into_The_Dark/

The Necrodon is a creature that you might have seen in the game previously. We originally intended to include it in the original release in October 2021. We prepared a 3D model, visual variants for Alpha and Ultra strains, and all the animations. However, we didn’t finish programming and testing its behavior and skillset. Furthermore, it didn’t really fit in any of the Galatean Biomes, and we couldn’t really figure out its gameplay role. As the release date drew near, we decided to put the Necrodon on the shelf and come back to it at a more opportune moment. You can still encounter it sometimes in the Desert Biome, but it’s nowhere near what it is today. When we came up with the concept of the Crystal Caverns biome, the Necrodon finally got its moment to shine. An entire cavern system filled with crystalline formations of an unknown origin and purpose was the perfect home for this monster.



Necrodons are tall, menacing humanoids. Their physical appearance differs from other Galatean creatures. A standout feature of Necrodon’s physique is the presence of crystals that seem to grow out of their bodies in various places. Either these creatures have been infected by the crystalline growth that is present all around the crystal caverns biome, or they have been brought to life by the growth itself. Both prospects are equally terrifying, especially when their abilities are considered.



Necrodons are not confrontational and aggressive on their own. If one is encountered in the wild, it will do its best to run away to safety. Once cornered, the Necrodon will do its best to scare the attacker away. Most often, they will try to deliver a powerful hit using their long arms. However, that’s not the only move in their arsenal. Necrodons seem to possess the ability to manipulate matter around them, similarly to Lesigians, but to a different extent. This allows them to concentrate energy into a powerful beam that they can direct at the creatures that decide to attack them. Still, Necrodons prefer to avoid direct confrontation and use their powers in more creative and terrifying ways.



These creatures become truly terrifying when accompanied by other species. Once in a while, you will encounter an attack wave that seems to never end. No matter how many enemies you defeat, it will seem like more join the ranks in their place. That’s the Necrodon’s true weapon - they are able to raise the defeated creatures back from the dead to fight by their side. If you’re not careful, they will hang back just out of your line of sight, bringing back more and more creatures. Even if they run out of corpses to bring back, they can even create entirely new undead creatures, seemingly out of thin air. Naturally, it is not the case - Necrodons manipulate organic matter to form a semblance of a living creature, very similar to a canoptrix. Nonetheless, it is a terrifying ability, and you must deal with them as quickly as possible.



There is a limit to Necrodon’s abilities. They won’t keep summoning creatures to their side without end. There is only a limited number of “minions” Necrodons can control at one time, meaning that you can overpower them quite easily if they are on their own. It gets a bit more difficult if you encounter several specimens during one attack wave. In multiples, they can eventually overwhelm you and your defenses, so plan accordingly. Additionally, remember that Necrodons can only raise creatures whose bodies remained intact after death. If you blow creatures to shreds, they will eventually run out of bodies to resurrect and have to resort to creating their necro-canoptrix, which are quite weak on their own.



That’s it for today. If you’d like to see more of the Necrodon in action, tune in to our streams on Tuesdays and Thursdays on www.twitch.tv/exorstudios. We also preview our tests of the co-op version there, so you should definitely join in and see how it’s coming along! Don’t forget to post your suggestions and feedback on riftbreaker.featureupvote.com, as well as our Discord server at www.discord.gg/exorstudios.

See you next time!
EXOR Studios

After two weeks break, it is time to return to the second Riftbreaker World Expansion: Into The Dark. We have already told you about some of the new game mechanics, buildings, and creatures you can expect to find in this biome. Today we would like to focus on a completely different aspect of the Caverns biome - the map tiles design. In this article, you will learn about all the new features we prepared to make this biome look and feel much different from what you’re used to. Read on!

Let’s start with the basics. As we explained before, maps in The Riftbreaker are generated procedurally by stitching together predesigned elements that we call tiles. The designer gives tiles a general structure through the use of movement-blocking props. These are usually boulders - they dictate where you can or cannot go and what kind of space will be available for you to build your base. Designers also place spots designated for resources, enemy spawns, bioanomalies, and prefabs containing various props. These rules remain the same in the case of the Caverns biome.

Map tiles from this biome seem claustrophobic, but it all changes when you turn the destructible rocks off!

The first difference is that almost all tiles are covered to the brim with our new ‘destructible rocks volume.’ It is a game logic structure that tells The Riftbreaker which areas of the map are allowed to be covered with destructible rocks, which we discussed in one of our previous articles. We do not place them manually - instead, the engine spawns them automatically. We can also determine how much of the tile we want to fill with rocks. If we create a tile focused on exploration, we will choose a more open layout that will not produce as many rocks as in the case of a tile we want you to dig through.


This biome allows us for more verticality in our map construction.

While most of the map is covered with destructible rocks volume, it does not mean that boulders are the only thing you can find in the Galatean underground. Our map generation system can make maps more attractive by cutting out caves and clearings within the rock structure. We have developed rules that control the extent to which destructible rocks will fill the level. Based on a specialized algorithm, some areas of the level will be left blank to accommodate various points of interest placed by the designers. If we simply filled the entire level with rocks, it could cause technical issues, for example, creatures spawning within walls. Besides, it would feel monotonous, which is the last thing we want.

Most of the caves and clearings you can see here were created automatically using our systems.

However, if all caves you stumble upon were filled with objects of interest, you would very quickly notice a pattern there. To avoid that, we developed a unique feature to add even more variety to the biome. The map generator can now use masks to change the map layout. There are two varieties of these masks - one is used to remove parts of the destructible rock formations. The other one ‘cuts out’ holes in the ceiling of the caves for the light to shine through. Let’s take a look at each type and see how they work.

Masks used to generate caves are rally simple. You will be easily able to make your own for modding purposes.

These masks tell the game where it can spawn our rock formations. The key is simple - white means the space should be left empty, and black means it’s fair game. The mask is a 128x128, black and white png file, with each pixel corresponding to one grid on a standard, square map tile. During the map generation process, one of these masks is taken randomly and virtually laid on top of the tile. Then, parts of rock formations are removed wherever the white pixels from the mask have landed. Rotations of the tile and mask are randomized, resulting in many possible combinations.

The masks responsible for light spots are more nuanced. The delicate glow around the holes is necessary to create on illusion of light scattering.

The other type of mask is more complicated. These textures shape the sunspots allowing sunlight to pierce through the ceiling. The white pixels determine not only the shape of the skylight but also allow us to create an approximation of the light’s behavior. The intensity of the white pixels on the mask determines how much light passes through the mask, trying to emulate the light scattering. Sunspots are an important gameplay feature in the Caverns biome. While generating power from solar panels is not the first choice here, you will have the option to place a couple of panels here and there if you like to!

An example of a couple of light masks in action.

Designing an exciting map tile in such a claustrophobic environment is no mean feat. Plants, mushrooms, and other props are rare and need to fit their surroundings - you don’t expect to find a forest in the middle of a cavern system. Verticality plays a much greater role in creating the atmosphere of this biome. First of all, thanks to the camera object culling system that we implemented, we can now build much taller structures without worrying about obstructing the view. Stone arches, stalactites and other formations make an appearance, giving you the feeling of actually being underground.

Everything that is situated below the ground level of the map is bound by an artificial box that prevents you from seeing artifacts.

While exploring the caves, you will often find that they open up into larger, naturally formed caverns. Such spots were featured previously on other biomes, but not to this extent. We build a ‘box underneath each tile where we want to show the lower levels of the cave. It ensures you won’t be able to see the skybox bleeding through the ground at any angle and gives us a rock-solid foundation to set up exciting sceneries that give you a real sense of depth when looking into them. Things get even better when the generator puts a skylight directly above such a spot, as lighting and shadows can completely change the presentation of the scene.

Tiles vary in how much of their area can actually be traversed.

As you can see, we had to solve several issues and develop several new features to bring The Riftbreaker’s gameplay underground. We are happy with the results and think that you will find the Caverns biome to be a completely unique experience. We also hope that the new features will be useful to you from a modding perspective. Remember that this world expansion's functional content and Survival Mode biome will be available to everyone as a free update so you can use it all in your creations. Speaking of modding, we await your submissions in the modding contest! We have some gaming PCs and GPUs looking for a new home. Don’t keep them waiting too long! As always, we are waiting for your feedback and questions! Catch us here, on social media or www.discord.gg/exorstudios. We’re also waiting for your suggestions at https://riftbreaker.featureupvote.com/.

EXOR Studios

It’s been quite some time since we last shared information about our progress on the co-op mode for The Riftbreaker. Many of you have been wondering how we’re doing on that front and why we have been so quiet for so long. The reason is quite simple - our programmers have been doing a lot of code refactoring and other work under the hood of our game engine. For a very long time, we could not show off immediately visible progress. However, all that work is being done for a reason, and recently, we’ve hit a couple of significant milestones. They allow us to check on co-op progress daily, find areas to work on and introduce small improvements often. Let’s talk about what’s changed since the previous article and what the plans look like for us.



[h2]WHAT HAS CHANGED SINCE THE LAST TIME?[/h2]

Our previous article listed the engine areas and game systems that would be our immediate focus going forward. We don’t expect you to read all that again, so here’s a TL;DR version: to minimize data transfer and latency, we aim to separate most systems into the client and server parts. For example, when you chop down a tree, the server only needs to know that the plant is no longer there. All the visual work - particles, parts flying, the trunk falling - can be done on the client's side. After the server broadcasts the message ‘Tree 49038 has been chopped down’, clients can reproduce that state independently, reducing latency and data transfer. This is a simplified example, but this philosophy can be applied to many game systems.

One of the systems that are co-op ready now is the MechSystem. It is responsible for all the actions of the players’ avatars. It translates pressing ‘W’ on your keyboard to ‘move the mech up’ command that the game can understand. As we told you last time, we couldn’t simply send player inputs from the client to the server since key presses mean nothing to the game. Instead, we send ‘translated’ commands that the game can act on and apply immediately. An excellent optimization introduced here is double verification of command legality. For example, player 2 (the client) is trying to throw a grenade. They press the hotkey, but they have no grenades left. The game sees that, determines that the command is illegal, and doesn’t even bother sending that info to the server. Scenario two: player two is trying to throw a grenade again. They press the hotkey and have grenades in their inventory. Information is sent to the server. The server verifies if the move is still legal, and if it is, the grenade is finally thrown. This reduces the number of potential errors that could stem from mismatched information between client and server machines.



The VegetationSystem has also been separated into client and server parts. This system is responsible for handling all things related to flora - swaying in the wind, bending in contact with creatures, and the growth cycle of plants, among other things. We concluded that the server should only handle the lifecycle part, so the plant is growing back after being destroyed and transitioning through its growth stages. This ensures that all flora entities are synchronized for all players and prevents situations where a tree sapling is displayed as an age-old, towering tree for one of the players. The client-side handles all other interactions with plants, such as bending, since they do not have any tangible effect on gameplay.

Another system that has undergone significant changes is the TerrainGridSystem. This system stores all information about the grids that we can see on the map. It tells the game whether the grids are occupied by buildings, if resource deposits are available, or if there are any liquids or props on the ground. We used to store that information in one large data structure. However, transferring all that info every time something changed could have been more optimal. We separated the entire terrain grid into smaller entities, one for each 2x2 meter grid, which can hold information on their own. This allows us to exchange information about the relevant parts of the world, not the entire map, and - you guessed it - minimize data transfer. There are two nice side effects to this. The first is that we will be able to embed fog of war information into grids, effectively killing two Vesauruses with one stone. The second - the data structure for TerrainGrid is much smaller now, reducing the overall save file size and shortening the dreaded autosave hiccup!



The DestructionSystem got a major overhaul as well. This system handles all the visual changes when an entity is damaged. Once more, we moved all the elements not essential for gameplay to the client side. Particle effects and random debris that get spawned when something is damaged do not affect the overall gameplay state, so they can be simulated for each client. It doesn’t matter if there are minimal differences between them. We kept all the relevant bits on the server, such as loot and wreckage (just to clarify, dead bodies of killed creatures are called ‘wreckage’ as well). Those elements are synchronized across all computers participating in the session and are guaranteed to line up with each other.

While playtesting the super early multiplayer builds, we quickly came to a couple of conclusions. The first one was - ‘wow, this is fun.’ The second - ‘haha, I can steal all the hard-earned money from my co-op buddy.’ The third - ‘WHAT DO YOU MEAN THEY USED UP ALL THE AMMO?!’. One of those is not like the others. We realized that working towards a shared economy, building infrastructure, saving up for big projects, and a little bit of trolling here and there is all fun, but having a common ammo pool is rather unfortunate. You might have got yourself into fights that you couldn’t win because your partner has used up all the ammo without telling you about it. This led to frustration. To avoid that, we decided to separate ammo pools for all players.



All those changes are super nice and were necessary steps on our road to reaching a playable build. Obviously, much work is ahead of us, as many systems still need a rework. However, one thing we’ve recently done makes us really optimistic about the future.

[h2]MAJOR BREAKTHROUGH[/h2]

As an experiment, we decided to try out some aggressive parallelization techniques. Most modern CPUs have multiple cores, often divided into even more threads. Each of those threads can process data independently from the others, meaning it is possible to carry out some operations simultaneously. This is called parallelization. Not all procedures can take advantage of this, as sometimes you need to know the result of one calculation to start working on the next one. However, for the co-op version of The Riftbreaker, we found an exciting avenue that could potentially lead to significant performance gain.



As an experiment, we decided to allow the client side of the game to process data deserialization (in human terms: deciphering data received from the server) and the world update processes simultaneously, using as many threads as possible. We did a similar thing for the server with processing client game states - each client got their own CPU thread now. Without going into much detail, we saw an immediate increase in performance that allowed us to play at a comfortable performance level for quite lengthy periods. As a result, we started running more tests, noting all the bugs, errors, and design problems we noticed. At one point, we even managed to run a 4-player game without any issues (for a few minutes).



This is a very important step for us. We use playtesting as a driving force for our development process. We simply didn’t want to spend too much time testing the co-op mode for a very long period, as too many things were not ready, and the performance made it very difficult to make any meaningful progress. Now things are different. We can jump into a multiplayer game at any time and try to break it in new ways. With each test that we run, we find new bugs to fix and new avenues for improvement. The progress we’re making now is faster than ever, and we are very optimistic for the future.

[h2]WHAT’S COMING NEXT[/h2]

Running regular playtests will supply us with a steady stream of minor (or major) bugs to fix. However, it is crucial to remember the big picture and adapt the remaining systems for co-op use. One of the most important goals we have our eyes on is reworking the EntityComponentSystem. Reducing the amount of data we have to synchronize between server and client entities will play a major role in increasing the performance and stability of the game. Large chunks of data in our entities always stay the same. For example, each item has its name, icon, blueprint, and sound effects. All that information is stored in the entity file for that item. We want to be able to flag such components and simply ignore them when synchronizing the game worlds.



Another aspect of the game that will get a little bit of special treatment is Research. It’s a massive part of the gameplay loop, so it must work well. The computational cost of this system in a singleplayer game is completely irrelevant, but in multiplayer it suddenly becomes a problem. The entire research tree, the queue, and the download timers are part of one large data structure. When research is running, we need to update it very often, increasing the strain on the CPU and sending large amounts of data. We could use those resources elsewhere, so we plan to prepare a custom serialization method allowing us to only exchange the relevant bits and pieces of the research data structure between the server and client PCs.

The question of reducing data transfers has appeared several times in this text. Our focus on that might seem slightly excessive in the days of fiber internet and 200 GB game downloads, but we pay attention to that for a different reason. The more data we send from one PC to another, the longer it takes to unpack everything and apply the changes. Our current system marks all the entities that have potentially changed since the last game world synchronization occurred. For an average Survival map, that could be somewhere between 2000 and 4000 entities (per server tick/update). The server sends such a synchronization package every 33 milliseconds, with the client constantly receiving data and continuously applying changes. That’s a lot of data to parse, and it comes 30 times every second! What is worse, though, is that in the end, it often turns out that out of the original 2000-4000 entities marked as potentially changed, only a handful needed to be synchronized. Therefore one of our biggest goals is to filter all that data and send only the relevant data, which will, in turn, decrease the load on the CPU and your network connection.



We want to achieve that data filtering by improving the functionality of the octree implementation in The Schmetterling Engine. As of right now, we can use an octree to quickly generate a list of entities that are visible on the scene. While that can be used to extract components from those entities and check for changes, it is not an efficient method and requires an additional function. As we know, the fewer steps, the better. After our planned upgrade, our octree implementation will be able to find all entities in any given area and read their components. That will simplify generating a list of changed entities (or delta) and boost the game's performance.



[h2]ENOUGH OF THE TECH MUMBO JUMBO. GIVE ME THE GAMEPLAY DETAILS![/h2]

As interesting as all the technical details are, we know that behind-the-scenes stuff is only for some. Some of you are simply looking to have your questions answered. With the help of our fantastic Community Moderator, SenorRagequit, we prepared this short FAQ. It is, of course, not exhaustive, so feel free to ask us even more questions.



[h3]Gamemode / MP styles[/h3]

Will we be able to play campaign and survival in coop? Or just one of them?

We aim to make both the Survival Mode and the Campaign Mode playable in co-op. Survival Mode will surely happen, including the Sandbox and Custom difficulty settings. As for the Campaign - we will do our best to make it happen, but it is still to be confirmed. We need to iron out a few issues and finalize the design, which will only happen after several internal playthroughs. After playing the game ourselves, we can make much more informed decisions and solve problems we otherwise wouldn’t have known about. It will require significantly more work than survival, so it is possible that coop for survival and campaign modes will come as two separate updates.

Will there be game modes created especially for multiplayer? Which ones? (PvP, PvPvE, King of the Hill, Prophunt, Tower defense map, etc.)

Not at launch. Developing the co-op module for the game is an enormous task. We are focused on delivering a stable, fully playable baseline co-op first. After we deal with that, we plan to incrementally develop additional co-op-specific content.

Can one player play as the alien faction while the other is the default Riggs?

No. That would require us to write another game within The Riftbreaker! It’s not impossible, but it’s a different game, c’mon! At present, we can control only the player’s mech. If we were to give you the ability to control aliens, we would have to develop a fully-fledged RTS control scheme with free camera movement, multiple unit selection, grouping, and all the other features you’d expect from a modern RTS. Let’s leave all that for Riftbreaker 2, for now!

Will there be a split-screen coop? Couch coop? Other local multiplayer?

Online co-op will be the only option available. Apart from the fact that going split-screen would double the performance cost of running the game, it would simply not work very well in split-screen - you would lose too much screen area to fight or build effectively. We can put that effort to better use.

Will there be an option for LAN multiplayer only?

If nothing drastic changes along the way, then playing co-op over LAN should be possible.

Will a multiplayer match browser exist so everyone worldwide can join my game and fight together?

That is yet to be determined. We will have a lobby/browser screen to make joining games easy and convenient. However, we don’t know if it will be limited to your friends list or all games being played at any moment.



[h3]General[/h3]

How will the world's persistency work? E.g, if both players leave the world, will it still be active, and can you re-join and continue where you left off as if you respawned?

In our architecture, one of the players’ PCs takes on the role of the server. All the gameplay state data, including world snapshots, will be stored on that PC, just like a regular save. Other players can join and leave at any time. It is still possible that we’ll enable the option to host dedicated servers that would host an instance of the game independently from all client machines.

Will there be cheat protection in case someone joins in and unlocks all achievements for me?

We’re going to make sure not to break achievements for any players. As for anti-cheating - if we go with the invite-only version of matchmaking, we don’t think it will be necessary. Software like this can cause more hassle for players who want to play the game without any cheats.

Developing or integrating anti-cheat mechanisms also requires a lot of development effort. Since we’re focusing on coop at the moment, we don’t want to unnecessarily extend the time it takes to allow you to play with your friends. If we develop a PVP mode in the future and cheating becomes a real problem, we’ll do our best to prevent that as best as we can.

When playing with two or more people, will the number of enemies also grow proportionally?

Difficulty scaling is a challenging subject. Doubling the number of enemies could potentially have huge ramifications and lead to unforeseen gameplay problems. Game performance and required network bandwidth would also suffer. We will likely develop custom logic rules tailored to co-op play with more challenging enemy wave construction, shorter wave intermissions etc.

Will there be cool new skins for multiplayer?

We plan to add more skins with each significant content update for the game. You can unlock them through in-game progression and our code redemption feature.

Since we will change skins a lot, is it planned to improve the skin menu? Clicking through 20+ skins is annoying

Yes. We know there are better UI choices than cycling through a few dozen skins. We will implement an additional menu layer that will allow you to scroll through a list of all the skins available to you and choose the one you want.

Will the end game stats dashboard be fitted to multiplayer so we can see how our partners did?

As long as we don’t encounter unforeseen technical difficulties, this should be doable and seems like an excellent addition to the stats screen.

Will there be weapons or items made specifically for multiplayer? Like an item that can teleport one player to another player?

We wouldn’t want multiplayer-only items; we want our content to be usable in as many scenarios as possible. That being said, utilities like teleporting to your co-op partners should make it in, but not in the form of a separate item, but as a UI functionality, available either through a click of a hotkey or a button on the map screen.



[h3]Communication[/h3]

Will there be a chat?

Yes. We will implement a basic, text-based chat for you to use in-game.

Will there be voice chat?

No. It is a complex feature that would require huge amounts of work to develop. There’s a lot of third-party apps that serve that purpose very well We will leave the voice chat options to third-party apps.

Will there be a ping wheel? Example: https://i.imgur.com/MzpI1ki.png

This is an interesting idea that we will consider implementing. It should be especially useful in no-voice-chat situations and on consoles, where typing messages is usually quite problematic. Good idea, thanks!



[h3]Player[/h3]

How many players will coop support?

At least two ;) In all honesty, we don’t know just yet. Technically we can connect as many clients as we want, but the question is - can the server handle that? Another question is - how many actually make sense? We will need to run extensive tests in all the different scenarios to determine the maximum number of players. That being said, we can tell you that we ran some 4-player games already, and they ran pretty well, so we hope to get to that number!

One more thing to note here as well is, that we don’t plan to “hard lock” that number (on PC). We all know that times change and even if something is not possible today then maybe future PCs and network infrastructure will be able to handle a thousand players. Some of you might also be ok with playing the game at 15FPS while others don’t want to touch anything that isn’t running at 200FPS. We’ll try to leave this as technically open as we can.

Will there be a different number of supported coop players on PC vs. on console?

Just like in the case of the previous question, we don’t know just yet. We prioritize getting The Riftbreaker running in co-op on PC, smooth and stable. Console version testing will likely run parallel to PC testing and optimizations, and that is when we will get the final picture. Please mind that achieving online multiplayer on consoles is significantly more difficult than on PC, so it may very well arrive later on these platforms.

Will players be able to exchange weapons, modules, etc., between them?

Most likely, yes, in the case of weapons, since one player can die and drop one of their guns, and someone else can later pick that up for them. It wouldn’t be polite not to give your partner’s weapon back now, would it? We don’t know if this will be true for other items. All players within a game have access to the same blueprints and should be able to match each other gear-wise without issues. We’re also eager to experimentation and community feedback in this case. Let’s see what works best for the game together.

Will the players have shared resources, or does everyone have their own?

Both players share resource pools except for ammunition and consumables. We quickly realized that finding out you’re out of ammo despite not shooting your guns a single time didn’t feel good. Everything else apart from ammo and consumables is fair game, though - you can spend your partner’s hard-earned cash on what you like!

Can we get a UI addition of the other players' HP + Shield (maybe equipped weapons as icons) somewhere? So we can see the status of the other players' health etc.

This is something that we can consider when we come closer to release. It is a nice feature - especially if it can be toggled on and off in the options menu.

Does every player have to be on the same map constantly? Or could the host be on the HQ map and the other players on some outposts?

The limitations of the game in its current form force us to have all players on the same map at all times. Otherwise, the server would have to simulate multiple worlds simultaneously, which could be very difficult.

Can the other players characters block my building/shooting if they stand in the way?

There is no friendly fire in The Riftbreaker. If someone stands in front of you when you’re shooting, they will block your shots but take no damage. Coordinating movement in combat is going to be very important! The same goes for buildings - you won’t be able to place a building if another person is blocking the grid.

Will we get some rank names or icons above our player mech, i.e., to show how many multiplayer matches we have played already?

We do not currently perceive the co-op mode for The Riftbreaker as a competitive experience. We do not plan on introducing any sort of level or rank progression. That being said, this might change as we develop the game further. Time will tell!



[h3]Crossplay[/h3]

Crossplay between PC and console platforms will not be possible. Crossplay between different PC store fronts i.e. Steam/Epic/GOG should be possible, but this is still to be confirmed.

[h3]Hosting[/h3]

Do you need to have bought a copy of the Riftbreaker to host it?

To play The Riftbreaker in co-op mode, all players must have purchased their game copy.

Will we get a tool to host the game "headless"?

The game can run in headless mode - this means that a Riftbreaker server can run on a PC without any visual representation. Whether we can release such an option to the public is yet to be determined, but it would be great for users with less powerful systems. We would really like to have this option available, but we can not confirm it 100%, yet.

Can we rent a beefy virtual server on some website to host The Riftbreaker world?

This largely depends on the previous question. If we can run a separate game server, decoupled from an instance of the game app itself, hosting the game on an external server shouldn’t be an issue—however, no promises for now.

Will we get options/settings for the multiplayer tool? Like an admin interface where we can toggle cheats for players, give resources, enter commands, set options for what happens if the game is over, etc.

You will get access to our standard Sandbox Menu, which already provides most of these options for you. We are likely going to expand it with a couple of co-op-centric parameters.

Can we kick/ban people, so they don't disturb others?
The host will receive simple moderation tools, such as ban/kick. You can’t do without them!

[h3]Modding / Mods[/h3]

Are game mods going to be supported in multiplayer? Will custom maps be supported in multiplayer? How will it work?

We would love to allow you to run mods and custom maps in multiplayer. It will likely be possible if we ensure compatibility between the server and the clients. There are two ways we could go about this. We can display a list of mods running on the server and require all clients to download and activate the same mods before connecting to the server. Alternatively, we could transfer mods directly from the server to the client while establishing the connection. We will see which option we have, but we’re optimistic about this.

Will we get access to some backend functions for modding? E.g., Check the current player steamUserId so we can make stuff happen only if a specific user is playing, get their RB play time, get their steamUserIcon, etc.

Giving you access to some additional, co-op-centric lua services is a possibility. However, we don’t know how much we can expose. We must consider that you will interact with other players and their accounts. We don’t want to slip up and leave a door open for some malicious activity. Simple things like player icons and usernames should be readily available, though.



[h2]CONCLUSION[/h2]

We are making excellent progress on the multiplayer version of The Riftbreaker. We are very sorry for the lengthy radio silence and promise to share more updates as time passes. We can not state an exact date when coop will be available, but we have hit a significant milestone that should increase the pace of development by a large margin. You can expect more updates and live previews on our streams at www.twitch.tv/exorstudios. Also, remember that we will hold closed beta tests - the best way to stay informed about them is to follow our news updates and become a member of our Discord server at www.discord.gg/exorstudios. Please feel free to ask any questions about The Riftbreaker Co-Op mode that come to your mind. We will do our best to keep you well-informed from now on.

EXOR Studios