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