The Riftbreaker News

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

This week we have a different kind of news for you. As you know, a high degree of moddability was one of the key aspects of The Riftbreaker throughout its development. Right from the get-go, we wanted you to be able to make changes to existing content and introduce new features with as few problems as possible. After the introduction of the in-game mod browser, along with Steam Workshop and Mod.io integration, tons of cool mods started to come out, and they get better every day.

It’s high time to give something back to our lovely modding community. In collaboration with Mod.io, we have the immense pleasure of announcing the first Riftbreaker Modding Competition! Starting today, you have three months to prepare your best mods and maps for the game for a chance to win valuable prizes in two categories.



This category is for all game modifications that are NOT custom maps, missions, or tilesets. All mods that introduce new game mechanics, buildings, weapons, or other things that significantly alter the way the game is played. Anything that is not a map/tile/mission or a reskin is allowed.

https://steamcommunity.com/sharedfiles/filedetails/?id=2889031236

A good example of a mod that fits this category is Destructible Rocks. The mod does not use any custom-made content (we highly encourage adding new, custom-made content, though!) but gives the players new gameplay opportunities by modifying the game's files. Sometimes simple stuff works best!



Competitors can enter with their custom maps, missions, and tilesets for The Riftbreaker. We encourage you to try using The Riftbreaker Editor Suite to build new adventures for Ashley and Mr. Riggs. Do you have a creative idea for an awesome spot that would fit in one of the Galatean biomes? Or perhaps you want to recreate in your hometown in the game? Or maybe you want to take our heroes to a new biome? This category is for your creations.

https://steamcommunity.com/sharedfiles/filedetails/?id=2944855092&searchtext=

The 'Starfish' map is just one of the examples of the things you can submit in this contest. Thanks to clever use of our assets and the extra building stipulations Survival plays out in a much more different way than usual. Try it out! Also, remember that custom assets are highly encouraged!



[h2]1st place[/h2]


[h3]Custom-built gaming PC with The Riftbreaker design printed on the case. The PC variant will be picked at random.[/h3]

[h2]2nd place[/h2]


[h3]One Sapphire Pulse AMD Radeon 6800 XT 16GB GPU.[/h3]

[h2]1st - 8th place[/h2]


[h3]Mr. Riggs plushie and a set of EXOR Studios gadgets.[/h3]

[h2]Contest Timeline:[/h2]

• Competition Start Date: March 10th, 2023
  
• Submissions Close: June 10th, 2023, 00:00 AM GMT
  
• Winner nominations announcement, community voting start: June 15th, 2023
  
• Community voting end: June 22nd, 2023
  
• Competition End Date and Winner Announcement: June 29th, 2023
  

[h2]The Riftbreaker Modding Competition - Rules:[/h2]

• The competition is split into two categories. The first category is ‘Custom Maps.’ Competitors can enter with their custom maps, missions, and tilesets for The Riftbreaker. The second category is for ‘Game Modifications’ - all other mods fall under this category.
  
• All mods submitted to the competition must comply with our rules of modding conduct.
• Reskins and rebalances are not allowed to participate. Each mod must introduce new functionalities or make creative use of assets already available in the game.
  
• Mods created before the contest starting period are allowed to participate.
  
• Mods must be self-contained and downloadable through the in-game mod browser through Mod.io and, optionally, through the Steam Workshop.
  
• Participants must enter their mods to the competition using this form before the deadline, which is June 10th.
  
• After the deadline, EXOR Studios will create a shortlist of the best mods in both competition categories.
  
• If one of the mods that get on the shortlist in either category cannot, for any reason, be uploaded to Mod.io, EXOR Studios is granted permission to upload the mod in an unchanged form to mod.io. Additionally, if a shortlisted mod is only available on Mod.io, EXOR Studios is granted permission to upload the mod in an unchanged form to the Steam Workshop. The creator retains all rights to their mod - we simply want users from all platforms to be able to access the best creations. We strongly encourage all modders to upload their creations to both Mod.io and Steam Workshop to maximize their audience.
  
• A public vote will be held using an easily accessible platform (TBD) where the community can decide which of the shortlisted mods should receive prizes.
  
• Over the course of the voting period, EXOR will prepare articles and stream the shortlisted mods, highlighting their best features.
  
• After the public vote, the winners are awarded computer hardware.
  
• Participants are responsible for ensuring that their mods remain in compatibility with the live version of the game, at least for the competition duration time.
  
• Teams can enter the competition. However, the prizes remain the same for both individuals and teams.
  
• Only one entry per person is accepted. If an individual is part of a team, they may not send in an additional solo project.
  
• The contest is open worldwide.
  
• EXOR Studios employees and affiliates are not allowed to participate in the contest.
  
• The contest is bound by the contest’s Legal Terms and Conditions.
  

[h2]Submission Form can be found here.[/h2]

We hope that this competition will unleash the talent of our modding community and facilitate the creation of tons of more amazing content. We can’t wait to see what kind of craziness you come up with this time. If you have any questions or need help - please do not hesitate to ask us for assistance at www.discord.gg/exorstudios or anywhere else - the Steam Discussions, comments, and all other places where you can find us are fair game. We're here to help!

EXOR Studios

In our previous articles, you have already learned about the two first creature species you will face in the Crystal Caverns biome. Crawlogs and Gulgors are native to the Galatean cavern systems. The natural process of evolution helped them adapt their bodies to the conditions of the biome. However, you can clearly see that they also became affected by the strange crystalline formations that seem to spread all over the caves. In fact, the crystals’ influence seems to be spreading to the surface of Galatea.

https://store.steampowered.com/app/2108630/The_Riftbreaker_Into_The_Dark/
WISHLIST THE NEW EXPANSION HERE!

As you will learn today, Gulgors and Crawlogs were not the only creatures that came into contact with anomalous crystals. It turns out that creature species usually found on the surface of Galatea 37 are also susceptible to ‘crystal corruption.’ The afflicted creatures do not live in the caves, but it doesn’t stop them from venturing into the tunnels whenever the natural order is disturbed. Let’s take a look at some of the Galatean creatures, which seem to be the most affected by the new, mysterious threat!

Look what they've done to our rabid space dogs...

The Canoptrix are some of the most common species of Galatean creatures. It is no surprise that some of them eventually came into contact with the crystalline growth, resulting in their mutation, although it might not be the right word here. The affected Canoptrix have crystals bursting out from their insides, tearing out pieces of flesh. In fact, their bodies seem to be rotting altogether, exposing bones and the extent to which the crystals have taken over their insides. It is unclear whether the Canoptrix are even alive at this point. The crystallized specimens are more deadly than their regular counterparts, so be careful studying them.

They might look undead, but their interest in your activities on Galatea is more alive than ever!

Despite changing their protective shell, Arachnoids are still pretty agile.

If Canoptrix got affected by this phenomenon, it is no surprise that Arachnoids have as well. This can lead us to the conclusion that the ‘ground zero’ for the crystal disease lies somewhere in the Galatean jungle. Arachnoids seem to have been changed to an even greater extent than the Canoptrix. Due to the crystal’s influence, they seem to have shed their chitinous armor and grown a new protective shell made entirely from these crystals. The brand-new armor is much more robust than the old shell, making these Arachnoids more resilient. Additionally, this strain no longer shoots acid from the glands on their tails. Those projectiles have been replaced with razor-sharp crystal shards. Revise your tactics accordingly!

Crystallized strains of Arachnoids are much tougher than the ones you regularly meet in the Tropical Zone.

Blue suits the Stregaros. Really brings out the yellow eyes.

One would expect that Hammerroceroses would also fall victim to these mutations, but that is not the case - perhaps it’s due to their sheer size. It would be difficult for a 5-meter-tall beast to wander around cavern tunnels. Nature filled that void with Stregaroses. Given that this species is not native to the Tropical zone, it is unclear if the crystalline growth spread as far as the Radioactive Desert region, or if this is a new species altogether. Similarly to the Arachnoids, Stregaroses' chitinous carapace has been replaced with crystals. These creatures prove to be the most dangerous in narrow, cavernous passageways. When in a group, Stregaroses can put up a shield that will be difficult to break through. That will allow creatures in the backline to effectively siege your outposts in the Crystal Caverns biome.

You can actually stumple upon Stregaroses in the Caverns, but we don't recommend it.

As you can see, the Crystal Caverns biome is going to offer a unique challenge not only thanks to its layout but also due to the variety of creatures you are going to face. Still, these are not the most dangerous species that will stand in your way. Be on the lookout for more news in the coming weeks, and join our streams every Tuesday and Thursday for exclusive previews! Follow www.twitch.tv/exorstudios and join www.discord.gg/exorstudios to get the latest info all the time.

EXOR Studios