Build it.
Keep it alive.

Make a ship your own.

Grevara’s shipbuilding vision is block by block, in a fully 3D world. The hull and its interior are intended to be part of the same construction process, making the ship something you inhabit as well as something you pilot.

This approach gives construction a practical context. The design aims to connect the layout of the vessel to the systems that keep it functioning and the crew who work within it. The goal is a coherent ship, not a cosmetic exterior that is separate from life aboard.

The exact construction toolset, part catalog, limits, and balancing are not announced here. Integrated modular shipbuilding belongs to the next playable slice.

A ship that has to work.

Power and life support are part of the connected-systems vision. They are intended to make a ship’s internal condition meaningful, giving construction and damage consequences beyond appearance.

Engine-level foundations for gas, power, geometry, and utility checkpoint ownership already exist. Their presence is valuable, but integration with ship damage, jobs, items, physics, and whole-ship authority still needs to be established.

A utility checkpoint is a bounded piece of persistence. It does not by itself demonstrate that the entire ship, its moving physical state, its crew work, and every dependent subsystem can leave and return together.

An emergency should
change the situation.

Damage and repair are intended to connect the physical ship to its utilities and crew. The aim is that a failure changes what the ship can do and creates understandable work for the people aboard.

Physical-fracture and safety work has advanced at the engine level. Current validation includes software-tested transaction and persistence behavior, with native backend acceptance tracked separately. A tested foundation is not the same as a finished gameplay damage model.

The integration priority is an engineering emergency that can be understood, acted on, repaired, and continued from. That is the bridge between a collection of subsystems and a playable ship-life experience.

Recovery has a cost
and an owner.

Finite-parts repair is part of the next intended loop. Repair work should belong to the same ship state as the damage, utilities, crew assignment, and resources it depends on.

The Captain prototype already investigates delegation and repair outcomes. Bounded evidence-backed outcomes can update learned trust and respect, linking a task’s result to a crew relationship without claiming the whole social simulation is complete.

The remaining integration is broader: damage must create the right utility consequences; the crew needs work that uses available parts; and the resulting recovery must remain coherent in saved and revisited ship state.

Leave. Return.
Find the same ship.

Persistence has several layers. Current prototype checkpoints preserve paired simulation and command state. Generated geometry save/load has also been validated locally in engine work. Neither alone establishes the whole-ship leave-and-return experience.

The larger goal needs clear ownership for the ship, its systems, crew, work, items, physical state, and regional presence. These responsibilities must agree about what is authoritative when the player is elsewhere and when they come back.

The roadmap therefore treats whole-ship continuity as its own acceptance task. It is a condition for expanding the sandbox, rather than something inferred from a successful save file.

What this means today.

Grevara is in development, and no public shipbuilding release is announced on this site. These pages explain the design and the integration work needed to deliver it.

The current Captain prototype gives command and crew systems a bounded environment. The next game slice adds one explorable system, modular shipbuilding, and basic AI ships around the first connected ship-life loop.