@@josepadillacampos4206 It is definitely easier and flexible. I don't have much experience with unity and react but bevy ui is a little hard for me. btw I'm not professional I have only built small games using raylib and godot so I could be wrong.
I've used HTML/XML syntax my whole life, but I have to admit that the proposed BSN syntax looks really good. Looks really promising, and a step up from existing libraries for Bevy, if they can execute their vision fully !
This is very interesting. I’m following your recent game tutorial, but on a bigger picture level I am also looking at implementing desktop apps in Rust. I’ve been playing with Dioxus for a UI and it seems to work well. It would be interesting to consider a Bevy based application UI. My concerns would be excessive frame redraws and accessibility support (screen readers, etc…). I am also very interested in a future Bevy editor. The Unity Editor made it very easy to get started.
I know accessibility will be a big priority, the team seems to always want to improve on that. Desktop apps with Bevy seem to be a growing area of interest but it's unclear how the future will look
I definitely think it's important to look at prior success stories for Rust UI frameworks. I think a good example would be Leptos, which seems to have all the same functionality goals that Cart outlined. The key difference is using Bevy's System architecture instead of Leptos' signals. Ideally, I would like a Bevy UI to be Leptos tbh.
@@logicprojects Leptos is really interesting and definitely look into it. I'm working on some minor issues on Bevy as my first big contributions to an open source project (biggest PR so far is only +1,000 / -2,000) I want to try and prototype actually using Leptos itself with Bevy, since it supports a custom rendering engine beyond just HTML with its view! macro (which is very similar to rsx!)
One objection I have the bsn! macro is that it looks like declarative code (e.g., maybe functional code that would be returning scene info), but it's actually imperative code that's modifying things in the background. That feels very unrustlike. I've also had nothing but negative experiences with embedding one language into another. That tends to lead to abominations like PHP.
So far I have been using bevy_egui in my project. It is quite simple to do stuff. But I do not use the UI much, just for basic stuff, like a spawn button and a text input field. When I used the default bevy UI, it was quite wordy. Too much code even for simple stuff. This change looks nice. But I can not really compare it with any other option than egui as I did not use anything else yet as having nice UI has not been my goal yet. But using this for spawning entities with components and children hiearchy based on composeble templates is something that I could use.
"The cool thing about proc macros in Rust is that they often work well with the Rust Analyzer out-of-the-box, so all of your Rust plugins should easily pick it up and create a seamless developer experience.". 😂
so i just recently got into rust and bevy, and i wonder. why do people want an editor? i actually prefer the code-only and modular style of bevy, so ... honestly going to an editor-heavy style such as unity or godot will be a downgrade.
I also feel the same way and I think bevy will always support code only approaches. Most people expect an editor from modern game engines though and it will be nice for laying out complex scenes. I'm hoping it ends up being a glorified bsn creator and most of the work is still in code just loading the bsn files
Because a lot of people working on a game in a team aren't programmers. You shouldn't need to find & adjust respective code to tweak or adjust something. Its just less time consuming overall and more practical.
It's a no from on the rsx! format. Non-technical users should be able to edit custom html like files. There should a separate dedicated parser outside of rust.
That seems to be a goal for the bsn file format, both human editable and easy to support from other tools and the editor. The macro in code is just a bonus I believe (but maybe the core development should focus on the file format, not the macro support)
Who in their right mind would want to have to recompile an entire rust project to update the background color of their view??? It's a silly gimmick in my opinion. Now if they were to transfer this RSX format to it's own dedicated parseable file outside of rust, my interest is peaked.
@@logicprojects If that is the case, I'm all for it. For this to actually take off, I think it would be advantageous to focus on the external bsn file format it's self, making rust macro support secondary. I've been playing around with the concept of a JSX file format for my own virtual operating system (with lua instead of javascript) for a while now. The best thing these developers can do it externalize the BSN files allowing for hot reloading among other things. I'm all for this now, seems like a wonderful idea. Perhaps they may want to take it a step further however and use a scripting language in place of rust. It may be a bit to heavy for normal user's to have to understand the borrow checker just to make simple user interfaces. Then again, I'm not sure if this project is targeted at "normal users" (web developers 🤮). I do think it'd be worth discussing a secondary abstraction layer though, perhaps something like I've been working on. Treesitter + lua + antlr can do wonders.
I don't think they want to go all the way to a scripting language for this. I did see support for hot reloading in the proposal though so I think that's in the plan and with embedded assets it's possible to ship the final project without needing to send the raw file or interact with a file system at all. The macro support is nice though if they are aiming for this to support scenes beyond ui (for example spawning a prefab entity) but we'll have to wait and see how it all shapes up.
@@logicprojects I agree, I think a scripting language would be a bit overkill and could be considered feature bloat. I like this project, seems like it has a lot of potential.
Forcing recompilation to tweak a widget sounds like it could be burdensome. Forcing recompilation to tweak the origin transform of an object is an absolute non-starter. We're missing a layer of separation.
I'm actually rather surprised at how really very unworkable the included UI system is. Supports only very basic layouts, very basic interactions, and requires a metric f-ton of error-prone boilerplate. On top of that there's no real guides on how to make a game UI in bevy, only a few examples on the GitHub and a lot of developer tool level UI guides. A lot of the time I think you're just better off using clickable sprites with tags and your own logic, at least that makes them conform to the scaling mode of the game itself and respects the camera settings. I'm really happy that some work is being done on this, because developing anything in Bevy right now is just a nightmare. Too bad we're not gonna see any results for a year, but at least it's being worked on.
I think that the most important fact here is that Cart is now fully working on the UI/Scene in Bevy, and this means that this part of the project will move forward. On top of that the community and expertise, prior work is big enough that this reach a good architecture/concept quicker than for other part ( think scheduling). And even if does not, we know Bevy is happy to overhaul things along the way. So as you say, I expect first prototypes of this project in 2024 (perhaps not 'early' 2024), and then several years of improvements, but the ball is rolling now on UI/Editor !
Hoping to see more Bevy development update posts. I think it's what most of us that are interested in Bevy are looking for anyways right now, rather than actual Bevy game development.
I think UI should use pure ECS. You could add a system to UI components to run every tick, but instead we prefer using reactive design. Reactive design should be supported in underlying ECS- similar to schedules. Reactive design might mean custom implementation of widget updates. - Define "update" or "redraw". Is this always required on every resize event? Do we need to redraw if same pixels, but different location on screen? - In a VList, we should not need to redraw every item if we append a new item. How can VList make this optimization? - If a VList is inside a ScrollContainer, we should skip drawing list items out of bounds. This is complicated when items have different sizes though. #[derive(Component)] struct VList; impl Widget for VList { fn update(&self) { // called when resized? called when parent resizes? where is the rendering actually happening? // this is where I'd imagine is the implementation of VList, which decides the new position of each element. } }
I hate UI so much... I just want something simple like egui, I want to place some standard components down (labels, buttons, sliders, ...) and maybe get mouse events on colliders or just screen regions.
Everyone hates UI, but everyone needs it. That is why we need something that is quick to change/easy to write and allows all the customization and styling. It should be as little friction as possible.
As a Swift developer who has recently been using SwiftUI, and a long-time Compose developer in Kotlin-land.. I really like this. It leans a bit closer to SwiftUI, and I'd like to see it go a little further and handle UI states specially (still Components, but specialized for UI when coerced).
I think Cart is thinking about something like that. He mentioned a few times that he was avoiding calling things components in his prototype so there might be a new concept soon
Always start with the existing tools, maybe not bevy internal ui but the others that Cart listed seem like good places to experiment. This might not be ready for 6 months and there's no point in waiting on something that is still just a proposal
@@logicprojects In your opinon, which current UI option seems closest to the proposed Bevy UI? I dont have lots of spare time so i'd like to learn something that will be most relevant to these proposed changes.
kayak is most similar but I don't think it will be updated to 0.11 soon. Currently I'd stay away from UI in bevy and focus on learning the other parts of the engine if you don't have much time. Things are still in early draft phases
ECS is already a core design to Bevy UI. I hope it will be good as Godot's UI - best in class in my experience.
hopefully better, godot ui isn't that flexible, it's just easy to understand and build stuff in as long as it's pretty simple.
Is Godot UI better than Unity UI?
I am a frontend developer and I miss not having a system like React...
@@josepadillacampos4206 It is definitely easier and flexible. I don't have much experience with unity and react but bevy ui is a little hard for me. btw I'm not professional I have only built small games using raylib and godot so I could be wrong.
@@josepadillacampos4206 Idk I haven't used unity ui very much. I just know godot ui has some series limitations.
I've used HTML/XML syntax my whole life, but I have to admit that the proposed BSN syntax looks really good. Looks really promising, and a step up from existing libraries for Bevy, if they can execute their vision fully !
this ui is what i want, good for coder from react, I think this is good start for bevy ui.
This is very interesting. I’m following your recent game tutorial, but on a bigger picture level I am also looking at implementing desktop apps in Rust. I’ve been playing with Dioxus for a UI and it seems to work well. It would be interesting to consider a Bevy based application UI. My concerns would be excessive frame redraws and accessibility support (screen readers, etc…).
I am also very interested in a future Bevy editor. The Unity Editor made it very easy to get started.
I know accessibility will be a big priority, the team seems to always want to improve on that. Desktop apps with Bevy seem to be a growing area of interest but it's unclear how the future will look
I really like this idea. I've been using this style for interface construction for HTML for a while and have grown to love it.
How are you using this style instead of HTML , what libraries?
@@shrin210 I've been using tide along with tide-jsx for this type of component-based style. And yes, this is rendering to HTML.
Yeah, currently developing a game almost entirely in Bevy UI and to say the least... It sucks. Very excited about the new proposal :)
I definitely think it's important to look at prior success stories for Rust UI frameworks. I think a good example would be Leptos, which seems to have all the same functionality goals that Cart outlined. The key difference is using Bevy's System architecture instead of Leptos' signals. Ideally, I would like a Bevy UI to be Leptos tbh.
I haven't heard of that before, I'll check it out. I wonder if someone has already tried tying their design into bevy
@@logicprojects Leptos is really interesting and definitely look into it. I'm working on some minor issues on Bevy as my first big contributions to an open source project (biggest PR so far is only +1,000 / -2,000)
I want to try and prototype actually using Leptos itself with Bevy, since it supports a custom rendering engine beyond just HTML with its view! macro (which is very similar to rsx!)
I'm hoping to play with bsn soon. An ergonomic was of representing changes over time in both UI and 3D scene component values will be very valuable.
One objection I have the bsn! macro is that it looks like declarative code (e.g., maybe functional code that would be returning scene info), but it's actually imperative code that's modifying things in the background. That feels very unrustlike. I've also had nothing but negative experiences with embedding one language into another. That tends to lead to abominations like PHP.
I'm curious if Bevy could take advantage of the libraries written for Iced's UI elements.
So far I have been using bevy_egui in my project. It is quite simple to do stuff. But I do not use the UI much, just for basic stuff, like a spawn button and a text input field.
When I used the default bevy UI, it was quite wordy. Too much code even for simple stuff. This change looks nice. But I can not really compare it with any other option than egui as I did not use anything else yet as having nice UI has not been my goal yet.
But using this for spawning entities with components and children hiearchy based on composeble templates is something that I could use.
Hey that looks pretty nice
"The cool thing about proc macros in Rust is that they often work well with the Rust Analyzer out-of-the-box, so all of your Rust plugins should easily pick it up and create a seamless developer experience.". 😂
Does Bevy have the ability for us to add our own screenspace shaders (post) ?
Yes. I think there's an post processing example on the github
@@logicprojects - thanks, yeah, I noticed later on. Back in 2022. Bevy is coming together very nicely. Already a ton of functionality in there.
so i just recently got into rust and bevy, and i wonder. why do people want an editor? i actually prefer the code-only and modular style of bevy, so ... honestly going to an editor-heavy style such as unity or godot will be a downgrade.
I also feel the same way and I think bevy will always support code only approaches. Most people expect an editor from modern game engines though and it will be nice for laying out complex scenes. I'm hoping it ends up being a glorified bsn creator and most of the work is still in code just loading the bsn files
Because a lot of people working on a game in a team aren't programmers. You shouldn't need to find & adjust respective code to tweak or adjust something.
Its just less time consuming overall and more practical.
b e v u i
It's a no from on the rsx! format. Non-technical users should be able to edit custom html like files. There should a separate dedicated parser outside of rust.
That seems to be a goal for the bsn file format, both human editable and easy to support from other tools and the editor. The macro in code is just a bonus I believe (but maybe the core development should focus on the file format, not the macro support)
Who in their right mind would want to have to recompile an entire rust project to update the background color of their view??? It's a silly gimmick in my opinion. Now if they were to transfer this RSX format to it's own dedicated parseable file outside of rust, my interest is peaked.
@@logicprojects If that is the case, I'm all for it. For this to actually take off, I think it would be advantageous to focus on the external bsn file format it's self, making rust macro support secondary. I've been playing around with the concept of a JSX file format for my own virtual operating system (with lua instead of javascript) for a while now. The best thing these developers can do it externalize the BSN files allowing for hot reloading among other things.
I'm all for this now, seems like a wonderful idea. Perhaps they may want to take it a step further however and use a scripting language in place of rust. It may be a bit to heavy for normal user's to have to understand the borrow checker just to make simple user interfaces. Then again, I'm not sure if this project is targeted at "normal users" (web developers 🤮). I do think it'd be worth discussing a secondary abstraction layer though, perhaps something like I've been working on. Treesitter + lua + antlr can do wonders.
I don't think they want to go all the way to a scripting language for this. I did see support for hot reloading in the proposal though so I think that's in the plan and with embedded assets it's possible to ship the final project without needing to send the raw file or interact with a file system at all. The macro support is nice though if they are aiming for this to support scenes beyond ui (for example spawning a prefab entity) but we'll have to wait and see how it all shapes up.
@@logicprojects I agree, I think a scripting language would be a bit overkill and could be considered feature bloat. I like this project, seems like it has a lot of potential.
7:27 *patrons
Words are hard :/
Forcing recompilation to tweak a widget sounds like it could be burdensome.
Forcing recompilation to tweak the origin transform of an object is an absolute non-starter.
We're missing a layer of separation.
Yeah that's what I think the goal of the scene format is. Get everything into a text file that will work with hot reloading
I'm very excited for Bevy Editor. I hope it is Simple and Powerful and Lightweight like Godot is. Is it achievable? My guess is yes!
Seems to be the goal and so far they haven't let us down
I'm actually rather surprised at how really very unworkable the included UI system is. Supports only very basic layouts, very basic interactions, and requires a metric f-ton of error-prone boilerplate. On top of that there's no real guides on how to make a game UI in bevy, only a few examples on the GitHub and a lot of developer tool level UI guides. A lot of the time I think you're just better off using clickable sprites with tags and your own logic, at least that makes them conform to the scaling mode of the game itself and respects the camera settings. I'm really happy that some work is being done on this, because developing anything in Bevy right now is just a nightmare. Too bad we're not gonna see any results for a year, but at least it's being worked on.
Not to mention the UI is fixed to the camera. Forget naming UI that follows the player character in a local coop.
I think that the most important fact here is that Cart is now fully working on the UI/Scene in Bevy, and this means that this part of the project will move forward. On top of that the community and expertise, prior work is big enough that this reach a good architecture/concept quicker than for other part ( think scheduling). And even if does not, we know Bevy is happy to overhaul things along the way.
So as you say, I expect first prototypes of this project in 2024 (perhaps not 'early' 2024), and then several years of improvements, but the ball is rolling now on UI/Editor !
Hoping to see more Bevy development update posts. I think it's what most of us that are interested in Bevy are looking for anyways right now, rather than actual Bevy game development.
Yeah, it's harder to make videos like this though. I might experiment with more like this showing off the new asset system if people like the style
I think UI should use pure ECS. You could add a system to UI components to run every tick, but instead we prefer using reactive design. Reactive design should be supported in underlying ECS- similar to schedules.
Reactive design might mean custom implementation of widget updates.
- Define "update" or "redraw". Is this always required on every resize event? Do we need to redraw if same pixels, but different location on screen?
- In a VList, we should not need to redraw every item if we append a new item. How can VList make this optimization?
- If a VList is inside a ScrollContainer, we should skip drawing list items out of bounds. This is complicated when items have different sizes though.
#[derive(Component)]
struct VList;
impl Widget for VList {
fn update(&self) {
// called when resized? called when parent resizes? where is the rendering actually happening?
// this is where I'd imagine is the implementation of VList, which decides the new position of each element.
}
}
Interesting, I think bevy has some support for what you are describing with run conditions
I'm just an appreciator of all the interesting work in this community. Hope one day I can make some contributions too.
I hate UI so much... I just want something simple like egui, I want to place some standard components down (labels, buttons, sliders, ...) and maybe get mouse events on colliders or just screen regions.
Yeah, I've been very satisfied with egui and left flutter for it. So I'm not super sold on the rsx stuff
Everyone hates UI, but everyone needs it. That is why we need something that is quick to change/easy to write and allows all the customization and styling. It should be as little friction as possible.
Start video from the demonstration of the result of using plugings.
It's better to show place of these lines of code in an entire project. I'am begginer, I cannot understand where I can put them.
As a Swift developer who has recently been using SwiftUI, and a long-time Compose developer in Kotlin-land.. I really like this. It leans a bit closer to SwiftUI, and I'd like to see it go a little further and handle UI states specially (still Components, but specialized for UI when coerced).
I think Cart is thinking about something like that. He mentioned a few times that he was avoiding calling things components in his prototype so there might be a new concept soon
Is it worth waiting for this new UI system to be implemented, or should I start using the existing UI?
Always start with the existing tools, maybe not bevy internal ui but the others that Cart listed seem like good places to experiment. This might not be ready for 6 months and there's no point in waiting on something that is still just a proposal
@@logicprojects In your opinon, which current UI option seems closest to the proposed Bevy UI? I dont have lots of spare time so i'd like to learn something that will be most relevant to these proposed changes.
@@liamhamilton2719 Probably KayakUI.
kayak is most similar but I don't think it will be updated to 0.11 soon. Currently I'd stay away from UI in bevy and focus on learning the other parts of the engine if you don't have much time. Things are still in early draft phases
@@logicprojects That is solid advice!
As a former React developer, I both hate and love this!
Yeah I've heard some people hate having Bevy looking more like their day jobs