# Minimal Editor Prototype Spec

This document is a early-draft collection of thoughts about the editor, which we will try to edit into something resembling a specification (at some point).

## Are We Editor Yet?

We have yet to officially define the requirements for an editor. But I think there is a general consensus forming around these points:
+ It will edit raw a bsn abstract syntax tree. Bsn is our new 'scene representation' although as people have pointed out recently, its more of a general 'ECS schematic' format.
+ The editor must be able to function as a stand-alone application, rather than something embedded in a bevy app. It would be nice to let users choose to embed if they want, but not a hard requirement.
+ The editor will (probably) need to be able to compile and run your project. This is a longer term goal.
+ We do not want the editor to link directly with application code. We want an "out-of-process editor" which can communicate to running game code using IPC.
+ Because we want editor to run as a separate process, it will need an auxiliary way to load information about the components defined in the app-code.
+ We also need a way to match up the fields of those components with the correct UI element. Color fields on a component should cause the editor to display a color-picker.
There's a bunch of tech we need to build still to make this work. I personally think it can be separated into two categories: Front end-work (eg. making our UI system capable enough to support an editor) and back-end work (designing the apis and logic that will underpin the editor UI widgets).

## Design Inspiration
It is good to know how similar software solves these problems, but in trying to directly emulate their functionality without doing our own design work, it's easy to (a) port over bad designs (b) apply good designs in a domain where they do not fit or (c) fail to properly implement the reference in subtle ways (d) omit additional things that better fit our case, but that do not belong in the reference.

When we look at other apps and evaluate their design, I want us to ask (1) is this good (2) does it fit (3) what don't we need (4) what else should it do.

## 2-Process Architecture

+ The editor maintains a BSN ast.
+ When it changes, we serialize that bsn and send it to a child process, which loads it and renders it.
+ The rendered frame is then sent back and displayed in the editor using a gpu subsurface.
+ Window events within the preview area are proxied back over to the app process via IPC.
+ A shim in the game app emits these events as a proxy for bevy_window.
+ The game runs picking and interaction to update transform gizmos, select objects and such.
+ The editor shim then sends back information about how to update the editor state to the editor.
+ The editor updates the BSN ast and other state info. The loop continues.

## Editor Modes

#### None
The app is being run as a standalone application without the editor. In this mode, all systems except those required for editor functionality are enabled.

#### Edit
This is the default mode in the editor used for viewing and modifying a scene. In this mode, only systems required for editor functionality are enabled. Some systems (such as Animation), may be optionally toggled on.

#### Play
This is the mode commonly represented in other editors by the "play button," allowing the editor to compile and run the current scene. This mode is similar to `None`, with the exception of potentially disabling scene transitions.

**This is not needed in the prototype. We can get away with using `None` for the first iteration of the Play feature.**

### Editor Mode Systems

Unless explicity defined below:
+ When in `None` and `Play` mode, all systems will be run
+ When in `Edit` mode, no systems will be run

| Mode | Default | Enabled | Disabled | Optional |
| -------- | ------- | ------- | -------- | -------- |
| None | All systems enabled | | Editor* | |
| Edit | All systems disabled | Editor<br>Extract<br>Render | | Animation |
| Play | All systems enabled | | Editor | Debug Tools |

\*Editor Systems (not exhaustive):
+ Systems for reading bsn/changes sent from the editor and writing to the App World
+ Systems for editor camera control
+ Systems for ray-trace mouse selection of entities