UX/Architecture: evolve Multiverse into franchise packs with adaptive game experiences #90

Owner/current-product reconciliation — 9 October 2026: The new Collections + Home behavior uses one currently selected Home Adventure across the library and global Y / Recent games. Older per-series Home selections and Y-per-pack descriptions below are historical and must not be reintroduced. The active game's Experience Package must encapsulate its additional UI/screens, actions, semantics and presentation; both former fixed Companions/Trainer primary slots receive dynamically resolved labels, faces and content from the selected-game experience (#174–#178). A franchise pack remains a shared grouping/reuse layer inside a composed experience, and exact-build adapters remain narrow semantic/runtime components — no title-specific switch trees in the core shell. A game may belong to several user collections without multiple game experiences. Nonintegrated games retain an honest generic fallback. Old examples like FF/NFS are illustrative, not verified implemented adapters.

Product direction

Pokémon should be understood as the first deeply integrated game-family pack in TrainerOS, not as a permanent special case beside one monolithic "Multiverse".

Over time, large game series should be able to graduate out of the generic Multiverse pool into their own first-class packs, for example:

Pokémon
Final Fantasy
Metal Slug
Need for Speed
Sonic
...

Games that do not belong to a dedicated pack remain available through the generic Multiverse context.

The long-term Home/domain model therefore evolves from:

Pokémon / Multiverse

toward something closer to:

Pokémon / Final Fantasy / Metal Slug / Need for Speed / ... / Multiverse

Each pack can have its own Home presentation, library organization, game-aware faces and deeper integrations while preserving the same TrainerOS shell and controller grammar.

What a pack means

A pack is a first-class TrainerOS game-family/domain grouping.

It is not merely a visual theme and not merely a genre template.

A pack may own:

• its own Home context;
• its own selection/history within that family;
• its own library organization;
• its own secondary faces;
• shared series-specific terminology;
• series-wide presentation components;
• reusable semantic mappings;
• game-specific overrides for individual titles;
• optional social or cross-title features where meaningful.

Examples:

Pokémon pack

Home
Worlds / Adventures
Pokédex
Party
Boxes
Pokémon Center
Playroom
Shops
Journey / Hall / RA

Final Fantasy pack

Possible future structure:

Home
Games / Timeline
Party
Inventory
World / Quests
Bestiary / Collections
Journey

Exact faces depend on the supported games and adapter capabilities.

Need for Speed pack

Possible future structure:

Home
Games
Garage
Events / Career
Cars / Unlocks
Records
Journey

Metal Slug pack

Possible future structure:

Home
Games
Missions
Characters
Collectibles / POW records
Scores / Records
Journey

These examples are conceptual. Do not force identical semantics onto every game in a series.

Multiverse becomes the generic fallback

Multiverse remains useful for:

• standalone games;
• small series without a dedicated pack;
• newly discovered/imported titles;
• games with only generic launch/media/history support;
• games whose deeper experience has not been implemented yet.

A game may later migrate from generic Multiverse presentation into a dedicated franchise pack without losing its stable Adventure identity, history or media.

Do not duplicate ROM/library records merely because presentation ownership changes.

Domain-scoped selection

Do not merge every game in the device into one global Y list.

Each pack keeps its own current selection/context.

Conceptually:

Pokémon current Adventure
Final Fantasy current Adventure
Metal Slug current Adventure
Need for Speed current Adventure
Multiverse current Adventure
...

Y / Choose Adventure remains scoped to the active pack/domain.

Examples:

• in Pokémon → Y shows Pokémon Adventures;
• in Final Fantasy → Y shows Final Fantasy games;
• in Metal Slug → Y shows Metal Slug games;
• in generic Multiverse → Y shows generic Multiverse games.

Switching pack/domain is a separate shell navigation action and does not overwrite another pack's current selection.

Home evolution

Home should switch among available packs/domains rather than remain a fixed Pokémon/Multiverse binary.

The exact control can be finalized after physical testing, but the model should support a cyclic set such as:

Pokémon ↔ Final Fantasy ↔ Metal Slug ↔ Need for Speed ↔ Multiverse

The current #84 L2/R2 secondary-navigation grammar is a natural candidate.

Each pack owns its own Home state.

Returning to Pokémon should restore the selected Pokémon Adventure.

Returning to Final Fantasy should restore the selected Final Fantasy title.

Do not rebuild selection/history from scratch every time the user changes pack.

Library organization

A pack can define a family-appropriate way to browse its games.

Pokémon uses region-first Worlds.

Other packs do not need to imitate that vocabulary.

Examples:

Final Fantasy:

• numbered mainline;
• spin-offs;
• eras/platform groups where useful.

Need for Speed:

• eras/sub-series;
• Underground / Most Wanted / Hot Pursuit / Shift etc. where meaningful.

Metal Slug:

• main series;
• spin-offs / variants.

The stable Adventure/game identity remains independent from how a pack chooses to group it.

Experience composition inside a pack

A pack should not require completely bespoke UI code for every title.

Use layered reuse inside each pack:

Stable TrainerOS shell
        ↓
Pack / franchise experience
        ↓
Genre-oriented reusable components where useful
        ↓
Exact-title override
        ↓
Exact adapter capabilities + data

Genre templates are implementation aids, not the user-visible top-level concept.

For example a Final Fantasy pack may reuse RPG-oriented Party/Inventory/Quest components, while still presenting itself to the user as Final Fantasy, not "RPG Mode".

Adapter-driven data

The game-adapter boundary being audited in #89 supplies verified semantic capabilities and data.

Conceptually:

Exact Game Adapter
  capabilities
  semantic models
  extensions
        ↓
Pack Experience Resolver
        ↓
pack faces / widgets / actions

Possible capability inputs:

PARTY_READ
INVENTORY_READ
MONEY_READ
CURRENT_LOCATION_READ
QUEST_READ
STORY_MILESTONE_READ
CHARACTER_ROSTER_READ
STAGE_PROGRESS_READ
COLLECTIBLES_READ
GARAGE_READ
RACE_PROGRESS_READ
RECORDS_READ
ENTITY_EXPORT
ENTITY_IMPORT

Adapters remain presentation-agnostic.

Do not spread exact title checks through QML.

Deep integrations for popular games

A pack provides reusable series-level structure, but popular individual games should still receive deeper adaptations.

Example:

Final Fantasy pack
  ├── shared Party / Inventory / Journey patterns
  ├── FFVI-specific systems
  ├── FFVII-specific systems
  └── FFX-specific systems

Likewise:

Need for Speed pack
  ├── shared Garage / Career / Records
  ├── Underground-specific systems
  ├── Most Wanted blacklist / bounty
  └── Hot Pursuit-specific systems

Do not flatten unique game mechanics merely to keep one universal UI.

Migration from current Pokémon / Multiverse model

The current two-domain model is the starting point:

Pokémon
Multiverse

The architecture should allow new packs to be introduced without a destructive schema redesign.

Requirements:

• stable Adventure IDs survive reassignment into a pack;
• play history survives;
• exit media survives;
• Trainer ownership survives;
• save lineage survives;
• current generic Multiverse games remain valid;
• a pack can be installed/enabled later and claim only explicitly matched games;
• ambiguous classification requires review rather than silent reassignment.

Pack availability

Do not hard-code an enormous list of empty packs into the shell.

A pack should appear when it is:

• built into the supported product and useful;
• installed/enabled;
• or has at least one owned/supported Adventure according to the chosen product policy.

The UI must remain clean for users who only have Pokémon plus a few generic games.

Relationship to #83–#89

• UX: turn Pokémon into an L2/R2 section with first-class Dex, Party, Boxes, Center, Playroom and Shops views #83 defines the current Pokémon pack's deeper face layout.
• UX: make L2/R2 the consistent secondary-navigation rule on Home and Worlds #84 supplies the secondary-navigation grammar and should evolve from the current binary Home model to multiple pack contexts.
• UX: preserve Journey, Hall and RetroAchievements as peer faces inside the combined Trainer tab #85 keeps Journey as a reusable major concept where a pack can supply meaningful content.
• UX: make A launch the selected game immediately in both Pokémon Worlds and Multiverse #87 owns immediate A-to-launch behavior in game wheels.
• UX: simplify Back semantics and declutter controller hints #88 owns Back/hint consistency.
• Architecture: audit and strengthen game adapter encapsulation #89 owns the portable game-adapter / semantic boundary.

This issue owns the pack/domain layer between the generic TrainerOS shell and exact game adapters.

Relationship to external adapter tooling

Projects such as ELIGEN are exploring game adapters, save semantics, reverse engineering and technical/modding workflows.

TrainerOS must not depend on ELIGEN.

However, a portable semantic adapter boundary from #89 could allow external tools to create or validate game knowledge that TrainerOS later presents through Pokémon, Final Fantasy, NFS, Metal Slug or other packs.

Initial proof

A convincing first proof beyond Pokémon should include:

1. one dedicated non-Pokémon franchise pack with multiple games;
2. at least two titles in that pack sharing reusable presentation/semantic components;
3. at least one title-specific override proving unique mechanics are still possible;
4. generic Multiverse fallback remaining functional for everything else.

A series such as Final Fantasy, Metal Slug, Need for Speed or Sonic can be chosen later based on adapter readiness.

Deliverable

Define and prototype:

• pack/domain registry;
• per-pack current Adventure selection;
• Home pack switching;
• pack-specific library grouping;
• pack experience resolver;
• reusable genre-oriented presentation components;
• title-specific override mechanism;
• capability → face/widget/action mapping;
• generic Multiverse fallback;
• migration path from the current Pokémon/Multiverse binary model.

Keep pack presentation separate from executable game-adapter code.

Acceptance

• Pokémon is represented as the first first-class pack/domain rather than a permanent hard-coded exception.
• TrainerOS can add a second franchise pack without rewriting the shell.
• Home can support more than the current Pokémon/Multiverse binary context.
• each pack retains its own current Adventure and navigation state.
• Y remains scoped to the active pack and never becomes one mixed all-games chooser.
• games without a dedicated pack continue to work through Multiverse.
• moving a game into a newly available pack preserves stable identity/history/save lineage.
• pack UI uses adapter capabilities rather than filename/title conditionals.
• franchise-level reuse and exact-title specialization can coexist.
• the shell/controller grammar remains stable across all packs.