The Riftbreaker News

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

www.mixer.com/exor_studios

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

www.twitch.tv/exorstudios

Another topic that the Discord community (which you should totally join - www.discord.gg/exorstudios) wanted to know about is concept art. For those of you unfamiliar with the term, concept art is what our artists produce as a base for their further work. It is created in order to visualize the artist’s ideas to the other members of the team. Then, the artist iterates on their first draft in order to achieve the quality we expect. Today we are going to show you a couple of these ‘first drafts’.



This was the first iteration of Mr. Riggs’ appearance. There were a couple of problems with this version - it looks very heavy and incapable of handling anything but flat terrain. The arm extensions - energy sword and drill - are excessively big and disproportionate to the rest of the body. Moreover, the drill doesn’t look like it could mine anything at all. All these issues have been corrected, and now Mr. Riggs looks much sleeker and agile. In the art, you can also see a drone that was supposed to accompany Mr. Riggs, but we ultimately decided to change the character of drones in the game.



Next up, we have our concept art for Ashley. Admittedly, this is not the first version - we spent a long time figuring out what kind of features we would like to give her. It is, actually, quite close to the final version that we used to create the 3D model. The cybernetic elements stand out a bit too much, and the uniform looks a bit too baggy. Another aspect that required correction was the color scheme of the uniform - we wanted it to fall in line with the main colors that we use in the game - orange, blue and green. All of these issues were fixed in the final render. Now, let’s put Mr. Riggs and Ashley together.



This is one of my favorites (it’s me, voidreaver, the guy who streams!) when it comes to concept art. We wanted to feature Ashley and Mr. Riggs on one piece to show that they are inseparable and both are the protagonists of the game. This scene feels powerful - the giant robot is towering over a mound of slain beasts, while the pilot relaxes after a job well done. The position of the sword seems a little awkward, but that could have been easily fixed. This piece was not chosen to be the key art for the game, however. It suggests that The Riftbreaker is all about fighting, while there is much more to it, but it will remain #1 in my heart forever.

Next time we are going to show you the concept art for some of the creatures and biomes found in the game. We’ll also tell you where the inspiration for those came from. Until then you can find us and ask questions on our Discord - www.discord.gg/exorstudios