The Riftbreaker News

[h3]Last time we discussed the Multiplayer version of The Riftbreaker, we told you about our happy little accident that led to the creation of the deathmatch mode. It turned out to be one of the most helpful research and development tools we could have hoped for. In today’s update on our Co-Op development progress, we will tell you what issues we have solved already, what our testing routine looks like, and what milestones we plan to hit in the immediate future.[/h3]

If you missed any of our previous Co-Op updates, you can catch up on them here:

https://store.steampowered.com/news/app/780310/view/3381659291157676103
https://store.steampowered.com/news/app/780310/view/3701435238673426124?l=english
https://store.steampowered.com/news/app/780310/view/3657536564724315072?l=english
https://store.steampowered.com/news/app/780310/view/3657539010840327508

[h2]CONNECTION THROUGH SEPARATION[/h2]

Opening bioanomalies is easier with two flamethrowers at the ready!

After the deathmatch mod came into existence, we decided to package it into a separate product and publish it as a hidden item on Steam for internal use only. This special build is stripped of all the single-player functionality and currently only supports the DM mod. We have been using it for the past few months to test connectivity. We decided to prepare a specialized build for two main reasons:

• A separate, much smaller build allows us to test, improve, and iterate on the new game versions much faster. It also ensures that all testers are on the same game version (mismatched versions happen more often than you think!)
  
• Removing the unnecessary elements lets us focus on networking and connectivity issues without the unnecessary overhead cost from the game’s content.
  

By removing the majority of the game’s logic flow, redundant Lua scripts, and tons of other data, we can focus on what is truly important for us at this moment - improving the online playing experience, and that comes by optimizing transfer rates.

When we first started running multiplayer tests, we brute-forced the game to transfer all the gameplay state data from the server to the client. As a result, our data transfer rates reached upwards of 25 megabytes per second. Many people don’t even have access to an internet connection quick enough to transfer that much data consistently. Yet, our first tests demanded the game to send, receive, unpack, and apply all changes to the client’s game world multiple times a second. It barely worked over the local area network. We had a long journey ahead of us.

Most of the work we described in our previous articles about co-op development aimed to reduce the amount of data transferred between the client and the server. With each iteration, we were sending less and less data through the network. The latency was still high, but less data caused the game to run at a tolerable level of performance for much longer, allowing us to collect more information about the problems we were facing. At this point, all our tests were conducted by running a Survival Mode mission with two or more players connected to the same server. Making the server run both the game logic and handle the networking simultaneously was a tall order, given how much happens in each second of The Riftbreaker’s gameplay.

That last blade bounce was totally calculated.

Many of the problems we faced while testing this way resulted from the clients desynchronizing from the server. At some point, the performance overhead for the server was too high to handle all the tasks, and the clients expecting a server update did not receive it in time, resulting in lags, disconnections, and crashes. If only there were a way of stripping the game to the bare minimum, allowing us to focus on fixing the connectivity issues first without worrying about all the overhead costs generated by the Survival Mode mission running in the background…

Enter Deathmatch. A small and simple map, a couple of basic weapons, friendly fire, and no enemy units. Running tests in this environment gave us more insight in a couple of weeks than trying to complete Survival missions in the months before. We could find problems and reach conclusions previously hidden from us underneath all the unnecessary data. Thus, we started conducting daily playtests in a variety of configurations. Sometimes, we ran a dedicated server on a PC with no other tasks. Other times, we used the listen server option to maximize the load on the host PC. Profiling all our game sessions gave our team much insight into what was happening.

Sometimes it is complete, non-stop mayhem.

Using the data gathered during our playtests allowed the programmers to introduce the necessary changes. We started a lengthy back-and-forth process, where they would push a new build to the rest of the team and ask for a playtest while keeping watch on the network stats and ongoing threads. We kept on carving off chunks of data that were not necessary to be transferred. Bit by bit, month by month, hard work started showing its effects. Looking back at the start of the multiplayer refactoring process, we managed to reduce the data transfer rate from 25 megabytes per second to 200 kilobytes per second per client. This is still far from our target (10 to 20 kilobytes would be best), but it is a significant victory overall. The DM build helped us a lot in speeding up our iteration time. Best of all, the work we've done using the PVP build is transferable to the main project.

After we published our article about the PVP mode, many feared we would neglect the Co-Op mode. We want to assure you that this is not the case. Thanks to separating the PVP-only build from the main branch of the game, we built a perfect network testing sandbox for the most basic feature set on online gameplay. It doesn’t include any bells and whistles, just the essential game elements running unobstructed - precisely what we need to focus on the basic feature set.

[h2]NECESSARY ADDITIONS[/h2]

The significant optimization of the data transfer we described in the previous chapter allowed us to start moving towards playing The Riftbreaker PvP on a PC outside the office network for the first time. To make that dream a reality without a VPN, we needed to add some features first. The list was as follows:

Host game screen with several options:

• The option to run a dedicated server (in headless mode - the host PC does not render the game)
  
• The option to run the game in listen server mode (the server PC also renders the game and allows its owner to play)
  
• Map selector list
  
• Basic game options, such as frag and time limit for any given map
  

Join game screen:

• Public server browser, listing the server’s name, latency, map name, and player count
  
• Refresh button, forcing the game to retrieve the public server list ahead of a scheduled update
  
• The option to join any public server.
  

Looking at this list, we realized that The Riftbreaker’s main menu will not be able to accommodate all these options in its current form. Therefore, we reworked the main menu layout to separate the single and multiplayer options from each other in their own submenus (it was already quite dated and cramped, so the facelift was much needed anyway). The layout we’re currently testing looks like this (please bear in mind that it’s not final and will likely change before the public release):

The options included in the current version of the main menu are still quite limited, but given our experience with bloat from earlier, we decided to focus on the bare essentials for now.

The server browser uses the Steam Data Relay Network. Despite the ‘Steam’ name prefix, this library is not limited to the Valve platform only. It can be used to establish connections between players on different platforms without any issues. However, to make things easier for us and take it one step at a time, we limit ourselves to playing with Steam for the time being. Any team member can set up a server with just a few clicks, which will become visible to everyone on the same game version. Then, it’s just a matter of clicking ‘join’ and we’re in the game.

The bots are quite bad, to be honest, but they still get the upper hand on us sometimes!

Not all of us are always available to test how the game behaves during online play. Our jobs generally need us to be focused on things for long periods. Sometimes, it’s challenging to get into that rhythm. Drawing someone away from their current task for a test can significantly disrupt their workflow. As a partial solution to this issue, we programmed very simple bots. VERY simple bots. They know the player’s positioning at all times and simply run forward, shooting as often as possible, as long as they have the ammo. They are useless as opponents but give us the ability to run basic tests with no involvement of more people around the office. Their development took only a few days, which we will quickly get back at a profit, considering our team’s time. With the help of our bot army, we can quickly populate our servers and run automated tests of game rules. As a bonus, whenever a real player wants to join the game, one of the bots is kicked out to make room for that player, so it is still possible to call someone in for help in case you need them.

It’s worth noting that none of this work will be discarded later when we move to more advanced testing. The main menu rework, the server list, game hosting, and joining servers - all these elements are essential, and we would have to make these happen either way. Completing these tasks also allowed us to make our tests more structured and semi-automated.

[h2]COMPUTER, RUN DIAGNOSTICS[/h2]

We've taken these stats from a session hosted by a friend hundreds of kilometers away. Worked pretty well and consistently!

With the new functionality in place, we could finally keep tabs on the multiplayer build. We came up with a set of tests to help us catch bugs and measure the performance of the game. We’d love to tell you that every build that leaves the hands of programmers goes through rigorous testing, but we never lie to you - this is just a set of guidelines. However, we have a short list of basic multiplayer functionality that we try to ensure is operational. The list is as follows (in no particular order):

• Is it possible to name your server using the game’s menu?
  
• Is it possible to name your server using the configuration files?
  
• Does the server name show up correctly on other PCs?
  
• Does setting the warmup time limit work as intended?
  
• Does setting the frag limit work as intended?
  
• Does setting the time limit work as intended?
  
• Does setting the player limit work as intended? Can it be set to zero?
  
• Does the max bot count setting work properly?
  
• What happens if you set all the game rule value sliders to zero?
  
• Does the server keep the settings after loading another map?
  
• Do all the settings work both in the listen server and dedicated server mode?
  
• Can you use the Steam friends list to join the game? Does it break if the friend you’re joining is in the menu, loading the game, their avatar is dead, etc?
  
• Does the server browser display server names or IP addresses?
  
• Does the server browser display the actual number of players on the server?
  
• Does the server browser work with both dedicated and listen servers?
  
• Does the refresh button work correctly?
  
• Does the server browser refresh automatically?
  
• Does the game work as intended when a player joins a game session filled with bots?
  
• Can players still join the server when the maximum player limit is met?
  
• Can you set up a listen server on an external network and connect to it from the office?
  
• Can you set up a dedicated server on an external network and connect to it from the office?
  
• Can you set up a dedicated server on our internal network and connect to it from the outside?
  
• Can you set up a listen server on our internal network and connect to it from the outside?
  
• Can you see all running servers in the server browser menu in all the cases above?
  
• Can you use the ‘Join Friend’ feature in all the cases above?
  

This list is non-exhaustive. Our testing is often focused on the areas under active development. For example, we’ve recently been trying to figure out how to fix the problem that causes the player to lose weapons permanently on death. It is made worse by the fact that the problem persists when switching maps (on the other hand, it means you won’t lose your inventory during planetary travel in co-op, yay!) Naturally, we will pay more attention to the details surrounding our current area of interest, but keeping track of the basic functionality is paramount. Testing all these things will likely continue way beyond the final release.

[h2]WHERE DO WE GO FROM HERE[/h2]

Clone wars, Riftbreaker style. Note that the game wasn't running too well during this run.

We still have a lot of work regarding optimizing the data transfer. As mentioned before, we ideally want to get the amount of incoming data down to about 10-20 kilobytes per second per player. We have already greatly reduced the amount of data transferred between the PCs during gameplay. However, we still generate more information than necessary. That is because we have not yet reworked all the in-game systems for multiplayer context. On the other hand, it gives us a couple of clear targets where we are sure to find performance gains.

Special effects are one of the significant areas of the game that still require a rework. More specifically - separating the audiovisual representation of the effects taking place in-game from the logic underneath them. We mentioned it in more detail in the first Co-Op Update article if you want to know more. Here’s the TL;DR: Currently, game logic runs exclusively on the server. For example, if a player shoots a gun, all effects happen on the server first and are then “copied” to clients. Instead of doing the same work twice, the server can command the client to spawn the effects on their end, reducing the overhead for the server. It sounds simple, but it is a monumental task, and its development is an ongoing process, as we need to rework all systems in the game to accommodate that.

In a similar vein, we are reworking the game logic so that not all of it has to be carried out on the server first. Some more minor game logic elements can be handled by the clients and later only verified by the server. However, introducing changes to how game logic unfolds carries huge implications for saving files. We still maintain backward compatibility with all (unmodded) game versions, going back to version 1.0 (PC players did not even have the chance to download it! Version 1.0 only exists in the physical disc console versions of the game. To run it, you need to have no internet connection for the entire gameplay duration. Still - it is officially supported). Even though the number of users that play such old game versions is minimal, we maintain save file compatibility as a rule.

With such a huge rework, touching almost all aspects of the game, you will find a lot of issues, even in the most unexpected places. Music is the best example - what could be so difficult about playing an .ogg file? The problem is that The Riftbreaker features an adaptive music system. When a player is fighting, the music changes to a ‘combat’ playlist. When you’re building the base, we use the ‘building’ playlist. We want to keep that feature for each player individually. However, there are certain moments in the game when the game’s logic forces a certain type of music to be played - during the final attack, for example. We want the server to be able to overrule the clients in this case, which requires reprogramming the system to work in a more complex client/server architecture. This is only one of dozens of problems we encounter, each needing a different treatment.

We discovered many issues when we started running our connection testing gauntlet. The high number of possible ways to connect to a game session and other variables, like the type of network your PC is connected to, cause numerous problems. Sometimes, they become apparent immediately, while others remain hidden for weeks. We carefully examine the causes of these issues on a case-by-case basis. We can’t possibly catch all mistakes on our own - which is also why we want to test the multiplayer portion with you.

Ragequit is one of our moderators and modders of The Riftbreaker. He immediately started modding the multiplayer build. We are not surprised at this point.

Starting this week, we have been allowing access to the multiplayer build of The Riftbreaker to people outside EXOR. Those players are handed keys to the hidden Steam product and are welcome to test the game with us and host their own sessions. This is a major milestone we are very proud of, and we hope that you will join us! The invitations will be handed out via Discord, so if you have not joined www.discord.gg/exorstudios - now is the best time to do so. The deathmatch test will eventually evolve into the real deal - a Co-Op beta test, which makes it even more exciting. We can’t wait!

[h2]CONCLUSION[/h2]

The basic deathmatch gameplay loop, coupled with the essential interface features for hosting and joining the game, gives us an excellent tool for testing network performance. It has already yielded great results, and we expect it to improve. That said, we don’t want to develop this game mode any further. Any updates we introduce will only be aimed at making the game run better. We plan to invite selected Discord members to test the game with us, slowly opening the Deathmatch demo to more and more people. However, Co-Op remains our primary focus.

We never promised a release date since we knew the development process would be very long. Nobody could predict how long. Yet, you’re here with us, reading the articles, following the latest developments, and sharing your feedback. We would like to express our enormous gratitude for your support and patience. You will be rewarded with the best multiplayer experience we can offer - that’s the only thing we can guarantee.

In the meantime, we’re going back to work. The programmers - back to unspaghettifying The Schmetterling Engine’s code. The designers - to creating a new part of the adventure in the coming World Expansion III. We hope you’ll come on both of these adventures together with us. Join our Discord at www.discord.gg/exorstudios and watch us stream twice a week at www.twitch.tv/exorstudios.

Thank you once again!
EXOR Studios

We have just published a small update for the game, including some new elements and changes necessary for the upcoming Halloween seasonal event. The update also includes a couple of fixes for minor bugs - all of them are listed below.



With this update, the game now supports the new Halloween seasonal event. If you have been with us for a long time, you might remember the Halloween event we held long ago. At that time, we added a couple of decorative buildings - pumpkin lamps and tombstones for walls. However, we did not have the tech to replace those buildings in real time. The event never got the final touch necessary to make it public-worthy, so we shelved it. In the meantime, we produced Winter Holiday-themed and Lunar New Year events. With this experience, we revamped the Halloween event a little.



The new Halloween event is going to be active between October 26th and November 10th. During that time, the Tropical and Volcanic Zones of Galatea 37 will be illuminated by a custom-made weather event, with orange haze and a smokey atmosphere, as if you were close to a fire. Delicate ash and ember particles complete the look of a burning planet. Your Energy Connectors will be replaced with skulls and bones. Basic lamps will be decorated with Jack-o-lanterns. Rift portals you place on the ground will change into magical cauldrons filled with a strange substance of an unknown origin. The basic floors will also get an overhaul as we apply a cobweb theme to them in true Halloween fashion.



All the changes that happen during this event are purely cosmetic and can be turned off at any time. Simply go to the options menu, select ‘gameplay’, and change the ‘seasonal events’ option to on or off, depending on your preference. You can even switch between them back and forth - the change applies in real time!



Last but not least, here’s the full changelog for this update:

[h3]The Riftbreaker Halloween Update, October 24th, 2024 EXE: 918, DATA: 510 Changelog:[/h3]

• Fixed a bug in one of the attack waves in Volcanic Area survival that caused an unreasonable amount of Magmoths to attack the player's base at a certain point in the game on higher difficulty levels.
  
• Updated the Prologue mission. Unit placement has been improved, a couple of bugs have been fixed, and the lighting has been changed to make use of the volumetric effects.
  
• Fixed a bug with Arachnoid Sentinels not setting their aggro distance properly when spawned randomly by the map generator.
  
• Fixed a bug that caused Artillery Towers to be unavailable in the Prologue mission. The adverse effect of this fix is that Artillery won't be available in custom-made biomes unless the modder manually updates the condition_value "magma,jungle,desert,acid,metallic,legacy_maps,prologue,swamp" with the name of their custom biome. This line can be found in the "buildings/defense/tower_artillery.ent" and all other artillery-related buildings. You can also ignore this for the time being, as we are working on a better, permanent fix.
  
• Halloween event items have been added. This seasonal event will be active between October 26th and November 10th. The event will add a special holiday weather event and replace some of the buildings and props with festive versions. The event is visual only, and it can be turned off at any time via the options menu.
  
• Time windows for other seasonal events have been set. The winter event will last from December 5th to 27th. The Lunar New Year event will last from January 20th, 2024, to February 5th, 2024.
  

EXOR Studios

Our game engine is the main focus of today's article. It is one of the reasons why we can throw THIS amount of enemies at you and not worry about the game blowing up.

The game development industry has recently gone through an earthquake of a cataclysmic magnitude. A major game engine provider recently announced changes to their pricing model, which caused an upset in the gamedev community. It left many studios wondering about how to proceed with their work in the future. Luckily, we were not affected by that since EXOR Studios’ games are made using our own engine - The Schmetterling. It is one of the advantages of working with your own technology. You are independent but, on the other hand, solely responsible for the state and features of the engine. Still - we enjoy working with our tech and decided to give you our personal view of the pros and cons of working with The Schmetterling.

[h3]The Good[/h3]

[previewyoutube][/previewyoutube]
The humble beginnings of The Schmetterling engine were captured in this making-of video for Zombie Driver.

When we started working on our first standalone project, Zombie Driver, back in 2008, we did not have the means to afford any of the ready-made solutions available on the market. We had no choice but to look for open-source solutions to make our first game a reality. Our plan was not to build an engine but to somehow piece the game together. In the process of Zombie Driver’s development, we learned what kind of tools work for us and which ones don’t quite make the cut. Over time, we started reducing the bloat of the software we were using and forming a semblance of what our engine is today. It was a naturally occurring process, and it shaped The Schmetterling engine to have all the necessary tools and features we need to make our own games in the isometric camera view. It was a set of answers to our needs at that time, which is one of the reasons why we have kept working with it ever since.

Destructible environment was one of the key features of X-Morph: Defense. We don't know if achieving this level of destruction would be possible for us in any other engine at that time.

As the tech in games evolved, The Schmetterling needed to keep up with the times and evolve as well. This is where the second advantage of the engine became apparent. Because we have the entire codebase for the engine and know it in and out, we can expand the engine with any kind of feature that we can develop within reasonable time. Whether it’s a new physics model, like in the case of X-Morph: Defense, or a new rendering technique, such as real-time raytraced shadows introduced in The Riftbreaker - if we want a new feature in our engine, it is only a matter of time and dedication before we get our hands on it. Our programmers get the experience of working with the new tech, and the designers can unleash their vision, not limited by artificial constraints.

The aforementioned "artistic vision not limited by artificial constraints." We're not quite normal.

Many of the features of our engine have been implemented with designers in mind - most files are human-readable and, as a result, can be edited by anyone with access to notepad. Thanks to how easy it is to create entities, prepare logic files, create scripts and edit databases, most developers in the studio can create entirely new game assets from scratch without ever asking programmers for help. This is also thanks to the simple Entity Component System, which works like a set of building blocks. Each component in this system adds a set of functions to a game entity. By picking and choosing the right components, we can give game assets the desired properties and have them function in-game as intended.

Tweaking sensitive values gets much easier when no baking is necessary. It allows us to fine-tune visual (or physical) effects much easier.

Another aspect of The Schmetterling engine that helps us with development is that there is no baking necessary and most assets, scripts and effects can be edited in real-time. Baking is the common name for the preprocessing of game assets. It is done to make sure that all assets load and function well and do not cause issues in-game. Since our assets are game-ready right away, we can skip this step, drastically reducing iteration time, as all our changes take effect immediately. This allows us to catch mistakes and test new solutions in a very quick manner.

Automated tests won't catch all bugs but they are a great help. We have a feeling this Gnerot will be back.

There is also a bunch of quality-of-life solutions within The Schmetterling that positively affect our workflow. Our automated crash reporter allows users to send us the data necessary to fix many errors with the game. The reporter also gives us basic stats on error occurrences, helping us prioritize the most common crashes. The engine also allows us to automate game tests and performance benchmarks. This helps us identify many issues before anyone has really had a chance to notice them in the first place. Our toolset is also very modular and easily expandable. If we’re missing any features or test setups, it is usually a matter of just a couple of days of work to add them.

[h3]The Not So Good[/h3]

You need to know what you're going for and how to achieve it. If something is possible within The Schmetterling, it's usually a matter of adding the proper components. But first, you need to know which ones will do the trick for you.

Naturally, The Schmetterling is not perfect. One of the most difficult aspects of working with the engine is the fact that there is no documentation available. You can’t refer to the manual for a list of the available features or examples of how to use them. We rely on the knowledge we gained working with the engine over the course of all these years. Programmers tell us about the new features they deliver, and designers often refer to their previous work as a makeshift ‘cheat sheet.’ However, for a person without access to any of that knowledge, the entry barrier is very high. Mastering the ways of the Schmetterling requires dedication and some reverse engineering.

When we were implementing raytraced shadows, we had to carve the path and figure out solutions to all the issues ourselves. At times, it was tough, but the end effect was well worth it.

Another thing worth mentioning is that nobody is coming to help if something is broken. You can’t count on an engine update magically being published by the developer because YOU are the developer. When there is a bug in the engine, you have to ask the person responsible for that part of the codebase to fix it for you. This can be seen both as an advantage and a disadvantage. On the one hand, you directly impact the state of the engine and can request a quick fix if you’ve encountered a critical error. However, it also means a lot of additional responsibility for our programmers, which they (probably) wouldn’t be dealing with had we chosen a ready-made solution.

[h3]The Downright Ugly[/h3]

The engine wasn't made with multiplayer in mind. Neither was the game. But it's not going to stop us.

Now, we come to the worst part of working with our engine: it is well optimized for the games that we make. It’s not well-suited for anything else. We have all the tools and features necessary to make single-player games in isometric view. However, if we want to achieve something beyond that scope, we must devote long hours of research and development to build the new features from scratch. This is, unfortunately, why developing online co-op is taking so long. We have to essentially build the entire engine for the multiplayer version of the game from the ground up. While this is probably the most hardcore task we could have taken on, we would face similar challenges if we wanted to introduce other drastic changes to the engine and move the camera to the first-person view, for example.

Testing network play on a small PvP map allows us to progress with the work on the multiplayer portion of the game much faster.

Knowing our situation, we knew going into this that adding co-op mode to The Riftbreaker would be a monumental task. Still, we want to assure you once more that we are indeed working on it. We read all your comments. We know you’re frustrated and angry that you’ve been waiting so long. However, rushing things is not the answer here. In order to develop a good multiplayer mode, we need to make sure all the engine work with each other well. A lot of manhours have gone into assuring that we won’t have problems down the line. There is no going around these things, and the unfortunate thing about that is that more often than not, we do not have much to show our progress.

The next progress report will focus on the network connections and the issues we faced while working on the multiplayer.

We hope that we can give you something playable sooner rather than later. We hope that we can meet your expectations. But until then, we need to ask for your patience. We will publish a full-length Co-Op Progress article in the coming weeks. Stay tuned for that.

If you missed any of our previous co-op progress updates, you can catch up here:


https://store.steampowered.com/news/app/780310/view/3381659291157676103
https://store.steampowered.com/news/app/780310/view/3701435238673426124?l=english
https://store.steampowered.com/news/app/780310/view/3657536564724315072?l=english

[h3]Conclusion[/h3]

The Schmetterling is not very universal, but it's VERY good for our use cases.

Developing our own engine has had a lot of benefits for us. It has given our developers lots of invaluable knowledge. We have benefitted from The Schmetterling’s flexibility and adaptability multiple times. However, maintaining and expanding the engine has been an additional, significant responsibility for our team - a responsibility that does not always show obvious benefits and can get frustrating at times.

There is a lot of craftsmanship involved in working with a custom engine. If we were to use an analogy, it is a bit like brewing your own beer. You can learn all the theory, pick your style and ingredients, and control the entire process. On the other hand, you can go to the supermarket and pick up a bottle of your favorite brand. Both will hit just as good as you wind down after a hard work day, but you won’t feel the extra satisfaction of enjoying the fruit of your work from start to finish.

The bottom line is that there are no silver bullets. Each engine has its strengths and weaknesses. Whether it’s a ready-made solution or a custom-built engine, you will have to face some issues along the way. The most important thing is to make an informed decision in the first place. In our case, we’re glad we have The Schmetterling and don’t think we will switch anytime soon.

EXOR Studios

The development of the third World Expansion for The Riftbreaker is well underway. We stream our progress previews on Twitch from time to time, testing the new survival mode setup and the basics of the new biome’s gameplay - follow www.twitch.tv/exorstudios to catch us live! As you know from one of our previous articles, the development of an update or an expansion is a lengthy process. It’s full of trial and error and involves a lot of iterations over various elements we want to include in the game. Today, we would like to tell you what it looks like in the case of 3D graphics. We will take a look at a couple of new creature models, what they looked like initially, why they were rejected, and what kind of improvements our artists made to make them viable. Today we’re looking at the technical side of things only - these cute little creatures will get a proper introductory article when the time is right. With all that out of the way - let’s see what the process looks like.

Some of the new creatures are quite menacing, but aren't aggressive.

Please note that there is much more to creating new creatures than we can cover with just one article. After designing and modeling the creature, we need to create textures, animation rig, create animations themselves and program the unit’s behavior that will make use of those animations. After that, we add a whole bunch of effects. All blood splats, projectiles, and any other visuals produced by the creature are custom-made for that unit. Same goes for sound effects - they are all created on a per-unit basis. Then, after all the technicalities are done, we can finally playtest the game including the new unit, tweak its behavior and balance it in the context of gameplay as a whole. This article will only cover the process of getting from the concept phase to the final, high-poly model.

...unless you come too close for their comfort.

The work starts with the concept. During the pre-production phase, after we have decided on the general theme of the new biome, we run a series of design meetings where we come up with ideas for the fauna and flora you’re going to find in the area. While plants and other props are designed to support the general theme and serve as decoration, creatures need to fit both thematically and functionally. We gather tons of references, looking at our favorite works of science fiction, other games, and all other media that could be even remotely relevant to the theme of the biome. We come up with several designs and decide what kind of units we need for the new area when it comes to function. We usually need a light ground unit to appear in large numbers, a medium-sized ranged unit, a tank, and a couple of special units with unique mechanics. Our designs for the large tank and the small cannon-fodder came first.

Stickrids are so delicate you can just stomp them.

Fungor is the first of them. The initial design for the creature was to make a tall, menacing hybrid of an animal with a mushroom. Fungor’s design is supposed to make you ask yourself ‘what is going on here?’, as the creature tries to rip the mecha-suit apart and consume you with its giant jaws. Our artists came up with several propositions, trying to solve the issues of Fungor’s proportions, anatomy, movement, and attack mechanics. These are the first concepts they came up with.



Ahhh, sweet man-made horrors beyond comprehension. Everything immediately fell into place after these concepts were presented to the team. We chose elements that we liked from each version. What we wanted was a fungal abomination that moves in an upright position using massive tentacles. We also decided to add another tentacle to the back of the creature that it can use as a weird whip/hammer hybrid. With these assumptions, the artists got back to work. A couple of days later we got this beauty:

Fungor in its ‘rigging pose’ - all the appendages are extended as far as they go and add the animation rig to the model. Essentially, Fungor is T-posing here.



Designing Fungor was rather straightforward. There was no need to go back and do a couple of redesigns - when a clear vision clicked in our heads, it was only a matter of time before our art team could make it a reality. The scale, anatomy and form all match the desired function of the creature. However, things do not always go so smoothly. This little guy is called a Stickrid:



Hey, this is a Stickrid, too…



And this one as well…

The notes next to the arrow say: [top] the tail fin is helpful when living in a swamp. and [lower, next to the hand] fangs so that the creature can climb.

Here, we got three wildly different concepts. After some discussions and looking deep into the beautiful googly eyes of number 1 and number 3, we decided that number 2 was the only one we wanted to kill. However, number 2 had its fair share of problems. First of all - it resembled a spider a little bit too much and we are aware that not everyone would jam with this idea. Second - the spider-like anatomy meant that the creature’s body would be very low to the ground. In the case of the swamp biome, that’s not really what we wanted, as the critter would not be visible to the player most of the time. We decided to merge some ideas from number 1 and number 2 into one model and lengthen the legs. This way the creature would resemble a grasshopper more and its body would stick over the surface of the water.

Stickrids' design allows us to place them directly in bodies of water.

Another thing is the creature’s function. Even though it falls into the ‘cannon fodder’ category - it’s small and always comes at the player in relatively large numbers - it is different from the other small creatures in the game. Instead of melee attacks, Stickrid prefers ranged combat. It will run away from its target to a safe distance and try to take it down with a barrage of small projectiles. If you try to come closer, the creatures will scatter around, trying to keep their distance from you. This feature means that the creature needs to look like it’s able to launch projectiles. Unfortunately, this eliminates the cute number 3. Goodbye, Frogozaurus Rex.



This was the first attempt at merging the first two concepts. The legs have changed significantly, but we were still not very happy with the overall body shape. We decided that the abdomen, also known professionally as the ‘spider butt’ should be slimmed down. We thought that the creature would look beter in a ‘cigar’ shape.



After all of these changes we arrived at this concept. All our goals have been met:

1. It has an elongated body and no longer resembles a spider
   
2. Long legs ensure that the creature will not hide beneath the surface of the swamp
   
3. The gaping mouth is ready to shoot projectiles at you and your base
   
4. It’s not cute anymore and we have no problems killing it.
   

All that’s left is to add some detail and final polish to the model. Here’s the final version:



If you compare the last two versions of the Stickrid we presented, you will easily see the difference between the sketch and the final hi-poly model. When going for the ‘final quality’ model, artists pay a lot more attention to the anatomical details of the creatures they model. The legs have been beefed up, and their joints have been moved slightly to make the model more lifelike. The legs themselves no longer stick out of the abdomen. Now, both these elements flow naturally from one to another. Stickrid’s body has also become more compact, ensuring it behaves as intended in large groups, which is the intended use case. Apart from these touch-ups, the creature also received a lot more details. Ribbed carapace, sharp feet, and striped antennae on the head - we have to skip all these things when coming up with low-poly concepts.

One Stickrid is not that threatening...

Artists at EXOR have complete freedom when choosing references and style for their models. The design team only gives them broad descriptions of what kind of creature they think will work well gameplay-wise. Everything else is up to the artist. Our way of creating game art is not for everyone. Some people prefer to make models based on concept art, since that more-or-less guarantees that nothing they create goes unused. However, we believe that when artists can interpret the creature description freely and create something from the ground up is our strength. It always leads to interesting results and gives them a chance to put a personal touch on their work.

...but there is never just one!

So there we have it - an overview of the first steps that our models take, from the humble beginnings to the final hi-poly model. Let us know if you would like to hear about all the other stages of creature development - texturing, animations, particles, sounds, and everything else! We’ll gladly share more info on this. Remember to join our Discord at www.discord.gg/exorstudios for more news and daily changelogs. Also join our streams at www.twitch.tv/exorstudios - we haven’t streamed our co-op progress for a while, so it might happen soon…

See you next time!
EXOR Studios

Last week, we showed you what our organization of work looks like when it comes to larger-scale projects, like expansions or major patches. It takes hundreds of hours of work from individual people to eventually create something that is much more than just a sum of its elements. Today, we would like to tell you what kind of tools and technologies we use daily to make our jobs a) possible and b) easier. Some of the tools we use are quite specialized and unpopular. Others - you might very well have them installed on your PC. Let’s take a closer look, going from team to team.

[h3]GRAPHICS[/h3]

Blender. Throughout this article, you will see what we're working on at the moment. Pay attention to details!

Blender - This open-source 3D modeling software is the bread and butter of the graphics department at EXOR Studios. The vast majority of the hard-surface objects are modeled in this program. It is used for all stages of asset production, from basic sketches through detailed high-poly models to simplified low-poly versions ready for use in-game. We make animations in Blender as well! Thanks to Blender’s open nature and plugin-based expandability, our designers always have the freedom to look for new tools and add-ons to help them with their work. The best part is that the software is completely free, and with a large number of courses available online, anyone can learn it and start their journey with graphics design!

Zbrush. New creatures are coming to life right as you're reading this!

Zbrush - As good as Blender is, it is not perfect for all tasks. When it comes to modeling organics, such as creatures or plants, Zbrush is the tool of choice for our team. This program allows the artists to sculpt models with fine details as if they were working with a real-life material such as clay. Using a range of virtual brushes, our designers can intuitively create lifelike models with relative ease.

Substance Painter is where all models get their colors. And materials. And basically, everything else that makes them not look like an unpainted Warhammer mini.

Substance Painter and Designer - We use Painter to create textures for our models. It allows our artists to create highly detailed textures using a range of smart tools. It simplifies the texturing process by automatically wrapping the model and allowing the artist to observe the effects of their work in real-time. Designer, on the other hand, allows us to create materials for our in-game models using procedural generation.

Photoshop. Layers, keyboard shortcuts, 20 gigs of RAM usage. Photoshop in a nutshell.

Photoshop - When it comes to creating 2D graphics, nothing beats good old Photoshop. Apart from the more obvious use cases, such as creating concept art and loading screen art, we also use Photoshop to create the elements of the Graphical User Interface, or GUI. All buttons, frames, and menus have started their lives in Photoshop. They are later cut into individual elements for the engine to use across all the different screens in the game.

After Effects. Even the animations you can see in the game's main menu were born in After Effects.

After Effects - the layered 2D graphics created using Photoshop can also be used to create basic animations. By applying simple movements to some elements of the artwork made by our team, additional particle effects, and a dash of post-processing, we can prepare in-game animatics on our own. Of course, they may not be as spectacular as fully-rendered 3D movies, but they serve the purpose of conveying story elements quite well. Additionally, we can make changes to them quickly and avoid the need to rent costly render-farm hardware.

[h3]PROGRAMMING[/h3]



Visual Studio and Visual Studios Code. For non-programmers out there: spot 5 differences.

Visual Studio and Visual Studio Code - our programmers’ weapons of choice. The Riftbreaker’s game and engine code is written using C++. Our Programmers use Visual Studio as their development environment and debugger. However, the code is only a part of the game and works in tandem with the game’s content. This is where Visual Studio Code comes in. Our programmers use it to navigate the game’s scripts and content. It also gives us a LUA debugger that we can attach to the game’s process. Additionally, there is a number of different shader languages (depending on the platform), various tools written in Python, Powershell, C#, or whatever new tech the programming team finds useful at the time.

SVN keeps track of all changes ever made to a file. You can't hide your mistakes, even if you really want to!

SVN - A free and open content versioning system that can be integrated with the Windows interface through e.g. TortoiseSVN. It allows us to distribute the working copy of the game to all developers in the studio, keep track of changes made by each user, and fall back to any revision of The Riftbreaker in the history of the project. It serves both as a tool for organizing our work, as well as one of our many backups.

TeamCity. This list goes on and on, as we have multiple configurations for all platforms and all our games there.

TeamCity - This piece of software allows us to automate a lot of things around the office. It directly controls our four dedicated build machines - the main job of these computers is to compile game code quickly. TeamCity maintains the building queue, distributes tasks between the build machines, as well as helps us automate some tedious tasks, like deploying new game builds to the repository, running benchmarks, and automated game tests.

[h3]SOUND[/h3]

REAPER. After a little while you stop seeing weird shapes and start seeing sounds. Is this synesthesia?

REAPER - We choose to work with this Digital Audio Workstation because it is simple, robust and lightweight. Its functionality can easily be expanded with VST plugins, as well as plenty of free JavaScript addons created by users. REAPER offers a huge amount of customization and has never let us down in our day-to-day work. We use it mostly for working with dialogues - cutting long recordings into samples, and applying post-processing effects. You can read more about how we work with audio here.

[h3]MISCELLANEOUS[/h3]

Notepad++. You can edit the majority of the game's files in this program. Very much recommended.

Notepad++ - the #1 most popular computer program in EXOR Studios. Used for editing LUA scripts, editing entity files, and, of course - taking notes. It has a multitude of features that help us with our daily jobs, such as finding all instances of a phrase in multiple files at once, the ability to open many text files in several tabs, and saving your work regardless of not clicking the ‘save’ button yourself. Much recommended.

Paint dot net. Photoshop for people without talent or skills. Or both!

paint [dot] net - For those of us who do not need or can’t use Photoshop, paint [dot] net is a sufficient alternative. The programmers and designers use it to quickly edit textures and mark them as temporary - something that is often needed when creating prototypes of new game features. It has a simple interface and offers just a bit more functionality than regular Paint, with layers and transparency support, for example. Also - sorry for the weird spelling. Steam recognized the name of this program as a link, and the link did not lead anywhere we would want to lead you.

Paint - the most legendary and classic tool available. Used by those who can’t grasp the complexities of paint [dot] net (wait, what!?). You might think this is a joke, but it was even used to create EPIC cutscene mockups:
[previewyoutube][/previewyoutube]
You know what? EPIC doesn't even cut it for this video.

The Riftbreaker World Editor Suite - last but not least important. All the props, creatures, items, and all the other game pieces that we create using the tools mentioned above are put together into one using our editors. We use the map editor to create map tiles for all the game’s biomes. The model editor allows us to attach particle effects to models and add events to specific points in the animations of those models. The Riftbreaker Editor gives us access to all the databases of the game - loot tables, damage values, and many others. Mission Editor allows us to create campaigns, missions and in-game events using a simple, block-based setup. These programs, combined with some of the ones we mentioned earlier, give you everything you need to create great mods for The Riftbreaker.

You can read about these tools here:
https://store.steampowered.com/news/app/780310/view/3109170041988719336?l=english

That’s probably not all the individual pieces of software we use daily, but we have certainly covered the most important ones. Are you surprised by some of our choices? Did you expect to see something different? Or perhaps there are some omissions that you’d like to ask us about? et us know here in the comments! You can also get in touch with us on our Discord at www.discord.gg/exorstudios - we’re always happy to share our insights!

See you soon!
EXOR Studios