Hey there!

We would like to thank you for all the feedback and the positive reception of The Riftbreaker. It’s great to see so many people joining us on our journey every day. Today, instead of our traditional Friday devlog, we would like to present to you an updated version of our official FAQ (Frequently Asked Questions). It has been updated with all the latest information available on the project.

If you happen to have any additional questions, leave a comment or catch us on Discord.

What kind of game is The Riftbreaker?
The Riftbreaker is a base building game with elements of action RPG, exploration and survival.

Is this similar to Factorio and They Are Billions?
A little bit. Both these games served as an inspiration for us, with a little bit of Diablo sprinkled in as well. The list of our inspirations is quite extensive.

What platforms will it be available on?
PC, Playstation and Xbox. Nintendo Switch is not planned at the moment, but it’s not out of the question.

Can I play using a gamepad/mouse/keyboard?
We designed the controls with both keyboard + mouse and gamepads in mind.

When will it be released?
Our current prediction is late 2020. This might change, of course.

Is the release date October 21st?
No. It’s been a running joke in our community because of what Voidreaver said on one of our streams. Here’s the clip - https://www.twitch.tv/exorstudios/clip/FunnyCreativeWolfDoggo

Is it free to play?
No. The Riftbreaker is a premium game, you’ll need to buy it in order to play.

Will it cost $60?
We don’t know the exact price but it will be lower than $60.



Is this Unity/Godot/Unreal?
None of the above. The Riftbreaker runs on our own engine called The Schmetterling.

...but why?
When we were starting out we couldn’t afford a good engine and the free tools were not as good as they are today. We decided to create our own tech and simply kept expanding on it.

How is it that your engine is called The Schmetterling, which is a German word, although you are a Polish studio?
There are two stories behind this. The first one is that it's 'lightweight, beautiful and fast' - just like a butterfly (Schmetterling is a butterfly in German). The second (and the true one) is that the lead programmer thought that the word sounds funny, and we decided to just roll with it.

What are the system requirements for the game?
We don’t have the exact specs yet, but we will do our best to optimize the game well and make it run smoothly on most PCs, not just the high-end ones.

Will there be microtransactions?
Definitely not. There might be DLCs offering additional content, but no microtransactions that allow you to gain an advantage in the game or progress more quickly.

Is there an alpha/beta I can join?
We are planning to launch an alpha test very soon. You can find the link to the application form on our Discord in the #faq channel.

Alpha keys when?
We don’t know exactly. We are planning to release closed Alpha keys in small batches over time. We are currently preparing crash and bug reporting tools for the game. This way you will be able to easily send us feedback, and we will solve your problems a lot faster. We are also finishing a large portion of new gameplay features that we’d like to be included in the nearest update.

Are there any keys out yet?
Yes, a select group of streamers and influencers received a chance to have an early first look at the game. A few people from our Discord community received access as well.

When I get access to Alpha, is the game mine to keep forever?
Unfortunately, no. The test keys will be deactivated before launch. We may decide to gift full game keys to the most active members of the closed testing phase.



Where can I see the unedited gameplay?
We stream from our office twice a week. Tuesdays at 3 PM CET we are live on Mixer. Thursdays, 3 PM CET - Twitch. Follow us to get notifications - www.mixer.com/exor_studios and www.twitch.tv/exorstudios - you can also watch VODs if you can’t watch us live.

Can I stream the game?
Of course! We even have special features to integrate the game with your Mixer/Twitch chat. Simply let us know about your channel in the Alpha application.

What game modes are there in the game?
We are planning a story campaign, a survival mode, and a sandbox mode.

Is there multiplayer?
Not at the moment. We are going to release the game with singleplayer only. After that, we will start working on online coop. We are a small team and need to set priorities - hope you understand. ;)

How long is the game going to be?
We don’t know the exact length of the Story Campaign. A typical Survival Mode run lasts about 60-120 minutes, and you can additionally tweak that number using the custom difficulty settings.

Can I pilot a different Mech?
No. Mr. Riggs is the only Mech in the game, but we are thinking about adding some customization options for you.

Can I change the character I play?
No. Ashley is the only playable character in The Riftbreaker.

Can I upgrade the Mech?
Yes! Researching new technologies and tools to equip Mr. Riggs with will be a major aspect of the game. You can expect a lot of options in that regard.



Can I travel to different planets?
No. The action of The Riftbreaker takes place on Galatea 37, a planet in the distant reaches of the Milky Way. Your task is to prepare it for human colonization, so it will be the only planet you see in the game. There will be plenty of places to visit, so do not worry.

Is there only one map we can play on?
No. The levels are procedurally generated, so each playthrough is going to be different.

Do you visit different places during the campaign?
Yes, the campaign will require you to discover and visit a lot of new biomes. They are treated as separate maps, though, and will be separated by loading screens.

Can we automate things or use drones?
Most of the basic operations, such as resource collection and ammo production do not require any action from the player. You just need to build factories and you’re set. We are also going to give you the option of using drones for some more advanced things.

Can I build an army of automated units to defend my base?
No. In The Riftbreaker you use a variety of defensive towers and Mr. Riggs himself to defeat your enemies. There is no option to build or control other units.

Will there be mods?
We are not going to obfuscate the game file structure at all, so you are free to tweak the parameters any way you want. We will give you access to most or all of our internal game development tools

If you can think of any additional questions we can add to this FAQ, let us know.

Visit us on our social media!

Other social media:
www.facebook.com/exorstudios
www.twitter.com/exorstudios
www.mixer.com/exor_studios
www.twitch.tv/exorstudios
www.youtube.com/exorstudios

Setting up the lighting for the scene plays a major role in constructing the proper atmosphere for the level. It determines how the shadows work, how the light bounces off various surfaces and a ton of other small details that make up the majority of the game’s look and feel. Today we would like to tell you what kind of tools are available to us in The Riftbreaker when it comes to lighting effects. We will also tell you what settings we can change and what it takes to make the most of our game.


There are many ways to set up the directional light, but some of them are slightly... off. The color picker works instantly and we can fix our mistakes on the fly.

We illuminate the game scene using one powerful light source - directional light. Since the action in The Riftbreaker takes place on the surface of the planet Galatea 37, the light usually tries to simulate the behavior of the Sun. ‘Simulate’ is the key word here, because the directional light is always on (with the exception of the night, obviously). The parameters of the light make all the difference here. We can create and save separate presets for the sunrise, the day, the sunset and the night. Blending them with each other over time gives us the day and night cycle, that we discussed earlier.


Thanks to fog we can easily change the mood of the scene.

There are several parameters of the directional light that we can change. The most obvious one is the color. We can pick any color available in the RGB palette in order to change the mood of the scene. The light at dusk has to be different than at midday and this is the setting that makes it possible. We can also adjust the look of the scene by changing the parameters of the fog. Fog allows us to better simulate the effects of light dispersal and how it affects the objects on the scene. We can change the fog’s color, density and the distance at which it becomes visible.


We own the sun.

Over the course of the day, the source of directional light travels across the sky, changing its position as if Galatea 37 really revolved around a star. However, in real life, the sun appears to be in various parts of the sky, depending on your geographic position. If we set up just one orbit for all the maps to use, we would get the same results all the time. That is why we have introduced a set of sliders that change the simulated latitude and longitude of the map’s location. Instead of moving the planet around the star, we do it the other way around. In your face, Copernicus!


See how much of a difference the skybox light makes.

Following the trend of trying to copy the way nature works, we also added a skybox that affects the ambient lighting on the scene. A single directional source of light would essentially leave everything on the unlit side in complete darkness, just like a spotlight in a dark room. The skybox simulates how the atmosphere disperses the light and adds some delicate lighting to the whole scene. The nature of that light will depend on the skybox texture itself and 2 parameters that we control - how much light is emitted, and how much is reflected by the props.


Adding dynamic lights makes the night sceneries much more lively.

On top of our main light source, we can also add smaller, dynamic lights to the scene. They come in two flavors - point lights (they emit light in all directions like a lightbulb - our Base Lamp is an example of one) and spotlights, which are cone-shaped. They are highly customizable. We can change their color, intensity and add custom affectors (conditions that change their behavior, such as light fading in under a fire source, simulating the growth of flames). Spotlights can also add shadows, but it comes with a high performance cost, so we decided to use it only on Mr. Riggs’ spotlights.

That’s the lighting in The Riftbreaker in a nutshell. Naturally, setting everything up just right requires a lot of trial and error, but when you do something you love it’s not that big of a deal. The end effect makes up for all the hours of work! We hope you enjoyed this article. Leave a comment on what you would like to read about in the future. You can do it either here or on our Discord - 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

Designing quests for a video game is never easy. In a perfect world, all the tasks you give to the player would be unique and offer completely new experiences. Realistically, however, the designers don’t always have enough time or means to craft such experiences all the time. Sometimes this results in a lot of ‘generic’ missions being given to the player, such as ‘Bring X items to person Y’, or ‘Kill X monsters’. Such filler missions are sometimes necessary, but the mistake some designers make is settling for this type of mission as the bread and butter of their games.



To avoid pointless grind and repetition in The Riftbreaker, we decided to employ a slightly adapted SMART technique. It is a method for setting personal or professional goals that are specific, measurable, achievable, realistic and time-constrained. This technique helps people easily set well-constructed personal goals, such as ‘I’m going to learn 5 new Spanish words this week’. The same method can be also useful in game design. Today we are going to tell you how these principles guide us while preparing the Campaign Mode for The Riftbreaker. Let’s explore this concept, letter by letter.



S for Specific - The instructions for each mission that we give to the player have to be very clear and give them immediate knowledge of what they are expected to do. If we gave you an objective such as ‘Fortify your base’, you wouldn’t be entirely sure what to do and what counts as fortifying the base. The objective itself is not wrong but lacks information. We can fix it by saying, for example, ‘Fortify your base by building 8 Sentinel Towers.’ When we add this info, our expectations are clear, and so is the path to completing the mission.



M for Measurable - The benefit of completing the objective has to be easily measurable for the player. The Riftbreaker is not an old-school RPG game, where sometimes you are forced to collect 70 kilos of cabbage for a random peasant in order to get 100 XP. Every time you do something, you need to feel the purpose of it. Various metrics can be employed to measure the benefit of completing a quest. The rewards don’t always have to be grand to be measurable and noticeable enough. If you fortify your base before an attack comes, your precious buildings are less likely to be destroyed. If you clear out a nest of monsters, they won’t attack you as often.



A for Achievable - Giving the player a mission that is impossible to complete will lead to frustration, and that’s what we have to avoid. Some games have managed to use impossible quests and pulled off great plot twists by doing so (the first fight with Desann in Jedi Outcast - never forget), but it’s a one-trick pony. You can’t base your game on such missions. All objectives in The Riftbreaker will be possible to complete without jumping through impossible hurdles. If we tell you to build something, we will be sure to give you enough resources. If we tell you to kill something, it will be possible to do so.



R for Realistic - Sometimes, even though the mission follows the previous principles, its expectations can be set too high. A mission such as ‘Build 400 Wind Turbines’ (cheers, dualanalogs!) will most likely result in a quick Alt + F4, followed by pressing the ‘uninstall’ button - even if the player has enough resources to complete the objective. The pacing of missions must leave the player satisfied with their progress, and that is achieved by setting realistic goals.



T - for Time-constrained - This one is optional. Some missions benefit greatly by adding a timer into the mix. The sense of urgency when you have just 2 minutes to prepare for a massive attack is immense. However, that is not the only way you can introduce time constraints to your missions. The Riftbreaker features day and night cycle, which allows us to add dynamics to the wildlife. Some species of flora and fauna will only be discoverable at night, while others will come out when the sun comes up. We can give the player a mission to obtain a sample of a nocturnal creature for research. This naturally constrains the win condition to nighttime only.



The SMART method is just a guideline and it is overruled by the most important principle of them all - BREAK THE RULES! Slightly bending the expectations or twisting the rules can be a lot more fun. Game creators have the power to breathe life into new worlds. Why limit your creativity? We always try to lead the players into unexpected and interesting scenarios, and that’s what you can be sure you will find in The Riftbreaker.

Let us know in the comments what kind of missions you would like to see in the game - we’re always open to suggestions. Join our Discord to discuss everything related to EXOR Studios - 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

Hello everyone!

We often get questions about our sources of inspiration for The Riftbreaker. If you want to know what games inspired us in terms of mechanics, graphics and design - today’s article is for you. We play a lot of games in our free time and our tastes vary from person to person, so there are a lot of titles that we could mention. With that being said, we are going to try to keep the list short, limiting ourselves to the most relevant titles. This should give you an insight into what games we like and, perhaps, what you should play next. ;)



One of the most important aspects of The Riftbreaker’s gameplay is base building. While it could be easy to draw parallels to Factorio, truth be told, that is only a part of the story. We have sunk countless hours in classic RTS games, where base-building and resource management have been the focal point. Total Annihilation, Command & Conquer and Supreme Commander all spring to mind here. Factorio got our attention quite late in the design phase. It showed us that making the base work similar to a living organism, with all the interconnected systems relying on each other facilitates creativity, and that’s what we wanted for The Riftbreaker. What can we say - we love strategy games, especially the ones that support various play styles.



When it comes to combat, there are loads of titles that influenced our game. We loved the mecha-combat against the alien hordes in Alienation, along with the loot and inventory system. Many of us are also fans of action RPG games, such as Diablo, Path of Exile, Grim Dawn and the Van Helsing series. The twin-stick shooter aspect of the game has been decided very early on, as it’s a very intuitive control scheme that works really well for single-character combat. It also supports both the keyboard + mouse combo and gamepads, which is very important for us. In order to make the game more sci-fi and less fantasy, we dropped the level and experience elements from those games, changing them to tech instead. That’s what gave birth to The Riftbreaker combat system.



As for the visual side of The Riftbreaker, all of the games above had their influence on what we wanted the game to look like. One game that we can add to that list is Starcraft. The way that buildings, units and the elements of the background interact with each other is great for the fast-paced, competitive aspect of the Blizzard RTS. However, its visual style is more cartoonish than what we are aiming for, so even though The Riftbreaker looks a little similar, it’s a different beast. We learned many things from Starcraft and you can see that in The Riftbreaker, but our influences are much broader, reaching beyond the world of gaming. Notable examples here are the Halo series, Peter Jackson’s Avatar, as well as nature itself.

This list is not comprehensive, of course. We play various games every day and you can find similarities everywhere. The most important thing is that we spend a lot of time giving The Riftbreaker an identity of its own. We aren’t afraid to look to other great games for inspiration, we try to evolve and innovate on the ideas that made those titles influential. We want the Riftbreaker to be a unique experience worth your attention and time, not just a blend of elements that worked elsewhere. We hope you’ll find out about it hands-on sooner rather than later!

Other social media:
www.discord.gg/exorstudios
www.facebook.com/exorstudios
www.twitter.com/exorstudios
www.mixer.com/exor_studios
www.twitch.tv/exorstudios
www.youtube.com/exorstudios

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

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

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

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

We're a serious company, promise.

Now that you know what our studio looks like and what our responsibilities are, we are going to take a look at how our work is organized. Like every other job in the world, game development has some aspects that can come as a surprise for those who have never investigated what the process looks like. Don’t worry - we’re not going to bore you with unnecessary technicalities, we’re just scratching the surface today. Let’s talk about how our work is organized, what tools we use and what a typical week looks like.


Our team on the stage of PGA Awards.

EXOR Studios is a small company and we have a very friendly attitude towards each other. This allows us to be incredibly flexible when it comes to working hours. The majority of us come to work Monday to Friday and work 8 hours a day. The hours are flexible, though - you don’t have to come at 8 every day, and if you need to leave early that’s fine too. Our core hours are 11 AM - 4 PM. That’s when all of us are in the office - we can hold meetings at this time and consult each other on our tasks. Every Monday we also hold an office-wide meeting, where we share what we did during the previous week and set our priorities for the next one.

We all work on different things at the same time, according to our specialties and current needs of the project. Sometimes these are ‘safe’ changes, completely unrelated to other parts of the game, but others have the potential to cause the butterfly effect (The Schmetterling means butterfly, after all). One small change in code can break the entire game. If we all worked on the same copy of the program we wouldn’t make much progress at all. That is why we use a software versioning system.


This line is not just gibberish. It tells you what version of the game you're playing. You can tell that there have been 9107 versions of game content and the executables have been compiled 2607 times. And we're not in even in alpha yet!

The way it works is quite simple. The current, up-to-date version of the game is being kept safe on our server. We call it ‘head revision’. Each person downloads a copy of the program to their personal workstation. it becomes their ‘working copy’, where they can make all the changes they want - locally, without affecting the head revision. When the task is complete and the changes have been tested (more or less) we can ‘commit’ our changes - send the changes to the version on the server for everyone to download and use. The previous version is not gone - all the revisions of the project are backed up, so if we want to revert some changes, it is possible even years after the change was made. All our data is safely stored in 3 locations.


Underneath the mess of cables and dust, there is a highly automated system of world domination...

Changes to game code require the executable files to be compiled again. If all the programmers were required to compile all the changes they make to the game on their own machines it would take up a significant amount of time. That is why we have 3 powerful PCs running all the time, which serve as build agents. Their only tasks are compiling the code and running benchmarks. Why do we need 3? Sometimes (quite often, actually) we need to work on several things at once, and having multiple agents reduces the potential bottleneck. That allows us both to build new versions of our executables and run our automated benchmarks. Apart from giving us information on performance, the benchmarks also let us know if the game runs without issues.


Performance of the Riftbreaker over the course of the past year. We're making progress!

All of the things we mentioned today keep the studio operational and assure smooth running all the time. That is it for now. We hope you learned something useful, and if you’d like to know more - go ahead and ask us anything on our Discord - 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

Bonus points if you can find Roger!

A couple of weeks ago we asked our Discord community what they would like to read about in our devlog. We were given a lot of great ideas and topics. Some of them, such as balancing the game elements, need to wait until we are finished with the game, but the rest of them we can start covering right away. They will be featured here over the next couple of weeks. If you have any additional ideas for articles, let us know! It turns out, quite a few people are interested in how the studio works, how our responsibilities are divided and what our typical week looks like. Well, in our line of work, no two weeks are ever the same and the nature of the things we do changes on a day-to-day basis, but we will do our best regardless.


Ready to battle!

EXOR Studios currently has 14 in-house employees. We operate from our cozy office in the center of Szczecin in north-west Poland. We have 4 spacious rooms at our disposal, plus a kitchen and two bathrooms. Setting the space up to accommodate such a number of people can be a bit tricky, but we did what we could in order to maximize comfort and productivity. The graphics designers have their own room, and so do the programmers. We also have a conference room, which doubles as a dining room. The last available space houses the design/management staff. Such an arrangement gives each of the rooms a clear purpose and lets the specialists communicate with each other without the need of leaving their workspace.


MVP, Employee of the Month, the Year and the Century

There are 4 graphics designers in our team. Their job consists of preparing all the assets that you see in our games - the character and prop models, the menus, and animations. The nature of their work is varied and changes according to the current needs of the project. The graphics designers can work on 2D concept art sketches, sculpt 3D models, create textures, as well as prepare promotional materials for the game. The lead designer overlooks the team’s progress, giving them feedback and assisting in case of problems. The tools they use are Adobe Photoshop, Adobe After Effects, Zbrush and Blender.


Our conference room, shortly after we moved in.

Next up are the programmers. They are elusive creatures, but you can easily catch one by turning a monitor or a coffee machine on. Especially the coffee machine. They are the wizards that maintain the Schmetterling engine, program gameplay features and make game designers’ wishes come true. All of them are well-versed in multiple programming languages but use mainly C++ and Lua scripting. Programming is a very broad subject that can be quite difficult to understand for a layperson. That’s why we have a lead programmer, who distributes the tasks among people according to their specialty.


Insert programmers here.

The lead programmer himself does open-heart surgery on the game engine. Next, we have the tools specialist, who prepares all the game editors that the designers use later, although he’s great at programming gameplay features as well. Then, we have the navigation/AI expert - the person responsible for the dynamic pathfinding in X-Morph: Defense and the behavior of swarms in The Riftbreaker. Then there are two guys who fix all the bugs we make, program new game features, create shaders and help the designers. The last programmer works on GUI and heavy backend stuff. He gets the tasks that nobody else could do and always starts feature description with ‘it works, but…’.


The command center being set up.

The last room is occupied by designers/managerial staff. The people here are responsible for keeping the studio running on all fronts. They deal with the business side of things, take care of all the paperwork and keep the hardware operational. When they are not busy dealing with all the boring, grown-up stuff they also design the game itself. Before anything makes it to the screen it has to be conceptualized first, and it happens right here. When any other member of the team needs consultation on a task they are working on they can come here and work out the details. I (the community manager) also work in this room. This is where our streams happen (that’s also why it gets quite loud here at times).


No time for hardware upgrades, gotta code!

There you go - our roles and office layout. In the next part of the article, we will describe our workflow and what our typical day of work looks like. As always, you are more than welcome to ask questions on our Discord - www.discord.gg/exorstudios

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