Engine architecture map¶
Ludus composes explicit module owners into an application. Understanding which owner holds a resource, which provider it borrows, and when it can publish a change explains most startup, rendering and editing behavior.
This section describes the source baseline on October 5, 2026. It complements the workflow overview; the engineering documents retain detailed contracts, reference attribution and acceptance evidence.
Choose a subsystem¶
| Reading path | Questions it answers |
|---|---|
| Foundation and jobs | What can every module use? Who owns allocation and background work? |
| Startup and shutdown | When is a provider usable? How does partial startup unwind? |
| Platform and rendering | Who owns a window, frame and GPU resource? |
| Terrain and generation | How should ground, generation, editing and streaming connect? |
| Procedural content generation | How do recipes, domain generators, author controls and runtime publication compose? |
| Physics systems | Who owns shapes, bodies, sensors, constraints and queries? |
| Worlds and frame updates | What makes an entity valid? When do edits and simulation take effect? |
| Content and audio | Who owns source documents, resource revisions and playback? |
| Runtime and editor | How do SDKs, game code, configuration and desktop tools connect? |
Shared contracts and development policy¶
- Module ownership and dependencies
- Engine quality architecture and consulted-source review
- Current CI checks
- Platform targets and validated capabilities
- Architecture decisions
Read each design's status and corresponding implementation evidence before relying on a proposed API or platform integration.