Fighting Game · Guides & deep dives

Difficulty Analytics

Rendered UI should lead with encounter rows sorted by loss rate and retry rate, then show compact win/loss, retry, and time-to-complete charts.

2sections1 minread

On this page

Phase 72.5.2.7 adds @v2/difficulty-analytics, the operational difficulty surface for per-encounter win/loss rates, retry counts, time-to-complete, and difficulty spike detection. The policy is v2-difficulty-analytics-v1.

buildV2DifficultyAnalyticsSurface composes @iris/analytics-realtime for spike alert snapshots and aggregates V2 encounter telemetry for started, completed, failed, retry, and abandoned events. It emits chart-ready win/loss rates, retry counts, completion-time percentiles, and spike rows when an encounter crosses loss-rate, retry-rate, or p95 completion-time thresholds.

The service consumes accountIdHash only for player-scoped encounter events. The surface exposes aggregate values only and does not expose raw account IDs.

Operator Surface#

Rendered UI should lead with encounter rows sorted by loss rate and retry rate, then show compact win/loss, retry, and time-to-complete charts. Difficulty spike rows should show the triggering metric, observed value, threshold, sample size, and difficulty tier.

The first screen should make it clear which encounters are blocking progress, which encounters are producing repeated retries, and which completions are taking longer than the p95 threshold. Avoid marketing copy and show empty states when encounter telemetry has not arrived.

Verification#

Targeted verification:

bash
pnpm --filter @v2/difficulty-analytics run typecheck
pnpm --filter @v2/difficulty-analytics run test
python V2/ue/Tools/check-v2-difficulty-analytics.py
python -m json.tool V2/ue/Build/Telemetry/v2-difficulty-analytics.json