You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refine milestones and add a section on architecture (#193)
* Add architecture doc
* Light cleanup on the roadmap
* Call out the design book more prominently in the README
* Aggressively refactor milestones
* More thought on architecture
Copy file name to clipboardExpand all lines: README.md
+6-1Lines changed: 6 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,15 @@
1
1
# Bevy Editor Prototypes
2
2
3
3
> [!WARNING]
4
-
> This project is a prototype for a shippable Bevy Editor and is still in heavy development and testing.
4
+
> This project is a prototype for a shippable Bevy Editor and is still in heavy development and testing.
5
5
> Everything you see is very much a work-in-progress. Read about what we're building in the [Design Book](https://bevyengine.github.io/bevy_editor_prototypes/)! or [Figma document].
6
6
> To run just type the ```cargo run``` or ```cargo run --example``` command in the terminal of the `bevy_editor_prototypes` folder.
7
7
8
+
Want to see what we have planned? Check out [design-book/vision] for a high-level view on our goals, and [design-book/architecture] for a summary of how we think it should all fit together.
9
+
10
+
Want to help? See [design-book/roadmap] for an up-to-date summary of the work that has been done and needs to be done to advance the project to the next phase.
11
+
To avoid ballooning scope and ensure we can ship something useful and reasonably polished, please try your best to focus efforts on the next milestone that has yet to be completed, or standalone proof-of-concepts or design work for important open questions.
12
+
8
13
## Figma Designs
9
14
10
15
While laying out the foundations for an editor prototype in this repository, we are also experimenting with various UI designs in a public [Figma document]. If you are interested in collaborating and sharing your own designs, head over to the document and request write permissions to join the effort.
Bevy's editor, like the rest of Bevy, is fundamentally designed to be modular, reusable, and robust to weird use patterns.
4
+
But at the same time, a new user's initial experience should be polished, reasonably complete and ready to jump into.
5
+
6
+
These goals are obviously in tension, and to thread the needle we need to think carefully about our project architecture, both organizationally and technically.
7
+
8
+
So far, we've agreed upon the following architecture:
9
+
10
+
- the Bevy editor is a binary application made using `bevy`, and `bevy_ui`
11
+
- the Bevy editor will live in the main Bevy repo, and must be updated and fixed as part of the ordinary development process
12
+
- as a large binary project, it represents a great proving ground for how changes will impact users
13
+
- as an important part of Bevy users' workflow, it's important that we don't break it!
14
+
- as a consequence, the Bevy editor cannot rely on any crates that themselves rely on `bevy`: they are not kept up to date with `main`
15
+
- fixing the editor before each release is much more difficult, requiring diverse expertise and a large volume of changes all at once
16
+
- note: until we have an MVP: the editor work is done outside of the main repo, and tracks `main` on an as-updated basis
17
+
- functionality that is useful without a graphical editor should be usable without the editor
18
+
- project creation functionality should live in the `bevy_cli`, and be called by the editor
19
+
- asset preprocessing steps should be standalone tools whenever possible, which can then be called by the `bevy_cli` (and then the editor)
20
+
- the foundational, reusable elements of the `bevy_editor` should be spun out into their own crates once they mature, but are best prototyped inside of the code for the specific binary application
21
+
- UI widgets, an undo-redo model, preferences, viewport widgets, a node graph abstraction and more all great candidates for this approach
22
+
- self-contained GUI-based development tools should be self-contained `Plugin`s which can be reused by projects without requiring the Bevy editor binary
23
+
- for example: an asset browser, entity inspector or system visualization tools
24
+
- the editor will not try and inspect the running process: instead, users will be encouraged to reuse modular dev tools from the editor, `bevy_dev_tools` and the broader ecosystem by compiling them into their own project under a per-project `dev_tools` feature flag
25
+
- we should still develop, ship and promote powerful, polished tools for these use cases!
26
+
- this is significantly simpler and offers more flexibility to users around customized workflows
27
+
28
+
## Open questions
29
+
30
+
These questions are pressing, and need serious design work.
31
+
32
+
- how do we distribute the Bevy editor?
33
+
- do users need to have a local working copy of the Rust compiler to use the editor effectively?
34
+
- how does the Bevy editor communicate with the Bevy game to enable effective scene editing with user-defined types?
35
+
- how should undo-redo be handled?
36
+
37
+
## Extensions
38
+
39
+
These questions are less pressing, but deserve investigation to ensure we can support more advanced user needs.
40
+
41
+
- do we need a launcher?
42
+
- are users able to use versions of the Bevy editor that are newer (or older) than their current project?
43
+
- how do we allow users to add and remove non-trivial functionality to the editor?
44
+
- for now they can just fork things,
45
+
- how are preferences handled?
46
+
- where are they stored?
47
+
- how are they shared between projects?
48
+
- how are they shared between team members?
49
+
- can the Bevy editor play nicely with a hotpatched type definitions for things like components?
Copy file name to clipboardExpand all lines: design-book/src/roadmap.md
+92-51Lines changed: 92 additions & 51 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,12 +13,13 @@ For actionable, well-scoped items, please open issues instead.
13
13
As you complete tasks, check them off here!
14
14
The tasks don't need to be done *well* to be considered completed here: the Bevy community is very good at cleaning up loose strings as we work.
15
15
16
-
Feel free to tackle any listed item in any order: foundations and primitives can often be built out well before the features that need them are in place.
17
16
This list is not "all of the features that the editor will have": other stages will follow as these features are added.
18
17
It's best not to plan too far in advance!
19
18
20
19
## Stage 0: Hello Project
21
20
21
+
After this milestone, we have a project that Bevy developers can work on together.
22
+
22
23
-[x] make a repo
23
24
-[x] add a README
24
25
-[x] add a CONTRIBUTING.md
@@ -27,108 +28,147 @@ It's best not to plan too far in advance!
27
28
-[x] define basic constraints for how we're building the editor
28
29
-[x] define a shared vision for what the editor is (and is not)
29
30
30
-
## Stage 1: Standalone Read-Only Editor
31
+
## Stage 1: Read-only Scene Viewer
32
+
33
+
After this milestone, we have a useful if limited tool that lets users see how scenes would be rendered and represented in Bevy.
34
+
35
+
If this work is done to a high level of polish, we can consider providing it as clearly scoped standalone tool for Bevy users to experiment with and refine.
31
36
32
37
-[x] can load scenes from disk using a native file picking widget
33
38
-[x] can display scenes in a viewer
34
39
-[x] 2D
35
40
-[x] 3D
41
+
-[x] infinite grid
42
+
-[x] 2D
43
+
-[x] 3D
36
44
-[x] simple camera controller
37
45
-[x] 2D
38
46
-[x] 3D
39
-
-[ ] gizmos can be toggled
47
+
-[ ]toggleable gizmos for physical entities that aren't visible in the scene itself
40
48
-[ ] UI outlines
41
49
-[ ] lights
42
50
-[ ] AABBs
51
+
-[ ] cameras
43
52
-[x] lists entities in the scene
44
53
-[ ] supports hierarchy via a folding tree view
45
-
-[x] click entities in the list to select them.
54
+
-[ ] select entities
55
+
-[ ] look up entities by name
56
+
-[ ] from the scene using picking
57
+
-[x] from the inspector
58
+
-[ ] show selected entities in the inspector
59
+
-[ ] clearly show selected entities in the world via an outline
60
+
-[ ] one entity
61
+
-[ ] multiple entities
46
62
-[ ] components of selected entity are shown in the inspector with component values, including components specific to the user's game
47
63
-[ ] resources can be inspected, showing their values
48
64
-[ ] loaded assets can be inspected, providing basic information about them
49
65
50
66
## Stage 2: Basic Editing Capabilities
51
67
52
-
-[ ] undo-redo abstraction
53
-
-[ ] entities can be added and removed
54
-
-[ ] components and resources can be added, removed, and modified
68
+
After this milestone, the scene viewer can be used to make very simple changes to scenes, allowing it to be used as a simple level editor tool.
69
+
70
+
Additionally, the inspector can and should be spun out and shipped as a helpful first-party dev tool.
71
+
72
+
-[ ] entities can be spawned
73
+
-[ ] components can be added or removed from entities
74
+
-[ ] resources can be added or removed
75
+
-[ ] the values of components and resources can be modified
76
+
-[ ] interactive transform gizmo in the viewport that modifies all selected objects
55
77
-[ ] scenes can be saved back to disk
56
-
-[ ] interactive transform gizmo in the viewport
57
-
-[ ] translation
58
-
-[ ] scale
59
-
-[ ] rotation
60
-
61
-
## Stage 3: Editor-Game Interaction
62
-
63
-
-[ ] provide the editor with access to the game's code, allowing it to correctly initialize objects
64
-
-[ ] game-specific rendering techniques display correctly in the editor's scene editing
65
-
-[ ] users can press a button in the editor, launching the game from the very beginning
66
-
-[ ] users can press a button in the editor, and their game will run, loading the currently active scene
67
-
-[ ] asset hotreloading, allowing changes in the asset file to be reflected in the editor and game views
68
-
-[ ] components that reference assets can be changed to load a new asset via a file dialog
69
-
-[ ] entity hierarchies can be spawned and despawned via a GUI
70
-
-[ ] manually
71
-
-[ ] by composing scene files
72
-
-[ ] distinct editor and game views that can be run simultaneously
73
-
-[ ] live edit resource and component data in the editor view while the game is running
74
-
75
-
## Stage 4: UI/UX Foundations
78
+
- .bsn integration would be ideal, but we can read and write .ron scene files well enough to make an MVP
79
+
80
+
## Stage 3: Technical Difficulties
76
81
82
+
After this milestone, we've solved the most critical technical challenges that may force large-scale refactors and rewrites,
83
+
and have the confidence to build more features without accumulating serious technical risk.
84
+
85
+
-[ ] undo-redo abstraction
86
+
-[ ] architecture established
87
+
-[ ] used for all modifications
88
+
-[ ] Bevy Editor can call the bevy_cli
89
+
-[ ] game-defined components can be edited and instantiated
90
+
-[ ] game-specific rendering techniques display correctly in the editor's scene editing
91
+
-[ ] a stand-alone Bevy editor executable or launcher can be shipped as a download
92
+
-[ ] asset hot reloading works inside of the editor, changing assets displayed when the underlying file is modified
93
+
-[ ] Bevy Editor users can press "Run Game", and an appropriate binary for the game will be run in a new window
77
94
-[ ] tooltips
78
95
-[ ] hotkeys
79
-
-[ ] primitive widgets
96
+
-[ ] standardized framework to add these
97
+
-[ ] centralized list for users to view the hotkeys
98
+
-[ ] hotkeys for our actions
99
+
-[ ] keyboard-based UI navigation
100
+
101
+
## Stage 4: Design Time
102
+
103
+
After this milestone, we will have the raw components needed to quickly build out new UI-based features in a consistent, polished fashion.
104
+
105
+
Additionally, these widgets will be useful for Bevy's examples, users and other dev tooling.
106
+
107
+
-[ ] mockup demonstrating what an ideal out-of-the-box 1.0 editor would look like
108
+
-[ ] clear written and visual guidelines for exactly what the "default Bevy editor theme" looks like and cares about
109
+
-[ ] Bevy Editor themed widgets (built on top of headless widgets)
80
110
-[ ] text entry
81
111
-[ ] numeric entry
112
+
-[ ] file path entry
82
113
-[ ] radio buttons
83
114
-[ ] dropdown
84
115
-[ ] checkboxes
85
116
-[ ] slider
86
117
-[ ] color selector
87
118
-[ ] image preview
88
-
-[ ] file path entry
89
119
-[ ] progress bar
90
120
-[ ] audio playback widget
91
-
-[ ] editor UI foundations
121
+
-[ ] editor-specific widgets
92
122
-[ ] resizable panes
93
123
-[ ] scrollable tool detail panels
94
124
-[ ] toolbar
95
125
-[ ] Blender-style workspaces
96
126
-[ ] context menus
97
127
-[ ] command palette
98
128
-[ ] toggleable fullscreen panes
99
-
-[ ] dedicated hotkeys and controls for the most common operations:
100
-
-[ ] manipulating camera
101
-
-[ ] modifying transforms
102
-
-[ ] toggling visibility
103
-
-[ ] adding and removing entities
104
-
-[ ] saving the project
105
-
-[ ] opening the command palette
129
+
-[ ] exclusively use these widgets in the editor itself
106
130
107
-
## Stage 5: Fundamental Features
131
+
## Stage 5: End-to-end projects
108
132
109
-
-[ ] preferences
110
-
-[ ] hotkey rebinding
111
-
-[ ] camera controls
112
-
-[ ] preferred language
113
-
-[ ] scene object picking: click on objects in the scene to select them in the inspector
114
-
-[ ] entities can be looked up by name in the inspector
115
-
-[ ] system stepping support
116
-
-[ ] create new Bevy project
117
-
-[ ] blank
133
+
After this milestone, users will be able to download the Bevy editor and use it to get started with Bevy.
134
+
135
+
The completion of this milestone represents the first true MVP of a "Bevy editor", and the point where we should consider shipping this as an experimental alpha editor to experienced Bevy users,
136
+
and moving it to live inside of the `bevyengine/bevy` repository.
137
+
138
+
-[ ] download the Bevy editor as a standalone executable
0 commit comments