35 lines
1.8 KiB
Markdown
35 lines
1.8 KiB
Markdown
# ADR 0001: Roadmap Architecture
|
|
|
|
## Status
|
|
|
|
Accepted
|
|
|
|
## Context
|
|
|
|
The project is a Bevy FPS foundation with a runtime game, shared authoring data, and an in-process editor. The long-term goal is a server-authoritative multiplayer FPS that can also serve as a reusable Bevy engine/editor toolkit.
|
|
|
|
The architecture needs to keep early editor work productive while avoiding choices that would make later deterministic simulation, networking, and web support expensive.
|
|
|
|
## Decision
|
|
|
|
Keep the current `game`, `shared`, and `editor` crates for M0/M1, but treat them as stepping stones toward a stricter split:
|
|
|
|
- `shared` owns reflectable authoring types and scene hydration until it can be renamed or split into a scene-focused crate.
|
|
- `game` owns native client presentation, player input, rendering, audio, UI, and glue.
|
|
- `editor` owns native editor tooling and editor-only dependencies.
|
|
- Future deterministic gameplay moves out of `game` into a simulation crate that can be reused by the native client, a headless server, and tests.
|
|
- Future network protocol types move into a protocol crate shared by client and server.
|
|
- Runtime app startup/windowing stays narrow and reusable so both the game and editor launch consistently.
|
|
|
|
## Consequences
|
|
|
|
This preserves the current M1 editor velocity while setting boundaries for later milestones. Gameplay code should avoid depending on editor systems, and reusable authoring/simulation code should avoid native-only editor dependencies.
|
|
|
|
The project will add CI and focused local verification now, then expand tests around determinism, scene migration, and networking as those crates appear.
|
|
|
|
## Follow-Ups
|
|
|
|
- M2 extracts deterministic simulation and input-as-intent systems.
|
|
- M3 adds the server-authoritative networking spike and chooses the production netcode stack.
|
|
- M5 formalizes scene schema versioning and migrations.
|