Private · playable pre-release · Deterministic simulation

FireOne

A submarine tactics game about uncertainty, geometry and commitment—where the interesting problem is deciding when the evidence is good enough to act.

Niche
Information-constrained tactical simulation
Core stack
Rust · Bevy ECS · Ratatui
Architecture
Authoritative deterministic simulation
Target
Native tactical command-station client

The niche

FireOne is not trying to reproduce a submarine visually. It is trying to reproduce the decision problem of submarine combat.

The player listens, classifies uncertain contacts, changes geometry, chooses when to reveal themselves with active sensing, commits a weapon, and survives the consequences. The product niche is tactical simulation where information itself is a scarce resource.

What is different

The distinction between world truth and observed truth is enforced by architecture, not role-play.

Epistemic boundaries

Players, AI and presentation layers consume observations rather than hidden transforms or omniscient state.

Deterministic outcomes

A fixed seed, scenario and command history are intended to reproduce the same authoritative simulation for replay, testing and balance work.

Replaceable presentation

The terminal UI is a client of the simulation, not the game’s source of truth; the native Bevy client is designed to consume the same safe projection.

AI under the same uncertainty

The intended opponent reasons from allowed observations rather than receiving privileged access to the world.

Product & design thinking

Better graphics are only useful if they preserve uncertainty.

The native client is conceived as a tactical command station rather than an omniscient free camera. Sonar, periscope, audio and status surfaces can improve perception, but they must not reveal information the player has not earned through the sensing model.

The core loop is intentionally about commitment rather than reaction speed. Position, contact confidence and timing should matter more than rapidly pressing fire as soon as an object appears on screen.

Development approach

Simulation correctness is treated as part of the product contract.

The core remains headless and testable, presentation does not own gameplay truth, and render rate or device behavior may not alter authoritative fixed-seed results. Migrations are staged so a successful compile is never treated as proof that behavior survived.

The current TUI is valuable precisely because it makes the simulation usable before the final presentation client exists, while also serving as a reference/debug client for later native work.

Private repository · proprietary pre-release
Next: Signal Broker