OmiLithENGINEField notes ↗

01 / Architecture

One world.
Clear boundaries.

The useful unit is a contract: who owns the state, who can change it, and how the next system receives it.

OmiLith architecture and ownershipIndependent games own rules, scenes and content. Application contracts coordinate an authoritative simulation and a client presentation. Shared engine libraries provide scene reflection and scripting, cooked assets, networking, physics, rendering, audio and UI. Rendering selects native backend paths.Independent gameRules · authored world · content · product identityAuthorityInput validation → game rules → physics → snapshotsClient presentationInterpolation → view → rendering, UI & soundReusable engine librariesScene & RTTR · Luau · assets & cooking · networking · physics · world systemsRender policy · frame graph · materials · environment · audio · UI · OpenXRNative platform & graphics pathsVulkan · Metal · Direct3D 12 · WebGPU
Independent gameRules · world · content · product identity
AuthorityValidate input → game rules → physics → snapshots
Client presentationInterpolation → view → rendering, UI & sound
Reusable engine librariesScene & RTTR · Luau · assets · networking · physics · rendering · environment · audio · UI · XR
Native platform pathsVulkan · Metal · Direct3D 12 · WebGPU
Ownership and data flow at a glance. Modules are selected by the consumer; the headless authority excludes window, rendering, and output audio.

The game owns the game.

OmiLith's reusable libraries do not depend on a particular game or sample application. A consumer owns its rules, authored scene, content, controls, presentation document, packaging, and product identity. Drune and Glasswake are separate consumers of that foundation.

Applications select engine options before collecting dependencies, include the engine as a source dependency, then link public library targets. Offline tools and client-only systems stay outside a headless server build.

Simulation has an authority.

The authority validates input, advances gameplay and physics at a fixed tick, and publishes snapshots. The documented baseline advances at 60 Hz and broadcasts at 20 Hz. These are scheduling contracts, not a promise of a particular player count or device frame rate.

Clients send controls and render interpolated snapshots. Native GameNetworkingSockets and WebRTC routes feed the same bounded game protocol. Rendering, local view response, UI, and cosmetic effects live on the presentation side; they do not silently become authoritative game state.

A shared language for scene data.

Entities own simple value components. OmiLith deliberately does not use a full entity-component-system framework. The RTTR registry supplies the shared field metadata for JSON scene assembly, Luau property access, serialization, and the inspector.

That shared registry keeps numeric bounds and writable properties aligned. Scene replacement validates a new scene before publication, and scripts operate through checked entity identities. The current project scripting boundary is for trusted game scripts, not a general untrusted mod sandbox.

Intent enters. A render plan leaves.

Rendering combines the scene's policy with device capabilities and the compiled shader package. Required behavior can fail clearly when unsupported; preferred effects can select an authored fallback. A simpler route should preserve the game's visual intent.

The public Renderer boundary remains consistent while Vulkan, Metal, Direct3D 12, and WebGPU own their native resources and command submission. Slang is the shared shader source; build tools generate backend shader formats ahead of time.

Renderer architecture: scene inputs flow through shared rendering policy and device profiles to native backend paths.
Render-policy overview from the development journal. Open the full-size diagram.

Publication is a lifetime boundary.

Runtime scene and asset data are validated before becoming visible to their owners. Frame extraction builds contiguous data for command recording. Uploads, resource generations, and asset leases remain alive until the GPU has completed the work that uses them.

The frame graph makes attachment and sampled-resource use explicit. Backend barriers and encoders implement that contract. This keeps a scene replacement or changed material binding from retiring a resource while an earlier frame still needs it.

Continue exploringMeet the components ↗