A scene is a widget
The renderer draws into a pixel buffer that Flutter’s texture registry adopts, so the 3D view takes part in layout. A panel can overlap it, a slider can resize it, and the whole thing clips to a rounded rectangle. A platform view can do none of that.
You state the scene, not the changes
Every frame, you say what the scene contains, in full. The objects are
keyed, so saying it again sixty times a second only costs you what
actually changed. There is no addChild, so there is nothing to fall out
of sync.
The core is C++, the game is not
An archetype entity-component store, reached over a C ABI. Component data arrives in Dart as views over the store’s own memory rather than as copies, so walking a column isn’t a translation step.
Time is sampled, not accumulated
Effects, sprite animation and cutscenes are all functions of a playhead. Ask any of them for a moment and you get that moment. That is why scrubbing, replaying and stepping backwards all give the same answer as playing forwards.
Pre-alpha, and honest about it. The renderer is proven on macOS, has drawn on the iOS simulator, an Android handset and in Chrome, and is less far along on Linux and Windows. The simulation, geometry, rigging, noise and networking packages run anywhere Dart does. Have a look at platform support for what that means in practice, before you plan around it.
What we are building towards is an engine that is community-led and console-grade: open from the first commit, MIT-licensed throughout, and aimed at desktops and consoles rather than at a demo. Where this came from covers the projects that got us here, what each of them got right, and what Orblit does differently.
Pre-alpha is the stage where a user is worth more than a contributor. The most useful thing anyone can do right now is try to build something, get stuck, and tell us where.
