// Patterns

What Traced looks like in real teams.

Traced is intentionally engine-agnostic about what kind of 3D app you're building. Here's how four different team types use it.

For game studios

Multiplayer shooters, VR arena games, anything with combat in a contested space. The questions that matter:

  • Where do players die? → fire death events on respawn. Death Heatmap exposes choke points and bad sightlines.
  • Where are kills happening? → fire kill events from the shooter. Compared to deaths, kill clusters reveal advantageous positions.
  • What weapons dominate at each position? → metadata { "weapon": "sniper" } on every death. The recent-events table filter shows weapon distribution by area.
  • Did our rebalance work? → segment by build_version in session context. Compare arena_01 v1.3 vs v1.4.
  • Are we spawn-camping? → fire both spawn and kill. Density overlay of the two shows kill clusters near spawn points.

For VR / AR training simulations

Procedural training (factory floor, surgery, fire response), assessment scenarios, compliance walkthroughs. The questions that matter:

  • What do trainees actually look at? → fire sight_check frustum events tied to head transform. View cones in the dashboard show where attention pooled.
  • Where do they freeze? → fire area_entered + area_exited and emit a stuck point if dwell time exceeds a threshold.
  • Did they touch the hazard? → TrackVolume on every hazard interaction, with metadata { "severity": "critical" }.
  • Did they take the right path? → continuous TrackPosition + Path Flow visualization. Outliers from the intended route are immediately visible.
  • Compliance retention? → Studio tier offers custom retention windows. Per-trainee data can be exported via the API for archival.

For level designers

Sole purpose: validate your level geometry against what players actually do. Run an internal playtest:

  • Wire death, damage_dealt, pickup, area_entered at minimum.
  • Set build_version + map in session context so you can compare iterations.
  • Run a 10-player session for an hour.
  • Open Death Heatmap. Walk the level and ask: were those clusters intentional? If not, why are players ending up there?
  • Compare against the level's intended flow — are players using the path you designed, or finding an unintended shortcut?

For QA and playtesting teams

Catch bugs that depend on where something happened:

  • Repro a clip-through bug → fire clipped_through_geometry events from your collision detection. The cluster pinpoints the geometry seam.
  • Track NPC stuck-in-wall reports → AI controller fires npc_stuck with the NPC position. Repeat-offender locations cluster.
  • Identify performance hotspots → fire perf_drop events when frame time exceeds a threshold; correlate with player position.
  • Measure tutorial completion rates → fire tutorial_step_n at each tutorial milestone. The Pickup Distribution template (or rather, any density report on these events) shows which steps players actually finish.

Beyond games

Traced runs on Unity coordinates. Any Unity-based product with a 3D scene can use it — VR fitness, location-based entertainment, architectural visualization with user tours, museum AR experiences. If your users move through 3D space and you want to know where, fire events and we'll cluster them.

Not a fit (yet)

  • Non-Unity engines — Unreal, Godot, custom engines need their own SDK. On the roadmap; not built.
  • Web-only games (Three.js / Babylon.js) — the wire format is engine-agnostic, but no client SDK ships for these yet.
  • 2D-only games (top-down RPGs, side-scrollers) — you can fire 2D positions as (x, 0, z) but you'll be paying for 3D rendering that doesn't earn its keep.

Want to discuss a specific use case? Email hello@traced.gg or join the beta.