The title of today’s article is not a mistake - that’s a typical filename for an EXOR Studios trailer in the final stages of its production. Looking at our gameplay trailers, you’d never expect that their production takes a long time - it’s just a couple of gameplay clips stitched together, after all. However, the opposite is true. Our trailers are a result of a long process that is a bit messy at times, but always very fun and definitely more interesting than the file name suggests. It's also a process that makes the game itself better in some unexpected ways. This article will talk about gameplay trailers only. We have a couple of CG trailers out there, but the workflow is completely different in their case.

Our very first gameplay trailer for The Riftbreaker. What you can see in the video is pretty much EVERYTHING we had in the game at that point. If you pay attention to details, you will quickly notice that there are only three enemies shown for the entire duration of the trailer. That's because these are the only ones we had. There is also one voiceline that is spoken by your truly. Can you tell which one? Paweł spent an entire week setting up the map for the last scene with the horde and nukes!

Every gameplay trailer we put out is either made fully in-house or in collaboration with an outside editing company. Before a single frame gets recorded, we write a paper draft of the trailer, fully scripting each second of screen time. What do we want to show? What does the mech look like? What kind of weapons are in use? Which setting are we in? We try to make each scene robust enough to convey its own story, but we also pay close attention to continuity between shots. We don’t want to create a blur of cool-looking clips stitched together for no reason. That’s a music video, not a game trailer. If a scene cannot justify its own existence in the context of the whole trailer, it doesn’t make the cut, no matter how good it is.

All the placeholders and missing features can be spotted easily in this commentary trailer. Making a trailer way before launch is basically the art of hiding what's unfinished. You can also see how badly we used to play this game!

The Launch trailer is basically a remake of the video above, but now with production-quality assets and very few placeholders.

The next step is, quite surprisingly, choosing the right music. We pick the track before we start recording a single scene, because the whole trailer gets cut to the beat of music. Sometimes we license something from various stock asset marketplaces. Other times, when we want a more custom treatment, we go straight to our music composer, Marcin Pukaluk. We give him the trailer script and describe what emotions we want to convey and what style we want to hear. After some time, Marcin comes back with a couple of prototypes, one of which gets developed into the real soundtrack of the trailer. After that, we are finally ready to start shooting the actual scenes.

We decided to do a couple of separate trailers focused on the core pillars of Riftbreaker gameplay - one for building and one for fighting. Our inspiration for the building trailer was the Satisfactory reveal trailer. Groovy music with a driving bassline and relaxed gameplay showing that you can totally get 'in the zone' and build for hours.

Regardless of whether we decide to edit the trailer in-house or outsource the editing, we have to record all the footage ourselves. If you see something on the screen in one of our trailers, someone on our team had to actually play it. Trailers usually accompany our World Expansions, which add a ton of new content we want to show off. There is a small caveat, though. Trailers have to be ready before the release date, which means that we have to record good footage while actively avoiding showing unfinished elements of those updates. The first takes are usually shot on a buggy developer build, full of placeholder assets and performance problems that would make anyone flinch. We have made peace with the fact that all of these recordings are headed straight to the trash. However, they are instrumental in creating the first draft of the trailer - a proof of concept that shows whether our paper plans make sense in reality, before we commit them full speed.

The second gameplay pillar - weapons and combat. A big portion of this trailer was recorded on a custom, pre-made map. We built the entire base in the editor, set up custom spawn points, and scripted camera movement a couple of times. The scene with the horde heading towards the base was recorded at half speed and then sped up, because that version of the game couldn't handle that many units and maintain stable 60 FPS. This is also the reason why we recorded all the base defense scenes separately for north, south, east, and west.

That first draft is also the point where the trailer quietly turns into a development tool. We sit down and watch it with two very different questions in mind. The first one is about coverage - what did we plan to show, and what do we simply not have yet? The second one is a lot harsher. What looks bad? What is obviously unfinished? What needs another round of work before we'd be comfortable putting it in front of you? A trailer is merciless in this respect. Seeing your own game in short, isolated clips that you replay over and over exposes every rough edge you had stopped noticing during day-to-day development.

This is our pride and joy. We put in a lot of effort into this trailer, even though we outsourced the editing to Radikal Studio - our go-to partners for this kind of work. It was also fun speaking to Jon Bailey aka Epic Voice Guy and hearing his regular voice.

After that step, we enter the stage of recording scenes with the intention of actually using them in the release version of the trailer. We do this in stages - as the features and assets our scenes depend on mature, we record them and replace the placeholder footage in the trailer draft. By preparing the proof-of-concept trailer version beforehand, we can simply drop the replacement footage into the project timeline rather than starting from scratch. Recording the ‘final’ scenes is difficult in ways that have nothing to do with creativity or execution. There are dozens of small errors that can ruin a perfect scene. Frame drops, random notifications, system sounds, our own music we forgot to mute, or random rendering glitches. These are the kinds of errors you usually notice only when reviewing the footage and usually mean a retake is required.

For the second expansion, we went full indie and did everything ourselves. This is the first showable draft, complete with a timer, scene notes, and LOTS of placeholders. We even forgot that we used the Zombie Driver boss as a placeholder!

After 37423921 iterations, this is what we ended up with. It's the same, but different!

Retakes are the most demanding part of our trailer projects. Our games have no ‘demo’ mode. We can’t pre-program the mech movement, enemy behavior, building up the base, or any other in-game actions. Nothing fakes the footage for us. (The only thing we can control to some degree is the camera movement.) Every single action in every single shot has to be played live, exactly as a real player would. This usually means dozens of attempts to shoot a scene that we pictured on paper. In the most hardcore cases, we spent eight hours just to get eight seconds of footage right. The amount of effort necessary compounds when we record multiplayer scenes - double the players, double the points of failure. Nowadays, with thousands of gameplay hours under our belts, spending eight hours on one scene is unlikely. However, back in the early days it was a real possibility.

The third expansion was an opportunity to show the graphics upgrade the game has received. Better liquid rendering, volumetrics, new shading method. This was a fun one!

This is exactly why trailer production ends up improving the game, and honestly, it might be the most valuable side effect of the whole thing. Since nothing on screen is faked, the only way to make a shot look better is to actually make the game better - so that’s exactly what we do. We fix animation errors, level propping, and visual effects that are too subdued or too pronounced. On top of that, replaying the same encounter dozens of times in a row is a brutally effective way to find bugs, and we fix a mass of them in the process. For the length of a trailer project, a large part of the studio is focused on nothing but making the game look and feel as good as it possibly can. All of that work goes straight into the update you download. Improved visuals, better-feeling weapons, smoother animations, and the squashed bugs aren't trailer magic that evaporates once the video ends - they're in the build, because they had to be in the build for us to record the trailer in the first place. You'll never see the footage we threw in the trash, but you do get to play the game that came out of making it.

These longer 'developer overview' trailers are our favorite. They allow us to talk about everything we want and show off what we have been working on in greater detail. They are easier to make as well, since the editing doesn't have to be so tight. However, this trailer required us to learn a new skill - recording co-op scenes.

Once we have all the scenes we actually want, we get rid of the placeholder footage and do a final editing pass, choosing the right spots for transitions and cuts. After that, we move on to editing audio, where things get surprisingly technical. We pull stem tracks from our trailer video project, with sound effects, voiceovers, and music all separated into their own WAV files, and put them in REAPER, a digital audio workstation. Since SFX, VO, and music were not explicitly designed to work together, they often fight for the same frequency space. The result is a muddy mess that is very unpleasant to listen to. Getting all sounds to coexist peacefully requires a lot of sidechain compression, careful EQing, and volume automation. After mixing, the trailer is almost ready for release.

This is a preview of the co-op gameplay trailer before we sent it to Radikal Studio for editing. This one was cut to "How Much Is The Fish?" by Scooter. It was never a candidate for the real thing, obviously, but it had the exact BPM and the build we needed to test whether the co-op beats landed. Every explosion in here is sitting on a Scooter drop.

The real trailer, edited by Radikal Studios. Hours of footage, condensed into a couple dozen best shots.

We publish our trailers on various platforms - social media, video hosting sites, digital storefronts, and many others. Many of them have different technical requirements for a video. Bitrate, file size, file format, codec used, title cards, mnemonics, closed captions, thumbnails - all of them can make or break your upload. We create a list of the required trailer versions and render separate versions for each hosting service. The number of versions we have to produce can easily go into double digits. However, at this point we usually see the light at the end of the tunnel (the headlight of an incoming deadline), making the end of the trailer project, so time flies when you’re doing it.

The latest trailer we made - a descriptive summary of the World Expansion 4 update. The production went very smoothly on this one, as we had a lot of experience with recording both solo and co-op scenes. Fun fact: all the panoramic scenery shots are made with our in-game camera by hiding the mech and removing all walking effects.

Adding it all up, from the first paper draft to the final platform-specific export, a trailer usually goes through more than thirty iterations before we consider it done - for something that runs a minute and a half… Is it worth it? ABSOLUTELY. A trailer is the single most important asset we have for getting a game discovered in the first place, and it doubles as one of the most intense polish passes our games ever get. That is worth every retake, rerender, and every cup of coffee.

If you would like to learn more about EXOR Studios, our games, and get some more behind-the-scenes development tidbits, join our newsletter at https://www.exorstudios.com/blog/#newsletter and our Discord at https://www.discord.gg/exorstudios. We are always eager to learn from you and share our own experiences!

See you next time!
EXOR Studios

Our game has changed a lot since it came out in 2021. Over the past five years, we've added a lot of new content and features for you to enjoy. The Metallic Valley, Crystal Caverns, Fungal Swamp, and Cryo Field biomes bring more variety to the original four biomes. We've also added hundreds of new technology items to help you take on the challenges in these areas. The expanded endgame campaign gives you something new to work toward after finishing the main story. And of course, we can't forget multiplayer mode. It took us a bit longer than planned, but it's become a big reason why many of you still play. These updates are easy to spot on the release calendar. But there's another change, or a series of changes, that's harder to pinpoint on our development roadmap: the graphics. Today, we want to give you a quick look at how the graphics in The Riftbreaker have evolved.



Here's our 'origin story' video, showing the progress we made during the development of Zombie Driver.Before we dive into The Riftbreaker, let's talk about our game engine, The Schmetterling, and how it came to be. We built it because we needed a solution. Our first big release at EXOR Studios was D.I.P.R.I.P., a total conversion mod for Half-Life 2. At that time, we used free tools and didn't expect to earn anything from our games. We soon realized this approach wasn't sustainable, so we needed a way to support our future projects. That meant making our own game. We came up with the idea for Zombie Driver, but before we could start, we had to pick a game engine. All the commercial engines were way too expensive - licenses cost hundreds of thousands of dollars. That didn't fit with our zero-budget approach, so we had to look for another way.


X-Morph: Defense, released in 2017, brought many improvements, including more spectacular physics interactions. However, it used many outdated techniques that were blocking our progress.

Fortunately, we found the OGRE Engine[www.ogre3d.org], which was free under the MIT license. That fit our budget perfectly! The team took the renderer from Ogre and built everything else in-house. Ogre handled drawing pixels on screen - it didn't touch gameplay systems, tools, platform code, or anything else that makes a game an actual game. As the project grew, that split became a problem. Ogre wasn't built for the kind of cross-platform work EXOR needed. So the team built the EXOR Abstraction Layer, decoupling the engine from any single rendering backend and eventually porting the game across platforms.

This was the actual engine. Ogre was one component inside it, responsible for one job. Everything else, from the ground up, was EXOR's own code. We called it 'The Schmetterling Engine'. Why that name? Schmetterling means butterfly in German, and while our engine is fast and lightweight, we mostly just thought it was a funny word. The engine continued to evolve as we moved from Zombie Driver to X-Morph: Defense. The Schmetterling Engine eventually became the foundation for The Riftbreaker, but first, it needed some new features. So we started working on version 2.0.



This is our first attempt at our classic 'mech running through the jungle' clip. You can notice that we were quite eager to use the new powers that PBR rendering gave us. The 'wet' ground turned out glossy like polished marble. It might have been physically accurate, but not correct.

The biggest difference between Schmetterling 1.0 and 2.0 is the rendering method. The 1.0 version relied on Phong diffuse-specular shading[en.wikipedia.org]. In version 2.0, we switched to more accurate physically based rendering. If you don't care about detailed descriptions, here's the tl;dr: Phong is an empirical model. It fakes shininess with a handful of numbers, like specular color and a "shininess" exponent, chosen by an artist because they look cool, not because they describe how the material actually behaves. Nothing in the model is tied to real-world material properties, and nothing stops a surface from reflecting more light than it receives.

On the other hand, PBR uses real material properties, like roughness and metalness, to determine how a surface scatters light. It uses a lighting model that conserves energy: a surface can never reflect more light than it takes in. This guarantees consistent behavior under all lighting conditions. Here's a great, interactive page that can show you what PBR is all about.[artofpilgrim.github.io] It was a completely new experience for us, requiring us to learn a new graphics production pipeline. As you can see in the examples above, the first attempts were slightly off. It took us some time to learn how to make our materials look good. In the early days, even Mr. Riggs' suit looked different. Over time, we learned to use PBR properties properly and applied that knowledge to improve materials across the entire game.


The first version of the texture on Mr.Riggs' armor was more orange than yellow, did not bring out any detail and reflected light in a way we weren't happy with. We improved it before the official release of the game.

We made many other small changes before releasing our first demo. We learned how to use our new lighting system (you can read more here), which let us take full advantage of the PBR pipeline. After that, we set up a day-and-night cycle (details here). We also replaced our old Screen-Space Ambient Occlusion with Horizon-Based Ambient Occlusion, which handles complex shapes and uneven surfaces much better and helps us create more realistic indirect lighting. We were happy with these improvements. In June 2020, you could try them yourself when we released our first demo during Steam Next Fest. But we still had more to show.



Back then, we weren't able to have multiple shadow-casting light sources in one scene. DXR gave us that possibility. We later introduced improvements that made it possible without the use of raytracing.

At the end of 2020, we showed off the DirectX 12 raytracing (DXR) we'd been working on. Raytracing let us create pixel-perfect shadows from multiple light sources, so it wasn't just Mr. Riggs' spotlight casting shadows at night. If you ran into another strong light, like a boss creature, both lights would cast detailed, dynamic shadows. DXR also helped us make shadows more realistic by softening them as the light source became more diffused. For example, a rock's shadow would be sharp in sunlight but get softer if it was cloudy, just like in real life. We also added Raytraced Ambient Occlusion to make the graphics even better. Unfortunately, we had to remove DXR features from the game due to issues beyond our control, but we found other ways to make up for it.


Here's a showcase video for our Screen Space Reflections. You can really see the difference in these on/off scenarios.In late 2022, we added AMD FidelityFX Stochastic Screen Space Reflections (SSSR). This let us show real-time reflections of buildings and map props on reflective surfaces like metals and liquids. Before SSSR, reflective surfaces relied on the skybox rather than what was actually happening in the scene. It might not sound as flashy as raytracing, but it makes a real difference. Reflective floors, wet surfaces, and Morphium all look noticeably better reflecting the actual scene around them instead of just the sky. It's one of those upgrades you don't consciously notice until you go back and look at old footage without it.



The tiled deferred shading algorithm divides the screen into tiles of 16x16 pixels. Each tile knows exactly how many and which light sources affect it. This allows us to calculate lighting information much more efficiently and grants us additional possibilities.

In early 2023, we made more upgrades to The Schmetterling Engine. We added Tiled Deferred Shading (learn more here), which made the game run much better in scenes with lots of lights. This let us increase shadow map resolution and use several shadow-casting lights at once, even without ray tracing. The tradeoff is a bit less accuracy, but performance is much better. If you look closely, you might notice small differences between the two methods, but they're pretty subtle. Tiled Deferred Shading also made it possible for us to add more improvements later on.


Volumetric lighting effects allow us to simulate things like rays of light shining through a hole in the cavern ceiling. They also allow Mr. Riggs' headlight to scatter more softly.
One of these upgrades came with the release of the Into the Dark DLC and World Expansion 2. Crystal Caverns was the perfect place to introduce Volumetric Lighting (more info here). Volumetric Lighting lets us show how light interacts with particles and air, giving us more control over the game's look. This effect is fully dynamic. For example, we can change the weather to add or remove fog and even adjust its color. We can also tweak fog in certain parts of the map to set the mood. While this isn't a brand new technique, it gave The Riftbreaker a big boost in visual quality.



The last big graphics upgrade for The Riftbreaker was better liquid rendering, thanks to our switch to Tiled Deferred Shading. Before this, we couldn't show transparent surfaces or materials, which is why our buildings didn't have windows. There is one exception to this rule: particle effects materials can be transparent, but in turn they are always unlit. The Heart of the Swamp expansion was the perfect time to add real transparent liquids and effects for how things interact with water. (Read more here) Since this area is full of water and mud, we wanted it to look right. We improved how all liquids look, added decorations to the bottoms of pools, and included details like wave ripples and wakes from objects moving through the water.


WHERE DID RAYTRACING GO?


Here's a direct comparison between the raytraced and non-raytraced shadows. Both videos have been recorded on July 16th, 2026 using the Steam build of the game. Thanks to the upgrades we made over the years, the difference is minimal.

Now it's time to address the big question: why did we remove raytracing options from the game? We made this decision after several driver updates caused major instability on some systems. We didn't see these problems during our own testing, but because everyone's PC setup is different, many players started experiencing constant crashes. We waited for updates and fixes, but they never came. Even though it was tough for us, since we put a lot of work into these features, we decided to turn them off for everyone and remove the option from the settings menu. But raytracing isn't completely gone.

If you feel adventurous and want to try playing The Riftbreaker with raytracing enabled today, there is a way to do it. All you have to do is:

1. Go to your Steam library. Find The Riftbreaker.
   
2. Right-click it on the game list, select Manage > Browse Local Files
   
3. Go to the folder "conf", open initial_config_win.cfg with notepad.
   
4. Change the variable set d3d12_raytracing_support 0 to set d3d12_raytracing_support 1.
   
5. Save the file and launch the game.

This will allow you to enable raytracing options in the game settings menu once more. Keep in mind, we haven't tested raytracing in a long time, so it might be unstable, especially in co-op. But if you want to try it, you can.


Boy, did we come a long way from this...


...to this! And the best part is that these improvements will benefit us in our future project(s).

The Riftbreaker and The Schmetterling engine have come a long way over the past few years. We've made big improvements to the game's visuals and developed features that will help us in the future. We learned a lot along the way, and we hope you found this interesting too. If you want to get our news as soon as it's out, sign up for our newsletter at https://www.exorstudios.com/blog/#newsletter and join our Discord at https://www.discord.gg/exorstudios. We hope to see you there!

EXOR Studios