We switched from synchronizing snapshots of the entire world to updating only the entities that changed in a significant way. Instead of synchronizing the entire client’s world with the server, we limited the number of entities by including just the ones currently visible on the screen. That’s when the first optimizations started materializing. Synchronizing an empty map with just two mechs running around took as long as 400 milliseconds per update! This was, of course, the first “brute force” prototype. That alone revealed how much work we had ahead of us. Step by step, we began synchronizing models, particles, and animations. The first layer of the game that we started transferring was the visuals. As soon as that was one, we started the process of synchronizing entities between the two worlds. Each ran independently, which was a significant milestone but still far from our goal. We started small - simply by running two Riftbreaker apps on the same PC. This library allowed us to establish a connection between two game instances - we first achieved that in mid-April 2022.
We made sure that it would support all platforms. Don’t be afraid of the name ‘Valve’ there - this library is cross-platform and is not tied to the Steam ecosystem. It’s an open-source solution that you can check out here. The first step was to port and implement the Valve Networking Sockets library into the Schmetterling engine. Īfter settling on the client-server architecture, it was time to start laying the groundwork - the process began in February 2022. If you would like to dive even deeper into the world of multiplayer game architecture, here’s an article we can recommend. However, this method comes with many problems we have to deal with anyway - but more on that later. This is why we decided on the client-server architecture, eliminating that issue. A lot of things are simulated in The Riftbreaker every second, and ensuring determinism seemed very difficult. We were unsure whether we could pull this off or even if it was possible in the first place.
For example, we would need to guarantee that a group of creatures attacking your base would always follow the same path and behave the same way (provided that all other conditions were the same in all cases). The latter option would require us to make absolutely sure that the game would always behave in the same, 100% predictable manner.
THE RIFTBREAKER PS5 REVIEW CODE
It would come at the cost of refactoring a substantial portion of game code and restructuring the engine, but we believe it will be well worth it.īuilding is more efficient when there's two of you!īefore doing any kind of development work, we had to settle on the sort of architecture the multiplayer module was going to run on. We know that making this decision this late in the development cycle wasn’t the perfect solution. However, thanks to The Riftbreaker’s popularity and your support, we were able to pull the trigger and start working on the multiplayer mode after the game’s 1.0 launch. We decided to limit the scope of the game to single-player only. Since we are an entirely self-funded Small Indie Company™, we knew that implementing co-op was just beyond our reach. The Riftbreaker project officially began in February 2018. The one caveat is that you need to implement all the changes yourself, and while some are pretty straightforward, others can be slightly more challenging. You can implement basically any feature you want, which is why we were able to significantly improve our game with technologies such as raytraced shadows and ambient occlusion, which were not available when we first started working on the game. We have always enjoyed working with our own technology, as it gives us an unparalleled degree of freedom when it comes to choosing the right tools for the project.
The Riftbreaker runs on our proprietary game engine - The Schmetterling 2.0.
0 kommentar(er)
