The deadline for the first Riftbreaker Modding competition is fast approaching! Many talented modders have already sent in their entries to get the chance to show off their mod-making prowess. They all have taken their shot at winning their share of our prize pool. Will you take your shot as well?
If this is the first time you’ve heard about our contest, here’s a quick recap of all the important information:
We’re holding a Modding Competition in cooperation with mod.io.
There are two categories in the contest - Custom Maps and Game Modifications.
The 1st prize winner in each category will receive a custom-made gaming PC with The Riftbreaker artwork printed on the case.
The 2nd prize winner in each category takes home an AMD Radeon 6800XT GPU.
Runners-up from 3rd to 8th places in each category receive a Mr. Riggs plushie and a bag of EXOR Studios gadgets.
EXOR Studios will pick the shortlist of candidates in each category. Then, the winner will be determined by the community in the form of a public vote.
Submissions close on June 10th, 2023, 00:00 AM GMT.
So, what are you waiting for? Download The Riftbreaker Editor Suite from Steam or from our GitHub and give yourself a chance at winning as well. You’ve still got 1.5 months to blow us all away with your creativity and skills!
If you have any questions for us, please do not hesitate to ask either here or on our Discord server at www.discord.gg/exorstudios - we will gladly help you find your way around our tools and achieve the results you want. You can also help us improve the Editor Suite by reporting issues and adding suggestions here: https://github.com/exorstudios/riftbreaker-tools/issues.
As you know, along with the release of Into the Dark, the second Story Expansion for The Riftbreaker, we are also releasing our second World Expansion. The World Expansion is free for everyone and brings a lot of changes and improvements for the game. Apart from giving you access to the Crystal Caverns biome in Survival mode with all of its features, new tech and equipment, you will also be able to enjoy a lot of changes and improvements for the base game. One such feature is the “Building Ruins” feature we talked about last week. Today we will tell you about another addition we are implementing to improve your gameplay experience - new map tiles we prepared for the Acidic Plains biome.
First, let’s do a little recap of what map tiles are and what role they play in The Riftbreaker. Maps in The Riftbreaker are randomized to give you a slightly different experience every time you launch the game. Our procedural generation algorithm stitches a full map together from a set of pre-designed tiles handcrafted by level designers. This ensures a natural look and feel of the world and also guarantees that maps will contain all the elements necessary to play the game - resources, spawn points, and many more. A typical survival map is a square composed of 36 such tiles. You can read more about this process in this article.
Mr. Riggs likes making an explosive entrance.
In the current version of the game, the Acidic Plains biome maps are generated from a set of just nine different base tiles. The number might seem small, but thanks to rotation, randomization of props within the tiles themselves, and specific mission generation rules, you can still get decent results and guarantee that each map feels different. However, the more you play, the more patterns you start to notice. We were not really satisfied with that, so we decided to expand the tile pool.
We expand the tile pool to give you more nice places to line with the bodies of your enemies.
The World Expansion update will give you access to ten new tiles, bringing the total up to nineteen (more than double the original number - yay!). If we do a little bit of math (a little simplified math, to be exact - we have parameters to control the generation process to get the results we want), that gives us almost three thousand possible 6x6 base map layout variants. The new tiles also feature elements that we previously had to avoid. One such example is tall rock structures that obstruct the camera view. Now, with the introduction of the camera object culler, tall structures are no longer an issue, so we can use them more freely. We could spend a long time describing each tile, but we will let the images speak for themselves:
Holes and canyons are a big part of our new tile design approach. You can say the caves influenced us. Objects beneath the main surface of the tile are often covered by the distance fog, making the caverns feel more mysterious. It's spring, so here's a nice flower. Naturally, our first thought was to throw a grenade in there to see what happens. Some tiles are more classic. This example still offers interesting natural protection options. Not all map tiles have to be square. By making a tile like this we can, for example, create large rock structures several hundred meters in length. New tiles are not any less dangerous than the old ones, so be careful while exploring. Who made these circles? Probably aliens. Tall objects will be a much more common occurrence with the camera culler system. Here's how the culler works during building.
The Acidic Plains biome is not the only biome that’s getting special treatment with the World Expansion 2 update. We are also preparing more tiles for the other biomes - we’re just not quite ready to show them off just yet. We can tell you, though, that some of them have a special purpose… If you would like to find out what it is, be on the lookout for future news and join our discord at www.discord.gg/exorstudios, where you always get access to the news first!
Today we will look at a much-requested quality-of-life improvement that will come to you as a part of the second free World Expansion update - the free part of our upcoming Into The Dark expansion. The feature in question is building ruins. Many of you let us know that rebuilding the base after a large attack is difficult and time-consuming. It is not easy to remember the exact placement of all structures, and setting everything up manually when under time pressure makes matters even less pleasant. We hope that this feature will remedy that.
You could previously see the prototype of the ruins feature during our developer streams (every Tuesday and Thursday, 3 PM CEST, www.twitch.tv/exorstudios). The premise is really simple - once a building is completely destroyed, it leaves behind a pile of wreckage. The wreckage can be identified either by selecting it in build mode, where it will display the name of the original building, or by the visuals. Each building has a custom-made wreckage model to make identification a little easier - more on that later.
Testing destruction features is always the most fun.
Once a building is destroyed and wreckage spawns in its place, you have two options. You can use the deconstruction tool to remove the rubble completely and recover the space, or you can use the repair tool to rebuild the original structure for its full price. You can also use the mass repair/deconstruction tools to take care of multiple pieces of wreckage all at once. If you want to reconstruct multiple buildings, a tooltip will appear, informing you of the total cost of repairs. If you can’t afford the total cost of repairs, the game will try to repair as many buildings as possible instead, so you can bring your base back into shape piece by piece. Ruins have an unlimited lifetime, so you can simply come back to them whenever it is convenient for you.
Less time spent on repairs = more time spent on upgrades!
Naturally, modeling ruins for all buildings in the game would have taken a long time, and using a generic model for all structures would make identification very difficult. To speed the process up, we used Houdini. It’s a tool suite that uses procedural generation to let artists quickly iterate on their models, create visual effects, and much more. In our case, one of the artists created a specialized setup that can remove large parts of building models from The Riftbreaker in a matter of minutes. Here’s how it works.
We swear, this is work, it's not just fun.
First, we import the Blender building model into the specialized Houdini setup. The base part of the setup is a very large cube (large enough to cover all individual building models we have in the game). The bottom surface of the cube is irregular instead of flat. That is because the bottom surface is where the actual ‘cutting’ process will take place. When the bottom of the cube reaches the top of the building model, polygons are automatically removed.
Before and after the procedurally-generated destruction.
The artist can control at what height they want to cut the building. Houdini automatically generated the new geometry that covers the wreckage surface. That surface is then covered with a ‘burnt metal’ texture. When the artist is happy with the result, they export the new wreckage model to Blender for a final touch-up. Thanks to all this, a monotonous process that would take weeks for all buildings in the game can be completed within a couple of days.
As we slide the cube further down, more parts of the building disappear.
This feature will arrive to you as a part of the next large free game update. It will work even on saved games made earlier, so you can continue your campaigns with this new option available to you. We hope you will enjoy playing with it and that you will suggest even more improvements to us. In fact, this idea came from our suggestion board: https://riftbreaker.featureupvote.com/suggestions/332558/ghost-buildings-to-show-where-destroyed-buildings-were. Don’t hesitate to post your own ideas - we carefully consider all of them! If you want to contact us directly, reach out on Discord: www.discord.gg/exorstudios.
When we started developing our games, EXOR Studios had few choices regarding picking the right game engine. In early 2008, the commercial solutions were out of our reach because of their prohibitive costs, while free engines offered only some of the features we needed. Thus, we decided to develop our technology based on multiple open-source solutions, including the OGRE 3D render system. This allowed us to build games precisely how we wanted to. As years progressed and we moved from one project to another, the Schmetterling Engine slowly began to take shape and eventually evolved into the complete framework we use today.
A making-of video of our first game, Zombie Driver. You can see how it all started for us those 15 years ago!
Developing your engine comes with many difficulties. You can’t refer to any documentation or expect bugs to be fixed by someone else - you’re on your own. On the other hand, you are free to implement solutions that your game will benefit from. We have already told you about some of the new additions to the Schmetterling Engine we implemented for The Riftbreaker. Raytraced Shadows and Ambient Occlusion, AMD FSR, and Intel XeSS are just a few of them. Today we would like to discuss a significant improvement coming to the engine - Tiled Deferred Shading. This cryptic-sounding technique opens the door for improvements and new features in The Riftbreaker. We’d like to talk about how this new technique works, but first, we need to discuss some basics about shading in general.
Deferred Shading
There are several ways you can approach computer graphics rendering. The available ideas and techniques vary considerably, resulting in unique requirements, advantages, and disadvantages for each one. Our earliest project - Zombie Driver, used forward rendering. In this technique, the scene is rendered by drawing each object in the scene one by one. Each object is rendered with its own set of material properties, such as color, transparency, and reflectivity. Lighting is applied to each object in the scene as it is rendered, calculating the contribution of each light source to the final color of each pixel on the surface of the object being rendered.
In Zombie Driver we used forward rendering. We were limited to using only one light per scene. None of the particle effects you can see in this picture emit any light. We faked the highlights with additive alpha particles - smoke and mirrors ;)
It sounds simple enough, but it has a major disadvantage - to ensure correct results, contributions from all lights need to be taken into account per each pixel on the screen. If the scene is lit by only one light source, it can be quite quick. However, when you add more lights, things can get complicated. Even if a pixel is fully occluded and is not lit by any of the light sources on the screen, the forward rendering method will calculate the lighting for that pixel anyway. We will learn that it is occluded only after computing the lighting for that pixel, and all that computational time will be wasted. This is why we have been using a more efficient technique called Deferred Shading in our later projects, X-Morph: Defense and The Riftbreaker. It excels in handling multiple light sources, which allows us to create scenes with many dynamic lights without sacrificing performance.
The primary advantage of deferred shading is treating the scene geometry and its lighting separately. In the first stage of the shading process, only the 3D geometry of the scene is rendered. The resulting information about each pixel's position, surface normal, and material properties is stored in the geometry buffer - or G-buffer, for short. In the shading stage, the lighting and shading calculations are performed using the information stored in the G-buffer. Lighting is calculated using the previously collected data stored in the G-buffer. With all the geometry data available at this point, lights are computed only for those pixels which they actually affect. We can also calculate complex post-processing effects such as ambient occlusion, temporal anti-aliasing, and upscaling thanks to all the information stored in the G-buffer.
The use of deferred lighting in X-Morph: Defense allowed us to use multiple light sources. In night scenarios, scenes are only lit by additional lights - there is no directional lighting present on this scene.
The current G-buffer layout in The Riftbreaker looks like this:
However, deferred shading also has some limitations. Reading and writing to the G-buffer takes some time, which can be a major downside when it comes to lower-spec hardware. It also does not scale well with high numbers of lights on the scene. Still, the most glaring issue for us regarding The Riftbreaker is transparency. Deferred shading can’t handle transparent objects. The fact that the technique relies on the g-buffer information means that all things that are not opaque can’t be used for lighting calculations since the buffer doesn’t store any information about non opaque geometry. This is one of the reasons why we decided to upgrade our renderer to use Tiled Deferred Shading.
Tiled Deferred Shading
Tiled Deferred Shading is an evolution of the Deferred Shading algorithm. The screen is divided into a grid of tiles, in our case, 16x16 pixels each. Each screen tile holds information about light indexes that affect that tile. This data is later used for light computation for opaque and non-opaque objects.
A debug view of a scene from The Riftbreaker with Tiled Deferred Shading enabled. The tile grid is visible. In this view, the color of the tile tells us how many lights affect the tile. The closer it is to red, the more lights affect a tile. It's essentially a heatmap.
We didn't joke about the heatmap thing.
The benchmark scene we used to test this technique. You can see how lights change in real time.
The algorithm for this process is:
G-buffer pass - Draw all opaque geometry.
Compute tile frustums - prepare frustums individually per tile depending on the buffer minimum/maximum depth.
Culling lights pass - use frustums to check if the light overlaps the tile and insert its index to the light index list.
Compute light shading for opaque objects - Use G-Buffer and prepared lights list for a single pass screen space light computation.
Compute light shading for non-opaque objects - Draw each non-opaque object and compute light shading per pixel only for lights that belong to the tile.
In higher resolutions the tile grid becomes more dense, allowing more precise calculations and much greater granulation.
The main advantage of this approach over the Deferred Shading we used up to this point is much higher efficiency. Traditional Deferred Shading has to access the G-buffer individually for each light source during the lighting pass The Tiled Deferred algorithm allows us to read the G-buffer only once for all light sources.
For contrast, in lower resolutions, the grid loses its precision.
The additional processing required for culling lights can add some overhead to the rendering pipeline on scenes with just a few light sources. In The Riftbreaker’s example, this is typically overcome in situations with more lights, such as bases with large numbers of defensive towers. The increased speed of completing the lighting pass becomes clearly apparent in those instances.
Results
In recent tests we conducted on The Riftbreaker, we observed that implementing tiled deferred shading resulted in a significant increase in performance. Specifically, tests we ran on various hardware revealed considerable performance improvements when it comes to scenes with many additional dynamic lights. On average, The Riftbreaker ran 20% faster in scenarios with many towers, explosions, enemy units, and building lights on the screen compared to the traditional deferred shading approach.
Test case 1: static scene, adding lights manually one by one.
This is what the synthetic multi-light test scenario looked like.
Synthetic multi-light benchmark scene results. In scenarios with more than 100 lightsources Tiled Deferred Rendering provides an almost 100% FPS boost!
You can see the tiles changing color as we turn sets of lights off.
Test case 2: In-game CPU benchmark mode.
Results presented are the average of 2 runs.
The test scene without the debug overlay.
"Benchmark CPU" testing results on three sample configurations. This benchmark is not perfect for testing this rendering method because it focuses primarily on CPU overhead. However, even in this case, we can report visibly better performance results.
Conclusions and future works
Tiled Deferred Rendering has allowed us to save a lot of CPU processing power in The Riftbreaker. This technique will make it easier to maintain high, stable frame rates, or if you’re already running the game above your monitor’s refresh rate, it will reduce the strain on your GPU and will lower your electricity bill - everybody wins! You will be able to start enjoying its benefits as soon as the World Expansion 2 free update reaches your hard drives.
Thanks to the changes we have introduced to the Schmetterling Engine, exciting new possibilities have become available for use in The Riftbreaker and our future projects. With tiled deferred shading, we can now add support for transparency and particle light shading or even go for something much bigger like volumetric fog support. We believe that these improvements will positively affect the player's reception of the game and give our artists more creative freedom when it comes to designing levels and effects.
We hope you enjoyed this deeper dive under the hood of the Schmetterling Engine and The Riftbreaker. We are really excited with the possibilities unfolding before us, and we hope to start using the new tech as soon as possible. Join our Discord at www.discord.gg/exorstudios to keep up with all the development news. Remember to post your ideas and suggestions at riftbreaker.featureupvote.com!
See you next time! EXOR Studios
P.S. During the last developer stream on Twitch we managed to finish a full Survival run in co-op, running a dedicated server in headless mode. We're making progress! Join us on Tuesday at 3PM CEST at www.twitch.tv/exorstudios for the next one!
Every week brings us closer to the release of Into the Dark, the upcoming second World Expansion for The Riftbreaker. We can’t wait to hear what you think of all the new content we have prepared for you. In fact, you will have a chance to tell us pretty soon, as we’re going to hold a closed beta test of the Survival portion of the update - join us at www.discord.gg/exorstudios for more details. Today, however, we would like to tell you more about one of the most terrifying and unique threats you will face in the Crystal Caverns biome - the Necrodons. Strap yourselves in - this one is really unique, not only when it comes to appearance but also its ability set.
The Necrodon is a creature that you might have seen in the game previously. We originally intended to include it in the original release in October 2021. We prepared a 3D model, visual variants for Alpha and Ultra strains, and all the animations. However, we didn’t finish programming and testing its behavior and skillset. Furthermore, it didn’t really fit in any of the Galatean Biomes, and we couldn’t really figure out its gameplay role. As the release date drew near, we decided to put the Necrodon on the shelf and come back to it at a more opportune moment. You can still encounter it sometimes in the Desert Biome, but it’s nowhere near what it is today. When we came up with the concept of the Crystal Caverns biome, the Necrodon finally got its moment to shine. An entire cavern system filled with crystalline formations of an unknown origin and purpose was the perfect home for this monster.
Necrodons are tall, menacing humanoids. Their physical appearance differs from other Galatean creatures. A standout feature of Necrodon’s physique is the presence of crystals that seem to grow out of their bodies in various places. Either these creatures have been infected by the crystalline growth that is present all around the crystal caverns biome, or they have been brought to life by the growth itself. Both prospects are equally terrifying, especially when their abilities are considered.
Necrodons are not confrontational and aggressive on their own. If one is encountered in the wild, it will do its best to run away to safety. Once cornered, the Necrodon will do its best to scare the attacker away. Most often, they will try to deliver a powerful hit using their long arms. However, that’s not the only move in their arsenal. Necrodons seem to possess the ability to manipulate matter around them, similarly to Lesigians, but to a different extent. This allows them to concentrate energy into a powerful beam that they can direct at the creatures that decide to attack them. Still, Necrodons prefer to avoid direct confrontation and use their powers in more creative and terrifying ways.
These creatures become truly terrifying when accompanied by other species. Once in a while, you will encounter an attack wave that seems to never end. No matter how many enemies you defeat, it will seem like more join the ranks in their place. That’s the Necrodon’s true weapon - they are able to raise the defeated creatures back from the dead to fight by their side. If you’re not careful, they will hang back just out of your line of sight, bringing back more and more creatures. Even if they run out of corpses to bring back, they can even create entirely new undead creatures, seemingly out of thin air. Naturally, it is not the case - Necrodons manipulate organic matter to form a semblance of a living creature, very similar to a canoptrix. Nonetheless, it is a terrifying ability, and you must deal with them as quickly as possible.
There is a limit to Necrodon’s abilities. They won’t keep summoning creatures to their side without end. There is only a limited number of “minions” Necrodons can control at one time, meaning that you can overpower them quite easily if they are on their own. It gets a bit more difficult if you encounter several specimens during one attack wave. In multiples, they can eventually overwhelm you and your defenses, so plan accordingly. Additionally, remember that Necrodons can only raise creatures whose bodies remained intact after death. If you blow creatures to shreds, they will eventually run out of bodies to resurrect and have to resort to creating their necro-canoptrix, which are quite weak on their own.
That’s it for today. If you’d like to see more of the Necrodon in action, tune in to our streams on Tuesdays and Thursdays on www.twitch.tv/exorstudios. We also preview our tests of the co-op version there, so you should definitely join in and see how it’s coming along! Don’t forget to post your suggestions and feedback on riftbreaker.featureupvote.com, as well as our Discord server at www.discord.gg/exorstudios.
After two weeks break, it is time to return to the second Riftbreaker World Expansion: Into The Dark. We have already told you about some of the new game mechanics, buildings, and creatures you can expect to find in this biome. Today we would like to focus on a completely different aspect of the Caverns biome - the map tiles design. In this article, you will learn about all the new features we prepared to make this biome look and feel much different from what you’re used to. Read on!
Let’s start with the basics. As we explained before, maps in The Riftbreaker are generated procedurally by stitching together predesigned elements that we call tiles. The designer gives tiles a general structure through the use of movement-blocking props. These are usually boulders - they dictate where you can or cannot go and what kind of space will be available for you to build your base. Designers also place spots designated for resources, enemy spawns, bioanomalies, and prefabs containing various props. These rules remain the same in the case of the Caverns biome.
Map tiles from this biome seem claustrophobic, but it all changes when you turn the destructible rocks off!
The first difference is that almost all tiles are covered to the brim with our new ‘destructible rocks volume.’ It is a game logic structure that tells The Riftbreaker which areas of the map are allowed to be covered with destructible rocks, which we discussed in one of our previous articles. We do not place them manually - instead, the engine spawns them automatically. We can also determine how much of the tile we want to fill with rocks. If we create a tile focused on exploration, we will choose a more open layout that will not produce as many rocks as in the case of a tile we want you to dig through.
This biome allows us for more verticality in our map construction.
While most of the map is covered with destructible rocks volume, it does not mean that boulders are the only thing you can find in the Galatean underground. Our map generation system can make maps more attractive by cutting out caves and clearings within the rock structure. We have developed rules that control the extent to which destructible rocks will fill the level. Based on a specialized algorithm, some areas of the level will be left blank to accommodate various points of interest placed by the designers. If we simply filled the entire level with rocks, it could cause technical issues, for example, creatures spawning within walls. Besides, it would feel monotonous, which is the last thing we want.
Most of the caves and clearings you can see here were created automatically using our systems.
However, if all caves you stumble upon were filled with objects of interest, you would very quickly notice a pattern there. To avoid that, we developed a unique feature to add even more variety to the biome. The map generator can now use masks to change the map layout. There are two varieties of these masks - one is used to remove parts of the destructible rock formations. The other one ‘cuts out’ holes in the ceiling of the caves for the light to shine through. Let’s take a look at each type and see how they work.
Masks used to generate caves are rally simple. You will be easily able to make your own for modding purposes.
These masks tell the game where it can spawn our rock formations. The key is simple - white means the space should be left empty, and black means it’s fair game. The mask is a 128x128, black and white png file, with each pixel corresponding to one grid on a standard, square map tile. During the map generation process, one of these masks is taken randomly and virtually laid on top of the tile. Then, parts of rock formations are removed wherever the white pixels from the mask have landed. Rotations of the tile and mask are randomized, resulting in many possible combinations.
The masks responsible for light spots are more nuanced. The delicate glow around the holes is necessary to create on illusion of light scattering.
The other type of mask is more complicated. These textures shape the sunspots allowing sunlight to pierce through the ceiling. The white pixels determine not only the shape of the skylight but also allow us to create an approximation of the light’s behavior. The intensity of the white pixels on the mask determines how much light passes through the mask, trying to emulate the light scattering. Sunspots are an important gameplay feature in the Caverns biome. While generating power from solar panels is not the first choice here, you will have the option to place a couple of panels here and there if you like to!
An example of a couple of light masks in action.
Designing an exciting map tile in such a claustrophobic environment is no mean feat. Plants, mushrooms, and other props are rare and need to fit their surroundings - you don’t expect to find a forest in the middle of a cavern system. Verticality plays a much greater role in creating the atmosphere of this biome. First of all, thanks to the camera object culling system that we implemented, we can now build much taller structures without worrying about obstructing the view. Stone arches, stalactites and other formations make an appearance, giving you the feeling of actually being underground.
Everything that is situated below the ground level of the map is bound by an artificial box that prevents you from seeing artifacts.
While exploring the caves, you will often find that they open up into larger, naturally formed caverns. Such spots were featured previously on other biomes, but not to this extent. We build a ‘box underneath each tile where we want to show the lower levels of the cave. It ensures you won’t be able to see the skybox bleeding through the ground at any angle and gives us a rock-solid foundation to set up exciting sceneries that give you a real sense of depth when looking into them. Things get even better when the generator puts a skylight directly above such a spot, as lighting and shadows can completely change the presentation of the scene.
Tiles vary in how much of their area can actually be traversed.
As you can see, we had to solve several issues and develop several new features to bring The Riftbreaker’s gameplay underground. We are happy with the results and think that you will find the Caverns biome to be a completely unique experience. We also hope that the new features will be useful to you from a modding perspective. Remember that this world expansion's functional content and Survival Mode biome will be available to everyone as a free update so you can use it all in your creations. Speaking of modding, we await your submissions in the modding contest! We have some gaming PCs and GPUs looking for a new home. Don’t keep them waiting too long! As always, we are waiting for your feedback and questions! Catch us here, on social media or www.discord.gg/exorstudios. We’re also waiting for your suggestions at https://riftbreaker.featureupvote.com/.
It’s been quite some time since we last shared information about our progress on the co-op mode for The Riftbreaker. Many of you have been wondering how we’re doing on that front and why we have been so quiet for so long. The reason is quite simple - our programmers have been doing a lot of code refactoring and other work under the hood of our game engine. For a very long time, we could not show off immediately visible progress. However, all that work is being done for a reason, and recently, we’ve hit a couple of significant milestones. They allow us to check on co-op progress daily, find areas to work on and introduce small improvements often. Let’s talk about what’s changed since the previous article and what the plans look like for us.
WHAT HAS CHANGED SINCE THE LAST TIME?
Our previous article listed the engine areas and game systems that would be our immediate focus going forward. We don’t expect you to read all that again, so here’s a TL;DR version: to minimize data transfer and latency, we aim to separate most systems into the client and server parts. For example, when you chop down a tree, the server only needs to know that the plant is no longer there. All the visual work - particles, parts flying, the trunk falling - can be done on the client's side. After the server broadcasts the message ‘Tree 49038 has been chopped down’, clients can reproduce that state independently, reducing latency and data transfer. This is a simplified example, but this philosophy can be applied to many game systems.
One of the systems that are co-op ready now is the MechSystem. It is responsible for all the actions of the players’ avatars. It translates pressing ‘W’ on your keyboard to ‘move the mech up’ command that the game can understand. As we told you last time, we couldn’t simply send player inputs from the client to the server since key presses mean nothing to the game. Instead, we send ‘translated’ commands that the game can act on and apply immediately. An excellent optimization introduced here is double verification of command legality. For example, player 2 (the client) is trying to throw a grenade. They press the hotkey, but they have no grenades left. The game sees that, determines that the command is illegal, and doesn’t even bother sending that info to the server. Scenario two: player two is trying to throw a grenade again. They press the hotkey and have grenades in their inventory. Information is sent to the server. The server verifies if the move is still legal, and if it is, the grenade is finally thrown. This reduces the number of potential errors that could stem from mismatched information between client and server machines.
The VegetationSystem has also been separated into client and server parts. This system is responsible for handling all things related to flora - swaying in the wind, bending in contact with creatures, and the growth cycle of plants, among other things. We concluded that the server should only handle the lifecycle part, so the plant is growing back after being destroyed and transitioning through its growth stages. This ensures that all flora entities are synchronized for all players and prevents situations where a tree sapling is displayed as an age-old, towering tree for one of the players. The client-side handles all other interactions with plants, such as bending, since they do not have any tangible effect on gameplay.
Another system that has undergone significant changes is the TerrainGridSystem. This system stores all information about the grids that we can see on the map. It tells the game whether the grids are occupied by buildings, if resource deposits are available, or if there are any liquids or props on the ground. We used to store that information in one large data structure. However, transferring all that info every time something changed could have been more optimal. We separated the entire terrain grid into smaller entities, one for each 2x2 meter grid, which can hold information on their own. This allows us to exchange information about the relevant parts of the world, not the entire map, and - you guessed it - minimize data transfer. There are two nice side effects to this. The first is that we will be able to embed fog of war information into grids, effectively killing two Vesauruses with one stone. The second - the data structure for TerrainGrid is much smaller now, reducing the overall save file size and shortening the dreaded autosave hiccup!
The DestructionSystem got a major overhaul as well. This system handles all the visual changes when an entity is damaged. Once more, we moved all the elements not essential for gameplay to the client side. Particle effects and random debris that get spawned when something is damaged do not affect the overall gameplay state, so they can be simulated for each client. It doesn’t matter if there are minimal differences between them. We kept all the relevant bits on the server, such as loot and wreckage (just to clarify, dead bodies of killed creatures are called ‘wreckage’ as well). Those elements are synchronized across all computers participating in the session and are guaranteed to line up with each other.
While playtesting the super early multiplayer builds, we quickly came to a couple of conclusions. The first one was - ‘wow, this is fun.’ The second - ‘haha, I can steal all the hard-earned money from my co-op buddy.’ The third - ‘WHAT DO YOU MEAN THEY USED UP ALL THE AMMO?!’. One of those is not like the others. We realized that working towards a shared economy, building infrastructure, saving up for big projects, and a little bit of trolling here and there is all fun, but having a common ammo pool is rather unfortunate. You might have got yourself into fights that you couldn’t win because your partner has used up all the ammo without telling you about it. This led to frustration. To avoid that, we decided to separate ammo pools for all players.
All those changes are super nice and were necessary steps on our road to reaching a playable build. Obviously, much work is ahead of us, as many systems still need a rework. However, one thing we’ve recently done makes us really optimistic about the future.
MAJOR BREAKTHROUGH
As an experiment, we decided to try out some aggressive parallelization techniques. Most modern CPUs have multiple cores, often divided into even more threads. Each of those threads can process data independently from the others, meaning it is possible to carry out some operations simultaneously. This is called parallelization. Not all procedures can take advantage of this, as sometimes you need to know the result of one calculation to start working on the next one. However, for the co-op version of The Riftbreaker, we found an exciting avenue that could potentially lead to significant performance gain.
As an experiment, we decided to allow the client side of the game to process data deserialization (in human terms: deciphering data received from the server) and the world update processes simultaneously, using as many threads as possible. We did a similar thing for the server with processing client game states - each client got their own CPU thread now. Without going into much detail, we saw an immediate increase in performance that allowed us to play at a comfortable performance level for quite lengthy periods. As a result, we started running more tests, noting all the bugs, errors, and design problems we noticed. At one point, we even managed to run a 4-player game without any issues (for a few minutes).
This is a very important step for us. We use playtesting as a driving force for our development process. We simply didn’t want to spend too much time testing the co-op mode for a very long period, as too many things were not ready, and the performance made it very difficult to make any meaningful progress. Now things are different. We can jump into a multiplayer game at any time and try to break it in new ways. With each test that we run, we find new bugs to fix and new avenues for improvement. The progress we’re making now is faster than ever, and we are very optimistic for the future.
WHAT’S COMING NEXT
Running regular playtests will supply us with a steady stream of minor (or major) bugs to fix. However, it is crucial to remember the big picture and adapt the remaining systems for co-op use. One of the most important goals we have our eyes on is reworking the EntityComponentSystem. Reducing the amount of data we have to synchronize between server and client entities will play a major role in increasing the performance and stability of the game. Large chunks of data in our entities always stay the same. For example, each item has its name, icon, blueprint, and sound effects. All that information is stored in the entity file for that item. We want to be able to flag such components and simply ignore them when synchronizing the game worlds.
Another aspect of the game that will get a little bit of special treatment is Research. It’s a massive part of the gameplay loop, so it must work well. The computational cost of this system in a singleplayer game is completely irrelevant, but in multiplayer it suddenly becomes a problem. The entire research tree, the queue, and the download timers are part of one large data structure. When research is running, we need to update it very often, increasing the strain on the CPU and sending large amounts of data. We could use those resources elsewhere, so we plan to prepare a custom serialization method allowing us to only exchange the relevant bits and pieces of the research data structure between the server and client PCs.
The question of reducing data transfers has appeared several times in this text. Our focus on that might seem slightly excessive in the days of fiber internet and 200 GB game downloads, but we pay attention to that for a different reason. The more data we send from one PC to another, the longer it takes to unpack everything and apply the changes. Our current system marks all the entities that have potentially changed since the last game world synchronization occurred. For an average Survival map, that could be somewhere between 2000 and 4000 entities (per server tick/update). The server sends such a synchronization package every 33 milliseconds, with the client constantly receiving data and continuously applying changes. That’s a lot of data to parse, and it comes 30 times every second! What is worse, though, is that in the end, it often turns out that out of the original 2000-4000 entities marked as potentially changed, only a handful needed to be synchronized. Therefore one of our biggest goals is to filter all that data and send only the relevant data, which will, in turn, decrease the load on the CPU and your network connection.
We want to achieve that data filtering by improving the functionality of the octree implementation in The Schmetterling Engine. As of right now, we can use an octree to quickly generate a list of entities that are visible on the scene. While that can be used to extract components from those entities and check for changes, it is not an efficient method and requires an additional function. As we know, the fewer steps, the better. After our planned upgrade, our octree implementation will be able to find all entities in any given area and read their components. That will simplify generating a list of changed entities (or delta) and boost the game's performance.
ENOUGH OF THE TECH MUMBO JUMBO. GIVE ME THE GAMEPLAY DETAILS!
As interesting as all the technical details are, we know that behind-the-scenes stuff is only for some. Some of you are simply looking to have your questions answered. With the help of our fantastic Community Moderator, SenorRagequit, we prepared this short FAQ. It is, of course, not exhaustive, so feel free to ask us even more questions.
Gamemode / MP styles
Will we be able to play campaign and survival in coop? Or just one of them?
We aim to make both the Survival Mode and the Campaign Mode playable in co-op. Survival Mode will surely happen, including the Sandbox and Custom difficulty settings. As for the Campaign - we will do our best to make it happen, but it is still to be confirmed. We need to iron out a few issues and finalize the design, which will only happen after several internal playthroughs. After playing the game ourselves, we can make much more informed decisions and solve problems we otherwise wouldn’t have known about. It will require significantly more work than survival, so it is possible that coop for survival and campaign modes will come as two separate updates.
Will there be game modes created especially for multiplayer? Which ones? (PvP, PvPvE, King of the Hill, Prophunt, Tower defense map, etc.)
Not at launch. Developing the co-op module for the game is an enormous task. We are focused on delivering a stable, fully playable baseline co-op first. After we deal with that, we plan to incrementally develop additional co-op-specific content.
Can one player play as the alien faction while the other is the default Riggs?
No. That would require us to write another game within The Riftbreaker! It’s not impossible, but it’s a different game, c’mon! At present, we can control only the player’s mech. If we were to give you the ability to control aliens, we would have to develop a fully-fledged RTS control scheme with free camera movement, multiple unit selection, grouping, and all the other features you’d expect from a modern RTS. Let’s leave all that for Riftbreaker 2, for now!
Will there be a split-screen coop? Couch coop? Other local multiplayer?
Online co-op will be the only option available. Apart from the fact that going split-screen would double the performance cost of running the game, it would simply not work very well in split-screen - you would lose too much screen area to fight or build effectively. We can put that effort to better use.
Will there be an option for LAN multiplayer only?
If nothing drastic changes along the way, then playing co-op over LAN should be possible.
Will a multiplayer match browser exist so everyone worldwide can join my game and fight together?
That is yet to be determined. We will have a lobby/browser screen to make joining games easy and convenient. However, we don’t know if it will be limited to your friends list or all games being played at any moment.
General
How will the world's persistency work? E.g, if both players leave the world, will it still be active, and can you re-join and continue where you left off as if you respawned?
In our architecture, one of the players’ PCs takes on the role of the server. All the gameplay state data, including world snapshots, will be stored on that PC, just like a regular save. Other players can join and leave at any time. It is still possible that we’ll enable the option to host dedicated servers that would host an instance of the game independently from all client machines.
Will there be cheat protection in case someone joins in and unlocks all achievements for me?
We’re going to make sure not to break achievements for any players. As for anti-cheating - if we go with the invite-only version of matchmaking, we don’t think it will be necessary. Software like this can cause more hassle for players who want to play the game without any cheats.
Developing or integrating anti-cheat mechanisms also requires a lot of development effort. Since we’re focusing on coop at the moment, we don’t want to unnecessarily extend the time it takes to allow you to play with your friends. If we develop a PVP mode in the future and cheating becomes a real problem, we’ll do our best to prevent that as best as we can.
When playing with two or more people, will the number of enemies also grow proportionally?
Difficulty scaling is a challenging subject. Doubling the number of enemies could potentially have huge ramifications and lead to unforeseen gameplay problems. Game performance and required network bandwidth would also suffer. We will likely develop custom logic rules tailored to co-op play with more challenging enemy wave construction, shorter wave intermissions etc.
Will there be cool new skins for multiplayer?
We plan to add more skins with each significant content update for the game. You can unlock them through in-game progression and our code redemption feature.
Since we will change skins a lot, is it planned to improve the skin menu? Clicking through 20+ skins is annoying
Yes. We know there are better UI choices than cycling through a few dozen skins. We will implement an additional menu layer that will allow you to scroll through a list of all the skins available to you and choose the one you want.
Will the end game stats dashboard be fitted to multiplayer so we can see how our partners did?
As long as we don’t encounter unforeseen technical difficulties, this should be doable and seems like an excellent addition to the stats screen.
Will there be weapons or items made specifically for multiplayer? Like an item that can teleport one player to another player?
We wouldn’t want multiplayer-only items; we want our content to be usable in as many scenarios as possible. That being said, utilities like teleporting to your co-op partners should make it in, but not in the form of a separate item, but as a UI functionality, available either through a click of a hotkey or a button on the map screen.
Communication
Will there be a chat?
Yes. We will implement a basic, text-based chat for you to use in-game.
Will there be voice chat?
No. It is a complex feature that would require huge amounts of work to develop. There’s a lot of third-party apps that serve that purpose very well We will leave the voice chat options to third-party apps.
This is an interesting idea that we will consider implementing. It should be especially useful in no-voice-chat situations and on consoles, where typing messages is usually quite problematic. Good idea, thanks!
Player
How many players will coop support?
At least two ;) In all honesty, we don’t know just yet. Technically we can connect as many clients as we want, but the question is - can the server handle that? Another question is - how many actually make sense? We will need to run extensive tests in all the different scenarios to determine the maximum number of players. That being said, we can tell you that we ran some 4-player games already, and they ran pretty well, so we hope to get to that number!
One more thing to note here as well is, that we don’t plan to “hard lock” that number (on PC). We all know that times change and even if something is not possible today then maybe future PCs and network infrastructure will be able to handle a thousand players. Some of you might also be ok with playing the game at 15FPS while others don’t want to touch anything that isn’t running at 200FPS. We’ll try to leave this as technically open as we can.
Will there be a different number of supported coop players on PC vs. on console?
Just like in the case of the previous question, we don’t know just yet. We prioritize getting The Riftbreaker running in co-op on PC, smooth and stable. Console version testing will likely run parallel to PC testing and optimizations, and that is when we will get the final picture. Please mind that achieving online multiplayer on consoles is significantly more difficult than on PC, so it may very well arrive later on these platforms.
Will players be able to exchange weapons, modules, etc., between them?
Most likely, yes, in the case of weapons, since one player can die and drop one of their guns, and someone else can later pick that up for them. It wouldn’t be polite not to give your partner’s weapon back now, would it? We don’t know if this will be true for other items. All players within a game have access to the same blueprints and should be able to match each other gear-wise without issues. We’re also eager to experimentation and community feedback in this case. Let’s see what works best for the game together.
Will the players have shared resources, or does everyone have their own?
Both players share resource pools except for ammunition and consumables. We quickly realized that finding out you’re out of ammo despite not shooting your guns a single time didn’t feel good. Everything else apart from ammo and consumables is fair game, though - you can spend your partner’s hard-earned cash on what you like!
Can we get a UI addition of the other players' HP + Shield (maybe equipped weapons as icons) somewhere? So we can see the status of the other players' health etc.
This is something that we can consider when we come closer to release. It is a nice feature - especially if it can be toggled on and off in the options menu.
Does every player have to be on the same map constantly? Or could the host be on the HQ map and the other players on some outposts?
The limitations of the game in its current form force us to have all players on the same map at all times. Otherwise, the server would have to simulate multiple worlds simultaneously, which could be very difficult.
Can the other players characters block my building/shooting if they stand in the way? There is no friendly fire in The Riftbreaker. If someone stands in front of you when you’re shooting, they will block your shots but take no damage. Coordinating movement in combat is going to be very important! The same goes for buildings - you won’t be able to place a building if another person is blocking the grid.
Will we get some rank names or icons above our player mech, i.e., to show how many multiplayer matches we have played already?
We do not currently perceive the co-op mode for The Riftbreaker as a competitive experience. We do not plan on introducing any sort of level or rank progression. That being said, this might change as we develop the game further. Time will tell!
Crossplay
Crossplay between PC and console platforms will not be possible. Crossplay between different PC store fronts i.e. Steam/Epic/GOG should be possible, but this is still to be confirmed.
Hosting
Do you need to have bought a copy of the Riftbreaker to host it?
To play The Riftbreaker in co-op mode, all players must have purchased their game copy.
Will we get a tool to host the game "headless"?
The game can run in headless mode - this means that a Riftbreaker server can run on a PC without any visual representation. Whether we can release such an option to the public is yet to be determined, but it would be great for users with less powerful systems. We would really like to have this option available, but we can not confirm it 100%, yet.
Can we rent a beefy virtual server on some website to host The Riftbreaker world?
This largely depends on the previous question. If we can run a separate game server, decoupled from an instance of the game app itself, hosting the game on an external server shouldn’t be an issue—however, no promises for now.
Will we get options/settings for the multiplayer tool? Like an admin interface where we can toggle cheats for players, give resources, enter commands, set options for what happens if the game is over, etc.
You will get access to our standard Sandbox Menu, which already provides most of these options for you. We are likely going to expand it with a couple of co-op-centric parameters.
Can we kick/ban people, so they don't disturb others? The host will receive simple moderation tools, such as ban/kick. You can’t do without them!
Modding / Mods
Are game mods going to be supported in multiplayer? Will custom maps be supported in multiplayer? How will it work?
We would love to allow you to run mods and custom maps in multiplayer. It will likely be possible if we ensure compatibility between the server and the clients. There are two ways we could go about this. We can display a list of mods running on the server and require all clients to download and activate the same mods before connecting to the server. Alternatively, we could transfer mods directly from the server to the client while establishing the connection. We will see which option we have, but we’re optimistic about this.
Will we get access to some backend functions for modding? E.g., Check the current player steamUserId so we can make stuff happen only if a specific user is playing, get their RB play time, get their steamUserIcon, etc.
Giving you access to some additional, co-op-centric lua services is a possibility. However, we don’t know how much we can expose. We must consider that you will interact with other players and their accounts. We don’t want to slip up and leave a door open for some malicious activity. Simple things like player icons and usernames should be readily available, though.
CONCLUSION
We are making excellent progress on the multiplayer version of The Riftbreaker. We are very sorry for the lengthy radio silence and promise to share more updates as time passes. We can not state an exact date when coop will be available, but we have hit a significant milestone that should increase the pace of development by a large margin. You can expect more updates and live previews on our streams at www.twitch.tv/exorstudios. Also, remember that we will hold closed beta tests - the best way to stay informed about them is to follow our news updates and become a member of our Discord server at www.discord.gg/exorstudios. Please feel free to ask any questions about The Riftbreaker Co-Op mode that come to your mind. We will do our best to keep you well-informed from now on.
This week we have a different kind of news for you. As you know, a high degree of moddability was one of the key aspects of The Riftbreaker throughout its development. Right from the get-go, we wanted you to be able to make changes to existing content and introduce new features with as few problems as possible. After the introduction of the in-game mod browser, along with Steam Workshop and Mod.io integration, tons of cool mods started to come out, and they get better every day.
It’s high time to give something back to our lovely modding community. In collaboration with Mod.io, we have the immense pleasure of announcing the first Riftbreaker Modding Competition! Starting today, you have three months to prepare your best mods and maps for the game for a chance to win valuable prizes in two categories.
This category is for all game modifications that are NOT custom maps, missions, or tilesets. All mods that introduce new game mechanics, buildings, weapons, or other things that significantly alter the way the game is played. Anything that is not a map/tile/mission or a reskin is allowed.
A good example of a mod that fits this category is Destructible Rocks. The mod does not use any custom-made content (we highly encourage adding new, custom-made content, though!) but gives the players new gameplay opportunities by modifying the game's files. Sometimes simple stuff works best!
Competitors can enter with their custom maps, missions, and tilesets for The Riftbreaker. We encourage you to try using The Riftbreaker Editor Suite to build new adventures for Ashley and Mr. Riggs. Do you have a creative idea for an awesome spot that would fit in one of the Galatean biomes? Or perhaps you want to recreate in your hometown in the game? Or maybe you want to take our heroes to a new biome? This category is for your creations.
The 'Starfish' map is just one of the examples of the things you can submit in this contest. Thanks to clever use of our assets and the extra building stipulations Survival plays out in a much more different way than usual. Try it out! Also, remember that custom assets are highly encouraged!
1st place
Custom-built gaming PC with The Riftbreaker design printed on the case. The PC variant will be picked at random.
2nd place
One Sapphire Pulse AMD Radeon 6800 XT 16GB GPU.
1st - 8th place
Mr. Riggs plushie and a set of EXOR Studios gadgets.
Contest Timeline:
Competition Start Date: March 10th, 2023
Submissions Close: June 10th, 2023, 00:00 AM GMT
Winner nominations announcement, community voting start: June 15th, 2023
Community voting end: June 22nd, 2023
Competition End Date and Winner Announcement: June 29th, 2023
The Riftbreaker Modding Competition - Rules:
The competition is split into two categories. The first category is ‘Custom Maps.’ Competitors can enter with their custom maps, missions, and tilesets for The Riftbreaker. The second category is for ‘Game Modifications’ - all other mods fall under this category.
Reskins and rebalances are not allowed to participate. Each mod must introduce new functionalities or make creative use of assets already available in the game.
Mods created before the contest starting period are allowed to participate.
Mods must be self-contained and downloadable through the in-game mod browser through Mod.io and, optionally, through the Steam Workshop.
Participants must enter their mods to the competition using this form before the deadline, which is June 10th.
After the deadline, EXOR Studios will create a shortlist of the best mods in both competition categories.
If one of the mods that get on the shortlist in either category cannot, for any reason, be uploaded to Mod.io, EXOR Studios is granted permission to upload the mod in an unchanged form to mod.io. Additionally, if a shortlisted mod is only available on Mod.io, EXOR Studios is granted permission to upload the mod in an unchanged form to the Steam Workshop. The creator retains all rights to their mod - we simply want users from all platforms to be able to access the best creations. We strongly encourage all modders to upload their creations to both Mod.io and Steam Workshop to maximize their audience.
A public vote will be held using an easily accessible platform (TBD) where the community can decide which of the shortlisted mods should receive prizes.
Over the course of the voting period, EXOR will prepare articles and stream the shortlisted mods, highlighting their best features.
After the public vote, the winners are awarded computer hardware.
Participants are responsible for ensuring that their mods remain in compatibility with the live version of the game, at least for the competition duration time.
Teams can enter the competition. However, the prizes remain the same for both individuals and teams.
Only one entry per person is accepted. If an individual is part of a team, they may not send in an additional solo project.
The contest is open worldwide.
EXOR Studios employees and affiliates are not allowed to participate in the contest.
We hope that this competition will unleash the talent of our modding community and facilitate the creation of tons of more amazing content. We can’t wait to see what kind of craziness you come up with this time. If you have any questions or need help - please do not hesitate to ask us for assistance at www.discord.gg/exorstudios or anywhere else - the Steam Discussions, comments, and all other places where you can find us are fair game. We're here to help!
In our previous articles, you have already learned about the two first creature species you will face in the Crystal Caverns biome. Crawlogs and Gulgors are native to the Galatean cavern systems. The natural process of evolution helped them adapt their bodies to the conditions of the biome. However, you can clearly see that they also became affected by the strange crystalline formations that seem to spread all over the caves. In fact, the crystals’ influence seems to be spreading to the surface of Galatea.
As you will learn today, Gulgors and Crawlogs were not the only creatures that came into contact with anomalous crystals. It turns out that creature species usually found on the surface of Galatea 37 are also susceptible to ‘crystal corruption.’ The afflicted creatures do not live in the caves, but it doesn’t stop them from venturing into the tunnels whenever the natural order is disturbed. Let’s take a look at some of the Galatean creatures, which seem to be the most affected by the new, mysterious threat!
Look what they've done to our rabid space dogs...
The Canoptrix are some of the most common species of Galatean creatures. It is no surprise that some of them eventually came into contact with the crystalline growth, resulting in their mutation, although it might not be the right word here. The affected Canoptrix have crystals bursting out from their insides, tearing out pieces of flesh. In fact, their bodies seem to be rotting altogether, exposing bones and the extent to which the crystals have taken over their insides. It is unclear whether the Canoptrix are even alive at this point. The crystallized specimens are more deadly than their regular counterparts, so be careful studying them.
They might look undead, but their interest in your activities on Galatea is more alive than ever!
Despite changing their protective shell, Arachnoids are still pretty agile.
If Canoptrix got affected by this phenomenon, it is no surprise that Arachnoids have as well. This can lead us to the conclusion that the ‘ground zero’ for the crystal disease lies somewhere in the Galatean jungle. Arachnoids seem to have been changed to an even greater extent than the Canoptrix. Due to the crystal’s influence, they seem to have shed their chitinous armor and grown a new protective shell made entirely from these crystals. The brand-new armor is much more robust than the old shell, making these Arachnoids more resilient. Additionally, this strain no longer shoots acid from the glands on their tails. Those projectiles have been replaced with razor-sharp crystal shards. Revise your tactics accordingly!
Crystallized strains of Arachnoids are much tougher than the ones you regularly meet in the Tropical Zone.
Blue suits the Stregaros. Really brings out the yellow eyes.
One would expect that Hammerroceroses would also fall victim to these mutations, but that is not the case - perhaps it’s due to their sheer size. It would be difficult for a 5-meter-tall beast to wander around cavern tunnels. Nature filled that void with Stregaroses. Given that this species is not native to the Tropical zone, it is unclear if the crystalline growth spread as far as the Radioactive Desert region, or if this is a new species altogether. Similarly to the Arachnoids, Stregaroses' chitinous carapace has been replaced with crystals. These creatures prove to be the most dangerous in narrow, cavernous passageways. When in a group, Stregaroses can put up a shield that will be difficult to break through. That will allow creatures in the backline to effectively siege your outposts in the Crystal Caverns biome.
You can actually stumple upon Stregaroses in the Caverns, but we don't recommend it.
As you can see, the Crystal Caverns biome is going to offer a unique challenge not only thanks to its layout but also due to the variety of creatures you are going to face. Still, these are not the most dangerous species that will stand in your way. Be on the lookout for more news in the coming weeks, and join our streams every Tuesday and Thursday for exclusive previews! Follow www.twitch.tv/exorstudios and join www.discord.gg/exorstudios to get the latest info all the time.
About ten months ago, we introduced you to a game made by friends of ours - Lumencraft. Lumencraft is a top-down action game with tower defense elements taking place deep below the Earth’s surface. After a series of cataclysmic events, the surface of our homeworld became almost uninhabitable. To survive, people hid below ground, which led them to the discovery of Lumen - a mineral that might save the world from total annihilation. You are one of humanity’s scouts, and your job is to secure as much Lumen as possible.
[nowy trailer lumencrafta]
When we first talked about Lumencraft, it was just launching in Early Access. At that point, the game offered a set of scenarios with a high degree of freedom and replay value, thanks to the fully dynamic, destructible world. Since then, our friends at 2Dynamic have been very busy collecting feedback and implementing new features for the launch of the final version version. Now, the time has come for you to see everything Lumencraft has to offer - the game is out of Early Access today!
The top-down style of Lumencraft reminds us of some of the good old games we played in our childhood!
To celebrate the launch of Lumencraft's full version, we are teaming up with them once more to offer you a time-limited bundle deal. You can pick up The Riftbreaker, Lumencraft, and another awesome roguelike survival - Dome Keeper - in one package at a 20% discount. If you own any of the three games, you can also complete your collection and still benefit from the deal, so go and check it out!
One of the biggest new features you will find when launching the 1.0 version of Lumencraft is the Campaign Mode, consisting of 27 brand-new missions. Each one of those is a new set of challenges, ever-increasing in difficulty, leading to an epic finale that will test all your base-building, cave-digging, and bug-killing skills. In between the missions, you get to chill out for a bit in the hub - a safe haven that serves as a ‘portal’ to all the game missions. When visiting the hub, you also get to choose from a number of permanent upgrades that will boost your chances of survival in future missions.
You're free to explore the world and drill anywhere you like, but pack your flamethrower just in case.
Another new element in the full release of Lumencraft is procedural map generation, adding a ton of replayability to the game and giving it a slight roguelike twist. Every time you embark on a mission, you can choose to play on a handcrafted, predetermined map designed by the developers, or you can generate an entirely new map. The latter option will guarantee that no two playthroughs of Lumencraft are ever going to be the same. The digging mechanics play nicely with procedurally generated maps, as you can freely explore the world, never knowing what lies around the next corner.
i[]Defending your base against attacks from hordes of angry monsters will become your second nature.[/i]
Apart from these major upgrades to the version you know from Early Access, Lumencraft has also received numerous content updates. The game now features more defensive tower types to help you protect your bases and brand-new weapons to slay your enemies. You also get to apply numerous upgrades to your gear and structures, giving you a chance to get through all 27 campaign missions in one piece and to earn as many as 88 achievements. Some of them are quite tricky, so if you’re looking for a challenge that will definitely keep you occupied for quite some time.
Some threats you face are going to be bigger than others. Luckily, your weapons get stronger as the game progresses.
It’s definitely the right time to come back to Lumencraft if you’ve played it before or to check it out for the first time. There is a demo available as well, so go ahead and give it a shot. You won’t be disappointed!