Steam Community

Ripper

All Discussions Screenshots Artwork Broadcasts Videos News Guides Reviews

Ripper

0 in Group Chat

Ripper is a top-down shooter with fully destructible environments, fog of war, and Steam multiplayer. Break through walls, survive enemy waves, and battle your friends.

Visit the Store Page

Most popular community and official content for the past week. (?)

The Projectile System

Feb 28

Note: this article was taken from our blog site[blog.unheard-software.com]. For better format & experience go there.

Welcome back to the Ripper devlogs! Today we are diving into how the projectile system works. Fair warning: this one builds heavily on the previous devlog about the world[blog.unheard-software.com], especially the multi-floor setup and collision layers. If you have not read that one yet, we highly recommend starting there — it will make this a lot easier to follow.

Quick Recap and What We Need

As covered in the last devlog, Ripper is a top-down, multi-floor game. All floors exist in the same physics space but are separated using collision layers — each floor gets its own dedicated layer. This setup works great for the world itself, but it introduces some interesting challenges when you start firing projectiles through it.

Here is what the projectile system needs to handle:

Work across multiple floors using the collision layer system
Handle a large number of projectiles at once (this is a multiplayer shooter after all)
Synchronize efficiently without eating up all the network bandwidth
Support modding — the community should be able to add custom projectile types
Allow for penetration — some projectiles need to punch through walls and keep going

Let's walk through how we tackled these problems.

What Even Is a Projectile?

At its core, a projectile is just an object moving through space. Simple, right? Well, kind of. The tricky part is making it flexible enough to support all the different behaviours we want — bullets, shotgun pellets, sniper rounds, thrown grenades, whatever the modding community dreams up.

Our solution keeps projectiles abstract. Each projectile is stored as a simple piece of data:

Position and floor — where it currently is
Velocity vector — speed and direction combined into one value
Penetration counter — tracks how many surfaces it has punched through (like health for the projectile; when it hits zero, the projectile is removed)

Different projectile types are handled by factories, the same system we use for world objects. Each factory defines the behaviour for its projectile type — speed, trajectory changes, hit detection, everything. This keeps the system modular and easy to extend.

One important detail: on the server, projectiles do not actually exist as physical objects in the world. They are just data. The factory uses that data to perform raycasts and calculate movement, but no physics bodies are spawned. This keeps things lightweight and prevents unnecessary physics overhead.

Managing All the Projectiles

With individual projectiles sorted, we need a way to keep track of them all. We use a simple list that holds every active projectile in the world. Each projectile gets a unique ID made up of two parts: the current game tick (a 64-bit integer) and the projectile's index within that tick (a 16-bit integer). This guarantees uniqueness without needing to track or recycle IDs manually.

Every game tick, we loop through the list and call each projectile's factory to handle movement and updates.

There is a key difference between how the server and client handle this. The client is only responsible for visualizing projectiles and updating their positions smoothly. The server, on the other hand, does not visualize anything — it just handles collision detection and physics.

The Raycast Problem

Here is where the multi-floor system starts causing headaches. The server needs to detect collisions for projectiles, which means casting a ray from the projectile's current position to where it will be next frame. In a normal single-floor game, you would just use the engine's built-in raycast. Done.

But we cannot do that. Godot's raycast uses an OR operation across collision layers — if any of the requested bits match, it registers a hit. That means if we ask for "projectile hitboxes on floor 2," it would also pick up projectile hitboxes on floors 1, 3, 4, and so on. We need an AND operation instead — the collision layer must have all the required bits (both the floor bit and the projectile bit).

We also cannot write our own raycast from scratch, because the actual physics calculations happen in Godot's C++ core and we are working in C#. So we had to get creative.

Our workaround works like this:

Cast a ray from the projectile's current position toward its next position
If the ray hits something, check whether the hit object's collision layer contains all the required bits (e.g., for a projectile on floor 2, we need both bit 5 for projectiles and bit 17 for floor 2)
If it does not have all the bits, add that object to an ignore list and cast the ray again
Repeat until we either hit something valid or reach the end position

It is not the most elegant solution — repeatedly casting rays is not cheap — but it works, and it handles the multi-floor collision logic correctly.

Keeping Clients in Sync

\[VIDEOS ARE ONLY AVAILABLE ON OUR BLOG SITE [url="https://blog.unheard-software.com/the-projectile-system"]https://blog.unheard-software.com/the-projectile-system[/url]]

Multiplayer introduces another challenge: making sure projectiles on the client side match what the server is doing, without overwhelming the network.

When a new projectile is created, the server sends a message to all clients within visibility range. This message includes where the projectile spawned, what type it is, and what direction it is moving. The client receives this, looks up the appropriate factory for that projectile type, and starts simulating the movement locally.

In theory, if the server and client are running the same movement code, the projectile will stay perfectly in sync. In practice... it is pretty close. Our testing so far has shown it works well enough, though there is always going to be some minor drift.

If something significant happens — the projectile hits a target, penetrates a wall, or gets destroyed — the server sends an update or removal message using the projectile's unique ID. This keeps the important events aligned without needing to constantly broadcast position updates for every single projectile.

One other detail: we only sync projectiles to clients that are nearby. If a projectile is on the other side of the map, there is no point sending updates about it. This cuts down on bandwidth significantly in larger matches.

In the Game Right Now

Ripper currently has four different types of projectiles:

9mm — Standard rounds used by the pistol and Vector SMG. Balanced speed and damage.
Gauge — Shotgun pellets. The shotgun fires up to 14 of these per shot, spread in a cone.
Sniper — High-damage, high-penetration rounds. Punches through multiple walls and enemies.
Thrown — Grenades and all the other throwable items.

Each of these has its own factory controlling behaviour — the sniper round penetrates more surfaces before expiring, shotgun pellets spread out, thrown items have more air drag. The system is flexible enough that adding new types (explosive rounds, ricochet bullets, whatever) is just a matter of defining a new factory.

Potential Issues

No system is perfect, and ours has a few known quirks:

Client latency — The higher a player's ping, the less accurate projectile positions may appear on their screen. The server is always authoritative, but visual lag can still happen.
Server-side collision — All hit detection happens on the server, so sometimes a player might see a projectile hit something on their screen while another player does not. The server's version is the truth, but perception can differ.

We are keeping an eye on these and are ready to tweak the system based on community feedback once the game is out there.

Wrapping Up

This system meets our requirements — multi-floor support, multiplayer sync, moddability, and penetration mechanics all work. Is it perfect? Not quite. We are still learning as we go, and we are committed to iterating and improving based on feedback. Transparency is important to us, so we want to be upfront about how the system works and where its rough edges are.

As always, if you have not already, please wishlist Ripper on Steam! This started as a passion project and has turned into something we are genuinely excited about. We want to keep working on it for some time.

For the next devlog, we are not committing to a specific date — time is tight at the moment — but we can tell you what is coming: the item and inventory system. See you then!

Unheard Software

Ripper

Making of the World

Feb 14

Note: this article was taken from our blog site[blog.unheard-software.com]. For better format & experience go there.

Welcome to the very first devlog for Ripper, our indie top-down shooter! We want to bring you along for the ride as we build this game, sharing the problems we run into and how we solve them. Today we are talking about the world itself — how it is built, how multi-floor buildings work, and how we keep it all running smoothly with multiple players in the same game.

What We Wanted

From the start, we had a pretty specific vision. We wanted players to be able to raid multi-floor buildings — blowing up walls, kicking in doors, and wrecking everything in sight, all while playing with friends. We also knew from day one that we wanted to support modding, so the whole system needed to be flexible enough for the community to reshape it however they like.

That combination of requirements — multiplayer, multiple floors, full destructibility, and moddability — pushed us toward some creative solutions. Let's walk through them.

Building the World from Small Pieces

Everything in the game world is made up of objects. Each object is just a piece of data — think of it like a blueprint — and a dedicated factory is responsible for bringing it to life and managing its behavior. Instead of every single fridge or wall segment being its own fully loaded entity in memory, there is one factory per object type that handles all instances of that type at once. This keeps memory usage manageable, especially for larger worlds.

There are three kinds of objects:

Tiles — the most common type, arranged on a grid across two layers (floors and walls). Think grass, wooden wall corners, that kind of thing.
Furniture — physical objects in the world. You can move some of them around, and you can blow all of them up. Fridges, trees, explosive barrels...
Utilities — mostly invisible, but they serve important purposes. Stairs, item spawners, and similar things fall into this category.

Tiles on the left, furniture in the middle, utilities on the right.

A nice bonus of this factory-based setup: because the object data is already structured and separated from the game logic, sending world state to all players in a multiplayer session requires no extra work. It is already in a format that can be sent directly over the network.

The Multi-Floor Problem

This is where things get interesting. Getting multiple floors to work in a game that has real physics, multiplayer, and enemy AI is trickier than it might seem.

The most obvious solution — unloading one floor and loading the next when a player uses the stairs — works well in single-player games, but falls apart for us immediately. Players can be on different floors at the same time, and enemies need to be able to follow players across floors. You cannot just swap out the whole level.

Another idea we considered was placing each floor at a different physical location in the world and teleporting the player between them. This technically works, but it is messy — it creates arbitrary boundaries, wastes space, and most importantly, the farther you get from the origin point of the world, the more floating point errors accumulate. On the 15th floor, you could start seeing strange, unpredictable physics behaviour.

Our actual solution uses collision layers. Godot, the engine we use, supports 32 collision layers. We reserve the top 16 of those to represent floors — each floor gets its own dedicated layer. This still leaves us 15 layers free for everything else (projectiles, melee hit detection, triggers, etc.).

\[VIDEOS ARE ONLY AVAILABLE ON OUR BLOG SITE [url="https://blog.unheard-software.com/making-of-the-world"]https://blog.unheard-software.com/making-of-the-world[/url]]

Animation showing how different collision types work across floors within a single physics space.

Every entity and physical object only exists on the collision layer of the floor it is currently on. For things like projectiles or melee weapons that need to interact with objects, they carry a second hitbox area that combines the floor layer with their own purpose layer — so a projectile on floor 2 checks both the floor 2 layer and the "projectile" layer.

A neat side effect of this setup is that all floors physically exist at the same location in the world, just on different layers. This means lower floors are always rendered beneath upper floors, and the player can actually see down through openings like balconies. It opens up some fun vertical gameplay possibilities.

Getting Enemies Around the World

With the floors sorted, we needed enemies to actually navigate them — and to follow players between floors.

Our first idea was to use Godot's built-in tilemap navigation system, which supports navigation layers. It seemed perfect. Unfortunately, we hit a wall: Godot does not allow multiple navigation meshes to exist above each other, even on separate layers. Since every floor in our game can have a completely different layout, we need separate navigation data per floor. So that approach was out.

Next we looked at Godot's [c]AStarGrid2D[/c], which lets you feed in a grid and mark cells as blocked (walls) or open. This was promising, but it comes with a catch — it requires you to define a fixed grid size upfront. We do not want to cap the world at an arbitrary boundary, so that was a dead end too.

Our final solution is a custom pathfinding grid we built from scratch. It works on the same principles — tracking which cells are walkable based on wall placement — but without any size limit, and with a few extra tweaks to handle larger entities better.

For navigating between floors, we tie into the stairs system. Each staircase object is linked to its counterpart on another floor via a unique ID. When a player or enemy enters a staircase, they are moved to the connected staircase on the target floor (currently as an instant teleport — a transition animation is on the maybe do it later list). For enemy navigation, when a target is on a different floor the AI looks up the nearest staircase that connects to that floor and pathfinds toward it first, then continues on the new floor.

How Big Can the World Get?

Just for fun, here are the hard technical limits. Each floor supports up to 32,767 tiles in each direction across two layers, and there can be up to 16 floors total. That works out to a theoretical maximum of over 137 billion tiles in a single world — which, at roughly 12 bytes per tile, would be a file size of around 1,500 gigabytes. For other objects, each one gets a unique 8-byte identifier (1 byte for the floor, 7 bytes for the unique ID), giving each floor room for an almost incomprehensible number of individual objects.

We are pretty confident nobody is hitting these limits. Realistically, the game engine would have long since given up before you got anywhere close.

Wrapping Up

This solution ticks all our boxes — multiplayer, multi-floor, full destructibility, and modding support. Is it perfect? Not yet. We already have a list of optimizations and improvements we want to make, and we will keep iterating.

Thanks for reading! If you want to support the project, you can wishlist Ripper on Steam or check out more on our website[ripper.unheard-software.com].

Next devlog — hopefully in two weeks — we will be digging into how we built the projectile system. See you there!

Unheard Software

Ripper

Introducing RIPPER

Jan 31

Note: this article was taken from our blog site[unheard-software.bearblog.dev]. For better format go there.

It has finally come to the time for us to announce what we have been cooking for the past few months!

Say hello to RIPPER

Ripper is our top down 2D multiplayer shooter game with fully destroy-able environment and immersive fog of war. You can (and should) wishlist the game on Steam right now.

In the base game you can find four different game modes to explore with your friends. Survive invasion of zombies eager to kill you and destroy your hidey-hole. Create assault strikes against zombies in cities, sewers or factories. Or if you want to play against your buddies you'll enjoy free for all and team death-match.

If you want to know more information visit the ripper page at https://ripper.unheard-software.com or join our discord[discord.unheard-software.com].

What's coming

This game is still in development, and will be for few more months. Most of the features we mentioned are already implemented into the game, but there is more coming that we don't have the guts to fully advertise yet. That's why we have created a roadmap for you to see what's possibly coming.

There is still time for this game to change, so keep an eye on updates as we continue development.

Built for the community

We want our players to be able to add their own content to the game. The game features a built in level editor for creating maps from different types of objects. These objects will be mod-able into the game. So when the game eventually reaches you, you will be able to add your own furniture, weapons or tile sets.

We want this project to be focused on the players (community) playing it, allowing them to play what they wish to play. And we hope that we can achieve it with you.

Notes about development

This is our first public game that we had guts to publish to the Steam platform. Naturally we don't have enough experience for such a project and this project also serves as a learning ground. We will cover this in the future, but even though this game looks simple on the surface, there is a lot of hidden complexity in it.

We will keep you updated with the game development over the coming months. We have several blogs already in-works to give you some information about how the game was developed and how it works in the background.

We're looking for team members! We are looking for someone that would know how to create a soundtrack for our game. Additionally we would like someone that would be capable of managing the public community, because we want to focus most of our effort into the game development. Since this game has literally no budget, we cannot offer much other than sneak peak into the game development and free copy of the game (+ alpha testing).

Until then - thank you for being with us!

Unheard Software

Ripper

See More Content

No more content. So sad.

You can help: share a screenshot, make a video, or start a new discussion!

Returning to where you were last on this page...

Cancel