Astral Productions - Technical Gameplay Design
Want to read something specific? Jump to…
Storm Reavers
What is storm Reavers?
The plan is dead. The guards are closing in. You flip gravity and the floor becomes a wall, flying sideways toward the exit with the loot in your arms. Storm Reavers is a co-op heist game where every job falls apart and every player can save the run. Plans may fail, but gravity doesn’t.
Storm Reavers is ultimately a co-op heist game driven by gravity. My goal was to create a replayable co-op experience like recent hits ala R.E.P.O or Lethal Company but with more mechanical depth and combat — so less horror and more combat.
Design Details
Version 1 and the pitfalls.
Version 1 of Storm Reavers began around January 2026 with Gravity and PCG-based Island Generation as the two centerpieces of the game.
The idea was to build replayability around procedural island generation as the backbone of the experience. Points of Interest would spawn across the map, and players would gradually work their way toward an objective — get in, get out, heist-style. In isolation, this worked. Gravity was an excellent way to move through the world. The PCG islands held up on their own. The problem was putting them together.
How do you stop players from using gravity to skip the on-foot exploration the islands were built around? I tried the obvious answers:
A cooldown on gravity usage
A distance limit
A mana cost, paid for as long as gravity was active
A duration limit — gravity cuts out after some fixed time
Some mix of all of the above
I landed on a mix: a mana cost via GAS, ticking down for as long as gravity stayed active. It worked, but only barely. Players could still cross the map faster than the island design accounted for. Gravity wasn't complementing island generation, it was actively opposed to it. Gravity wanted to be a fun, fast way to move. Island generation needed players to slow down and explore on foot, to find things naturally instead of skipping to them.
That's the wall I kept hitting: nerf gravity enough to protect the exploration loop, and I'd be sanding down the best part of the game, the thing Storm Reavers was actually about. Don't nerf it, and island generation, the pillar the whole loop was built on, couldn't do its job. Neither side could give. That's the pivot.
Version 2 - Bernal Spheres
Ever heard of a Bernal Sphere? That's the core of version 2.
Instead of islands, I went full steam ahead on a true 3D generator — a mix of custom C++ generation for the sphere itself, plus a PCG pass for the procedural POIs layered inside it. This solves a few problems at once:
Generation is genuinely three-dimensional, not scattered across a 2D plane and called "explorable"
Enemies get real space to operate in, instead of being pinned to a single walkable layer
The core fantasy gets sharper — true omnidirectional movement, not movement that's fast but still secretly flat
Original Bernal Sphere concept via Wikipedia
A couple of questions worth answering directly:
Why not do this sooner? Generating a sphere/planet seems obvious.
Because it's dramatically more work. Unreal — and most of its built-in systems — isn't built for omnidirectional space by default. NavMesh breaks. PCG breaks. A long list of calculations that assume "up" means one fixed direction need to be reworked from the ground up. It essentially takes a few months of work total and scales the tech dev time alone (no gameplay) to a month or so.
What's the biggest challenge?
NavMesh, easily. AI pathing on walls, ceilings, anywhere that isn't a flat floor needs a custom voxel-based pathfinding solution. Generating the voxel space is its own challenge. Rethinking how AI actually moves through that space is a bigger one. AI needs to have comprehensive information to figure out not just which direction to go, but when and how to change gravity.
That decision shapes a lot of what's below.
The loop, inside a sphere:
Each sphere is a self-contained heist. You drop in, you scavenge, you get out, and the clock is not a suggestion. Difficulty escalates the longer you stay: enemy spawn rate climbs, and so do their stats becoming more aggressive, more accurate, tougher to put down. Eventually the exit itself starts to close, and getting caught in that closure is lethal. There's no backing out once you're committed. You finish the run or you don't.
The one lever you have against that clock is risk. Small, frequent objectives buy you a little time each. Rarer, harder ones, a high-value kill, a hidden cache, buy you a lot. The sphere is daring you to stay just a little longer.
Combat is ranged-first, melee as a backup when something gets in your face. Gravity is fully manual - point anywhere, and you're falling straight away. This is a derelict structure full of things that want to kill you, not a tranquil floating-puzzle box. And the enemies aren't blind to it, they read your gravity orientation and react to it, so reorienting isn't just traversal, it's a tell you're giving away every time you do it.
Loot follows the same risk logic as the clock. Baseline salvage is quiet, grab it, move on, nobody notices. The good stuff is loud. Cracking it open draws attention, and that attention doesn't stay put, it starts local and spreads outward the longer it goes unanswered. Whatever you scavenge and actually carry out the door is yours for good, which is the real hook keeping you in a sphere past the point where leaving would be the smart move.
Between spheres:
Each sphere connects to the next via a bridge, locked behind a puzzle or key objective found somewhere inside that run. Those objectives are varied and semi-procedural, one run might mean infiltrating a tower to activate a power source, another might drop you in front of a field boss that means business. Different enough to feel fresh each time, not so different that you lose your bearings. This is the throughline that replaces the old island-to-island pacing: progression isn't "explore until the map's done," it's "survive this sphere, unlock the next one."
There's a lot more to get into, how the spheres themselves actually get generated, but that's its own section, further down.
Bernal Sphere Generation from the outside, ~~~~ 50,000 units radius
25 Spheres generated with connecting bridges and directional aware outcomes.
Gravity - design + Tech
Gravity was initially an experimental idea for me, as Epic had exposed their gravity logic to blueprints only a version or two prior. With that I dove into the idea with a handful of gravity types:
Directional Gravity - Gravity that causes you to fall exactly towards your hit direction.
Plane Gravity - Gravity that causes you to fall towards the normal (or plane) of the hit surface. This is closer to the six cardinal directions. Less percise, but much faster to use.
Tethered Gravity - Very similar to planetary gravity where you will continue to fall towards the hit location even if you go past it. This creates a sort of slingshot effect.
Gravity Flip - A single input press that swaps your gravity to the inverse of your current gravity (e.g. 0,0,-1 swaps to 0,0,1). It does require a valid surface above you to work however.
Gravity on Run/Move - This is effectively foot based gravity as it checks your foot location, velocity, and determines the best gravity based on those values. This allows players to run on/across a surface with varied normals such as a sphere.
Gameplay Ability + Replication
The core logic for the gravity mechanics relies primarily on normals, traces, and a mix of GAS and RPC logic.
Gravity was initially an experimental idea for me, as Epic had only exposed their gravity logic a version or two prior. With that I dove in with a handful of gravity types: Directional, which falls exactly toward your hit location; Plane, which snaps to the nearest cardinal direction of the hit surface normal for faster less precise shifts; Tethered, which anchors to a world position and continuously recalculates the pull vector even after you pass it, creating a slingshot effect; Gravity Flip, a single input that inverts your current gravity vector gated behind a ceiling trace so it cannot be used in open air; and Gravity on Run, which samples your foot position and velocity each tick to compute gravity from the surface beneath you, allowing players to run across geometry with varied normals like the outside of a sphere.
Under the hood, each gravity type resolves to a direction vector which gets fed into Epic's exposed gravity override on the Character Movement Component. The heavier lifting is in how each type arrives at that vector. Directional and Plane both fire a single trace on activation and derive the vector from the hit result, with Plane adding a quantization step to snap to the nearest cardinal. Tethered stores the hit location as a persistent anchor and recalculates toward it every frame, which required careful handling to avoid fighting the CMC during transitions. Gravity on Run is the most involved, running a multi-trace sample from the foot each tick and blending normals to smooth out transitions across uneven geometry. GAS handles activation and state signaling, while the actual vector math and CMC overrides are driven from the Character Blueprint with manual RPC calls to keep replication clean.
Ragdoll
One of the goals I had for the gravity mechanic was a high opportunity cost. You could traverse distances quickly, sure, but there needed to be a risk. As such I opted for a sort of quick time event. Right before the player lands they can press their dodge input to gain momentary Iframes from fall damage. This has other effects as well, but if they fail they take fall damage and get ragdolled.
Having never (personally) made a replicated ragdoll I didn't quite estimate just how challenging this would be.
My first approach relied on Gameplay Abilities using existing logic to activate/deactivate logic. However this proved unreliable as the GA didn't properly replicate across clients. It looked great on server, but clients would often get bad desync as Gameplay Abilities aren't designed to work on Tick.
The next approach was a Hybrid, using GAS to activate/signal to activate the ragdoll, but driving the core logic via the character blueprint. This approach proved much more reliable as GAS replicates organically, then any additional RPC calls can be handled manually.
The hybrid approach works by having the Gameplay Ability fire an RPC to the Character Blueprint the moment the ragdoll condition is met, which then sets the mesh to simulate physics and applies the custom gravity override locally on each client. Because physics simulation state is inherently non-deterministic across the network, the server acts as the authority on when ragdoll begins and ends, broadcasting those events via multicast RPCs rather than trying to sync the raw physics frames themselves.
Recovery works on a timer driven from the server, and once the recovery window opens, the Character Blueprint blends back from physics to the AnimGraph using a Get Bone Transform snapshot, snapping the capsule to the mesh's current pelvis position before re-enabling movement. This prevents the jarring teleport you get when the capsule and mesh diverge during a long ragdoll.
The custom gravity component presented its own wrinkle here since standard Character Movement gravity is bypassed during physics simulation, meaning the gravity had to be re-applied as a direct impulse or force on the physics body rather than through CMC. This was handled via a tick-driven force application on the mesh's root body, scoped to only run while the ragdoll state is active, and disabled immediately on recovery to avoid fighting the CMC on re-enable. Just to be clear about what would happen here: if the ragdoll activated on, say, the roof the capsule of the character would properly be on the roof, but the mesh itself would fall onto the ground. This made for horrible desync as it seemed like the player was on the ground, not the roof, then they'd snap and tp back to the roof.
Island Generation
Proof of concept island generation taken around Feb 2026.
Enemies that can use Gravity too…
Coming soonTM - This section will contain information on how I approached practical AI design in 3D space using the Voxel system detailed above.
Tooling
Opted to put these as unique pages.
