A medieval sandbox,
built with Unreal Engine.

We plan to build the game in Unreal Engine 5, using its rendering, animation, world-building and multiplayer tools within one production environment. This keeps the work connected: a character can be assembled, animated, lit and tested in the same project.

C++ will handle the core systems and persistent data. Blueprint will support content assembly, interactions and quick iteration. Data assets will keep editable content separate from code, so changes do not require rewriting the underlying systems.

We want clear boundaries between world data, simulation, networking and presentation. That makes systems easier to test independently and reduces the risk of a visual or content change breaking an unrelated part of the project.

A stable production baseline

Unreal Engine 5.8 is the current evaluation baseline. The production build and plugins will be fixed after compatibility checks and representative scene tests. Upgrades will happen deliberately, with a working project to compare against. We do not want core production to depend on an experimental feature simply because it is new.

Nanite is part of the planned environment pipeline for suitable high-detail geometry. Lumen is the lighting direction for dynamic global illumination and reflections. We will evaluate them together in the environments the game actually needs, rather than judging the result from a single showcase scene.

Virtual Shadow Maps are a candidate for the shadow pipeline. Their use, along with Lumen settings and upscaling options, will be selected against measured GPU cost. The aim is a balanced real-time scene, not the highest possible setting in every menu.

Our current reference is Unreal Engine and MetaHuman 5.8, checked against Epic's documentation in October 2026. The plan is to build a custom character pipeline around it: authored identities, project-specific materials and clothing, reusable animation and separate runtime quality profiles.

We want control over the character's appearance while retaining a common technical foundation. A source sculpt, fitted rig and production assembly will be kept as distinct assets so that improving one stage does not mean rebuilding everything.

01 / Author the identity, then conform the mesh

We will begin with a custom human sculpt or appropriately licensed scan, refine the silhouette and proportions, and use the current From Custom Mesh workflow to conform the head and body to MetaHuman. The output adopts MetaHuman topology and rigging; the fitting result still needs an artist's review.

Source meshes will be cleaned before import. Loose clothing will be produced separately so its shape is not mistaken for the underlying body. Facial landmarks, hands and joints will receive a dedicated review after conforming.

02 / Keep a path back to the source assets

The current Export tool supports geometry, DNA, materials and DCC packages. We plan to use that round trip for targeted adjustments in external content tools, then bring the result back into Creator. MetaHuman for Maya or Houdini can be evaluated where their supported tools solve a specific production need.

For Lostern, the useful improvement is traceability: each assembled character should point back to its approved source, fitting revision, wardrobe set and export profile. A new assembly should be reproducible rather than a collection of undocumented manual edits.

03 / Develop the look in project lighting

We will evaluate unbaked materials and texture overrides for custom skin detail, wear and a coherent art direction. The intention is to keep the character editable during look development, then use an appropriate assembly and material-baking path for the runtime asset.

Creator's custom lighting scenes offer a useful review stage. We plan to maintain lighting presets representing our environments and compare them with the actual level. These previews are templates, not a replacement for checking the finished character inside the game.

04 / Treat wardrobe and hair as a shared library

Our proposed wardrobe workflow uses modular clothing, accessories and hair with reviewed compatibility across a controlled set of body shapes. Each item will be checked for deformation, intersections, material consistency and distance-based detail.

Character variation will come from approved combinations and authored changes. The aim is to create a recognisable population without manually rebuilding every outfit or relying on unrestricted random combinations.

05 / Assemble for real-time use

UE Optimized is the intended starting point for in-game assemblies. We will keep higher-detail authoring or presentation assets separate, and choose texture, hair and rig settings against the cost of the complete scene.

Our proposal is a small set of reviewed character profiles for close interaction, normal play and background use. The profiles will share source identities while changing presentation cost. Their quality and transitions must be checked in packaged builds.

06 / Automate repeatable assembly work

The MetaHuman Creator Python API and Editor Utility Blueprints provide a route to scripted creation, editing, conforming, assembly and export. We plan to build small tools for applying approved profiles, naming assets consistently, collecting dependencies and producing review batches.

A character recipe would record the source asset, approved appearance choices and assembly settings. Automation would then rebuild the candidate and prepare it for review. The artistic decision remains explicit; the repetitive editor work becomes easier to reproduce.

These are proposed development experiments. Each needs to demonstrate a useful result in this project before it becomes part of the production pipeline.

Track the new tools without making all of them dependencies

Unreal Animation Framework support for MetaHuman assembly is experimental and will be compared with the Animation Blueprint baseline. OpenRigLogic and the MetaHuman Devkit are also relevant to future custom tooling, but building a separate character platform is not a requirement for this game.

We will retain the simpler production path until an experiment shows a clear gain in asset quality, iteration time or runtime cost. This lets the project use current technology without tying its schedule to every new feature.

The intended animation pipeline combines Animation Blueprints, Control Rig and IK Rig / IK Retargeter. Together, these give us a way to organise runtime animation, make rig adjustments in the engine and adapt animation between characters with different proportions.

Motion Matching is under evaluation for locomotion. Its database-driven pose selection could help produce more natural movement transitions, but it also needs a suitable animation library. We will compare it with a simpler animation setup before making it a production dependency.

The first-person and third-person presentation will be developed around compatible character data. Animation assets, camera work and interaction alignment need to be considered together. Retargeting reduces repeated work; it does not remove the need to review each result in context.

Sequencer will support authored presentation where it is useful. Facial animation and capture workflows can be added as the content justifies them, without making a full performance-capture pipeline a prerequisite for the first prototype.

World Partition is the planned starting point for environment streaming. We will evaluate HLOD and distance-based detail alongside it, with the goal of keeping large views readable while limiting the amount of detailed content active at once.

The environment pipeline will use modular architecture, reusable materials and organised asset sets. Settlements and important locations will be authored intentionally. Procedural Content Generation tools are a candidate for repeatable environment dressing, where they can save production time without deciding the layout for us.

Visual streaming and persistent world data will remain separate concerns. A location can leave memory while its identity and state remain in the save. This separation is especially important for co-op, where players may be in different areas.

Assets that belong in the same world

Custom work and licensed assets will follow the same scale, material and naming conventions. Third-party content will be reviewed for visual fit, technical cost and usage rights before it becomes part of the production library.

StateTree and Smart Objects are candidates for structured character behaviour and usable locations in the environment. We want behaviour to be visible in debugging tools, so it is possible to understand what a character is doing and what it is waiting for.

Persistent entities will use stable identifiers and structured records. The visible characters and objects can then be created or unloaded without becoming the only source of truth for the world. Save-format versioning and recovery will be designed alongside the systems that produce the data.

We will begin with an architecture that is straightforward to inspect. Larger frameworks such as MassEntity will be considered if profiling shows a clear benefit. The choice will follow an identified bottleneck, rather than a target technology list.

The project targets solo play and two-to-four-player co-op. Our starting point is Unreal's networking framework with a host-authoritative model. Shared state will be validated by the host, while the client handles the presentation needed for a responsive experience.

The Character Movement Component provides the starting point for networked movement. Replication, relevancy and update frequency will be evaluated for the game's own actors and data. Networking will be part of early development, rather than an addition after a single-player game is complete.

Session joining, reconnection and world persistence will be tested together. The first scope uses a host-owned save and ends when the host leaves. Dedicated hosting and host migration remain later decisions, dependent on the actual product requirements.

The useful test case is a shared world under normal latency with players in different locations. We will profile that workload alongside rendering and simulation, because the host has to run all three.

Unreal Insights will be central to performance work: CPU timing, memory and network traces help identify where the cost is coming from. GPU profiling and the engine's diagnostic views will support rendering decisions.

We will keep repeatable test scenes for environments, characters and multiplayer. Results need a recorded hardware configuration, engine version and quality preset. Editor performance alone will not stand in for testing a packaged build.

Public hardware requirements and performance claims will come from working builds. At this stage, we are defining the measurement process and technical priorities.

The source and content workflow will use version control, isolated changes and regular playable builds. Git with large-file storage is the initial direction for code and binary assets. File organisation and asset ownership need to stay clear as outside contributors join specific pieces of work.

We will start with a compact environment that exercises the engine, character and multiplayer pipelines together. Once that foundation is stable, content can expand through repeatable imports, shared materials and reusable systems.

External support is planned for specialised work where it makes sense, particularly character or animation work, technical art and audio. Deliverables need a defined format and an in-engine acceptance check, so a finished asset can actually be integrated.

The project has no announced release date. The next commitment is a working foundation and a realistic understanding of the cost of making more content.

We plan to use Claude, Codex and other AI tools for programming assistance, debugging, documentation, test design and early content exploration. They can help a small team work through implementation alternatives and repetitive tasks.

Changes still need review and in-engine validation. The developer owns the architecture, checks the integration and decides whether the result works. Generated code is a starting point for development, not proof that a feature is ready.

Visual references can help establish direction before production art is made; they will be labelled as references. Final game assets need their own production and review process.

The current use of AI is in development. Live language-model-driven NPC dialogue is outside the planned runtime scope, and ordinary play is not intended to depend on an external AI service.