Hello Riftbreakers!

One of the goals of the articles we share with you every week is to bridge the gap between us, the developers, and you, our community. We love showing you what goes into making new features a reality and explaining why we do certain things. Today, instead of taking a detailed look at one feature (like last week’s article about Volumetric Lighting, which you should totally read), we are going to take a step back and show you what the production process looks like for The Riftbreaker when it comes to larger pieces of content. Here’s the story of how Into the Dark came to be.

THE IDEA

Fun Fact #1: The promo art for this biome featuring Drilgor arrived when we were quite deep into the development process, when we had the creature's appearance finalized.

After we finished work on the Metal Terror expansion, we gave our design team a task to come up with several concepts of new biomes for Galatea 37. We didn’t want these designs to be too specific. Instead, we asked for a general overview of the look and feel these biomes could have - the color palette, types of props we could expect there, and some ideas for plants and creatures that would inhabit the biome. Designers compiled all that info in the form of a presentation for each biome concept that all members of EXOR could read and form an opinion. Then, we held a vote to see which ideas resonated with us best. Crystal Caverns dominated the vote, and we got to work.

CAVE-DIGGING

Fun fact #2: the first destructible rocks were reused props from the Metallic Valley biome.

The first thing that came to our minds when brainstorming ideas for this biome was digging tunnels. We had no plans for such a feature before this, but it seemed interesting enough to try out. One of our programmers, Łukasz, decided to make a quick prototype of the feature. He took a couple of regular rocks that the artists made for other biomes and allowed the player to destroy those rocks with regular weapons. This solution was far from optimal and didn’t feel great just yet, but the potential was there. We decided to greenlight this feature and make it a key point of this biome.

We began iterating on the digging mechanics, moving away from using weapons to carve your way through the limestone (leaving it only as an option) in favor of using Mr. Riggs’ drilling arm. It quickly became apparent that filling the map with thousands of physical, destructible elements was a performance nightmare for our engine. The programmers decided to drastically reduce the number of destructibles by only spawning the rocks that the players could interact with - essentially, just the edges of the removable masses of limestone. The empty space behind the face of the wall would be covered with a texture that gives you the impression that you’re facing a solid wall. Sounds quite simple, but we kept tweaking this aspect of the game until release. You can read more about it here.

FIRST GAMEPLAY

Survival gameplay is never an afterthought - in fact, we have survival ready before the campaign starts to take shape.

Simultaneously, we started designing the flora and fauna of the Crystal Caverns. Given that creatures living underground often take weird and, frankly, disgusting forms, we took some liberties when it came to the design of their appearance and abilities. The goal was to make them eerie and almost unnatural. So, we got Crawlogs who can traverse walls and ceilings and come back from the dead. Gulgors spit shards of razor-sharp crystals. Crystaroses siege your defenses with incredible efficiency. However, there was a problem - if the map was filled with rocks the player had to dig through, how would the creatures get to your base? We created Drilgor to solve this problem. This monstrous creature has just one purpose - it will find the shortest path to your base and dig a tunnel for other creatures to follow.

Even playing with a limited and prototypical creature set can give us valuable insight into what we want the biome to look like.

This set of creatures, along with the cave-digging mechanics, gave us just enough elements to set up a simple survival mode setting that would serve as the base of the gameplay moving forward. The level designers created a couple of test map tiles using props from the other biomes in the game. This allowed us to get a feeling of what the gameplay would look like with the cave-digging mechanic. We also realized what kind of problems players would face, energy production being the main one. Before we started introducing new elements, we decided to start doing preview streams to gather some initial feedback from the community.

At this stage we also learn how to build new map tiles.

One example of a lesson learned from this early gameplay prototype was the need to handle attack waves in a different manner than we’re used to. Since there were few solid obstacles in Crystal Caverns, players would have problems setting up proper defenses, as they did not know where to put up walls and limit the expansion of their bases. We solved that by letting them know where the attack would come from ahead of time. Thanks to this early bit of information, they knew which parts of the base they should focus on and prepare for the incoming attack.

CAMPAIGN PROTOTYPE

There's always going to be a massive battle at some point during the campaign. The big question is - how do we get there?

With some conclusions from the survival playtesting, the campaign started to take shape. The initial draft is always written in paper form (not really; we use a doc for that, but you get the idea). The campaign designer comes up with a number of missions, their objectives, and how they are connected with each other. Only after the paper design is approved we move on to work on it in-game. We always start by creating a ‘skeleton’ - a series of very simple missions you can progress through in a few minutes. We mean REALLY simple: go to point A, go to the next map. Load into the next map, wait 30 seconds, and go to the next map. This logic structure is a foundation we can later fill with actual content.

We design and test various objectives. The ones that are potentially problematic are discarded to make place for better ones.

Naturally, it’s not as straightforward as we might like. As the missions take shape, we often discover that we lack the necessary logic blocks in the engine or other features that require help from the programmers. It must be noted, however, that we try to bother them as little as possible not to drag them away from their work on co-op, which runs parallel to the content creation. We also often work with placeholder assets while we’re waiting for the graphics team to finish the final models or animations. This is also the part when the story starts to take shape. There is no denying that The Riftbreaker does not rely on a strong narrative to drive players forward. However, we still like our story to be coherent and sensible. Iterating on the story often involves recording placeholder dialogues multiple times, which can sometimes be pretty funny.

NEW WEAPONS AND TECHNOLOGIES

Some new tech items have to wait for the proper treatment a little longer than others. Here you can see the Acid Spewer Towers in their final form. However, the traps around the base are just recolored Acid traps.

While the campaign is being developed, another part of our team starts working on all the tech items that we want to include with the expansion. As usual, we try to build working prototypes with the elements we already have in the game. We build new weapons using the existing meshes, sounds, and particle effects. The same applies to buildings. We do all this prototyping work to check whether the new tech we’re planning makes sense and if it’s fun gameplay-wise. That’s the thing with designing things on paper - sometimes things might sound good at first but turn out to be complete duds when it comes to playing with them. Testing things early allows us to correct our mistakes before investing precious production hours into something unusable.

Fun Fact #3: Drilgor had a bug that rendered it unable to hit more than one target at a time. It became a killing machine that wrecks your walls only after it was described as 'weak' in playtesting.

We tend to create way more prototypes than the final number of technology items that actually end up in the final release version. There are two main reasons for that. The first is time - we simply do not have enough time to implement everything we want properly. Items that did not receive the final polish are archived so that we can try to use them again when an opportunity arises. The second reason that new items are cut is that they do not feel right or do not fare well in gameplay of the new biome. Then, they will simply have to wait for a more opportune moment.

TESTING TESTING TESTING

Fun Fact #4: The 'Brittle' achievement used to be possible only with Level 1 Crystal Walls. Luckily, we caught that pretty quickly.

Needless to say, testing is a huge part of the development process, and it’s not a “one and done” deal. Neither is it a one-person job. All developers report problems with the new features and new missions as they work on their parts of the expansion. We try to fix our bugs the moment they are reported, but some slip through the cracks. This is where the QA department comes in. Our testers complete the game on all platforms in many configurations of equipment/game progress for several weeks leading up to the release. This part of development also continues way past the release date as we fix problems reported by you.

The Riftbreaker is available on a lot of various platforms - many PC storefronts and the two next-gen consoles. Each platform we develop the game for has different requirements and rules we must comply with. These generate unique problems that we need to iron out for each platform individually. Unfortunately, this means that sometimes we need to delay things. Into the Dark was not released simultaneously on all storefronts, as we needed some extra time to deal with memory, performance, and save file size issues that plagued some of the builds.

No bugs in this GIF, only a lot of explosions.

In addition to manual testing, we run automated tests several times a day. These tests run the latest available build of the game, and load saves that we prepared beforehand. In total, we run more than 150 saves - a collection made at different points of The Riftbreaker’s story campaign in various versions of the game. Each time we release a new patch, we add a couple of saved states to the test list to ensure compatibility. Not only does the test load save files, but it also saves the game again and checks whether the newly saved game still works. Automated testing allows us to catch a lot of problems before they have even had time to affect us, let alone any users.

MAKE SOME NOISE

If you make a good game, but nobody hears about it, did it really happen? Marketing is another ongoing process that has no clear endpoint. It begins with the moment we announce we’re working on the expansion and lasts for the entire production cycle. The entire point is to make gamers aware of the new content coming to the game - a difficult task considering how many new games and updates are released weekly. In our case, each marketing campaign has a pretty slow start as we usually have very little to show - some promotional artwork, a couple of screenshots, and a vague description based on the features we’re planning to include. The tempo ramps up as more features reach their final levels of polish, culminating with the release of the trailer on the launch day.

The work on the trailer video begins when the first gameplay prototype is available. We write a screenplay with a detailed description of the scenes and what new features they show. We also choose a suitable soundtrack for the trailer at this point, since it’s much easier to edit your video to match the music, not the other way around. Then, it’s time to record sample scenes. These are recorded using whatever is available at that time, even if some of the features are incomplete. Thanks to this approach, we can approve the initial edit of the video early on and replace the placeholder scenes with actual footage, drastically reducing the workload at launch. Here’s an example: an early placeholder version of the trailer for Into the Dark:

Do you recognize the big guy at the end?

And the final version, for comparison:

Another important part of getting the attention of the players is trying to get media coverage. We try to get in contact with game journalists, bloggers, and influencers - but again, so does every developer on the planet. At this point, it is a numbers game - you reach out to as many people as possible. At least ninety percent will not respond to you, and seven percent won’t be interested or won’t have the time. You have to do as much as you can with the remaining three percent of people willing to work with you. This is why it’s really important to start early.

FINAL POLISH

The addition of Volumetric Lighting came in the final weeks of the project. It added a lot of character to the biome.

As we near the release date, more and more features reach their final form. Bugs are fixed. Models are finalized. Sound effects take shape. Dialogue lines are improved and recorded by voice actors. Everyone starts to feel the pressure of the release date drawing near, and we begin the mad dash to the finish line. All placeholders must be removed and substituted for the final assets. At this point, every placeholder that is noticed by the QA is marked as a bug and fixed immediately. Trailer scenes are rerecorded, and the video is edited into the final cut.

A LOT of character. We even rerecorded the entire trailer, even though some scenes were good already.

Sometime before day zero, we release an experimental update for volunteers. The truth is that you can test the game for months, but the moment you release it to the public, you are going to find bugs that you had no idea could even happen. This is due to the differences in hardware, system software, drivers, and even individual playstyle. Releasing an experimental build helps us catch a lot of things that would otherwise greatly impact the final quality of the game. If you take part in our beta periods and report bugs - thank you from the bottom of our hearts!

RELEASE AND POST-RELEASE SUPPORT

We usually have a release candidate build locked in when the release day approaches. It’s a build of the game that is well-tested and good enough for public scrutiny. However, we always plan ahead and usually schedule a couple of patches ahead of time. We also actively monitor the community channels and our crash reporter dashboard in search of the most common problems that we have to prioritize. We include fixes for those with the scheduled patch releases and start over. This loop usually continues for the next couple of weeks. When the number of reported errors dies down, we gradually reduce the hours spent on the project and focus on the next milestone.

The cycle started anew, with World Expansion III now in the works. You can help us by dropping a wishlist here:

https://store.steampowered.com/app/2506610/The_Riftbreaker_World_Expansion_III/

The milestones we currently have in our sights are World Expansion III which you can add to your wishlist now, and, of course, the co-op multiplayer mode. As we stated before, the work on these two runs in parallel and we try to give the programmers as much freedom as they need in order to get this feature to you. As always, if you want to be ahead on the news on The Riftbreaker and all other things related to EXOR Studios, follow us here and join our Discord: www.discord.gg/exorstudios. We also started streaming previews of WE III on www.twitch.tv/exorstudios. See you there!

EXOR Studios