Lay out basic vision, roadmap and constraints for the editor

[alice-i-cecile]

This was scattered in a few places, namely https://hackmd.io/0urMiAXOQX6ul2f6Jbk4jQ and #editor-dev on Discord.

I've taken the liberty to collect our high-level discussions into a single, easy-to-discover place. These should not be taken as absolutely final, but give us a solid foundation to work off of.

[PROMETHIA-27]

LGTM! I think this lays out all the core components of the editor that have been (mostly) agreed on.

[janhohenheim]

I'm not much in the loop, but this looks very sensible to me. Left some comments, but feel free to disregard most of them. No strong opinions other than "the editor should one day allow custom content" (but that may be a "Stage 4") and "We should be able to modify assets and resources at runtime"

[recatek]

One question that might be worth asking is something along the lines of, "How does the editor present the game world?"

I ask this because one of Unity's killer aps (IMO) is the distinct Game vs. Editor view of the 3D world, and the fact that you can live-edit components and their data in the Editor view (with independent camera control) while the game is running. Building with that functionality in mind from early stages seems like it might be easier than trying to retrofit it in later, if the value proposition is there.

You also have things like 3D view sub-windows for previewing shaders, animations, and prefab asset bundles before they're played in the world.

[alice-i-cecile]

Right, that's a good point. We actually have consensus that that's something we want to do: we should work that in.

[rewin123]

I'm very glad about the appearance of the design document. It's written very clearly and I agree with much of it. I left several important additions from my point of view.

[recatek]

One thing I'm not seeing here (though I could be missing it somewhere?) is what the build packaging process is and how it ties into the editor. What does the asset pipeline look like for a shipping game build? Are we converting textures/models to a common format and compressing/blobbing them? What about scene representation?

Play-in-editor is mentioned but can the editor also build a packaged game and run it? Can you connect to it for diagnostics/profiling? What about launching multiple instances of that game (with specific command line args?) for testing multiplayer?

Not all of these things are probably in scope for the editor at this time, but at least understanding what the shipped and asset-packed version of all of these assets the editor will be manipulating would be worth discussing here.

[NthTensor]

I'd like to suggest that, following merging this PR, we also draw up and commit the stage-one architecture design doc. All design discussion should be held for that PR.

There's lots of questions here that are essentially implementation details extending beyond the base roadmap. And there's still obviously a wide verity of views/expectations/hopes/dreams about what the editor should be able to do. A well-scoped design doc laying out the proposed approach to the initial prototype will help to manage these.

[ChristopherBiscardi]

screenshot-2024-09-22-at-00.17.40.mp4

screenshot-2024-09-22-at-00.18.46.mp4

I read this and then did a bit of prototyping today. The docs written here seem fine.

Notably the bevy remote protocol (for type registry information without prior knowledge, also useful for querying components, etc) and bsn seem like hard requirements to make stage 1 progress so review and progress on bevyengine/bevy#14880 seems really important for the community to handle.

[alice-i-cecile]

Alright, merging :) Please feel free to revise this in follow-up PRs!