Hello Riftbreakers!
Today we would like to share a little bit of a ‘behind-the-scenes’ look at some of our work. This article will tell you what it takes to release a patch for The Riftbreaker. We will give you a step-by-step explanation of all the processes, tests, and verification each of the new builds undergoes. We hope that it will provide you with some valuable insight into how we operate, what kinds of issues we pay special attention to and why patching the Riftbreaker does not happen on a daily basis. It’s a long journey from our hard drives to your gaming devices, so let’s dive into it!
You can't talk about patching without mentioning bugs, so this article is filled with gifs of some weird bugs that happened during development. Here's Mr. Riggs discovering his hidden flight ability, for example.
If you have been following our Discord server for some time, you might have noticed the daily developer changelogs that we publish there. They contain information about all our team's changes to the game over the past 24 hours. Currently, we have three major things we are working on: the World Expansion, the Co-Op mode, and maintenance of the live version of the game. With that many things happening at once, it is natural that we will not want all the changes to make their way to the public version of the game. When it is time to release a patch, we choose the changes we want to include and create an experimental version with those changes only.
Here a Gnerot just decided that they want to slowly dive head-first into lava.
The first step to releasing a new update for The Riftbreaker is always identifying what we want to include in the update. These can be new features, changes to existing systems, fixes, and optimizations. We spend a significant amount of time scouting the Steam Discussions, our feedback and tech support channels on Discord, and our social media to learn about any problems. Sometimes we ask for additional information or a copy of your save files. That helps us find what causes bugs and allows us to prevent them in the future. When our programmers fix those issues, the developer version of the game on our repository gets updated.
A classic 'one zero too many' while setting up effects.
It is now time for an extensive round of testing. We usually focus most on the areas that have seen the most changes. For example, if we have been messing with the liquids system, we will do our best to break it and identify potential issues. Apart from that, we also check if all the game elements are working correctly during a ‘sanity check.’ It is a round of testing covering all the game areas where we found issues before. We make sure that all options work the way they should, all game modes are playable, and we haven’t missed anything important.
We heard you like resources, so here's a resource vein inside a resource vein.
Another area of focus is the save system. To ensure that all the changes that we make will not break the compatibility of your saves, we run automated tests on the experimental version. We have 122 save samples made in the 1.0 version of The Riftbreaker - the very first one that was burned to console discs on the 8th of September 202,1 more than a month before the game was released to the public on October 14th, 2021. Moreover, we prepare a set of save samples from each major game version released later. That quickly adds up to hundreds of tests. Our script loads each saved game individually, then re-saves the same save in the new version of the game and tries to load the updated version of the save file. If there are no issues, the script moves on to the next sample. Rinse and repeat hundreds of times. This automated process takes about 5-6 hours to complete. In the meantime, we do our best to break the save system on our own. We create giant bases, name our save files in a weird way, delete campaigns while playing them, shut the game down while saving - you name it.
No amount of testing will ever beat giving the game to real users. Once we are reasonably confident that the update we are working on should not cause any issues, we post it to the experimental branch so that the community can prove us wrong. Since our players play the game on different machines than ours, and in various ways, they often find bugs that would have otherwise eluded us. We fix those bugs, update the experimental branch and check if there aren’t any new problems as a result of the fixes. After we stop receiving bug reports, we move on to the next step - creating a ‘stable’ version.
This GIF is NOT sped up. They just drank too much coffee.
The major difference between our stable and experimental builds is error logging. The experimental build saves quite a lot of data about potential errors. Our programmers use that additional information for debugging. Unfortunately, that costs a lot of performance. For the “stable” build, we create a separate version of the game’s executables that do not keep track of the debug data. Removing logs might seem like a relatively minor change, but it is more than enough to warrant one final round of testing. We run through our checklist again, and if everything seems okay, we publish the patch.
A classic flickering shadows bug.
When it comes to publishing updates on PC platforms, we can make them public anytime we want. We are in complete control of that process. The matter gets a bit more complicated when it comes to consoles (and PC Game Pass). All changes that we make to the game need to be revised by the console vendors’ internal certification teams. They check if the updated version of the game is still in compliance with all the legal and technical standards. This process takes a couple of extra days, which is why you often see a slight delay between a patch arriving on PC versus consoles.
These Zorants decided they were not interested in fighting anymore. They just left.
‘If you spend so much time testing our builds, why are there still bugs in the game?’ you might ask. Well, The Riftbreaker is a very expansive and open-ended game. You can play any way you like and create strategies we have not even thought about while developing the game. With thousands of players trying out new things every day, some of them will inevitably run into errors we had no idea about. This is why the data from our crash reporter is so valuable to us - it allows us to figure out where we made a mistake and fix it in the next patch.
We hope you learned something interesting about our update process, and it has become a bit clearer why game patches don’t usually happen overnight. Let us know about any other aspects of game development you would like to read about. Perhaps one of these articles will inspire you to try a career in game dev?
See you next time!
EXOR Studios