# Storm Generations competitive wiki and analytics platform

Implementation plan · 9 September 2026 · Proposed product name: **Generations Competitive**

## 1. Product goal

Build the place a player opens to answer: **What should I do in this situation, why should it work, and how can I practice it?** Connect that reference to match review, community results and reproducible evidence as those capabilities become available.

The player journey is:

**Choose my character → learn a useful action → understand its risks → study a matchup → practice a response → review a match → revise my plan.**

A professional wiki must translate data into decisions. Put readable character names, inputs, action demonstrations and supported explanations first. Make the underlying sources one click away. Do not use file counts, hex dumps or unresolved fields as the homepage’s main attraction.

This document specifies the target product and implementation work. It does not claim that proposed gameplay measurements, replay capture, public accounts or rankings already exist.

## 2. LuckyStats benchmark: adopt the connected experience

The public [LuckyStats homepage](https://luckystats.gg/) was inspected in a browser. It provides player search, navigation among players/ranks/tournaments/stats/tools, regional communities, recent analyzed sets with watch links, activity summaries and event discovery. Its public [Stats page](https://luckystats.gg/stats) shows recent analyzed tournaments, examples of gameplay-derived metrics, rating distributions and data freshness. Some advanced analytics are login-gated and were not assessed. The [replay discovery route](https://luckystats.gg/replays) exposed event links and pagination, but its full interaction and playback were not verified in this audit.

Direct text retrieval of the homepage returned HTTP 403; the observations above came from the rendered public pages. No account was created, files uploaded or paid features tested. These observations establish visible product patterns, not LuckyStats’s internal architecture or the correctness of every statistic.

| Observed pattern | Generations implementation | Prerequisite |
|---|---|---|
| Shared navigation and player search | One search across characters, moves, mechanics, players and events; results labeled by type | Stable identities and indexed content |
| Recent analyzed sets with watch links | Match page linking video/trace moments to the relevant move and matchup article | Match records first; reliable trace/video alignment later |
| Ratings and tournament context | Player profiles, event history and head-to-head results with source and ruleset | Deduplicated, reviewed match results |
| Gameplay statistics | Resource use, punish conversions and defensive responses with definitions | Validated telemetry and event classification |
| Regional communities | Community directory and organizer-managed events | Community participation and moderation |
| Freshness and activity summaries | Build compatibility, last review date and newly validated findings | Versioned publication history |

Complement this with a wiki layer for move data, character strategy and mechanics. LuckyStats is a reference for the connected analytics experience; it is not evidence for Storm damage, timing or mechanics. [Project Slippi](https://github.com/project-slippi/project-slippi) also illustrates the value of separating recorded gameplay from the library that computes statistics. Storm requires its own validated capture format.

## 3. Honest starting point

The current installation audit and exports provide:

- 1,548 authored command records and 184 internal groups. These are not a confirmed playable-roster count.
- 1,813 skill nodes, 48,762 literal attributes and 58 attribute names from 542 selected assets.
- 2,756 named non-END skill slots; 13,182 slot records when blank/END entries are retained.
- 678 damage-identifier spans with source bytes and offsets; no validated numeric damage schema.
- A historical Naruto ranged-action pilot: three candidate-health decreases near 0.6 on an observed 100-point scale. Guard, authoritative units and action mapping remain unresolved.
- Searchable HTML, portable SQLite/JSON/CSV exports and provenance checks.
- No verified canonical damage values, frame timings, reconciled roster, production replay recorder or match-results corpus.

The supplied build45 folder was rechecked for C/C++ source, headers, project files and PDBs; none were found. Source access may accelerate investigation, but runtime measurement and binary analysis remain possible. Instrumentation work must have its own feasibility gate rather than a promised completion date.

References: [database summary](competitive-data-summary.json), [source inventory](competitive-source-access.json), [pilot](health-pilot.html), [current research browser](competitive.html).

## 4. Player-facing information architecture

Primary navigation: **Characters · Moves · Matchups · Learn · Practice · Matches**. Put **Players, Events and Rankings** under a clearly labeled Competition area when those datasets exist. Put **Research, Downloads, Methodology and Contribute** in secondary navigation. Unavailable capabilities get an explanatory status page, not a dashboard filled with example numbers.

### Homepage

Lead with “Find your character. Learn the matchup. Improve your next match.” Provide a character/move search, character directory, Getting Started path, practice entry point and recent reviewed changes. Keep build/ruleset selection visible. Show coverage as a small link, not a substitute for player content.

Suggested layout:

```text
Generations Competitive       Search                      Build / ruleset
Characters | Moves | Matchups | Learn | Practice | Matches

Find your next improvement.
[Choose a character] [Learn the basics] [Review a match]

Character directory                Start here
Readable names + confirmed forms    Inputs • resources • defense

Recently reviewed findings         Practice this week
What changed, applicable build      A supported drill with clear goals

Community competition              Research & data
Real events/results when available Coverage, sources, contributions
```

### Character page

Header: official localized name, exact variant/form, portrait only after identity mapping, build compatibility and reviewed date. Tabs: **Overview, Moves, Combos, Matchups, Practice, Results**.

Overview sections: how the character works, a starter game plan, supported strengths/limitations, useful actions and common mistakes. Each recommendation must identify its basis: measured interaction, reviewed strategy or an explicitly proposed drill. Unreviewed archetype or tier claims do not become facts through editorial phrasing.

Move tables show input, action name, verified damage, startup, recovery/advantage where established, cost and context. Default to useful, applicable columns; unavailable values read “Not measured.” Support an optional complete-field view. Cosmetic and mechanical variants must not be merged without evidence.

### Move page

Permanent identity independent of translated names. Present:

1. Name, character/form and input with a selectable controller notation.
2. A demonstration when a suitable capture exists; clearly distinguish video from simulation-synchronized playback.
3. Measured facts with units, range/conditions and evidence status.
4. “When to use it” and “How to respond,” with supported situations and known failure cases.
5. Branches, follow-ups and cancel routes; authored sequence versus escape-tested combo labels.
6. Test conditions and evidence drawer, source links and revision history.

For Naruto’s normal ranged throw today, this page can show the observed input and link the provisional pilot. Its damage card must remain “Not validated,” with the candidate-field observation explained separately. It must not display 0.6 as verified move damage.

### Matchup page

Store ordered character/form pairs. Organize by practical situations: round start, approaching, projectile interaction, pressure/defense, resource advantage, awakening and closing a round—only where those systems are confirmed for this build. Each interaction card gives setup, player options, counterplay, evidence and a practice link.

Keep three panels distinct: tested interactions, reviewed strategy, and observed match results. A matchup win rate does not prove a mechanical advantage, especially in a small community.

### Practice page

Each drill has prerequisites, exact setup, input sequence, expected observation, common failure, success criterion and evidence. Save attempts locally initially, including failures. Add example captures and import/export. Do not call manual logs automated analysis or guaranteed training-state playback.

### Match and player pages

Start with reviewed results and video timestamps. Later add synchronized events, resources and actionable-state timelines from validated traces. A player profile should answer “Who have I played, what is improving, and what should I practice?” before adding leaderboards.

## 5. Visual and usability specification

- Use a restrained dark/light theme, one accent color and clear typography. Character imagery supports recognition; large decorative images must not push useful controls below the fold.
- Use familiar action names and configurable input icons with accessible text. Always retain the original authored input in evidence.
- Use sentence-level explanations before technical tables. Provide glossary tooltips without requiring hover on mobile.
- Put evidence labels next to individual claims. A single page-level badge must not imply every field is validated.
- Keep global build/ruleset filters across navigation. Make incompatible comparisons explicit and offer a deliberate comparison mode.
- Support bookmarks, shareable filtered URLs, browser Back/Forward, keyboard search and printable move/drill pages.
- Use pagination or virtualized tables. Do not ship the whole raw attribute dump on every player page; load research data on demand.
- On phones, prioritize action/input, use case and key measured facts. Source tables may scroll inside their own containers; the page must not overflow.
- Provide accessible contrast, focus indicators, labels, reduced motion, captions/transcripts for teaching clips, and no status conveyed by color alone.

Design acceptance: a newcomer can find a named move and understand its input without an internal ID; a competitor can determine a claim’s build and conditions; a researcher can reach the exact source. Test these as user tasks, not just screenshot comparisons.

## 6. Data and evidence model

Preserve the raw extraction as an immutable evidence layer. Add a normalized publication layer rather than overwriting source fields with editorial interpretations.

| Entity | Required responsibilities |
|---|---|
| Build / ruleset | Executable hash, asset hashes, patch identity, effective settings and supported configuration |
| Character / variant / form | Display identity, selection-screen evidence, runtime mapping, relationships and unresolved aliases |
| Action / hit / branch | Stable IDs, authored references, runtime identity when validated, individual events and transitions |
| Metric observation | Value or interval, unit, counting convention, conditions, repetitions, precision and evidence |
| Published metric | Reviewed derivation, applicable action/build/context, source observations and revision |
| Strategy claim / interaction | Situation, recommendation, caveats, reviewer and supporting evidence |
| Drill / attempt | Setup, expected behavior, observed outcome, failure reason and capture |
| Player / event / set / game | Stable identity, source, ruleset, result, timestamps, corrections and deduplication |
| Trace / event / derived statistic | Capture schema, parser version, event identity, derivation version and fidelity |
| Contribution / review | Author, proposed change, evidence, discussion, decision and audit trail |

One scalar damage column is insufficient: damage can vary by hit, branch, target, guard, scaling, form and options. Likewise, startup, cancel eligibility, cinematic release and freely actionable time require separate definitions. Null means unknown; zero requires evidence; not-applicable is a separate state.

Use the requested evidence vocabulary: **Verified, Extracted, Measured, Estimated, Unknown**. Track review state separately: draft, submitted, reviewed, disputed, superseded. A measured candidate field is not a verified damage metric. Display confidence as explicit limitations and precision, not an unexplained percentage.

Every published number must resolve through `published metric → derivation → observations → source/capture hashes → build + conditions`. Revisions retain old values and show why they changed. Conflicting measurements are retained for review instead of silently averaged.

## 7. Measurement and replay prerequisites

### Damage and timing pilot

1. Start a fresh isolated run with process identity and effective configuration recorded.
2. Recalibrate health/resource fields through controlled interventions; independently establish attacker/defender mapping and units.
3. Capture exact fighter variants, normal/awakened state, stage, range, guard/COM settings, resources and refill behavior.
4. Collect idle controls and at least three repeat trials per pilot condition; increase repetitions when variation appears. Three repeats are an initial repeatability check, not broad statistical proof.
5. Establish a simulation update counter and accepted-input, collision and actionable-state boundaries. Declare indexing, inclusive/exclusive endpoints and treatment of hitstop.
6. Compare a second action and independently corroborate representative results. Keep health mirrors, render counters and wall-clock sampling distinct from authoritative gameplay events.
7. Validate representative ground, projectile, puppet and transformation cases before expanding across the roster. Confirm applicability instead of assigning every character every action type.

### Capture contract

Use a versioned Storm-specific trace format. Record a header with build/settings/schema hashes and per-event sequence numbers. Where observed, include simulation update, actor/form IDs, input acceptance, action changes, position, collision, health/resource changes and actionable states. Unknown event types and missing intervals must remain visible.

Handle resets, scene changes, actor reuse, dropped samples, truncated files and duplicate uploads. If the runtime resimulates updates, distinguish speculative events from committed outcomes; first establish whether that applies to this port. Check capture overhead with matched trace-on/off trials.

A telemetry trace is not necessarily a replay. Label playback fidelity explicitly: video review, event timeline, state visualization, or deterministic replay. Do not promise reconstruction, savestates or input playback until validated.

## 8. Competitive statistics and tier-list policy

Implement only metrics with a documented numerator, denominator, eligibility rule and event definition:

| Metric | Proposed calculation | Required qualification |
|---|---|---|
| Damage per successful opening | Net attributable health loss / eligible openings | Define opening/reset boundaries; separate healing and unrelated damage |
| Conversion success | Eligible openings reaching a defined outcome / eligible openings | Publish outcome rule; do not assume every sequence is a true combo |
| Resource efficiency | Attributable damage / net resource spent | Handle zero cost separately; never turn a divide-by-zero into a ranking |
| Punish success | Successful punish attempts / identified punish attempts | Distinguish an attempted punish from merely having an opportunity |
| Defensive response | Outcomes by observed guard/substitution/etc. option | Only include systems validated for the build; timing and resources matter |
| Matchup results | Wins / eligible completed games | Show game count, distinct players, events, date range and uncertainty |
| Practice consistency | Successful attempts / all eligible attempts | Preserve failures and setup differences |

For rankings, begin with reviewed result history. Evaluate a rating method on held-out results before public release; version its rules and show provisional status, inactivity handling and uncertainty. Keep online/offline and materially different rulesets separate. Exclude forfeits/disconnects according to a public policy.

Do not equate player rating with character strength. For matchup estimates, account for player skill, repeated players, stage, patch and selection bias; publish unadjusted and adjusted estimates separately when the model is validated. Establish minimum-publication thresholds from actual data coverage and uncertainty, not an arbitrary promise now.

Tier-list pages should be dated, build-specific editorial assessments with supporting matchup evidence, counterarguments and author/reviewer attribution. Sparse data produces “insufficient evidence,” not an automatic S/A/B label. Raw radius, script duration and damage alone cannot generate a defensible tier list.

## 9. Technical delivery and migration

Keep the working local guide available throughout migration. Proposed boundaries:

```text
Installed build → read-only extractors → immutable evidence + hashes
Controlled tests / future recorder → validated observations and traces
Reviewed content + metric derivations → publication database
Publication database → character/move/wiki pages and search
Reviewed results + validated traces → versioned analytics jobs
All layers → portable exports + documented read API
```

Reuse Python extraction/validation and the existing SQLite export. Separate the player UI from the raw browser. Introduce shared page components and route-aware state; generate small character/action payloads for an offline first release. Add a server relational database, object storage and background processing only when shared contributions/results/trace uploads require them. Choose hosting and runtime versions at implementation time after checking current support and requirements.

Proposed routes: `/characters/:variant`, `/moves/:action`, `/matchups/:left/:right`, `/mechanics/:slug`, `/practice/:drill`, `/matches/:game`, `/players/:player`, `/events/:event`, `/research`, `/changes`. Preserve current `guide.html` hash links with an alias map. IDs must not depend on page titles.

Uploads eventually need explicit visibility controls, file limits, isolated parsing, checksums, deduplication, deletion policy and participant-data handling. Local research files do not become public automatically. Public corrections require moderation, revision history and rollback. Back up content and evidence separately and exercise restore before launch.

## 10. Ordered implementation milestones

Each milestone has a demonstrable exit condition. Work estimates should be made after its prerequisites are satisfied; gameplay reverse engineering has substantial uncertainty.

| Order | Deliverable | Main work | Exit condition |
|---|---|---|---|
| M0 | Publication foundation | Freeze existing exports, schema, identity/evidence rules and migration map | Rebuild retains all source records; null/zero/not-applicable are tested; current links still work |
| M1 | Player-first wiki shell | Homepage, search, character directory, move layout, glossary, mobile/accessibility | Find character → move → evidence without internal IDs; no unmeasured claim is promoted |
| M2 | Roster and action reconciliation | Select-screen audit, variant/form mapping, standard/basic actions, coverage denominator | Every observed selection has an identity record; unresolved entries remain separate |
| M3 | Validated combat pilot | Health/units, clock, action mapping, guard/range conditions, repeatable controls | Representative damage and timing claims pass independent checks and retain raw evidence |
| M4 | Character and counterplay release | Populate measured moves, reviewed strategy, interactions and drills | Each released guide has useful supported advice, known limits and reproducible practice |
| M5 | Community evidence workflow | Submission templates, review queue, corrections, revision history and exports | A contributor can submit evidence; a reviewer can accept/reject; rollback preserves history |
| M6 | Match-results foundation | Player/event identities, reviewed imports, deduplication and disputes | Results reconcile against their sources; game/set/forfeit distinctions are preserved |
| M7 | Trace and match review | Recorder feasibility, parser, event timeline, video alignment and fidelity labels | A real match can be inspected reproducibly; missing data and capture overhead are reported |
| M8 | Competitive analytics | Validated metric definitions, cohort filters, player review and matchup summaries | Every statistic can be recomputed from exported eligible events; uncertainty and sample counts visible |
| M9 | Rankings and community launch | Rating validation, editorial tier framework, organizer tools, operations | Rating policy reviewed; unsupported rankings suppressed; backup/restore and moderation tested |

Dependencies: M0 precedes M1/M2. M2 plus the measurement foundation enables M3; M3 supplies M4. M5 can follow M1 while measurement proceeds. M6 can proceed independently of frame-data extraction. M7 depends on validated capture, not just a polished match page. M8 requires M6/M7 evidence appropriate to each statistic. M9 ratings need sufficient result coverage; trace-dependent features must not block the wiki’s earlier release.

Role ownership: product/editor owns player usefulness; gameplay researcher owns mapping/measurements; data engineer owns provenance/parsers; frontend owns navigation/accessibility; reviewer owns publication quality; community moderator owns disputes; operator owns deployment/restore. These are responsibilities, not an instruction to create accounts or recruit people.

## 11. First implementation slice

Build M0/M1 as a local player-facing preview while advancing the M3 feasibility investigation:

1. Snapshot current data, record hashes and establish schema/versioned identity adapters.
2. Build the homepage and character directory using extracted names with unresolved-form labels.
3. Implement one complete move-page template with inputs, conditions, practical explanation, evidence and related drills.
4. Populate representative pages using available evidence; do not fill numerical cards with invented examples.
5. Move the raw database browser into Research and retain all downloads.
6. Add global search, aliases, shareable URLs, build context and accessible mobile navigation.
7. Run guided tasks with beginner and experienced players; record confusion and revise labels/layout.
8. In parallel as a workstream, establish the fresh isolated measurement pilot. Publish numerical upgrades only when that evidence passes.

The first slice is complete when a player can find an action, understand the input, distinguish tested advice from an untested hypothesis, and reach a useful practice setup. It is not complete merely because the page looks finished.

## 12. Release gates and success measures

- **Accuracy:** every published numeric combat claim has units, context, evidence and reviewer state; no unexplained mix of builds or timing conventions.
- **Coverage:** show reconciled expected actions versus reviewed actions per variant/category. Preserve unsupported/system groups without counting them as playable characters.
- **Usability:** users complete character lookup, move comparison, source inspection and drill setup without assistance. Record task success and time before setting improvement targets.
- **Performance:** benchmark representative low-end/mobile devices; keep player pages independent of the full raw dataset; test worst-case searches and long evidence lists.
- **Accessibility:** keyboard-only completion, meaningful focus order, contrast, input labels and readable 200% zoom; inspect desktop and narrow screens.
- **Reproducibility:** sample published metrics can be recomputed from retained observations; parser/derivation changes trigger affected-data review.
- **Analytics:** deduplication, partial matches, missing telemetry, player identity changes and ruleset differences have tested behavior.
- **Operations:** export/import, backups, restore, contributor review and correction rollback work before public launch.

Track measured action coverage, reviewed-guide coverage, user task success, drill completion, correction turnaround, provenance completeness and repeatable match-review usage. Avoid raw extraction volume as the primary player-success metric.

The objective is a trusted competitive reference that grows into analytics. Useful guidance, reliable measurements and community evidence must advance together.