• Reduced the volume of certain possessed object sound effects.
  
• Fixed an issue where the chat would not close when pressing ENTER.
  
• Fixed a rare issue where the survivor’s bag was not being created.

Greetings Romans!

It is with great excitement that we're announcing our attendance to Gamescom 2025!

While we will mostly be in the business area, we will be walking around the event so don't hesitate to come say hi if you see us with our Beartwigs or Romestead shirts on!

For most of us it'll be the first time at Gamescom, and we're greatly looking forward to everything it has to offer during our trip!

See you there!

-The Beartwigs Team

We hope you’re having a lot of fun with the Open Beta of The Riftbreaker 2.0 Update this summer. The full release is just around the corner, so let your friends know that a new co-op game is on the block, perfect for having fun together. If you’ve been with us for a long time, you know that reworking our single-player game into a four-player cooperative mayhem simulator has been a massive challenge. It required us not only to rework most of the codebase but also to devise solutions to problems that we had never encountered before. Our elegant, optimized features suddenly stopped working or caused massive data transfer spikes. The creature movement system was one of the affected areas. We described the details of how it works very early in the development process. You can read all about it here - part 1 and here- part 2. It worked great for single-player gameplay, however, it was problematic during network play. In today’s article, we’re going to tell you all about our new invention - the NavMeshNetworkTransformSystem.


At the beginning of our journey, a simple situation like this - a group of Canoptrix running - would consume more than 130 kilobytes of transfer.

When we began working on the multiplayer mode for The Riftbreaker, we decided that the game would operate using a client-server architecture. In this model, one PC serves as the host of the game, and all the crucial game elements are simulated on that computer. The server broadcasts the information about the gameplay state to all the connected client PCs in the form of update packages. These packages must be as small as possible to avoid transfer issues. Best optimized online games often transfer as little as 8 kilobytes of data per second. We set our goal at 25 kBps. It’s not as low as 8, but still reasonable for most internet connections out there. To achieve this, we simulate as many non-critical gameplay effects locally on client PCs as possible. However, even with this setup, creature movement would consistently add more than 200 kilobytes of data per update on top of everything else, which is unacceptable. It was clear that we needed a smart solution.


[iThis article will tell you how we managed to reduce those 130 kilobytes by more than 10 times.[/i]

Enter the NavMeshNetworkTransferSystem. This magic system ensures enemy units move smoothly and appear in the correct location on every client. It was designed to help all the creatures you encounter in-game navigate the complex terrain of Galatea 37. The server is always “in charge” of where enemies are and which way they face, and the NavMeshNetworkTransformSystem ensures that this information is sent to players efficiently and reliably. This component is responsible for updating positions and orientations, determining when and how updates are sent, and how clients anticipate and correct enemy movements. We’ll also take a peek at developer-only clever tricks, such as height prediction, and even how movement and turning speed are fed into the animation system. It’s a deep dive today, we hope you’ll enjoy it!


If you launch the game as a server in multiplayer mode, all creatures become equipped with an additional NavMeshNetworkTransformServerComponent. In The Riftbreaker, game logic is updated every 33 milliseconds regardless of how many image frames are rendered per second. We usually refer to this as an ‘update’ or a ‘tick’. Each tick, the NavMeshNetworkTransformServerComponent reads a unit’s (e.g., a canoptrix) current position and orientation (typically, yaw and angle are sufficient, as most of our units stand upright). We represent this data in the form of 32-bit floats - often more than one per unit. Let’s say that we need three 32-bit floats to have complete information about one unit - that’s 96 bits that we would need to transfer. Multiply that by a wave of 1000 enemies. Suddenly, you get 96 kilobits, or 12 kilobytes (8 kilobits = 1 kilobyte), in a world where we fight for each kilobyte of transfer, this is far too much


We decided to sacrifice a bit of precision to save on data transfer. This led to many glitches, as game did not have enough information to precisely predict the unit's behavior. Here, you can see Hedroners 'walking' in place, or changing their animation state abruptly.

We decided to approach this by compressing the 32-bit floats into smaller, 16- or 8-bit integers, cutting the required transfer in half or by a factor of four, respectively. For position, only the X and Z coordinates are used. (Y is the vertical axis in our engine) These floating-point values are scaled using a factor of 10, clamped to a fixed range, and then converted into 16-bit unsigned integers. The result is packed into a single 16-bit integer, which also encodes the axis type in the highest bit. This provides approximately 0.1-unit precision over a range of ±1638 units.


We tweaked all units in the game individually to avoid glitches and unexpected behavior. Here you can see all animations working as expected, grass reacting to unit movement, and water ripples appearing in correct places.

Internally, the 16-bit value is structured so that the lower 15 bits represent the quantized position value, while the most significant bit (bit 15) is used to indicate the coordinate type (e.g., X or Z). The position value is stored as a signed integer in the range [−16,384, +16,383], which fits exactly within 15 bits. By masking the position with 0x7FFF and shifting the type flag into bit 15, both pieces of information can be compactly combined into a single value. This layout ensures that all 16 bits are efficiently used—15 for spatial data and 1 for metadata—without sacrificing numeric range or introducing ambiguity during unpacking.

We use the same treatment for rotation data. In this case, an 8-bit integer gives us rotation precision of 256 steps, or approximately 1.4 degrees. Speed is handled using the same packing approach, but with a small optimization to increase range. Before packing, the velocity magnitude is divided by 2, allowing values up to 51.0 units/second to fit into a single byte. On the client side, the unpacked speed is simply multiplied by 2.0 to restore the original scale. This technique effectively doubles the representable range while still using 8 bits, at the cost of slightly reduced precision. Without this division, an 8-bit integer could only represent values up to 25.5 with a precision of 0.1. Since the value is stored as a single byte, the number of fractional steps is fixed—only 256 possible values are available. By halving the speed before packing, we shift the balance slightly in favor of range rather than precision, which is often more valuable in fast-paced movement systems. Our code even has switches (flags or configs) to use 8-bit or 16-bit modes for testing and tuning. By packing a unit’s position coordinates and orientation into just a few bytes, we significantly reduce the amount of data sent with each update.



In this example, you can see that the floating neutral unit is moving very 'jittery'. This is a result of the game waiting for information about the unit's movement coming from the server.

Okay, we reduced kilobytes into bytes in the previous step, but multiplied by the number of creatures during our attack waves, it still adds up to massive numbers. We don’t want to spam transform updates every single frame. Instead, the NavMeshNetworkTransformSystem uses a timed replication system. Throughout many playtest sessions, we determined that we can get away with sending a creature movement update every 200 milliseconds - or five times per second of gameplay. Once the timer exceeds a configured replication interval of 200 milliseconds, the NavMeshNetworkTransformServerComponent packs the current transforms and sends them to clients, then resets the timer. This ensures regular, periodic updates, keeping clients up to date. The key is to choose an interval that is short enough for smooth motion but long enough to limit bandwidth. In practice, the interval is tuned to strike a balance between smoothness and efficiency.


We interpolate what happens between the movement updates and apply slight adjustments to ensure smooth movement.


Determining a unit’s position is only half the story. More often than not, the creatures you see on the screen will be moving - either wandering around, looking for food, or charging at you at full speed. We also need to take that into account. The NavMeshNetworkTransformSystem closely monitors a unit’s velocity and movement state. If it detects something weird, like an unexpected dash to another point on the map, the creature’s speed is clamped to the unit's maximum as determined by the creature’s properties in its .ent file. This prevents crazy outliers from being sent or extrapolated. It also allows us to smooth out any issues that may arise in case a unit experiences a temporary speed spike.
Next is movement state detection. The code constantly monitors whether the creature is “standing still” or “on the move”. This is typically done by checking speed against a small threshold. The value of this test determines whether the unit is idling, walking, or running. Values that do not exceed the threshold are treated as idle, because we don’t want to send clients essentially useless data in the form of minor jitters.



In the early days, even dead enemy units would jitter uncontrollably, trying to correct their position in the world.

As we mentioned before, every 200 milliseconds, the game checks for changes in creature positions. The difference between the previous and current state of a unit is called ‘delta’ (any change between the prior and current state is called a delta, to be precise. However, for the sake of this article, whenever we talk about a delta, it’s going to be the difference in the position of a unit). This 200 millisecond interval doesn’t mean that creatures only move that often on client PCs. To predict where an enemy should move next, the client relies on the direction and speed information provided by the server. We normalize this direction to a simple "forward" movement and extrapolate ahead based on an enemy’s reported speed. The faster the enemy or the longer the network update interval, the more aggressively the prediction extrapolates forward. Conversely, if the enemy is slowing down or standing still, we ease up on extrapolation to avoid overshooting their position.


Fortunately, more often than not, tweaking a couple of parameters allowed us to fix those glitches.

When a client gets an update from the server, it first checks how far off its current prediction is from the server’s latest position. If the client’s predicted enemy position is lagging behind (or running ahead) of the server’s position, the system makes gentle corrections to catch up or slow down accordingly. Instead of abruptly snapping the enemy into position—which would look jittery—it gradually adjusts the enemy's location over several frames. These calculations may become increasingly inaccurate if network conditions are less than perfect. To counteract this, the system dynamically adjusts prediction accuracy based on the difference between the predicted and actual positions. If the discrepancy becomes too large, a gradual "correction force" pulls the enemy smoothly back toward the server’s authoritative position, ensuring enemies don’t appear to teleport or jitter awkwardly. We've also built in an experimental feature: adjusting enemy speed prediction based on how consistently the enemy stays within certain expected boundaries. If an enemy seems to be drifting too far off-track - say, due to sudden lag spikes - the system intelligently adjusts the enemy’s speed slightly. This subtle tweaking keeps enemies on believable paths without noticeable snapping or stuttering.



Our beloved Gnerot had several problems: not only did it move as if it was skating on ice, but it also didn't spawn any of its effects correctly.


When we managed to get the particle effects to spawn, the movement got even worse!

Just like in the case of positioning, an enemy’s facing direction needs careful handling to avoid jarring rotations or awkward instant turns in multiplayer gameplay. Abrupt orientation changes break immersion, so we’ve implemented an orientation-smoothing algorithm to ensure that our creatures turn around naturally and gracefully, even under challenging network conditions. When an enemy changes direction, the client doesn't instantly snap the unit to face the new direction. Instead, it calculates the shortest angle between the enemy's current facing direction and the desired facing direction. This shortest angle ensures enemies turn the minimal necessary distance, whether clockwise or counter-clockwise, avoiding exaggerated spins. We also smartly select which orientation to follow. When an enemy is moving forward at a good pace, we assume it is facing in the direction of travel. If they’re stationary or moving slowly, we rely more on the explicit angle updates provided by the server, ensuring the enemy remains facing the right way without unnecessary jitter or micro-rotations.


A much better version. Most of the effects spawn correctly, and the creature moves and turns just like you would expect. We managed to get all those effects right in the end, by the way.



When Wigmites didn't have the information about terrain height, they would simply fly through obstacles.

Apart from the horizontal, we also need to consider the vertical positioning of units. Some of them, like Wingmites in the Metallic Valley biome, can fly over terrain obstacles. Others, like baxmoth drones, always fly and never even touch ground. However, syncing the vertical positioning of units in The Riftbreaker would increase the amount of data we transfer from the server to its clients. Instead, the clients maintain their local understanding of the world’s terrain height. By keeping a local copy of the map's topological data (terrain heights and obstacles), each client independently calculates how high above ground or water an enemy unit should be displayed. This clever optimization saves a third of precious bandwidth.


Using the terrain height information from the client allowed us to correctly predict Wingmites' height above ground at all times at no additional transfer cost.



The simplest case of animation desynchronization - the Arachnoid's attack animation and effects go out of sync completely. The unit's behavior is completely unpredictable at this point.

Predicting creature animations was one of the key parts of this system.. We didn’t want to rely too heavily on information from the server, as this would likely result in inconsistent movement and various errors. To achieve this, we revamped enemy animation graphs to respond directly to movement flags generated by our movement database component. Whenever the client detects changes in movement, like speed or angle, animations update instantly and independently, ensuring immediate feedback for players.


We had to make sure that animations stay in sync at all times. That includes interrupting them at random intervals, too.

The client continuously computes:

• Movement Speed: Calculated directly from client-side position predictions, ensuring enemies smoothly accelerate and decelerate visually, perfectly matching their actual speed.
  
• Angular Speed (Turning): By analyzing the rotation difference between the previous and current orientation, the client determines how fast a unit is turning. This keeps turn animations realistic, reflecting subtle directional changes smoothly.

By locally computing and applying these animation parameters, we avoid potential synchronization issues or noticeable mismatches between server and client states. Animations always match a creature's predicted movement, ensuring consistent visual presentation without relying on frequent network updates.


Every game tick, the NavMeshNetworkTransformSystem on the server gathers each creature’s latest world position and rotation, compresses them, and decides if it’s time to broadcast. When an update is sent, clients receive the packet, unpack the data, and compare it to their current prediction. If necessary, they correct the position with either a smooth lerp (linear interpolation) or a snap. Meanwhile, the client continuously updates creature positions each frame based on the last known velocity and heading, ensuring a seamless experience. Various flags enable us to tune responsiveness, and the animation system reads out movement rates, ensuring that creatures appear alive and consistent with their movement.


130 kilobytes of data, just to simulate the average Black Friday sale queue situation.

In summary, the NavMeshNetworkTransformSystem is our bespoke solution for enemy synchronization in Riftbreaker’s multiplayer. It carefully packs data to save bandwidth, updates on a smart schedule, predicts and corrects movement on clients, handles special cases (like flying or death), and even keeps animations in sync. The result for players is smooth multiplayer action: enemies show up where they should, move believably, and don’t spontaneously teleport (except Lesigians. And Magmoths. And Hedroners. Okay, maybe we have quite a few teleporting units.)


10 kilobytes sounds much more reasonable - doesn't it? (20 kb you see on the screen is the entire transfer, not just the navigation system!)

As a result of all the magic described in this article, we managed to reduce the amount of data transferred by the navigation systems from about 200 kilobytes to a range between 7 and 20 kilobytes, depending on the situation. Obviously, this is just one of the systems that we had to optimize heavily for network play, but now you have an idea of what kind of problems we had to face on our way here. You can already check out the results of our efforts by playing The Riftbreaker Survival Mode in our free Multiplayer Playtest app. You can also try the Campaign Mode already by checking out the coop_beta branch of the main game. If you’d rather wait for the full, official release, you won’t have to wait long. Keep your eyes peeled for more news!

EXOR Studios

------------ PLAYTEST ALPHA VERSION 0.1.6 --------------

Hello all! After a lot of time I have been able to prepare a playable version of Make your Move, it will be update with new version as the development continues. The idea is to get feedback about the gameplay. So hope you enjoy it 🙂!

------------ WHAT IS INCLUDED --------------

• Scenes: Main menu, Lobby and Game.

• Language: English.

• Tutorial panels.

• Save/Load system.

• Map generation. (Only 1 loop playable every Run).

• Void Deck. Where player can store new Tiles.

• Player levels and enemy levels (Twilight).

• Unlock equipment stats system.

• Buy/Sell system.

• Seed RNG system. (Only to read in case of find bugs to report).

• Original game themes. (Menu, Lobby/Run and Combat).

• Duration estimated: Around 15 - 20 min to finish a Run.

------------ GAMEPLAY CONTENT --------------

• 15 different player stats.

• 5 types of shards. Game money used to buy items.

• 45 equipment items.

• 16 types of potions.

• 2 classes. Each one with 5 unique abilities.

• 30 different Tiles. 10 basic Tiles that can be combine by 2 or 4 in this version. Each one with a different effect.

• 3 types of Chunk sizes. 2x2x2, 3x3x3 and 4x4x4.

• 15 variant of enemies.

• 10 Twilight effects that increase enemy stats.

• 4 Debuff effects in combat.

Again thanks you all to give an opportunite!

- Added quest log scrolling with arrow keys

Bugfixes
- Fixed a missing chest in the last map for Ch3 (Alchemist Mansion)
- Fixed a bug where the player can get stuck in a wall when trying to enter the community of hate
- Fixed text bugs

Patch1019

Hello Astra Odysseans!

We're writing to you today with an important update on our development and timeline.

This project is a labor of love, and your incredible support has allowed us to raise our ambitions for what this game can truly be. We believe true craftsmanship can't be rushed. To give our ideas the time they need to mature and to integrate all the features we're excited about, we are giving the project more breathing room.

Consequently, the Beta is now planned for the end of 2025, with a full release targeted for 2026.

To show you this extra time is being put to good use, we want to share a major milestone: we have officially finalized all the core city-building gameplay mechanics for both planetside cities and space structures!

It also means we have now launched into the full-scale asset production phase. Our artists are hard at work creating the final 3D models for every building, unit, space station, megastructure, and more.

For cities, our goal was to create architectural styles versatile enough for any civilization type you choose to play. To bring this to life, we've defined several distinct styles. Here’s a first look:

• Utility: A functional style defined by industrial concrete and metal. Built for efficiency and resilience.

• BioShape: An organic style inspired by natural shapes, featuring flowing structures and a warm, beige color scheme.

This image shows the Alloy Factory (left), the Solar Panel Field (center), and the Scientific Laboratory (right) in both styles. Other architectural styles are planned for the game's launch.

Technical Update: We are continuing to advance the game's AI/bot systems and are also finalizing the lore and quests that will make your journey unique. This july and august, we are also focusing on a significant improvements to lighting, shadows, and the game's overall atmosphere, as well as enriching the fauna and flora you will discover across all 20 biomes.

What’s Next? Our next major milestone is launching the Beta at the end of this year. If you’re interested in getting more frequent updates and want a chance to be among the first to play, we invite you to join our community on Discord!

On an exciting final note, we'll be participating in the 4X Fest on Steam next week!

Thank you for your incredible patience and continued support. We're building something we're extremely proud of, and we can't wait to share it with you.

Toward Astra and beyond!
Alex & Valentin

• NEW: Planets Visible toggle in Graphic Options!

• Game's art style reverted to the original.

• Fixed Prisoners bubble positions.

• Fixed Anunnachy autobuy for Citizens Upgrade.

• Minor fixes.

Hey everyone,

Your voice has come through loud and clear. As many of you know from the Early Access phase, this game has always been built around your feedback, and I underestimated how essential the visual identity was to the overall experience.

With this recent art rework, I clearly missed the mark.

First, I want to apologize for delaying the BigBang release due to the visual overhaul, and more importantly, for not involving you during these past months in this visual rework and for delivering an aesthetic that many of you felt didn’t match the game.

After several miscommunications with the current artist, I’ve decided to revert the game's art style back to its original version, which used AI-generated assets (outlined by hand by me, filled by AI). This will serve as a temporary solution until I’m certain I’ve found an artist who can fully reflect the game’s current style and mood, and bring you along for the journey in shaping the next visual rework together.

Also for new new players who discovered the game with version 1.0 or for long-time players who were looking forward to the new art, I’m sorry for the sudden shift in visuals overnight as we return to the game’s original look.

As always, I deeply appreciate your support and feedback. Being a solo developer, I genuinely couldn’t do this without your help.

Lastly, if you purchased a skin from the Skin Tab during the 1.0 launch, and would like a refund, feel free to open a ticket in the Support section on Discord.

Thank you again for sticking around.

—Soehnle

Hello.

This update focuses on diplomacy and some UI changes. Countries now have to declare war on each other. They can band together and fight against others by forming alliances. UI is now updated too.


Notes:

-Added diplomacy.

-Removed the music player (for now, there will be more UI changes soon and it will be likely re-added).

-Changed all scripts to now use diplomacy functions, including our character AIs.

-Unified country and region panels. You can find more info about countries by switching tabs.

-Alliance map mode.

-An alliance gets disbanded if it owns the whole world, forcing the game to end with only one country left.

-Backwards compatibility for AI Scripts. It will auto-declare wars on your targets, but I highly recommend updating your scripts.

Moving forward, I am planning to add leaderboards and god controls to the game.

If you're a script creator, check here: https://observe.fandom.com/wiki/Functions

Also, please join our Discord and help shape Observe's future

We’ve been listening… and we’re ready.

Thanks to your amazing feedback and support, our game has undergone a complete transformation. The name has changed. The theme has evolved. We’re diving deep into a dark medieval fantasy world—one filled with mystery, danger, and legends waiting to be uncovered.

This isn’t just a game for us. It’s a game for the community.
We’re building this together—with passion, with purpose, and with your voice at the heart of it all.

💥 And now, it’s time to show you what we’ve been working on.

Mark your calendars.
Sharpen your blades.
Darkness is coming.