AI-Native Retro Engine

Old-school games, deliberate tools

This engine concept explores Doom/Quake-like visual territory alongside a modern authoring question: what changes when AI-assisted access is considered from the beginning?

The design work connects rendering, level construction, assets, and scripting. My focus is on making those pieces understandable enough that a creator can predict what an edit will change—and that an automated tool can operate within the same clear rules.

This is a design and architecture exploration. The decisions below describe the intended engine rather than a finished implementation.

Start with predictable identity

A scene can contain several objects named “Torch.” Their internal identities still need to be distinct. The design therefore separates an object’s display name from its engine identity.

A lookup by name should succeed only when the target is unambiguous. If several objects match, the system should report that ambiguity instead of silently choosing one. Deliberate collections can be addressed through multi-object queries or tags.

That is a small rule with broad consequences: scripts, editor operations, and AI-assisted changes all need a reliable answer to “which object are we changing?”

Make shared state visible

Prefab instances are designed as stamps with inherited defaults. An instance stores its local differences; a source edit updates properties that still inherit, while preserving explicit overrides. The inspector should show which values are local and offer a way to reset a property—or an entire instance—to the source.

Asset ownership follows a similarly explicit model. Each level has a folder for its own content, alongside a project-wide Global Assets area. Duplicating a level copies its local assets so an experiment in the copy does not unexpectedly alter the original.

New imports default to the global library. Making a local version duplicates the asset, preserving the shared original. Editing a global asset should make its shared use obvious and offer a local-copy option. Deletion should be blocked when live references still depend on an asset.

Together, these decisions address a common creative problem: wanting to experiment freely without accidentally changing work elsewhere in the project.

Keep the editor familiar

The planned editor uses familiar move, rotate, and scale tools, with local/world space and snapping. Focused source editing ghosts out the surrounding world so the active authoring context is clear.

Camera continuity matters too. Moving between modes in the same viewport should preserve the camera’s position, while a dedicated asset window can own an object-focused view. The editor should help the creator stay oriented as they move between the level and its parts.

Scope is part of the design

The first version deliberately postpones some features, including negative-scale mirroring and unused-asset scanning. Reference-aware deletion stays in scope because it protects the basic authoring workflow.

The next challenge is to turn these rules into an executable editor and prove them with real levels and repeatable operations. The value of the current work is the coherence of the design: identity, inheritance, asset ownership, and editing context are considered together, before implementation makes those choices expensive to change.