Salt & Steel: Client Architecture

Document type: Technical Architecture — Canonical
Status: Canonical
Last updated: 2026-04
See also: Networking Model | Performance and Optimization | Server Architecture | Visual and Audio Pipeline

Overview

Salt & Steel's client is a custom-engine application built from the ground up for its specific demands. No existing off-the-shelf engine can adequately handle the combination of a dynamic ocean rendering system with ship-scale physics, seamless zoom transitions between isometric ARPG combat and pulled-back naval command views, real-time weather VFX at scale, and the architectural requirement that GURPS 3d6 resolution is always server-authoritative while the client simultaneously maintains responsive feel through predictive animation.

The client draws on lessons from PoE's architectural history: custom engines have steep upfront costs but allow game-specific optimizations impossible in generalist engines. The dual-domain nature of Salt & Steel (land ARPG + naval combat) makes this argument even stronger — Unreal or Unity would require significant runtime overhead for features Salt & Steel does not need, while lacking native support for several things it critically does.

Rendering Backend

Primary API: Vulkan / DirectX 12

Salt & Steel targets Vulkan as the primary rendering API on Windows and Linux, with DirectX 12 as an equivalent alternative for Windows users where DX12 driver maturity provides better stability. Both APIs offer the same fundamental capability: explicit GPU control, multi-threaded command buffer recording, low driver overhead, and access to modern GPU features (mesh shaders, variable rate shading, ray query).

The choice of Vulkan/DX12 over DX11 is non-negotiable for Salt & Steel. Ocean rendering, weather particle systems, and the simultaneous rendering of ship fleets with crew-level detail require draw-call submission at a scale that DX11's single-threaded command recording cannot handle. In dense naval combat with 8+ ships, particle effects from cannon fire, ocean surface simulation, and crew figures on decks, a DX11 renderer would be fatally CPU-bound.

Shader pre-compilation: Vulkan and DX12 both require pipeline state objects (PSOs) to be compiled before use. Salt & Steel handles this with a background compilation pass on first launch and after major patches. The progress is visible as a loading bar labeled "Preparing the seas." PSOs are cached to disk keyed by GPU driver version; patch updates invalidate only changed shaders, not the entire cache.

Legacy fallback: DirectX 11 support is provided for hardware that cannot support Vulkan or DX12 (below DX12 feature level 11_1). DX11 receives the same content but with a reduced rendering feature set: simplified water shader, no mesh shaders, reduced shadow quality, smaller particle budgets. DX11 is not the performance target; it is the accessibility baseline.

Rendering Pipeline: Deferred + Forward Hybrid

The core pipeline is deferred rendering with a forward pass for transparent geometry:

Deferred G-buffer layout:

RT0: Albedo (RGB) + Ambient Occlusion (A)
RT1: World-space Normal (RGB) + Material ID (A)
RT2: Metalness (R) + Roughness (G) + Emissive intensity (B) + Wet surface mask (A)
RT3: Velocity vectors (RG) for temporal anti-aliasing
Depth/Stencil: Depth (32-bit) + stencil for material classification

The deferred pipeline handles all opaque geometry: terrain, ship hulls, building structures, character bodies, monster meshes. Dynamic lighting — which is pervasive in Salt & Steel, from cannon fire flashes to lantern light aboard ships to bioluminescent sea creatures — is resolved in screen space against the G-buffer in a clustered light culling pass.

The forward pass handles all transparent geometry: ocean surface, particle effects, translucent weather effects, underwater volume rendering, glass and water-filled bottles in inventory. Transparency is too order-dependent for deferred resolution and is handled separately.

Physically Based Rendering (PBR): All materials use a metalness/roughness PBR workflow. This is essential for the visual fidelity targets: wet wood planking on ship hulls, iron cannon barrels, leather armor under rain, and corroded bronze figureheads all require accurate physical light interaction to read convincingly.

Ocean Rendering System

The ocean is the most technically demanding rendering system in Salt & Steel. It must be dynamic (real-time wave simulation), visually beautiful (the Living Sea pillar), computationally bounded (runs every frame alongside everything else), and match the server's weather state exactly (player and server must agree on sea conditions).

Wave Simulation

Ocean surface is computed using the Tessendorf iFFT ocean model on the GPU:

A frequency-domain representation of the ocean surface is generated based on the current weather state (wind speed, wind direction, storm intensity parameter received from server)
An inverse Fast Fourier Transform converts the frequency domain to a height field on the GPU via a compute shader
The height field is applied to a tessellated mesh via the hull and domain shaders (DX12) or equivalent Vulkan tessellation pipeline
A displacement map (height + horizontal XY chop displacement) is sampled by vertex shaders for the final surface geometry

Wave parameters are driven entirely by weather state received from the server. The client does not autonomously compute new weather — it renders the server's weather state. This ensures perfect synchronization: if the server says there is a Force 8 gale, all clients in that sea instance see the same wave height profile.

LOD for ocean tessellation:

Near (0-100m): Maximum tessellation, full displacement, full normal map detail
Mid (100-500m): Reduced tessellation, combined displacement + normal approximation
Far (500m-4km): Flat grid with billboard wave sprites, simplified reflections
Sky-sea transition: horizon blend to prevent visible tessellation pop-in

Ocean Shading

The ocean surface shader implements:

Subsurface scattering approximation: Water absorbs red/orange wavelengths; shallow water appears blue-green, deep water deep blue-black. Attenuation coefficients scale with the turbidity parameter (clear tropical water vs. murky estuary water)
Screen-space reflections (SSR): Ships, cliffs, and atmospheric effects are reflected in the water surface. SSR is a screen-space approximation — reflections from objects outside the frustum use a planar reflection fallback
Planar reflection plane: For near-surface camera positions (during anchoring at shore), a planar reflection render pass captures the scene above the waterline and applies it to the ocean surface
Foam generation: Breaking wave crests and ship wakes generate foam using a foam lifetime/diffusion simulation computed as a 2D texture advected by the wave velocity field
Wet surface masking: Ship hulls, character models, and terrain near the waterline receive a wet surface multiplier that modifies roughness, making surfaces appear darker and reflective when wet

Underwater Rendering

When the camera or player enters the underwater domain (diving mechanics):

The G-buffer clear color changes to deep blue-green
A post-process volume caustics overlay is applied using projected caustic textures animated by the wave simulation's frequency components
Visibility distance is governed by a turbidity parameter (received from server, set by region and weather state)
A depth-based fog in water-color space (not standard grey fog) attenuates objects with increasing depth
Bioluminescent creatures emit HDR light that is resolved in the clustered light pass alongside above-water lights
Sound propagation filtering changes (muffle high frequencies, emphasize low thumps — handled by FMOD spatial mix)

Underwater zones use the same deferred pipeline but with modified post-processing stack. The transition at the waterline is a full-screen distortion effect as the camera crosses the surface plane.

Weather System Rendering

Weather is received as a parameter set from the server and rendered client-side with full fidelity. The client owns the rendering of weather; the server owns the state of weather.

Weather Rendering Components

Rain:

GPU particle system: 50,000-200,000 rain streak particles in camera-frustum-aligned prism. Each particle is a velocity-stretched alpha-blended line segment.
Rain impact particles on surfaces: smaller GPU compute-dispatched splash particles at raindrop impact points (sampled from depth buffer)
Wetness propagation: accumulating wet surface mask driven by rain intensity parameter
Visibility reduction: forward-rendered fog volume with rain-specific blue-grey color

Storm:

Lightning: pre-baked branching lightning meshes with randomized activation timers and intensity. Flash is a full-frame additive white pulse decaying exponentially over 200ms. Thunder is an FMOD event with distance-proportional delay.
Heavy rain (see above) at maximum parameter values
Wave height increase driven by storm intensity parameter (feeds directly into Tessendorf FFT inputs)
Volumetric cloud geometry using signed-distance-field raymarching in a downsampled buffer, upscaled with temporal accumulation

Fog:

Standard exponential height fog with modified extinction coefficient
Dense fog (supernaturally generated by Voyage mechanics) uses a noise-driven volumetric fog volume with animated wind advection — creates the appearance of fog drifting past the camera rather than a static wall

Wind effects (visual):

Sail cloth physics: sail geometry is simulated with a lightweight cloth simulation driven by the current wind vector. Sails belly outward in tailwind, flatten and flog in headwind.
Vegetation on islands responds to wind with GPU-driven animation using vertex shader bend calculations
Rope and rigging sway using secondary motion procedural animation

Ship Rendering

Ships are the most visually complex objects in the game. Each ship is a multi-LOD assembly of components that must look correct at both naval combat camera distance (ship as a 200-pixel silhouette) and boarding camera distance (ship deck as a detailed combat environment).

Ship Component System

Each ship is composed of independent mesh components that can be damaged, replaced, and cosmetically customized:

Hull (multiple LOD states: intact, lightly damaged, heavily damaged, flooded)
Sails (cloth simulation geometry, separate mesh per mast)
Masts (breakable, with pre-baked fracture states)
Rigging (rope geometry with secondary motion)
Cannons (port/starboard/bow/stern slots, individually destructible)
Figurehead (cosmetically swappable attachment point)
Crew figures (instanced skinned mesh rendering — see below)
Flags and pennants (cloth simulation)
Anchor and chains (physics-driven for anchoring animations)

Hull damage states: Rather than continuous damage visualization, hull damage is expressed through a set of pre-authored damage states (intact → light damage → heavy damage → critical breach → sinking). Transitions between states use a material blend with damage overlay maps (scorch marks, splintered wood, hull punctures). Below-waterline breaches trigger a flooding particle effect inside the hull interior.

Instanced Crew Rendering

Crew members on ship decks during naval combat are rendered using GPU instanced skinned mesh rendering. Each ship may have 10-60 crew figures performing assigned roles (at cannon positions, climbing rigging, fighting during boarding). Without instancing, 8 ships × 40 crew × 2 draw calls each = 640 draw calls per frame for crew alone.

GPU instanced skinned mesh rendering consolidates all crew of the same skeleton type into a single draw call with per-instance bone transform data stored in a structured buffer. At eight ships in a naval engagement, crew rendering contributes approximately 8-16 draw calls total, regardless of crew count.

Crew animation uses a motion matching system rather than a state machine: a database of short animation clips is searched in real time to find the clip that best matches the current movement and action state of each crew member. This produces fluid, context-appropriate animation without the transition complexity of traditional state machines. The database is small (crew animations are a subset of character animations) and the search is GPU-assisted.

Ship LOD System

LOD Level	Camera Distance	Detail
LOD 0	0-50m (deck combat)	Full geometry, cloth sim, crew animation
LOD 1	50-200m (close naval)	Reduced poly hull, simplified rigging, crew as imposters
LOD 2	200-800m (mid naval)	Hull silhouette mesh, animated sail billboard, no crew
LOD 3	800m-4km	Static impostor billboard with animated flag

LOD transitions use dithered cross-fading to eliminate pop-in. The dither pattern is spatially stable (screen-space dither offset by object world position), preventing shimmer during camera movement.

GURPS Engine Implementation

The GURPS 3d6 combat system runs authoritatively on the server. The client's role is to:

Capture and transmit player intent (attack command, defense choice, stance selection)
Receive server-resolved combat results (hit/miss, damage value, defense success, status effects)
Animate the result convincingly, hiding the network round-trip latency through predictive animation
Display accurate state information (HP, FP, stance indicator, active defense cooldowns)

Client-Side Animation Prediction

When the player initiates an attack, the client immediately plays the attack wind-up and release animation. This is prediction — the client does not know whether the attack will hit. The server resolves the attack (3d6 roll vs. effective skill) and returns the result within one round-trip time (typically 20-80ms at normal latency).

If the attack hits: the client transitions from the release animation to the appropriate hit reaction on the target, and applies the visual damage indicator. If the attack misses: the client plays the miss animation (weapon passes through where the target was), which is visually indistinguishable from the predicted phase until the server result arrives.

Critical hits use a distinct animation variant (more dramatic impact, screen shake, particle burst) triggered only on server confirmation — they are not predicted.

Active defense prediction: When the player presses a defense input (Dodge, Parry, or Block), the client immediately begins the defense animation (dodge roll with i-frames visually indicated, weapon parry gesture, shield raise). The server resolves the 3d6 defense roll. If the defense succeeds, the animation completes cleanly. If the defense fails, the animation is interrupted and a hit-reaction animation begins. This creates the feel of responsive input while maintaining server authority.

Combat Input Handling

WASD: Directional movement. Client predicts movement, server validates position.
Left Mouse Button / Controller R2: Attack with primary weapon. Targeting is cone-based; client shows targeting preview, server determines actual target at resolution time.
Q / W / E / R (configurable): Active skills. Skill activation is sent to server immediately; animation begins on input, effect resolves on server confirmation.
Dodge key (Space / Circle): Initiates Dodge defense attempt. Client plays dodge-roll animation immediately.
Parry key (Left Shift / Square): Initiates Parry defense attempt. Client plays parry animation immediately.
Block key (V / Triangle, requires shield): Initiates Block defense attempt. Client raises shield immediately.
Stance wheel (Hold Tab): Opens stance radial menu. Stance change is sent to server; server enforces minimum stance duration (anti-spam).
Tab / D-pad: Cycle through secondary actions, crew commands.

FP and HP Display

FP and HP values displayed on the HUD are authoritative server values, updated each tick. The client does not predict HP/FP changes locally — these values always reflect the last server-confirmed state. Minor visual lag (one tick = 25-33ms) is imperceptible.

Ship Control Input System

Naval combat input is distinct from land combat input and must convey a fundamentally different spatial model: the player is commanding a vessel with momentum and wind dependency, not directing a character's footsteps.

Ship steering:

A / D (or left stick): Rudder left / right. The ship turns with inertia — pressing A initiates a gradual heading change, not an instant turn. Visual feedback: rudder position indicator on the ship model, compass heading change rate.
W / S (or right stick vertical): Sail trim — increase/decrease canvas. More sail = more speed but less maneuverability; reduced sail = slower but tighter turns. Current wind indicator on HUD shows effective speed.
Spacebar (or R1): All-stop — drop sail and deploy sea anchor for rapid deceleration.
Q / E (or bumpers): Fire port/starboard broadside volley.
Aim mode (hold right mouse / L2): Enter precision cannon targeting — HUD shows firing arc, range indicator, lead indicator for moving targets. Release to fire.
F (or face button): Initiate boarding action (when in boarding range and crew morale allows).
Tab / select: Open fleet command overlay (fleet management context).

Camera in naval mode:

Default: pulled-back isometric view centered on player's ship, showing surrounding ships at naval scale
Hold Right Mouse: free-look around the ship while maintaining course
Wheel scroll: zoom between naval overview (showing 1-2km radius) and close view (showing 50m radius, ship detail visible)
Auto-transition: when boarding is initiated, camera smoothly dollies in to deck-level over 2 seconds

Camera System

The camera system manages the transition between the game's two spatial scales: isometric ARPG combat (land instances, deck boarding) and pulled-back naval command view (sea instances).

Land / Deck Combat Camera

Fixed isometric angle: 45° horizontal, 60° vertical (from horizontal), rotatable in 45° steps with Q/E or mouse wheel click drag
Smoothly tracks player character with slight lag (look-ahead based on movement direction)
Collision avoidance: camera pulls in when geometry would clip, maintains minimum 3m above floor
Dynamic FOV: narrows slightly during fast movement (motion intensity cue), widens during standstill to emphasize environment

Naval Command Camera

Variable height: 50m-800m above sea surface
Position: centered on player's ship
Orientation: free-rotate with right mouse drag; auto-orient to ship heading with configurable sensitivity
Zoom transitions: smooth logarithmic zoom between heights; at minimum height, transitions to deck-level camera mode
Pitch limits: 20°-80° from horizontal (never top-down, never at sea level unless zoomed to deck)

Sea-to-Land Transition Camera

When the player anchors and transitions from sea instance to land instance:

Camera zooms in toward the shoreline anchor point over 3 seconds
A brief atmospheric dissolve (fog/mist particle effect) masks the instance handoff
Camera fades in at land-instance height centered on the player's spawn point on the beach/dock
Total transition: 4-6 seconds, no loading screen visible

When boarding is initiated during naval combat:

Camera dollies in from naval height to deck height over 2 seconds (plays while the boarding sequence animation runs)
No instance switch required — boarding combat runs within the sea instance as a sub-context
Camera adopts deck-combat mode at boarding resolution

UI Framework

Architecture

The UI is a retained-mode custom framework rendered via the same Vulkan/DX12 pipeline as the game world. UI elements are defined in a combination of Lua scripting (behavior) and a custom declarative markup language (layout and style). This approach, directly analogous to PoE's Lua-based UI, allows rapid iteration on UI without engine rebuilds, while ensuring UI rendering is tightly integrated with game rendering (particle effects can originate from UI elements, UI panels can be rendered with world-space lighting).

All UI rendering uses the same multi-threaded command recording infrastructure as scene geometry. UI draw calls are recorded in parallel with scene draw calls, merged in the submission pass.

HUD Elements

Persistent HUD (always visible in both domains):

Character HP orb (left) and FP orb (right) — pulse red at low HP, pulse orange at low FP
Active defense cooldown indicators: Dodge / Parry / Block with cooldown arcs
Current stance indicator: icon + text label for active combat stance
Compass: heading in degrees, wind direction indicator (sea domain), minimap toggle (land domain)
Crew status bar: compact icons showing key crew members, HP bars, and active roles

Land-domain HUD additions:

Skill hotbar (Q/W/E/R + secondary row): skill icons, FP cost, cooldown indicators
Minimap: 150px radius, procedurally generated from explored terrain
Status effect rack: active buffs/debuffs with duration

Sea-domain HUD additions:

Wind indicator: compass rose with wind direction and speed arrows
Ship damage diagram: outline of ship showing hull section integrity by color (green/yellow/red)
Crew morale gauge: aggregate crew FP as a single composite bar
Enemy ship information (on selected target): range, heading, broadside angle indicator
Cannon readiness indicators: port and starboard reload progress bars
Fleet status panel (if fleet commanding): miniature icons for each fleet ship, hull/crew status

Skill Atlas Renderer

The Skill Atlas is a zoomable canvas rendered as a map aesthetic — the underlying data structure is a graph (nodes and edges), but it is visually presented as a cartographic representation of thematic regions with visual landmarks, color-coded territories, and illustrated borders.

Technical implementation:

Atlas graph is loaded at startup into a GPU-resident vertex buffer (node positions and edge connectivity)
Rendering uses two LOD levels: at high zoom (individual node visible), full icon, tooltip-capable nodes; at low zoom (region visible), simplified region fill with node count aggregate
Text labels use signed-distance-field glyph rendering for clean scaling at any zoom level
Pan and zoom: standard 2D canvas with inertia-damped scrolling, mouse wheel zoom centered on cursor
Node state visualization: spent nodes rendered with filled icon + gold tint; available nodes with gold outline; locked nodes greyed

Nautical Chart Renderer

The Nautical Chart (endgame atlas equivalent) is rendered as a period-accurate nautical chart aesthetic — cream parchment background, hand-drawn coastline styling, region names in period script, sea monster illustrations in unexplored regions.

Known regions: fully rendered with danger-level color coding and applied modifier icons
Partially explored regions: faded rendering with fog-of-war overlay
Unexplored regions: blank parchment with "Here there be dragons" styling
Hoverable regions: tooltip showing region tier, current weather profile, active faction control, applied modifiers, and boss kill status
Region entry: click to enter the region (triggers sea instance creation for that chart zone)

Asset Pipeline and Archive Format

Asset Archive

Game assets are stored in a tiered archive format:

Core archive (SS_Core.pack): Engine shaders, base UI assets, critical gameplay data tables (item definitions, modifier definitions, skill definitions). Always present, never streamed. ~5 GB.
World archives (SS_World_[Region].pack): Tileset geometry, textures, and audio for each geographic region. Loaded on demand when the player first enters a region, cached for subsequent sessions. ~8-15 GB per region.
Ship archives (SS_Ships.pack): All ship hull geometry, sail meshes, cannon models, and figurehead models. Loaded at client startup; ships are encountered in any context. ~3 GB.
Character/creature archives (SS_Characters.pack, SS_Creatures.pack): Player character models, animation banks, monster models. Loaded at startup. ~4 GB.
Audio archive (SS_Audio.pack): Compressed FMOD audio banks. Streamed; only the current region's audio banks are decompressed in memory. ~10 GB total, ~2 GB active at any time.

Each archive uses a content-addressed file structure: files are named by their content hash, enabling patch operations to download only changed files. The patcher computes deltas between the current installed hash and the target build hash and downloads only the difference.

Streaming and Texture Management

Textures are streamed using a priority queue based on distance and visibility:

Mip level 0 (highest resolution) loaded when object is within 50m and screen coverage exceeds 200px²
Mip levels 1-3 loaded as distance/coverage decreases
Mip levels 4+ (lowest resolution) always resident for all visible objects

VRAM budget management: the streaming system maintains a target VRAM utilization of 80% of available VRAM. When a new texture is needed and VRAM is at budget, the least-recently-used high-mip texture is evicted. On GPU memory pressure events (other processes consuming VRAM), the budget floor drops automatically.

Audio System

FMOD Studio handles all audio. Salt & Steel's audio design requires:

3D spatial positioning: Cannon fire from a ship 300m to starboard sounds directionally from that bearing. Wave crashes are positionally placed. Crew combat sounds on an enemy ship's deck are heard appropriately muffled when below decks.
Underwater filtering: When diving, a low-pass filter is applied to all above-water audio sources. The player's own heartbeat and breathing are added as positional-agnostic foreground sounds.
Adaptive music: The shanty/ambient music system responds to combat state (quiet exploration → shanty travel music → building tension → full orchestral combat → resolution). Transitions are bar-aligned to prevent jarring cuts.
FMOD distance attenuation curves: Ocean ambience is omnidirectional with distance-based rolloff. Combat sounds (cannon impacts, swords clashing) use inverse-square rolloff. Voices (crew callouts, NPC dialogue) use linear rolloff for speech intelligibility at practical distances.
Voice budget management: Maximum simultaneous audio voices is capped at 256. FMOD's voice stealing prioritizes: player-attached sounds > nearby high-priority events (cannon impact near player) > distant ambient sounds.

Memory Management Strategy

Salt & Steel's dual-domain design creates a memory management challenge: a player can transition from sea to land without a loading screen, meaning both domains' assets cannot be fully unloaded and reloaded during the transition.

Persistent pools (never unloaded during session):

Core game data tables (items, modifiers, skills) — ~500 MB
Player character assets (model, animations, gear) — ~200 MB
Active ship assets (the player's ship and its current component set) — ~300 MB
Audio banks for current region — ~500 MB
UI assets — ~100 MB

Domain-specific pools (loaded for current domain, partially released on transition):

Sea domain: ocean rendering resources, weather particle systems, sea creature models, enemy ship assets (~800 MB active)
Land domain: current island tileset, dungeon assets, NPC models, environmental props (~600 MB active)

Transition strategy:

When transitioning from sea to land: land domain assets begin streaming 10 seconds before transition completes (pre-load during boarding animation / anchor animation). Sea domain assets are released 30 seconds after transition, once confirmed as no longer needed.
When transitioning from land to sea: sea domain assets are retained (never fully unloaded during a session, using a low-priority background retention). They are refreshed if the sea zone has changed.
Target: transition completes with no more than 200ms stall on the main thread from asset state changes.

Platform Targets

Platform	API	Target FPS	Minimum FPS	Notes
PC (mid-range)	Vulkan / DX12	60 fps	60 fps	RTX 3060 / RX 6600 tier target
PC (low-end)	Vulkan / DX11	60 fps	30 fps	GTX 1060 / RX 580 tier minimum
PC (high-end)	Vulkan / DX12	Uncapped	—	4K support, DLSS 3 / FSR 3
Console (PS5 / XSX)	Platform native	60 fps	60 fps	Performance mode; Quality mode at 30fps 4K
Console (PS4 / XBO)	Platform native	30 fps	30 fps	Reduced ocean quality, particle budget
Steam Deck	Vulkan	40-60 fps	30 fps	Medium settings profile, FSR required

Upscaling support: NVIDIA DLSS 3 (frame generation + super resolution), AMD FSR 3, Intel XeSS. All three are integrated at the same level — players select their preferred technology, or the client auto-selects based on detected GPU vendor.

Cross-references: design/10-technical-architecture/performance-optimization.md, design/10-technical-architecture/networking-model.md, design/11-visual-and-audio/rendering-pipeline.md, design/12-ui-ux/hud-design.md