How RUST LTD built the deep firearm simulation for Hot Dogs, Horseshoes & Hand Grenades 2

Creating Hot Dogs, Horseshoes & Hand Grenades 2 (H3VR2), a standalone VR physics firearms sandbox and extraction roguelike, meant starting over rather than carrying a decade of technical and design debt into a sequel.

Instead of porting the original game, RUST LTD started with a fresh Unity project and spent nearly six months focused on architecture and tooling before moving into full content production.

That foundation supports everything from firearm components and ballistics to enemy perception, rendering, audio, and Editor tooling. Real-world data feeds many of those systems, allowing mechanical differences to emerge through the simulation rather than the team authoring them as isolated gameplay values.

We spoke with Luke Noonan, cofounder and head of production at RUST LTD, and Anton Hand, cofounder and game director, about rebuilding the game from the ground up, pushing simulation complexity, balancing physical fidelity against VR performance, and building the tooling required to manage hundreds of mechanically distinct firearms.

What’s changed for the sequel – in scope and in ambition?

Luke Noonan: One of the big things we wanted to do with the new title was fix a lot of the technical and design debt that had accumulated.

We did a ground-up rewrite for H3VR2. This was a fresh Unity project when we started. We looked at pieces of the existing game and had that experience to draw from, but this wasn’t a port. It was a rebuild.

AH: Technically, we built this project almost exactly opposite to the way we built H3VR.

With H3VR2, we spent almost six months on pure architecture and tooling before we bothered with anything approaching full content production. We knew how to build the guns since we had already done that for 10 years. We needed systems that could scale to a five- or 10-year project of content additions.

LN: We also knew from the beginning that this would be a much bigger team. H3VR was largely Anton with other people supporting different parts of production. With H3VR2, we’re north of 20 people.

That required better development operations from the outset: good version control hygiene, build automation, custom Editor tooling, and production processes that work for a team distributed across five different time zones.

What does the level of simulation involve under the hood, and what were you determined to get right?

AH: Our process starts with an obsessive amount of classical research. We start by finding real reference material, including actual books and technical documentation.

From a simulation standpoint, our basic principle is to construct a model where we can feed real data into it and get the model to converge on something between received, colloquial realism and something that works for the game.

That becomes important the moment you build a really complex simulation with a huge number of inputs. We’ll eventually have hundreds of guns, hundreds of cartridges, and dozens of materials.

With H3VR2, we’ve been able to go much further. We can ask whether we can feed real spring constants into a system and discover that, yes, we can. Can we incorporate real-world dimensions and mechanical relationships into the firearm’s operating system? Yes.

LN: We pay a cost up front for that systematic approach, but we get a lot of benefits downstream. If we want to add a new cartridge type, for example, we can look at properties such as projectile mass and the characteristics of the cartridge rather than inventing a magic gameplay number.

Where does NVIDIA PhysX fit into the stack, and where did you decide you need custom systems instead of, or alongside, the built-in physics engine?

AH: We use a fairly restrained amount of the complexity available through NVIDIA PhysX.

Game physics engines don’t really handle tiny components inside a local reference frame while the player is carrying the parent object around and potentially throwing it across the room. So we have a lot of very bespoke internal simulations for firearm components that effectively exist in their own universes. We manage the translation of forces and impulses between those internal systems and the larger game space.

At the game-space level, we use physics much more directly. The Sosigs, our hot dog characters, are probably our greatest use of physics. They’re effectively perpetual physics ragdolls.

LN: At the very small scale, for component simulation inside the guns we’ve built custom systems. At the other end, for ballistics and a significant part of the agent systems we built another layer using ECS for Unity and Burst.

How did you architect the ballistics simulation using ECS for Unity?

LN: We knew we had to have a lot of guns firing, that guns can fire very quickly, and that whole gunfights could be happening at the same time. That puts a lot of performance pressure on the simulation, and we had to make compromises around that in the first game.

Using ECS for Unity and Burst lets us spawn huge numbers of ballistic entities for firearms, explosions, and other systems.

It helped us increase the fidelity rather than simply hit our original target. We can do smaller sub-step sampling for more accurate collision, model air resistance more accurately, and do higher-fidelity handling of penetration and projectiles moving into and out of different materials.

What were the biggest performance challenges a simulation this deep created?

LN: A lot of the early development period was about systematically testing those areas. What is cheap? What is expensive? What can or can’t this new platform do? Once we had those boundaries, it became much easier to keep frame time in line.

AH: We developed a very honed understanding of what is fast and what isn’t during H3VR. It’s one of the reasons we stayed out of standalone VR until Quest 3.

On the CPU side, that meant building the core simulation systems around ECS and Burst. On the rendering side, we knew sophisticated 3D models of guns were going to consume a significant portion of the frame budget, so everything else – total polygon count, texture memory, bandwidth, environment structure – had to remain very lean.

We weren’t willing to decimate the thing people are coming to the game for. So we designed the environments, interaction density, content typology, and level structure around those constraints from the beginning.

Optimization wasn’t a parallel track that came after a set of inflexible design decisions. It was part of the gestation process vertically through the entire project.

LN: Facility uses procedurally assembled levels we build from modular kits, so we also validated very early how the lighting model would work. We looked at how we could use light probes, reflection probes, and the rest of the lighting stack, and then followed those decisions backward into the art direction itself.

How did upgrading to Unity 6.3 benefit the project?

AH: Moving to Unity 6.3 for H3VR2 is basically a decade jump compared to H3VR.

There are the obvious quality-of-life improvements, such as nested prefabs, but some of the most impactful things for us have been the performance of the SRP Batcher, shader compilation improvements, and on-tile post-processing.

Shader compilation has helped with making those large uber shaders smaller on disk. On-tile post-processing was especially important for our visual approach. I don’t want to ship a game without tone mapping, but originally we wrote our HDR tone-mapping pass directly into our shaders because having a separate post-effect blit wasn’t performant enough on standalone VR hardware. With on-tile post-processing, we were able to remove that code.

LN: The overall stability and reliability of the current Unity version have also been genuinely important. We’re pushing a lot of custom tooling through the Editor, and that process has been very smooth.

Every weapon in the game has its own mechanical behavior. How do you author and keep it data-driven, and how do you maintain a roster that size?

AH: Keeping it maintainable is a constant fight. The sheer volume of Google Docs we have for everything is pretty wild, although the assets themselves ultimately become the single source of truth for how we configure those firearms.

It comes back to having very powerful Inspector tools. Those tools aren’t simply for entering information. We have calculation-centric Editor tools, validation tools, and analysis tools we built specifically around the firearms.

The simulation is deep enough that I would describe a lot of the work as being closer to real-life gunsmithing. We’re entering things such as spring constants and component masses. Cartridges have pressure-curve data and information describing the different components of the cartridge.

If those values are wrong, the firearm in the simulation doesn’t cycle correctly.

How did Odin Inspector and the Asset Store help your team manage the complexity of developing and maintaining the game?

AH: If I had to identify the central value proposition of Unity for a game like ours, it would be the extensibility of the Editor.

We use Odin Inspector extensively, and I don’t think this project would be feasible in the same way without it.

Everyone who has written code for the game has written custom inspectors. Odin dramatically minimizes the amount of work involved because it gives you incredibly powerful shorthand for building those tools.

That’s especially important when you’re dealing with something as ontologically and taxonomically complex as a firearm. For any individual gun, perhaps 95% or 98% of everything the base system could theoretically configure is irrelevant to that particular object. Odin lets us suppress those irrelevant options.

Technie Collider Creator 2 from Triangular Pixels in the Asset Store has also been a game changer. It has saved the team hundreds, if not thousands, of hours over the course of production.

For a physics-heavy VR game, authoring physics hulls requires an awkward combination of manual work and automation. A fully automated solution usually isn’t appropriate. You want to use physics primitives as much as possible and then convex meshes only where you absolutely need them.

What’s your top tip for developers looking to build a technically complex simulation game?

AH: Validate what you need fairly early. There’s a very big difference between building simulation systems because you enjoy the process of building simulation systems and building simulation systems that your game needs.

If I look back at H3VR, there’s simulation work I wrote that wasn’t legible to the player. The end user didn’t really experience its presence. It didn’t make my life easier, in some cases it made my life harder as a developer and designer, and it didn’t result in more rewarding gameplay.

That’s the risk with any complex simulation game. You can end up doing work that benefits nobody except perhaps your own experience of making it, while taking you further away from the macro goal of the project.

LN: I’d also point to the people. We’ve benefited immensely from finding the right experts for the team: a sound expert who is also deeply knowledgeable about firearms, weapon artists who understand the subject matter and the needs of VR, and engineers who are interested in the kinds of systems we’re building.

Hot Dogs, Horseshoes & Hand Grenades 2 can be pre-ordered now for Quest 3. The Steam version can be wishlisted now ahead of its 2027 launch. Check out more developer stories on the Unity Blog and Unity Resource Hub.