Choosing an engine for Stellar Mariner was never really about picking the one with the longest feature list. The more useful question was where we wanted Rynua's engineering effort to go.
Stellar Mariner needs first-person gameplay, vehicles, large environments, animation, physics, audio, networking, profiling tools, an asset pipeline and a renderer capable of carrying the visual side of the project. It also needs systems no general-purpose engine is going to provide for us: persistence, authority, replication policy, world-state management, economic simulation and the rules that make one persistent universe remain coherent while its live simulation is distributed.
Unreal gives us a mature base for the first group of problems. The second group remains ours.
That division of responsibility is the main reason we chose it.
Why not build an engine
There are good reasons to build proprietary technology. A custom engine can be designed around one game's exact requirements, and studios with mature engine teams can justify the cost because they control the full stack and reuse that investment across multiple projects.
The cost is that the engine becomes a second product. Rendering, platform support, tooling, asset import, animation, profiling, editor workflows, hardware changes and low-level systems all need continued engineering for as long as the game depends on them. A technical decision that begins as “we need more control” can easily become years spent maintaining infrastructure players never directly experience.
For Rynua, that would put engineering effort in the wrong place. We would rather spend time on the problems that are specific to Stellar Mariner: persistent state, simulation architecture, replication, world generation, economy, large-scale gameplay and the interaction between all of those systems.
Using an existing engine does not make those problems easy. It simply means we do not begin by recreating an editor, renderer and general-purpose game framework before we can work on them.
Large worlds
Planetary scale immediately puts pressure on ordinary assumptions about coordinate precision.
Unreal's Large World Coordinates support moves much of the engine away from the traditional single-precision coordinate limitations that historically made very large spaces difficult to represent accurately. That matters for a project where the distance between objects can be measured in kilometres rather than rooms and corridors.
It does not mean we can treat the entire universe as one undifferentiated coordinate space and forget about precision. Physics, rendering, simulation and content systems still have their own practical limits, and large-scale games still need careful decisions about reference frames and how local simulation relates to much larger spatial scales. What LWC gives us is a much stronger starting point than rebuilding the engine's spatial model ourselves.
That is the distinction we care about throughout this decision: Unreal removes work we would otherwise have to do before reaching the parts that are unique to Stellar Mariner.
Rendering and content production
The same applies to rendering. Systems such as Nanite, Unreal's lighting stack, virtual shadowing and the wider rendering pipeline give us options that would be enormously expensive to reproduce internally.
Nanite is particularly relevant because traditional geometric LOD production becomes painful at the content scale Stellar Mariner is aiming for. Removing or reducing manual LOD work does not make geometry free, and it does not remove memory, material, overdraw or visibility costs, but it changes where artists and technical artists spend their time.
Lighting presents a similar trade-off. A universe with rotating planets, moving light sources, interiors, exterior environments and changing time of day cannot depend entirely on lighting that was baked for one static configuration. Unreal already provides a modern dynamic-lighting foundation that can be evaluated and adapted rather than something we have to invent first.
None of this means every Unreal rendering feature will be enabled everywhere at maximum quality. Features have costs, and those costs have to fit alongside simulation, networking, physics, AI and everything else competing for the same frame budget. The value is having mature tools available and being able to decide where they earn their cost.
Characters and interaction
Stellar Mariner is first person, so the character stack matters long before the project reaches planetary scale.
Unreal gives us mature animation tooling, skeletal systems, motion matching, physics integration and a large body of existing engine code to build against. Our earliest prototypes used that foundation for character movement, interaction and equipable objects, and that work reinforced the same conclusion we reached elsewhere: there was very little value in rebuilding the general-purpose layers ourselves.
The important work is above them. How a character interacts with a persistent object, how equipment is represented in the world, what authority the server retains over an action and what consequences survive afterwards are Stellar Mariner problems. Animation graphs and skeletal evaluation are not.
That is where an engine earns its place: not by solving the game, but by making sure we spend less time solving the wrong layer of it.
What Unreal gives us for networking
Unreal already assumes an authoritative client-server model and provides a substantial replication framework. Actor replication, RPCs, relevancy mechanisms and newer systems such as Iris mean we are not starting from raw sockets and inventing every networking primitive ourselves.
That is useful, but it is important not to overstate what it means.
A replication framework does not decide the architecture of a persistent MMO. It does not decide which simulation owns a piece of state, how players are distributed across instances, which durable outcomes leave the live simulation, how geographic placement interacts with latency, or how one persistent state remains authoritative across the infrastructure.
Those decisions belong above the engine's networking layer.
We can use Unreal's networking facilities where they fit while building game-specific interest management, network culling, replication policy and service boundaries around the requirements of Stellar Mariner. The engine provides mechanisms. Rynua defines what information should move, when it should move and which system is allowed to decide that it is true.
Unreal does not provide persistence
The distinction is even clearer with persistence.
Unreal can serialize objects and expose data to storage systems, but serialization is not a persistence architecture. The difficult question is not whether a value can be written somewhere; it is whether that value belongs in durable state at all, who has authority to change it, what consistency it requires and what happens if the simulation fails halfway through an operation.
A projectile position may exist only for milliseconds and belong entirely to the live authoritative simulation. A ship ownership transfer may need to survive indefinitely and remain globally authoritative. Treating those as equivalent kinds of state because both can technically be serialized would be a serious architectural mistake.
The same applies to inventories, structures, claims, transactions and the other things the universe is expected to remember. Unreal provides the runtime environment in which those systems operate. It does not define the persistent world model for us.
World generation is ours too
Unreal gives us terrain, procedural frameworks, rendering and tooling. It does not give us Cassian.
Planetary generation has to express the rules of Stellar Mariner's worlds. Terrain, climate, resource distribution, environmental structure and authored locations need to produce something coherent at a scale where placing everything manually is not realistic.
That means procedural systems will do a significant amount of work, but procedural generation is not a substitute for design. The rules remain authored. The physical properties of a world still need to agree with one another. Important places still need intention behind them. The engine can execute those rules and render the result; deciding what those rules should produce remains our responsibility.
This is another reason we prefer an extensible general-purpose engine over developing one ourselves. We need freedom above the engine more than we need ownership of everything below it.
Performance is not inherited
Using Unreal also means inheriting its trade-offs.
The engine can produce very expensive frames if we ask it to. Dense geometry, dynamic lighting, shadows, effects, physics and large numbers of active actors all consume real CPU, GPU and memory budgets. An available feature is not automatically an affordable feature.
The same is true on the server. General-purpose engine abstractions carry overhead, and a large persistent online game has different workload characteristics from a bounded match. Actor count, replication work, physics, AI and simulation density all need profiling under representative loads rather than assumptions based on small tests.
We therefore do not treat performance as something Unreal solves for us. It is a design constraint imposed on every system we build. Budgets need to exist early, profiling needs to happen before content makes architectural changes expensive, and systems have to be judged under workloads resembling the ones they are eventually expected to carry.
A powerful development machine can hide bad decisions surprisingly well. Production hardware and real server workloads are less forgiving.
Extensibility matters more than convenience
Another reason Unreal fits the project is that using it does not mean accepting every default abstraction as permanent.
The engine is available in source, its systems are extensible, and lower-level C++ remains available when a project outgrows a higher-level implementation. That matters for a game like Stellar Mariner because some systems will inevitably need more control than an off-the-shelf gameplay framework provides.
The goal is not to modify the engine simply because we can. Every deep customization creates maintenance cost when the engine evolves, and maintaining a large private fork can eventually become its own engineering burden. We want to stay as close to standard Unreal as practical and move away from it only where Stellar Mariner demonstrates a real requirement.
That gives us a useful default: use Epic's solution where it solves the problem well enough, extend it where the game needs additional behaviour, and replace something only when measurement or architectural necessity justifies owning the replacement.
Tooling and future development
There is also a production advantage that becomes more important as Rynua grows.
Unreal is widely used. Artists, animators, engineers, technical artists and designers can arrive with transferable knowledge of the editor, content pipeline and common workflows. With proprietary technology, every new contributor first has to learn the studio's engine before becoming effective inside the game built on top of it.
That does not mean every future Rynua workflow will look like a conventional Unreal project. Stellar Mariner will accumulate its own tools and pipelines because every sufficiently large game does. The advantage is that those tools can begin from an established environment instead of replacing one.
For a project intended to grow over many years, that has real value.
Why Unreal Engine
We did not choose Unreal because selecting a popular engine makes Stellar Mariner more likely to succeed. It does not. Players will not care that a world uses Nanite if it stutters, and they will not care that the replication architecture looks elegant if the game loses track of their ship.
We chose it because the problems Unreal already solves are mostly problems we do not want Rynua spending years solving again.
Rendering, animation, editor tooling, asset pipelines, physics, basic networking infrastructure and platform support are important, but they are not what makes Stellar Mariner distinct. Persistence, simulation, scale, world generation, economic systems and the way all of those things combine into one continuing universe are.
That is where we want our engineering time.
Unreal gives us the foundation to start from.
What we build above it is the part that matters.