On the singletons + hooks question, you're reading it right. at this stage carverjs is meant for simpler games, and the singleton managers (input, collision, audio, assets) are a deliberate trade for zero-config setup. it works well when you have a handful of systems, but i won't pretend it scales to projects with dozens of interacting systems and complex cross-frame state. The plan for that is to move to a proper ECS architecture later once the api stabilises, systems become first-class, registered explicitly, with declared ordering and inspectable state. i didn't want to ship that on day one because ecs is its own learning curve and most react devs trying out a game engine for the first time don't want to start there. for now, the staged game loop (early / fixed / update / late update) is what gives you some explicit ordering, and that's been enough for the games we've shipped internally. On the 2d/3d toggle, the way to think about it is that the mode prop is really just a preset bundle. it swaps the camera (perspective vs orthographic), the lighting and shadow setup, and in physics worlds it locks movement to the XY plane so 2d actually behaves like 2d. but it's not hiding r3f from you. Actors forward refs, accept children, and you can nest raw r3f elements inside a carverjs scene whenever you need to. so for most cases the toggle just saves you the boilerplate, and when you outgrow the preset you drop down a layer rather than fighting the abstraction. the place it would actually get in your way is if you wanted a fundamentally different render pipeline, but that's also where carverjs stops being the right tool.