The Riftbreaker News

Our past couple of streams from The Riftbreaker featured some modifications to the regular gameplay you might have seen earlier. Apart from customizable difficulty settings, we have also introduced some changes to the way the game plays out. We do that using our mission flow system - it is a set of logic instructions that the game carries out once certain conditions are met. In today’s article, we’re going to show you how it works.

Due to resolution constraints the first and last graph in this article are illegible, but the rest of the images can be read if you use the zoom option in your browser (Ctrl + Mouse Wheel Up in Chrome by default) it will be a lot easier. You can also download the images to view them in full resolution.

Complete view of the mission flow for our survival mission.

We set up the mission flow using a visual editor that represents all the operations in the form of color-coded blocks. Each block contains a set of instructions for the game. They can range from displaying an objective to spawning a massive attack wave. It all depends on the designer. All the events that happen in-game that are not controlled by the AI have to be scripted this way. One could say that it slightly resembles writing a simple computer program, although take that with a grain of salt - you won’t run Doom in The Riftbreaker. ;)



In order to make it a little easier to understand, we’re going to take our survival mission flow as an example. The blocks can be ordered in any way you want, but we like setting them up in such a way that you read them from left to right. We start with the Event Start block. It is our entry point and the start of the mission - the game starts following the instructions. Then, we display the controls screen and spawn the player in. After Mr. Riggs lands, three things happen in parallel. First - we hear the dialogue between Ashley and the AI. Second, the player is given a basic loadout of items and resources. Lastly - the game checks if it is in sandbox mode - if that is true, the player won’t get any objectives and no enemy waves will ever attack.



If the game difficulty is set to a different setting than sandbox, the game will follow the graph further and start giving the player objectives. Pictured above is one of the first objectives in the game - build a Carbonium Factory. As you can see, this graph is separate from the main mission flow. How is it possible that the game knows it should carry out this set of instructions? Well, each of the green ‘Event Graph’ blocks can have an underlying set of operations. Once the mission flow reaches such a block, the instructions within are carried out before progressing further. Here you can see that the game displays dialogues, gives the player an objective and waits for the Carbonium Factory to be built. Once it’s done, the graph reaches the ‘End Event’ block and the whole mission carries on.



Attack waves are also spawned using this method. In survival mode, it happens every couple of minutes. Once it is time for the game to annihilate your beautiful base it will read the data stored in a block just like the one pictured above. This block tells the game which direction it should spawn the enemies from (we don’t specify spawn points, that is up to the random algorithm), what kind of creatures should spawn and in what numbers. Naturally, it’s never just one wave.

Here’s what the entire final wave looks like:

There are about 6000 creatures packed up in those blocks!

Which translates into situations like this one:



Our editor allows us to prepare all kinds of events in the game. We can control the camera, the weather, add events that trigger once you reach a certain spot and much more. We will put them to good use in the Campaign Mode, which is closer and closer every day! It’s also worth noting that we are considering launching the game with access to our map and mission editor, so you will be able to utilize these tools as well. If you would like to learn more about The Riftbreaker join our Discord at www.discord.gg/exorstudios

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

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