Riftbreaker - Live on Twitch
www.twitch.tv/exorstudios
The Riftbreaker News
Benchmarks and how we use them
When you work in an indie studio, you often find yourself needing to do a couple of things at once. We sometimes have to become testers/accountants/electricians/cleaners for a day. That’s what makes this job so fun - you never know what the next day is going to be like. That being said, in order not to become buried in repetitive tasks we automate some processes. One such process is benchmarking and that’s what we are going to tell you about today.
Visit r/programmerhumor subreddit for more quality content.
Benchmarking is the process of measuring the performance of a game or app. Every night, once the clock strikes midnight, one of our buildmachines wakes from its deep slumber, builds the game package (fresh .exe + all the assets) and runs a series of automated tests. We built tools into The Riftbreaker that output all the data in a form that is easily readable for regular human beings. We also accumulate all the results on our build management server in the form of graphs.
We already showed you this sad corner of tech and dust - it runs our benchmarks every night. The pink pony makes sure it does.
Our benchmarks are scripted scenarios that are intended to run in the same, or at least predictably similar way every time. The first one simply opens the app and shuts it down, measuring the time necessary to perform these actions. Then, we have two battle scenarios - one with a reasonable amount of enemies and one with an endless horde attacking a huge base. These tests show us the game’s performance in low-intensity and high-intensity scenarios.
We test the performance in high-intensity scenarios...
There are several reasons why we conduct these tests with such regularity and pay close attention to the results. First of all, the successful completion of each of the benchmarks lets us know that the game is working properly. With more than 10 people committing changes to the game every day it is not always possible to make sure that nothing went wrong. Sometimes a change that worked locally for one of the developers breaks the game for everybody else. Since we run tests every night (we can also run them “on-demand” during the day) we have fresh results every morning. If any of the tests fail we can immediately start fixing the issues, ensuring that we have a new, operational version of the game every day.
...as well as low-intensity ones.
Running tests every day lets us know that all the game elements work the way we intended them to. If any of our changes cause game systems to act incorrectly, the results of benchmarks change drastically. For example, one time when our towers stopped working, the number of enemies left alive at the end of our high-intensity battle scenario increased dramatically. We immediately knew that something was wrong and started looking for solutions.
What is this "GameplayState"? Why does it take so much time? Do we need it? Can we get rid of it?
Apart from making sure that the game works on a macro scale, we also gather individual data for much smaller markers. The cost of every system, measured in milliseconds, is being recorded and plotted on a graph. It allows the programmers to see how their work affects the overall performance of the game. They can see how much time each process takes to calculate everything that is necessary to render the next frame. This method allows us to determine which processes affect performance the most and determine the candidates for further optimization. We also measure the overall loading time of the game and take measures once it becomes way too long for comfort.
The loading time of the game since the very beginning. More content makes the game take longer to load, but we will find a way to improve it.
At the moment we run benchmarks on one PC configuration only. Later in the development cycle, we are going to run benchmarks on more machines, both high and low-end, as well as consoles to ensure that the game runs properly on as many hardware configurations as possible.
There is one idea we are toying with and we would like to ask for your opinion here. A lot of games have a built-in benchmark that lets you quickly check how well your PC will handle the selected settings. That’s useful, but there is nothing more you can do with that information. Would you like us to introduce ‘benchmark leaderboards’ and let you compete with other users for the highest score? Let us know in the comments and on our Discord! www.discord.gg/exorstudios
That’s everything for today. Take care and see you next time!
Other social media:
www.facebook.com/exorstudios
www.twitter.com/exorstudios
www.mixer.com/exor_studios
www.twitch.tv/exorstudios
www.youtube.com/exorstudios
Visit r/programmerhumor subreddit for more quality content.Benchmarking is the process of measuring the performance of a game or app. Every night, once the clock strikes midnight, one of our buildmachines wakes from its deep slumber, builds the game package (fresh .exe + all the assets) and runs a series of automated tests. We built tools into The Riftbreaker that output all the data in a form that is easily readable for regular human beings. We also accumulate all the results on our build management server in the form of graphs.
We already showed you this sad corner of tech and dust - it runs our benchmarks every night. The pink pony makes sure it does.Our benchmarks are scripted scenarios that are intended to run in the same, or at least predictably similar way every time. The first one simply opens the app and shuts it down, measuring the time necessary to perform these actions. Then, we have two battle scenarios - one with a reasonable amount of enemies and one with an endless horde attacking a huge base. These tests show us the game’s performance in low-intensity and high-intensity scenarios.
We test the performance in high-intensity scenarios...There are several reasons why we conduct these tests with such regularity and pay close attention to the results. First of all, the successful completion of each of the benchmarks lets us know that the game is working properly. With more than 10 people committing changes to the game every day it is not always possible to make sure that nothing went wrong. Sometimes a change that worked locally for one of the developers breaks the game for everybody else. Since we run tests every night (we can also run them “on-demand” during the day) we have fresh results every morning. If any of the tests fail we can immediately start fixing the issues, ensuring that we have a new, operational version of the game every day.
...as well as low-intensity ones.Running tests every day lets us know that all the game elements work the way we intended them to. If any of our changes cause game systems to act incorrectly, the results of benchmarks change drastically. For example, one time when our towers stopped working, the number of enemies left alive at the end of our high-intensity battle scenario increased dramatically. We immediately knew that something was wrong and started looking for solutions.
What is this "GameplayState"? Why does it take so much time? Do we need it? Can we get rid of it?Apart from making sure that the game works on a macro scale, we also gather individual data for much smaller markers. The cost of every system, measured in milliseconds, is being recorded and plotted on a graph. It allows the programmers to see how their work affects the overall performance of the game. They can see how much time each process takes to calculate everything that is necessary to render the next frame. This method allows us to determine which processes affect performance the most and determine the candidates for further optimization. We also measure the overall loading time of the game and take measures once it becomes way too long for comfort.
The loading time of the game since the very beginning. More content makes the game take longer to load, but we will find a way to improve it.At the moment we run benchmarks on one PC configuration only. Later in the development cycle, we are going to run benchmarks on more machines, both high and low-end, as well as consoles to ensure that the game runs properly on as many hardware configurations as possible.
There is one idea we are toying with and we would like to ask for your opinion here. A lot of games have a built-in benchmark that lets you quickly check how well your PC will handle the selected settings. That’s useful, but there is nothing more you can do with that information. Would you like us to introduce ‘benchmark leaderboards’ and let you compete with other users for the highest score? Let us know in the comments and on our Discord! www.discord.gg/exorstudios
That’s everything for today. Take care and see you next time!
Other social media:
www.facebook.com/exorstudios
www.twitter.com/exorstudios
www.mixer.com/exor_studios
www.twitch.tv/exorstudios
www.youtube.com/exorstudios
Riftbreaker - Live on Mixer
www.mixer.com/exor_studios
Early Concept Art for The Riftbreaker
Before any real work on the project such as the Riftbreaker can begin, you need to have at least some idea about what you want it to look like. Using only words to describe your concept is not enough. You leave room for misinterpretation and don’t set clear goals for the rest of the team. In order to avoid such occurrences, we spend a lot of time looking for references in other games and art pieces. Combining the elements that we like with our own ideas creates concept art that allows us to get down to work. We’re going to show you a couple of such pieces today.
This is one of the first concept art pieces for the game. We always knew that we wanted to make The Riftbreaker an isometric strategy/shooter with a giant robot as the playable character. However, we didn’t know what the environment should look like and what we can do to make Galatea 37 look and feel alien. This is what our artists came up with and it became the reference point for the space jungle biome. Now, let’s try to show it in isometric view.
Roy*, this doesn’t look alien to me. Can we dial up the alien-ness a little?
Muuuuuuuch better. We used the model of the Juggernaut Mecha from X-Morph: Defense as a placeholder for what would eventually become Mr. Riggs. Such experiments are important, as they show you what level of details you should be aiming for to make the environment come to life. With a reference like this, you can finally start preparing the assets and the tech for the rest of the project.
Naturally, there was a lot of concept art that was made before the production of the game began. Some pieces were scrapped entirely, while the others had useful elements that we decided to incorporate into the game. Here you can see one of the elements that didn’t make the cut - the portal (blue thingy in the middle). The fact that I had to add the parenthesis to explain what that thing is should tell you why. ;)
And the 'final' product - the result of months of design and iteration (it will probably change a lot before we release the game, though). You can still see some of the elements from the pictures above. The hours invested into preparation of concept really pay off in the long run.
That’s all for today. Hope you enjoyed this short dive into The Riftbreaker history. You can always learn more on our Discord - www.discord.gg/exorstudios.
See you next week!
*Name changed on purpose. We don’t have a Roy in our studio yet.
Other social media:
www.facebook.com/exorstudios
www.twitter.com/exorstudios
www.mixer.com/exor_studios
www.twitch.tv/exorstudios
www.youtube.com/exorstudios
This is one of the first concept art pieces for the game. We always knew that we wanted to make The Riftbreaker an isometric strategy/shooter with a giant robot as the playable character. However, we didn’t know what the environment should look like and what we can do to make Galatea 37 look and feel alien. This is what our artists came up with and it became the reference point for the space jungle biome. Now, let’s try to show it in isometric view.
Roy*, this doesn’t look alien to me. Can we dial up the alien-ness a little?
Muuuuuuuch better. We used the model of the Juggernaut Mecha from X-Morph: Defense as a placeholder for what would eventually become Mr. Riggs. Such experiments are important, as they show you what level of details you should be aiming for to make the environment come to life. With a reference like this, you can finally start preparing the assets and the tech for the rest of the project.
Naturally, there was a lot of concept art that was made before the production of the game began. Some pieces were scrapped entirely, while the others had useful elements that we decided to incorporate into the game. Here you can see one of the elements that didn’t make the cut - the portal (blue thingy in the middle). The fact that I had to add the parenthesis to explain what that thing is should tell you why. ;)
And the 'final' product - the result of months of design and iteration (it will probably change a lot before we release the game, though). You can still see some of the elements from the pictures above. The hours invested into preparation of concept really pay off in the long run.
That’s all for today. Hope you enjoyed this short dive into The Riftbreaker history. You can always learn more on our Discord - www.discord.gg/exorstudios.
See you next week!
*Name changed on purpose. We don’t have a Roy in our studio yet.
Other social media:
www.facebook.com/exorstudios
www.twitter.com/exorstudios
www.mixer.com/exor_studios
www.twitch.tv/exorstudios
www.youtube.com/exorstudios
The Riftbreaker - Live!
www.twitch.tv/exorstudios