Established foundation
An implemented prototype or engine subsystem. Its presence does not automatically mean the full player experience around it is complete.
A grounded development snapshot
Where we are.
A substantial prototype foundation is becoming a connected game experience. This page separates what exists, what has been software-tested, the acceptance still needed, and the wider path ahead.
01 / Read the status
Four different kinds
of progress.
Software-tested work
Behavior checked in a specific build or test configuration. This is evidence for that path, rather than proof of every platform or device.
Native acceptance
Direct checks of current behavior on the intended platform, including input, audible playback, GPU rendering, and the player-facing experience.
Game integration
Several foundations acting as one coherent loop, with clear authority and outcomes that survive save, restore, and return.
02 / Today’s foundation
Captain Who Remembers.
Established prototype
Crew, command, continuity.
The current engineering prototype provides a bounded setting for command and memory systems.
- 30 crew members and five existing host tiers
- Crew memory and command delegation
- Persisted simulation and command continuation
- Player checkpoint save and restore controls
- Bounded learning from accepted repair outcomes
- Trust and respect changes retained through persistence
Recent software-tested work
Reliability around the experience.
Recent work has advanced specific presentation, audio, physics, and save/load paths.
- Distinct Full and Reduced presentation behavior
- Bounded relevance transitions within the prototype
- CPU shadow ownership and offscreen-caster repairs
- Audio scheduling, cancellation, retry, and cleanup checks
- Staged fracture safety and native physics-backend tests
- Generated-geometry save/load validated locally
03 / Still to prove
The remaining
acceptance gates.
Actual Windows interaction
Verify movement, looking, fullscreen behavior, inspection, and player save/load on the current native build, including interruptions and restored continuation.
Real audible playback
Check the complete voice-to-device path, including queued or in-flight speech, cancellation, failures, and continuation. Software scheduling tests do not replace listening to actual output.
GPU & native presentation
Verify the current Vulkan shader package, rendering, native GUI, and representative captures. CPU correctness is a separate evidence path.
Representative performance
Measure real whole-frame behavior with normal relevance policy and the systems enabled. Reduced scene-cost measurements do not establish acceptable low-end gameplay performance.
Sustained operation
Validate long-run behavior, bounded retention, speech backpressure, checkpoint reuse, and clear diagnostics before making claims about indefinite operation.
Release readiness
Keep exact tested source, packaging, distribution, and acceptance aligned. No public game download or release date is announced on this site.
04 / The integration path
Build the loop.
Then widen the universe.
01
Established foundations
Preserve what already works.
The project has real engine and prototype foundations. The next work connects them; it does not require pretending those foundations are absent.
Engine & editor
Geometry, rendering, audio, utilities, physics and destruction primitives, Willow integration, editor windows, and debugging foundations.
Crew & command
Memory, delegation, paired continuation, checkpoint controls, and bounded repair-outcome learning.
Persistence in pieces
Prototype checkpoints, utility checkpoints, and geometry archives have distinct and limited responsibilities.
Presentation
Full/Reduced behavior and relevance transitions provide a starting point for broader scalability work.
02
Immediate integration focus
One credible engineering emergency.
Connect the physical ship problem to its utility consequences, crew work, resource use, and lasting outcome. Current Captain repair behavior is not yet the complete finite-resource ship-life loop.
Damage → utilities
A committed ship problem affects the systems that keep the vessel functioning.
Crew orders
Work is delegated in the context of the ship and the information available.
Finite-parts repair
Repair depends on resources and belongs to the same authoritative ship state.
Lasting outcomes
The recovery has clear consequences for ship condition and relevant crew relationships.
03
Persistence & authority
Leave. Return. Continue.
Bring ship systems together at a coherent persistence boundary, including the state that narrower archives do not own.
Whole-ship state
Coordinate utilities, physical state, destruction, items, work, crew, orders, and time.
Mid-emergency restoration
Restore ongoing work without duplicating bodies, resources, or repairs.
Leave & revisit
Retain the ship’s condition and pending work while the player is elsewhere.
Layered detail
Extend toward the final seven simulation/detail levels with safe reconstruction on return.
04
Next playable world slice
A ship. A system. A journey.
Prove a connected player experience at a smaller world scale before expanding the galaxy.
One explorable system
Navigate, discover, interact, leave, and return in a coherent space.
Modular shipbuilding
Connect block-by-block construction and interiors to the systems aboard.
Flight & basic AI ships
Bring player movement, ship flight, cameras, and basic other vessels into the same slice.
End-to-end usability
Make build, crew, damage, repair, flight, and persistence work as a player-facing sequence.
05
Longer-term horizons
Grow the wider galaxy.
Expand from the accepted smaller loop into the systems that define the broader Grevara vision.
Galaxy & authored content
Procedural scale, handcrafted discoveries, mysteries, and histories.
Factions, economies & fleets
A broader living context, space warfare, and wider command.
Modding & distribution
Validate authoring interfaces, compatibility, packaging, and public distribution when ready.
Multiplayer later
Build on the single-player foundation before extending the experience to multiplayer.
05 / Scope & timing
Ambition without
a fictional percentage.
Why are there no completion percentages?
A feature count does not measure whether a coherent game works. The roadmap uses concrete foundations, integration tasks, and acceptance gates instead of a percentage that would imply certainty the evidence does not support.
Are all seven simulation/detail levels complete?
No. Seven levels are the finished design target. Five host tiers exist in the Captain prototype, alongside bounded presentation relevance work. Whole-world authority and the final seven-level system still need development and acceptance.
Do passing software tests mean Windows gameplay is verified?
No. Tests support the specific configuration and behavior they exercise. Current Windows input, actual audible output, native GUI, Vulkan/GPU rendering, and representative whole-frame performance need their own acceptance.
Is there a release date or public download?
No public game download or release date is announced on this site. Windows and Steam are planned, with single-player as the first focus.
Where is the bigger game vision?
The Gameplay, Ships, Crew, Universe, and Technology pages explain the intended experience. This page explains the dated development state and the route toward that experience.
Start a conversation
Ideas deserve a conversation.
Talk to Casilian Studios.
Questions about Grevara development, collaboration, or the work behind it? Contact the studio directly.