How Hologryph built SAND: Raiders of Sophie for a sustainable live ops cadence

For Hologryph, developing SAND: Raiders of Sophie meant turning an alternate-history 1910 desert wasteland into an extraction game that could keep growing long after launch. Players crew and pilot Tramplers – gigantic walking machines that serve as base, loot vault, and weapon at the same time – then ride them across a procedurally generated open world in search of salvage, and each other.

Delivering that experience required a strict authoritative server and client split, procedural world generation that runs identically on both sides, synchronization of the hundreds of entities that make up a single Trampler, and world streaming smooth enough to sell the feeling of riding one. The team also needed a content pipeline fast enough to ship new compartments, weapons, effects, and seasonal environments on a regular cadence without destabilizing performance.

We spoke with Serhiy Grinets, CTO and game director at Hologryph, about architecting the game for the long term, keeping the content pipeline moving, and what it takes to run live ops on a game this technically ambitious.

What does your live ops model look like, and what goes into a typical update?

Serhiy Grinets: Our live ops model for SAND focuses on keeping the game evolving together with our passionate community. Our priority is to maintain a regular cadence of updates that combine new content, gameplay improvements, balancing, bug fixes, and quality-of-life changes. Our ultimate goal is to build a sustainable live ops model that supports the title long-term.

What were your core technical goals going in, and how did they shape your approach to building a game designed to live and evolve long-term?

We had three big goals:

• A strict split between an authoritative server and a client, with procedural world generation that runs identically on both sides.
• Synchronizing a huge number of entities – a single Trampler is made of hundreds of them.
• Smooth world streaming – the world is really big, and to sell the feeling of riding a Trampler, you need somewhere to ride.

Tramplers are central to the game’s identity. How did you build the customization system so you could ship new parts, cosmetics, and variants as ongoing live ops content?

The whole system is built around compartments. A compartment is a section of a Trampler – a deck, a cabin, a support frame, an equipment room – and every compartment is designed to fit together with the others.

Players assemble their Trampler from these blocks: They choose the layout, stack decks, place equipment, and end up with a machine that’s truly theirs – their base, their vault, and their weapon at the same time.

For us as developers, this is also the content pipeline. To add a new compartment, we model it and configure it without code. It plugs into the building system like any other block, and players can immediately use it in their designs. A programmer only steps in when a part needs a new mechanic, and even then it’s a small, isolated piece of work.

That’s what makes compartments perfect live ops content: Every new one multiplies the number of possible Trampler builds, and they’re inexpensive for us to produce.

What does the architecture underneath the compartment system look like, and how does it let you prototype new mechanics quickly?

We use a modular approach that lets us iterate on prototypes fast. Under the hood we have a custom inversion of control container for plugging in new functionality, and it fits our Entity Component System (ECS) very well. On top of that, our custom network engine means we almost never have to think about networking when building new mechanics. Replication is handled a layer below the gameplay code.

How did Unity’s C# Job System and Burst compiler give you the performance headroom to keep adding live ops content without regressions?

Our simulation runs on our own modified version of Entitas, an open source ECS framework, rather than Unity Entities, but the C# Job System and Burst compiler are critical for our hot paths. The procedural terrain generation, including heightmap and biome sampling jobs, Trampler movement math, and our custom occlusion culling, all run as Burst-compiled job chains. That work stays off the main thread, so a denser world doesn’t cost us frames.

What role did VFX Graph play in letting your team iterate quickly on effects for live events, seasonal moments, or achievement milestones?

All our effects – sand dust, smoke, shields, weapon effects – are built on VFX Graph, but the key point is how we use it. On top of it, we build configurable effect systems, like muzzle flash or bullet impact, that exist as one flexible graph with a large set of exposed parameters, including size, color, timing, debris, and smoke.

So when a new weapon comes in, an artist just tunes those parameters and gets a unique effect – there’s no technical artist involved or new graph built from scratch. The tech artists’ time goes into making these systems richer instead of hand-crafting every single effect for that weapon.

That’s what keeps production fast enough for a steady content cadence. New weapons and events get quality effects at the cost of configuration, not development.

How did the Unity Profiler shape your optimization workflow as your live ops content pipeline scaled up?

We regularly measure performance on both client and server to find and optimize the weak spots. The per-system breakdown in the Unity Profiler shows exactly where the time goes, which makes our ECS very convenient to profile.

We also have automated tests that measure performance in fixed scenarios, so we see the trend every day and can react to changes immediately.

How are you using Addressables to push live content updates, hotfixes, and seasonal drops without requiring a full client update?

Addressables are the backbone of our memory management. The world is streamed: As players ride across the desert, content is constantly loading in and unloading behind them. All of that goes through Addressables, so the memory stays flat no matter how far players travel.

A second, less obvious role is that we have two separate projects, the main client project and the server project, and we built a custom solution that transfers assets from one to the other. That keeps both environments consistent: The server sees the same data as the client, built through the same pipeline, so “works on client, broken on server” content bugs are structurally impossible instead of something we have to test for.

Were there any Asset Store tools that helped you build or maintain your live ops pipeline faster?

From the Unity Asset Store, GPU Instancer Pro renders all our desert scatter, which is essential for the open world, and Amplify Impostors handles distant objects. Odin Inspector powers our designer-facing tooling, which is key for a data-driven content pipeline, and Rewired handles input across PC and consoles. Easy Save, DOTween, and I2 Localization all saved us real time.

How did Cinemachine factor into capturing shareable, highlight-worthy moments – mech battles, big plays – that fuel your content strategy?

Our use of Cinemachine is deliberately simple. It manages our cameras and switches between them – the gameplay camera, the hangar, and the spectator view. We don’t do any extra staging or scripted cinematography on top, and that’s a conscious choice. SAND: Raiders of Sophie is a first-person, highly competitive game, and the camera’s job is to be reliable, not artistic.

The cinematic quality comes from the game itself. When two gigantic walking fortresses are trading cannon shells, and you’re standing on the deck of one of them reloading a gun, no scripted camera work can beat that. The epicness of the simulation is the cinematography. Cinemachine makes sure the camera never gets in the way.

You built a dual-channel Vivox setup – crew chat plus spatial proximity chat. What went into designing and implementing that?

Every player is in two Vivox channels at once: the regular crew channel, which is the “radio” where your crew always hears you, and a positional channel via 3D proximity voice, so you hear nearby players from other crews in the world.

The positional channel uses Vivox 3D properties – range, falloff, fade model – tuned in a config. Our ECS pushes speaker and listener positions to Vivox at a capped rate, only around 20 times per second and only when the player has moved. The authentication runs through our own backend token service.

Beyond voice, how did Vivox factor into your broader live ops strategy, and how did it help drive social engagement and retention?

Proximity voice is a gameplay feature for us, not just for communication. Extraction games live on emergent social moments, where crews meeting in the desert can talk, negotiate, team up, or betray each other, and hearing a stranger’s real voice nearby creates tension no scripted system can. The crew radio keeps teams coordinated.

What’s your top tip for developers looking to build a live ops-driven game?

Developing a live ops game is a challenging journey, so make sure your team has the resilience to see it through and that you have reliable partners and tools by your side. Stay close to your community – listen to your players, learn from their feedback, and let it help shape how the game evolves over time.

To read more about projects made with Unity, visit the Resources page.