96 lines
10 KiB
Markdown
96 lines
10 KiB
Markdown
# Reference Experience Mapping
|
|
|
|
Date: 2026-08-11
|
|
Status: `PHASE5_REFERENCE_FIDELITY_CANDIDATE`
|
|
|
|
## Purpose
|
|
|
|
This document maps directly observed functional structures from authorized
|
|
public-video research into Aetherbound Guild's original product. It is not a
|
|
commercial screen catalog and contains no copied screenshots, names, prose,
|
|
formulas, art, audio, code, or extracted assets.
|
|
|
|
The mapping answers four questions for every important player surface:
|
|
|
|
1. What layout and operation were directly observed?
|
|
2. Why did that structure help the player make a decision?
|
|
3. What does Aetherbound adopt or improve?
|
|
4. Which expressive or product-specific parts remain rejected?
|
|
|
|
Evidence classes retain their research meaning: `PROVEN`, `PROVEN_UI_ONLY`,
|
|
`LOWER_BOUND`, and `UNKNOWN`. An observed layout never proves an unseen rule.
|
|
|
|
## Product Decision
|
|
|
|
Aetherbound may learn functional information architecture, option grouping,
|
|
interaction sequence, visible state, comparison density, and feedback timing.
|
|
It does not reproduce the reference game's ornament, exact geometry, wording,
|
|
content identities, formulas, radial graph, or commercial media.
|
|
|
|
The strongest adopted composition is:
|
|
|
|
```text
|
|
persistent run/status strip
|
|
-> visible Company bench
|
|
-> three comparable Market or encounter choices
|
|
-> visible run inventory and mode actions
|
|
-> one primary commitment
|
|
```
|
|
|
|
The player should not need to leave the Market merely to remember Company size,
|
|
available inventory, current Coin, refresh cost, lock state, or what changed.
|
|
|
|
## Fifteen-Surface Mapping
|
|
|
|
| ID | Observed surface and evidence | Functional layout and visible options | Why it works | Aetherbound adoption | Deliberate change or rejection | Target |
|
|
|---|---|---|---|---|---|---|
|
|
| `REF-01` | Title and run entry; `PROVEN` across Phase 3 terminal returns and versioned titles | Stable title, current version/state, obvious new/continue path, secondary system entries at edges | Separates run action from persistent preparation | Title keeps Continue, New Run, Records, Settings, and save health in one first viewport | Original guild threshold art and hierarchy; no copied title treatment | `SYS-003`, `SYS-004` |
|
|
| `REF-02` | Difficulty and run setup; `PROVEN` for three described difficulties and mobile setup | Few large mode/difficulty choices, concise consequences, one commit | Makes failure policy visible before investment | Contract, difficulty, slot, and four stable provisional Recruit offers are reviewed before atomic Run creation | No clan names, copied difficulty prose, or hidden permanent-death switch | `SYS-005`, `PST-002` |
|
|
| `REF-03` | Mobile Shop/Hall; `PROVEN` continuous tutorial and late-run states | Company bench above, three offer cards centered, inventory grid below, tools on edges, currency and victories persistent | Keeps purchase context visible and makes comparison fast | Market shows Company, three Recruit offers, inventory, Coin, Credit, refresh, lock, selling mode, and the next risk route together | Original parchment-workshop composition; no copied frame, symbols, or exact dimensions | `SHP-001` |
|
|
| `REF-04` | Recruit offer and inspection; `PROVEN` tutorial purchase and multiple profession/tooltips | Large offer card, price, role/stat read, inspect before buy, Company slot context | Turns hiring into valuation rather than a blind button | Generated identity, Profession, Trait benefit/cost, behavior read, price, fit and Company delta precede hire confirmation | No fixed commercial character identity or relationship content | `SHP-002`, `REC-002` |
|
|
| `REF-05` | Inventory, equipment and selling; `PROVEN` Tap inventory placement, selling mode and visible capacity | Persistent slot grid, equipped/unequipped distinction, explicit selling mode, focused tooltip | Reduces navigation and prevents accidental destructive input | Eligible inventory, before/after behavior delta, target Recruit, reversible apply, separate sell review and capacity read | Equipment changes behavior; no copied item list, rarity palette, or exact sell values | `SHP-003`, `EQP-001`, `EQP-002` |
|
|
| `REF-06` | Ordered party surface; `PROVEN` Tap pickup/swap and late ten-member bench | One ordered horizontal Company row, stable slot positions, direct swap, equipment visible near each unit | Makes formation the central build expression | Tap Recruit then Tap destination is primary; drag optional; protected rear remains left and exposed front right | No named formation cards required for basic ordering and no mirrored locale layout | `PTY-001`, `PTY-002` |
|
|
| `REF-07` | Three-card encounter choice; `PROVEN` early and late runs | Three adjacent choices expose enemy composition, bounty/reward and entry result before battle | Creates a repeated risk/reward comparison with low navigation cost | Three battle offers show threat, reward class, retreat consequence, current coverage and frozen Company order | No copied enemy names, bounty formula or mystery card backs | `RSK-001`, `RSK-002` |
|
|
| `REF-08` | Automatic horizontal battle; `PROVEN` ordinary, ten-member and boss battles | Enemy and Company occupy one landscape arena; health/status remain near units; battle fills the visual center | Lets preparation become a readable spectacle | One ordered Company line, automatic actions/ultimates, clear objective, forecast, position and no-respawn rule | No manual attack/ultimate controls and no copied actor or HUD art | `BAT-001`, `BAT-002` |
|
|
| `REF-09` | Battle observation controls; `PROVEN` pause, speed, camera and retreat boundary | Small persistent controls around the arena without replacing combat focus | Supports diagnosis and pacing while preserving automation | Pause, `1x/2x/4x`, inspect, event log and retreat review remain available; event cause can be pinned | No pointer-only shortcuts or hidden manual targeting | `BAT-003..BAT-006` |
|
|
| `REF-10` | Victory report and reward; `PROVEN` ordinary/boss reports | Outcome appears immediately, unit rows and rewards remain visible, then returns to preparation | Connects battle result to the next build decision | First meaningful divergence precedes totals; losses, returned equipment, fixed reward choices and next Market are explicit | No copied report decoration, reward formula or item identities | `OUT-001..OUT-004` |
|
|
| `REF-11` | Game Over and persistent handoff; `PROVEN` at multiple run terminals | Full-party terminal report, accumulated victories/reward, direct route to persistent spending/title | Failure still advances understanding and long-term breadth | Run summary names exact closure cause, retained Records/Renown, cleared Coin/Credit and legal next actions | No same-battle resurrection claim and no victory-count farming requirement | `OUT-005`, `SYS-003` |
|
|
| `REF-12` | Rune Circle transaction; `PROVEN` point debit/path illumination, other persistence operations `UNKNOWN` | Persistent currency header, connected prerequisite paths, selectable node preview, visible cost and unlock boundary | Makes long-term planning spatial and shows progress immediately | Guild Charter uses eight horizontal Region seals, exact prerequisites, cost, future-run effect and breadth-only receipt | No radial graph, copied nodes, raw power, refund/import claims or reference formulas | `PRO-002` |
|
|
| `REF-13` | Forge, storage and veteran operation; `LOWER_BOUND` with one completed consumptive operation | Recipe browser or operation modal over visible inventory/storage; ingredients, target and result reviewed before commit | Keeps production transaction grounded in owned items | Equipment Workbench and Artifact Ledger keep source items, target, behavior delta, conflict and receipt visible | No separate crafting economy until a vertical slice proves it changes decisions; no copied recipes or probabilities | `EQP-001`, `ART-001` |
|
|
| `REF-14` | Tavern retirement/experience recovery; `PROVEN_UI_ONLY` | Separate between-run surface explains retirement value and redistribution but execution was not observed | Offers a closure sink for veteran value | Generated Company is archived into Records; Guild breadth and Oath eligibility persist without playable Recruit carryover | No retirement XP conversion, irreversible operation, equipment disposal or save claim until independently designed | `PRO-003`, `PST-001` |
|
|
| `REF-15` | Raid, final boss and continue/retire modal; `PROVEN` final victory and explicit choice | Boss preview precedes a large automatic fight; report and two clear post-victory paths follow | Gives the long run a visible target and respects completion/continuation motives | Sixteenth boss settles first, then Complete the First Chronicle or Open the Oath Season; both archive Company, ordinary New Run remains | No copied Raid page, boss identity, special reward, endless current-Company continuation or retirement wording | `RSK-002`, `BAT-002`, `PST-001..003` |
|
|
|
|
## Cross-Surface Option Inventory
|
|
|
|
The following observed option families are valid structural inputs:
|
|
|
|
- New Run, Continue, difficulty, mode/law review and safe return;
|
|
- recruit, inspect, compare, buy, refresh, lock and selling mode;
|
|
- inventory placement, equipment apply, storage inspection and transaction
|
|
review;
|
|
- Tap pickup, Tap destination, optional drag and stable position labels;
|
|
- encounter comparison, battle start, pause, speed, inspect and retreat;
|
|
- result acknowledgement, reward choice, recovery, Game Over and next run;
|
|
- persistent-path inspect, cost preview, prerequisite preview and claim;
|
|
- boss preview, final victory, finite completion and continued mastery.
|
|
|
|
Every adopted option must bind to an Aetherbound transaction and state. A
|
|
button is rejected if it merely resembles the reference UI or duplicates an
|
|
existing action without changing player choice.
|
|
|
|
## Layout Acceptance
|
|
|
|
The HTML reference map must show all 15 rows without embedding commercial
|
|
media. `REF-03`, `REF-07`, `REF-08`, `REF-12`, and `REF-15` require distinct
|
|
neutral wireframes plus the actual Aetherbound target composition. Desktop and
|
|
phone layouts must keep both the observed structure and the original adaptation
|
|
fully inspectable.
|
|
|
|
Owner review should answer:
|
|
|
|
1. Does the Aetherbound Market now preserve enough Company and inventory context?
|
|
2. Are three offers comparable without opening three separate pages?
|
|
3. Does the battle still read as the payoff of preparation?
|
|
4. Is the Guild Charter understandable despite rejecting the radial layout?
|
|
5. Does the final choice preserve the motivation of continue versus finish?
|