OmiLithENGINEField notes ↗

02 / Components

A collection
of useful parts.

Libraries have distinct jobs. A game composes them into an experience, without making that game a dependency of the engine.

01

scene / script / program / world

World & behavior

Scene assembly, reflected components, trusted Luau scripts, and game-owned world composition. Data is validated before publication; application contracts keep authority and presentation responsibilities separate.

02

assets / offline tools

Assets & cooking

Mesh import and optimization, measured LODs, texture mip chains, content-addressed shared texture banks, and provenance. Runtime packages consume validated cooked formats instead of linking source importers.

03

physics / character / vehicle / movement

Simulation & movement

Authority-owned Box3D integration and reusable movement components. Consumers choose the gameplay composition. Physical state stays on its owning simulation, while visual actors can remain presentation-only.

04

network / discovery / persistence

Connections & state

Input validation, snapshots, interpolation, and transport adapters. Native and RTC clients share the protocol boundary. Optional services and persistence retain explicit ownership rather than becoming mandatory application dependencies.

05

render / lighting / environment / terrain / vegetation

Rendering & environment

View extraction, visibility and LOD, material families, explicit passes, and device-selected quality. Shared environment data connects sky, sunlight, fog, and water while each effect retains its own budget.

06

application / platform / ui / audio / xr / media

Presentation & interaction

Application lifecycle, input routing, renderer-neutral UI, audio, OpenXR, and optional recording/capture services. The headless authority does not link window, renderer, or output-audio dependencies.

One registry, several views

Reflected once.
Used where it matters.

RTTR connects scene fields to serialization, Luau, and the development inspector. Reflection stays outside the draw loop; runtime work consumes validated data rather than repeatedly discovering its shape.

Tools support the runtime.

The cooker and authoring tools have different dependencies from a running game. Assimp import, mesh optimization, source image decoding, and offline analysis belong in the toolchain. Cooked geometry and texture banks carry hashes and provenance into a bounded runtime reader.

Development inspection, tracing, and automated performance reporting are optional build features. Their presence in a development capture does not mean the same tools are part of a shipping product.