Rengine / docsProject documentation

Explanation

Tradeoffs and Scope

Understand the design decisions, alternatives, and limits.

Rengine chooses a small, inspectable engine model over a feature-complete game framework. There is no asset pipeline, physics system, input abstraction, collision model, audio layer, or retained editor format. The reward for that narrowness is that every moving part in the demo can be traced to one of four ideas: entity state, folder composition, component updates, or renderer projection.

The canvas and React renderers are also intentionally asymmetric. Canvas is the better fit for wireframe markers and imperative drawing; React is useful for proving that the same entity state can become DOM. Keeping both paths exposes the renderer boundary, even though a production engine would likely commit harder to one primary target.

  • Folder entities make hierarchy simple, but they are not a full transform-node system.
  • Ordered component functions are easy to inspect, but they do not scale like a data-oriented ECS.
  • Debug overlays add visual noise, but they make anchor and position mistakes obvious.
  • The demo scenes act as regression examples for transform behavior rather than as finished game content.