May 19, 2023

The Riftbreaker Experimental Update, May 19th, 2023

The Riftbreaker - voidreaver

Hello Riftbreakers!

We have just updated the experimental branch of The Riftbreaker for beta testing purposes. This update brings some significant changes. Apart from the additions we have managed to finish working on over the past couple of days, it also includes gameplay changes, stability fixes and performance optimizations, all thanks to your feedback. Thank you for that!

However, the biggest and the most visible part of this update is our brand-new volumetric lighting system. For the past couple of months we have been quietly working on this feature, hoping we would get it before the launch of the World Expansion II - and we did! Volumetric lighting allows us to simulate fog, dust and aerosols in the air and their interactions with the lights. The results are pretty spectacular. The character of the distance fog has changed significantly - it is softer an more natural. You can also see beams of light as they travel through the dusty air. It looks especially great in the Caverns biome!

You can observe the effects of the new lighting system on all biomes in the game. It is the most prominent in the caverns, but we think that other areas also benefitted from this change. This feature is available both on DirectX 11 and DirectX 12 systems and is enabled by default. We're looking forward to hearing what you think about this.

This update is (most likely) incompatible with any current mods. Please remove all mods before playing. MAKE SURE TO MAKE A BACKUP COPY OF YOUR SAVE FILES! Make a copy of 'The Riftbreaker' folder from your documents and keep it safe.

With all these warnings out of the way, here’s how to access the experimental branch:

create a backup copy of your save folder (Documents/The Riftbreaker)
disable Steam Cloud save backup for The Riftbreaker
go to your Steam Library
right-click on The Riftbreaker
select 'Properties,’ then 'Betas,’ and use the following password: IknowWhatImDoing

After that, you will be able to choose 'experimental' from the drop-down menu. Download the update, play the game, and let us know if you encounter any issues. We also have a channel on our Discord: #rb-experimental-feedback - we highly encourage you to join in and share your feedback.

The Riftbreaker World Expansion II Beta Update, May 19th, 2023. Changelog:

The listed changes are the differences between the versions from May 16th and today.

Graphics

Added volumetric lighting. This rendering technique adds advanced lighting effects to the scene to better simulate fog, air density and other aerosols. It allows the viewer to see beams of light shining across the environment. All biomes in the game have been updated with the new lighting and fog settings. This option is enabled by default for all users, as it is compatible with both DX11 and DX12 systems and its performance impact is negligible compared to the visual benefit. This option can be disabled in the setting menu.

Features

Added a cheat command: cheat_buildings_ignore_limits. It will allow you to build any number of cap-limited buildings, such as traps, armories or communication hubs.
Added a cheat command: cheat_unlimited_activations. It will allow traps to stay functional indefinitely, with no activation limit.
Added support for destructible rock patterns and light mask materials spanning over multiple tiles. You can now create custom masks that are larger than one tile when creating modded maps in Crystal Caverns biome.

Changes

Changed the location of the light sources attached to player's mech to work better with the new volumetric lighting model.
Building limits for traps are now local instead of global. Traps set in one outpost do not count towards your limit on other ones.
Traps that have depleted all their charges now leave ruins that can be easily repaired.
The bodies of dead enemies disappear much faster if they're lying near traps.
Traps can now be overriden with other traps. If you want to replace a fire trap with an acid trap you no longer need to deconstruct the first - just place the new one on the old one.
The visual effect of the fire trap is now less bright.
Traps can't be accidentally destroyed by explosions or 'stomps' of large creatures.
Changed textures of most traps to easily distinguish between the different types.
Taking your suggestions into account, Crystal Walls now automatically rebuild themselves after being destroyed. If a piece of Crystal Wall is brought to ruin, it will regrow back to its former self after 60 seconds. The wall won't be at full HP, however, it will regenerate over time as long as it doesn't take damage. Thanks to our community member, Piisfun, who suggested this feature!
Sounds for Lava Gun, Crystal Gun, Spitters, Bouncing Blades, Pickaxe, Sonic Fist, Flamewave, Sonic Blast and Crystal Walls have been added.
Added a new model for Sonic Fists of all rarity levels.
"Fire" type enemies will no longer set other units on fire by simply touching them.
Added icons for the majority of research items.

Fixes

Fixed a crash in ResourceSystem.
Fixed a crash in ResistanceComponent.
Fixed a crash when trying to load save files from a very old version of the game.
Fixed a crash in DiscoverableSystem.
Fixed a crash in HudEquipment system.
Fixed a crash in FireArtilleryAmmo method.
Fixed a crash in building_creator.lua script.
Fixed an issue that caused Drillgors to follow the player instead of attacking the base.
Fixed an issue that caused Solar Panels to provide fractional energy values when placed on sun spots in Crystal Caverns.
FindService: fix find service methods returns duplicates (thanks @ponomaryow.dmitry).
Fixed the appearance of some of the crystal props after shader changes.
Fixed triggering visual effects on traps.
Removed an unnecessary pointer arrow from the Energy Pylon building.
Fixed a problem that caused Gulgors not to trigger traps.

Remember that the official update is coming your way on May 29th! We hope you enjoy discovering this new part of the game as much as we enjoyed developing it.

EXOR Studios

May 16, 2023

Open Beta Now Live

The Riftbreaker - voidreaver

Hello Riftbreakers!

We would like to invite you all to participate in the closed beta test of Survival Mode in the new Crystal Caverns biome from the upcoming World Expansion! If you have missed the last week’s announcement of the release date, follow this link. It contains all the information about what’s coming to you on May 29th. Now, let’s talk about the contents of this experimental update.

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

The Experimental Beta update allows you to play survival in the Crystal Caverns biome on all difficulty levels. This means full, unrestricted access to all the new monsters, technologies, weapons, and game mechanics, including wall excavation. We would love to hear all your thoughts about the new biome and what you think we should improve ahead of release. This update also allows you to try out the new technologies in other biomes of Galatea 37 - the research trees have all been updated to accommodate the 70+ new tech items. All of this content will come to you as a free update on May 29th.

This Beta does not contain any new Story Campaign content. That will be a part of the paid Into the Dark DLC, and we want to keep it secret until release. There’s some pretty sweet stuff waiting for you in this expansion!

Please note that this is a beta test. Many things are still unfinished, unbalanced, or use placeholder assets. Errors are expected. The game might crash or break - please report all such instances to us either on the Steam Forum or our Discord at www.discord.gg/exorstudios. We have already fixed a lot of issues during the closed beta period, so you should be fine, but it’s always good to keep that in mind.

This update is (most likely) incompatible with any current mods. Please remove all mods before playing. MAKE SURE TO MAKE A BACKUP COPY OF YOUR SAVE FILES! Make a copy of 'The Riftbreaker' folder from your documents and keep it safe.

With all these warnings out of the way, here’s how to access the experimental branch:

create a backup copy of your save folder (Documents/The Riftbreaker)
disable Steam Cloud save backup for The Riftbreaker
go to your Steam Library
right-click on The Riftbreaker
select 'Properties,’ then 'Betas,’ and use the following password: IknowWhatImDoing

Since we have already conducted some closed beta tests with our Discord members, we have two changelog versions for you. The first is a full changelog with the full contents of the update. This is meant for everyone who has not played Crystal Caverns yet. The second changelog contains fixes and changes we have introduced since the last beta. This one is meant for those of you who have already played the update. We hope that dividing the changelog into these two versions will make it easier for you to find the information that you want.

The Riftbreaker World Expansion II Experimental Beta, May 16th, 2023. Click 'Show Details' for Changelog:

[expand type=details]
New Features and Content

New Survival Mode Biome: Crystal Caverns - a new survival mode map taking place in an entirely new underground biome. It introduces a completely new rock excavation mechanic - you will have to make room for your base and you will be able to shape the terrain to your advantage. Resources are plentiful, but traditional ways of generating electricity work only to a limited degree. You will have to develop an entirely new set of skills to survive in the cavern system beneath the surface of Galatea 37. The new biome comes with a complete set of new species of flora, fauna, as well as new technologies - all described below
New Creature: Crawlog. A fast, relentless melee attacker that may rise up from the dead if you leave its body intact.
New Creature: Gulgor. A slower, more bulky creature that prefers to attack from a safe distance. Shoots volleys of cryo-damage projectiles.
New Creature: Necrodon. A mysterious, menacing support creature that lurks the caves of Galatea 37, summoning crystallized versions of Galatean creatures, as well as resurrecting fallen ones. You might have seen it in some places around Galatea 37 before - it has received a significant reward.
New Creature: Drillgor. It's a very large creature that rushes for the player's headquarters at the beginning of each attack wave, drilling a tunnel for the other creatures to follow. It will generally ignore the player and tries to dig in a straight line.
New Creature Variant: Cave Gnerot. It's a Gnerot strain that adapted to living in the new biome and taken on a new form of camouflage.
New Creature Variant: Crystaros. It's a species that is quite similar to Stregaros, but dropped its chitinous carapace in favor of utilizing crystalline growth as its armor.
New Creature Variant: Canomortus. Its origins are unknown, but the creature resembles a reanimated corpse of a canoptrix and shares most of its behavior and properties.
New Creature Variant: Arachnomortus. Similarily to Canomortus, this creature seems to be a reanimated husk of a regular Arachnoid. However, instead of secreting acid from its tail gland, the creature can form crystal shards to shoot at enemies instead.
New ambient creatures of the Crystal Caverns biome - Crysders and Crystugs - have been added to the Crystal Caverns biome. Crystugs are distant relatives of the Moltug species. They carry beautiful, crystalline 'shells' on their backs.
Added a new type of resource deposit - Wind Tunnel. It's a spot of increased wind speed that allows the player to take advantage of wind power in the Crystal Caverns biome.
The ruins system is now complete and enabled by default. Destroyed buildings will leave ruins behind that can be reconstructed into the original building for their full resource cost and build time using the repair tool. Ruins stay behind indefinitely, so you don't have to worry about them disappearing on you. Ruins can be removed using the deconstruction tool.
Expanded research tree with 75 new research items. [WORK IN PROGRESS - items are missing their icons and some research is not functional yet]
Added a new building category - Traps. Traps are completely flat structures that trigger when an enemy steps on them. Traps have a veriety of different effects that will help you defend your structures from incoming attacks. They do not require ammunition or energy to operate. There are 6 distinct trap types available, some of them can be researched while some are available as bioanomaly reward unlocks. [WORK IN PROGRESS - placeholder icons, not balanced]
Added a new tower - Loot Collector Drone Tower that spawns drones that collect loot for the player within the operating radius of the tower.
Added a new tower - Acid Spitter Tower. This liquid-based tower shoots acid projectiles that do not deal any direct damage. Instead, they leave trails of acid on the ground that deal acid damage to enemies walking through them.
Added a new building - Automated Resource Excavator that spawns drones which collect resources of all types withing the building's area of operation. This is a universal resource collector building, that can operate on multiple resource deposits, but with lower efficiency than specialized buildings.
Added a new building - Energy Pylon. This building is used to connect separated energy grids to the main energy grid in a given location. It has a long construction time and is relatively expensive, but it enables easy maintanance of remote bases without the need of creating very long power lines. [WORK IN PROGRESS - temporary mesh]
Added a new projectile weapon: Bouncing Blades - The weapon shoots a spinning blade disc that pierces through enemies and bounces after colliding with walls. [WORK IN PROGRESS - not balanced]
Added a new projectile weapon: Crystal Gun. This weapons shoots crystal projectiles that deal physical damage and shatter into another projectile upon hitting the target. The 'splinter' projectiles deal 100% of the damage of the original. [WORK IN PROGRESS - not balanced]
Added a new projectile weapon: Lava Gun. Shoots a fireball that explodes on impact, dealing area damage, as well as setting enemies on fire. [WORK IN PROGRESS - not balanced]
Added a new weapon: Fire Spitter. This weapon shoots projectiles that deal no impact damage, but set the impact area on fire. That location burns for a while,delaing fire damage to enemies and setting them on fire as well. [WORK IN PROGRESS - not balanced]
Added a new weapon: Acid Spitter. This weapon works very similarily to the Fire Spitter, bud deals acid damage instead. [WORK IN PROGRESS - not balanced]
Added a new weapon: Cryo Spitter. Same case as the two weapons above, but with cryo damage and a slow down effect this time. [WORK IN PROGRESS - not balanced]
Added a new melee weapon: Sonic Fist. They are slower compared to the regular power fists and deal physical damage instead of energy damage. However, they have a longer effective range, as each hit propels a small shockwave in the direction of the attack, dealing damage to enemies further back from Mr. Riggs. [WORK IN PROGRESS - not balanced]
Added a new melee weapon: Seismic Pickaxe. It's a weapon that is similar to the Hammer, but deals area damage in a different manner. Instead of dealing damage in a large radius, the impact force is focused forward, creating a narrow, but long shockwave. [WORK IN PROGRESS - not balanced]
Added a new Mech Upgrade: Gathering Tools - Installing this upgrade module gives Mr. Riggs a loot collecting drone, increases the mech radar range, and movement speed. Higher quality modules also upgrade other, randomized stats.
Added a new Mech Upgrade: Discovery Tools - Installing this upgrade module gives Mr. Riggs a loot collecting drone, increases the resource drop rate, and mod drop rate. Higher quality modules also upgrade other, randomized stats.
Added a new consumbale - Sonic Grenades. They are much weaker than regular, explosive grenades, but have a higher area of effect. [WORK IN PROGRESS - not balanced]
Added a new consumable: Holo Decoy. Once set, enemies will target the decoy instead of Mr. Riggs. The decoy has a large amount of HP, giving you a chance to escape from a tough fight or to target a specific enemy.
Added a new consumable: Cryo Sentry. It's a cryo damage counterpart of the regular sentry tower consumable.
Added a new consumable: Flare. It's a throwable item that shines a bright light on the surrounding objects. It can be useful during exploration of dark places, where you can't set up permanent lighting.
New Skill: Flame Wave. It will send a travelling wall of flames in the direction that Mr. Riggs is facing, dealing massive fire damage to enemies.
New Skill: Antimatter Ball. It sends a ball of antimatter (duh) that explodes on contact with an obstacle and deals energy damage to all enemies in its vicinity as it is travelling through air.
New Skill: Generator Overcharge. It sends an energy shockwave to stun and damage enemies and boosts the Force Shield recharge speed.
Completing Campaign Outposts for the Volcanic Area, Radioactive Desert and Acidic Plains will grant the player a reward in a form of unlocking a unique blueprint. The unlock will persist across game saves.
Crafting costs have been added for new weapons, items and consumables.
Added three new skins for Mr. Riggs as rewards for; completing the Into the Dark Story Campaign, completing Survival Mode in the Crystal Caverns biome, as well as one that is unlockable via bioanomaly drop.
Added new cosmetics: Crystal Floor. Obtainable from opening bioanomalies.
Added new cosmetics: Crystal Lamps. Obtainable from opening bioanomalies.
Added a new bioanomaly variant for the Crystal Caverns biome.
Added a new random encounter event - Crystal Growth. For a limited period of time crystals grow rapidly in one location on the map, allowing you to quickly gather a large amount of rare resources.
Added a new random encounter event: Falling Stalactites. Similar to meteor shower - stalactites start falling from the cave ceiling and deal damage to all objects in the affected area.
All new species have been added to the bestiary. There are no descriptions yet, but all the functional info and images are there.
Added multiple new map tiles for the Jungle, Acid, Magma and Desert biomes to improve map variety.

Changes

Resources, bioanomalies and other points of interest that are detected using radar will show up as 'unknown' on the minimap. They will change to their regular minimap icons once they are observed directly. This change affects all biomes, so we would love to hear your feedback on this.
Introduced higher difficulty attack waves for Hard and Brutal difficulties for the Acidic Plains, Radioactive Desert and Volcanic Area biomes in campaign mode. The campaign mode should provide a better challenge now.
Added Metallic Valley biome attack waves to the HQ attack pool after completing the Metal Terror Campaign.
Added difficulty level scaling for the Shegret attack event. It happens more oftern in the Crystal Caverns biome and is more significant than it used to.
Flammable objects will now catch fire from incidental sources, such as burning debris spawned from explosions. Even more wildfires!
Stone and Metal-based lifeforms are no longer flammable.
Changed the Carbonium Power Plant energy output from 50/100/150 to 60/120/180.
Increased the Arachnoid Sentinel 'agressive' state trigger distance to match other species.
Introduced a large number of improvements and fixes to our GUI . With these changes, implementing navigation and interaction functionalities should be a lot easier for us, and less buggy.
Volcanic Rock Rain in Magma Survival has been shortened (30-90 seconds changed to 30-60).
Large Cryoplant collisions are now slightly smaller, making it easier to navigate the biome.
Wild Phirians will no longer attack other units on the map.
Bouncing Blades can now cut vegetation.

Graphics

Added a per-object, camera-based object culling system that allows the player to see through tall objects. Rocks will no longer obstruct your view when passing underneath rock arches. All game tiles have been adapted to take advantage of this technique. You can read more about it here.
Rendering upgrade: Tiled Deferred Shading. This rendering technique handles scenes with large numbers of dynamic lights more efficiently. It provides a 10-15% GPU performance boost on average. You can read all about it in our article from a couple of weeks ago.
Improved non-raytraced soft shadows. The shadows now look much more natural and feature a variable penumbra. In human terms - shadows will be sharper and more defined at noon and more subtle in the morning, when the sun is softer.
Added two new loading screen artworks for the Crystal Caverns biome.
Added a custom Rift Station icon for the minimap to make locating it easier, especially in large bases.
Added an 'unknown' marker icon for the minimap. This icon appears when the player has discovered something important with their radar, but has not yet revealed what it is from within the fog of war.
Added a custom minimap icon for bioanomalies.
Changed the icon of railgun towers in the Alien Research tab of the Research screen.

Sound

Added a new music playlist - anticipation. A new set of "anticipation" music, played in a loop to prepare the player for an incoming significant attack wave. At present, it triggers when you upgrade the Headquarters, before each significant attack in the Story Campaign and during the final sequence of the Survival Run.

Fixes

Introduced a huge number of fixes and optimizations to nearly all game systems. Most of the changes we made have been aimed at the multiplayer portion of the game, but they should still positively affect the game's stability and performance.
Made changes to the random volume selection algorithm to prevent objectives from spawning in one area all the time.
Fixed numerous crashes and errors - way too many to list.

[/expand]

If you've played the beta before, this are the changes introduced since the last build.

[expand type=details]
Changes

Manual drilling (using Mr. Riggs' drilling arm) is now much faster thanks to a series of tweaks. It also has an animation!
Destructible wall 'trail' effect fades out faster to increase visibility during digging.
Crystal Gun has been updated with a new model and new projectiles.
Crystal Gun has been moved to the Low Caliber Ammo category.
Crafting costs have been added for new weapons, items and consumables.
Pickaxe now deals area damage instead of physical to enable digging through rocks.
Damage Trail skills of all variants now deal damage more often.
Added an icon for 'Charges Left' stat for traps.
Acid Spitter Towers level 2 and 3 deal more damage.
Loot added to the crystal creeper prototype.
Added plenty of new descriptions and localizations - English and Polish for now.
Spitter projectiles have been updated with physical, deforming meshes.
Spitter weapons now have a new target marker.
All Traps are now fully functional - they have preper damage types, effects, costs. Models are still missing from some of them.

Fixes

Added many materials to precache, which should reduce stuttering during gameplay.
Fixed bugs with mismatching destructible cavern walls.
Fixed a problem that could cause the game log to grow uncontrollably because of a certain character.
Fixed problems that caused the GPU benchmark not to launch properly in previous beta versions.
Fixed the offset of the 'Restart' button on the mission end screen.
Fixed a problem in GUI that caused the last line of the research description to be cut off.
Fixed Flare consumable collisions.
Fixed errors in descriptions and names of certain items.
Fixed the screenshot aspect ratio and alignemnt on the Load Game screen.
Fixed the 'missing' icon size and alignemnt on the Mod Management screen.
Spitter weapons should now display their weapon stats correctly.
Slight change in research tree width to prevent scrollbar appearing after adding new research items.
Fixed animation time statistics for melee weapons.
Fixed effects attachments placement in Acid Spitter Towers.
Hundreds of other small fixes, big fixes and optimizations.

[/expand]

We're looking forward to hearing what you think about the new biome!

EXOR Studios

Apr 7, 2023

Rendering Upgrade: Free FPS for everyone!

The Riftbreaker - voidreaver

Hello Riftbreakers!

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.

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.

Deferred Shading

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.

Tiled Deferred Shading

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:

G-buffer pass - Draw all opaque geometry.
Compute tile frustums - prepare frustums individually per tile depending on the buffer minimum/maximum depth.
Culling lights pass - use frustums to check if the light overlaps the tile and insert its index to the light index list.
Compute light shading for opaque objects - Use G-Buffer and prepared lights list for a single pass screen space light computation.
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.

Results

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.

Test case 1: static scene, adding lights manually one by one.

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.

Test case 2: In-game CPU benchmark mode.

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.

Conclusions and future works

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!

Mar 24, 2023

Designing Map Tiles for the Caverns Biome

The Riftbreaker - voidreaver

Hello Riftbreakers!

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

Mar 17, 2023

Co-Op Status Report

The Riftbreaker - voidreaver

Hello Riftbreakers!

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.

WHAT HAS CHANGED SINCE THE LAST TIME?

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.

MAJOR BREAKTHROUGH

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.

WHAT’S COMING NEXT

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.

ENOUGH OF THE TECH MUMBO JUMBO. GIVE ME THE GAMEPLAY DETAILS!

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.

Gamemode / MP styles

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.

General

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.

Communication

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!

Player

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!

Crossplay

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.

Hosting

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!

Modding / Mods

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.

CONCLUSION

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