Replies: 4 comments 5 replies
-
|
Just tossing an idea out, but I personally believe that bevy could use a custom scene filetype that allows for linking individual objects to components and bundles and essentially acts as a setup system when spawned. That would allow for an editor with pretty verbose application and little complexity for users. |
Beta Was this translation helpful? Give feedback.
-
|
Does the current scene format or the proposal for a new scene format address your idea here? |
Beta Was this translation helpful? Give feedback.
-
|
@ickk yes that new bsn format seems ideal. |
Beta Was this translation helpful? Give feedback.
-
|
I would add Blender to the external editors, while not a game editor anymore (Rip Blender game engine) it is still an industry standard and can be a good source of UI elements and things bevy can learn from, especially the shader/geometry nodes system can be a very good parallel will bevy's ECS system and shading. |
Beta Was this translation helpful? Give feedback.
-
|
I would add Source 2's Hammer editor to this as well. The ability to just 3D model right in the editor in Hammer is just amazing for usabilty and allows for rapid 3D level prototyping. Not sure if Bevy wants to tackle that as well, but personally I would love it. Hammer (Source 2) - Mesh Editing Also definitely Blender hotkeys, makes working in 3D so great. |
Beta Was this translation helpful? Give feedback.
-
|
yes |
Beta Was this translation helpful? Give feedback.
-
|
My primary issue I am facing with my personal bevy editor is the lack of any kind of standard scene system (besides bevy_scene). Bevy (by design) allows you to swap out everything so creating a general purpose editor around it just seems impossible. There's GLTF, but there's also blueprint like, prefab like third party plugins as well. So in the end I ended up creating a 'Bevy Engine Debugger' which simply allows me to select what to load (either scenes or gltf or blueprints) and interact with the game. The rest of the game editing is done within blender with the bevy components and auto export plugins. (Some of the proposed goals in my opinion will end up creating a rather bad developer experience due to being integrated within the game so the thoughts below are assuming that an external editor is one of the possible solutions) What I also see being rather difficult are physics and general "play-pause" functionality. Would it just spawn the game in another window and synchronize the components, but then what about the compile workflow? Should the editor be an external bevy application and connect to the game, but then what about the component information - how would the editor know about what the game is made out of? Currently there is bevy registry export which is used for the blender plugin which does allow assigning components to gltf entities which does indeed work. Taking all of that into account I think that having bevy_editor be some kind of a 'server' external ui application that games connect to while the game itself would include bevy_editor_client which would connect to the editor and synchronize data (or the other way around). The editor being a server would allow to manage multiple game instances which could be useful for testing multiplayer and other functionality. The challenge as I mentioned before would be synchronizing component information, but it seems rather trivial as bevy registry export already exists. This also allows us to launch the game in 'headless' mode and keep the game editor open instead of having a new window appear every time we want to recompile the game and run it in non-headless to view graphics since the editor would not be able to understand shaders and other information to view in the editor except for maybe having a shared buffer that hides the game window and shows the contents in the editor (similar to unity Game View). I am not sure how I would handle saving / loading scenes assets and other information this way, but I'm sure that it could be done in the bevy_editor_client. However, that has different issues - what about the default game loading logic? What if the game uses some kind of bevy_asset_loader plugin how would that work? Standardization seems needed - but that's not what bevy is about. |
Beta Was this translation helpful? Give feedback.
-
|
@NthTensor has started a very helpful list of design questions here: https://hackmd.io/0urMiAXOQX6ul2f6Jbk4jQ?edit |
Beta Was this translation helpful? Give feedback.
-
|
Great writeup! Thanks for linking it. |
Beta Was this translation helpful? Give feedback.
-
Bevy Editor Prototypes
Intro
Bevy currently lacks a visual editor - some way of visually viewing and modifying assets, displaying debug info and performing other tasks that really just want a GUI.
But what does it mean to have a
bevy_editor? The answer is, we don't quite know yet!No Bevy crate (ECS schedules, rendering, etc) was written perfectly on the first try. It's often the case that you don't know what code to write until you've already tried writing it.
Before we can have a bevy_editor, we're going to need a series of bevy_editor_prototypes. To that end, we've put together this project as the official exploration around learning what we want an eventual bevy_editor to be.
If you're an engine or tools dev who wants to help build Bevy's editor, you're in the right place! If you're a user looking for an editor for your Bevy app, you probably won't be happy with the level of features, stability, polish and documentation in these prototypes, but we do want to hear about what you find helpful, inspiring or pointless.
Project scope
This project is an experiment. The goal is not to produce a final, usable editor, but to understand what users will want out of a bevy_editor, and investigate unsolved technical questions. By the end of the project, we should be in a good position to write the actual bevy_editor.
To keep the project focused, we will be developing in multiple phases. Each phase will have a different focus, with the goal of answering specific questions about a future bevy_editor. Development will be taken one phase at a time, and will move onto the next phase once we feel we've explored enough of the problem and solution space for each phase.
If you're interested in working on the editor, but not the current phase, we encourage you to experiment in your own repo while we work on the current phase, and then share your findings when we get to that point later on.
How you can help!
We have lots of open questions, and lots of discussion, but no code! That's where you (and the rest of the Bevy developer community) come in!
We'll be using git branches in the bevy_editor_prototypes repo with a very permissive merge policy to manage the various prototypes. If there's a prototype that looks promising to you, fork the branch, write some code, and open a PR :)
If you think there's a promising direction our existing prototypes haven't explored, create a new prototype and open a PR to create a new branch.
Everyone in the Bevy organization (well, technically the Triage Team) has write permissions to this repo 🍿 Try not to obliterate other people's stuff without asking, but generally speaking, feel emboldened to experiment!
If you'd like to join this not-very-exclusive club, contribute a bit to Bevy (including these prototypes), then reach out to the maintainers for access.
For discussion on the prototype editors, join #editor-dev on our Discord. For more durable discussions, please post your write-ups to the Github Discussions page on the bevy_editor_prototypes repo.
Phases
Phase 1
Phase 2
Phase 3
Prior discussion
Bevy-specific prior art
External editors to learn from
Beta Was this translation helpful? Give feedback.
All reactions