The editor

The editor is a desktop application for building Orblit projects. It’s written in Flutter, with the same widgets a game uses, and it draws its viewports with the same renderer a game does. So what it shows you is what ships, rather than an approximation of it.

Getting it

There are no signed builds yet. Clone and run:

git clone https://github.com/ChxisB/orblit.git
git clone https://github.com/ChxisB/orblit-editor.git
cd orblit-editor
flutter run -d macos

The two checkouts must be siblings, and must be named exactly orblit and orblit-editor. The editor depends on the engine by path rather than by git revision, deliberately: the renderer and the editor change together, and a git dependency would put a push and a pub upgrade between writing a renderer change and seeing it.

What is in it

Scene	Hierarchy, inspector, gizmos, four viewports and a game view
Materials	Authoring, preview, per-face assignment
Geometry	Parametric shapes and mesh editing, in the viewport
Terrain	Sculpting and painting, under Add ▸ Terrain
Interface	A canvas for the same UI document a game draws
Blueprints	Reusable object definitions, as .blueprint assets
Sequences	A timeline for cutscenes
Cameras	Shots, and the blends between them
Examples	The worked examples, live, beside your projects
Scripting	Writing and compiling scripts, and checking them

Every edit is a command

Nothing in the editor mutates the document directly. An edit is an object with a do and an undo, and the document is what you get by applying the ones on the stack.

This is why history came first, before most of the panels existed. Bolting undo onto an editor that mutates is a rewrite, whereas building the panels on top of a command stack is not. It also means every panel gets undo for free, and none of them can get it subtly wrong.

The examples are in it

The worked examples show up in the launcher, beside your projects. They come from the same package the gallery application uses, so an example is written once and the two can’t drift apart.

They sit there rather than inside a project because that’s where the question actually gets asked. “How is a day cycle done?” comes up while you’re deciding what to build, and an answer you have to close your work to reach is an answer you’ll go and look up somewhere else.

What it is not

It isn’t required. A game is a Flutter application, so you can write one in a text editor and never open this at all. The editor is for the work that’s genuinely easier with a viewport in front of you: placing things, tuning materials, sculpting terrain, timing a cutscene. What it saves is files you could have written by hand.