Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bevy Foundation

bevyengine.org

Post reply on HN
Print view View original

61–70 of 82 posts

Re: The Bevy Foundation

#61

Post by adastra22 »

alice-i-cecile wrote: post #49
adastra22 wrote: post #43

Earlier quoted context omitted.

The release notes are great btw. Usually if I’m doing something for the first time I look it up in the bevy cheat book, get something that doesn’t work (because it’s two or three versions out of date), then check the intervening release notes. Usually there’s enough direction to figure it out.

They're so, so much work. Carefully going over the log, and patiently explaining / showcasing and contextualizing them is even more work than writing docs for the same feature, since you don't have the API to help structure things. I'm glad it pays off! Seeing them come together makes my day every time, even when I'm writing half of it.

Oh, I know! I’m a maintainer of another open source project and the release notes are such a chore. For the quality of Bevy’s I could easily see it being a full time job, albeit a mostly thankless one. So thank you for the effort you’ve put in!

Re: The Bevy Foundation

#62

Post by brundolf »

Does Bevy have a graphical editor yet (or one on the roadmap)?

It seems like it has good bones, but taking real territory away from Unity or Godot will be hard without an editor (not just for non-programmers; some game dev tasks are just way easier with a GUI)

Of course it's open so somebody could build one, but it seems to me this deserves to be a first-class citizen

Re: The Bevy Foundation

#63

Post by voxal »

brundolf wrote: post #62

Does Bevy have a graphical editor yet (or one on the roadmap)? It seems like it has good bones, but taking real territory away from Unity or Godot will be hard without an editor (not just for non-programmers; some game dev tasks are just way easier with a GUI) Of course it's open so somebody could build one, but it seems to me this deserves to be a first-class citizen

Bevy is working on a graphical editor, but its still in its prototyping phase.

https://bevyengine.org/news/bevy-0-13/#more-editor-experimen...

Re: The Bevy Foundation

#64

Post by LarsDu88 »

Love where Bevy is going. On the UI/UX side it has a long way to go, but on the non-rendering backend architecture side it can beat Unity, Unreal, and Godot in the long run.

Just crossing my fingers because by the time Bevy reaches that goal, compute power may have just 10x'd again, and the existing game engine giants will have added AI creation tooling by then.

Re: The Bevy Foundation

#65

Post by mostlysimilar »

LarsDu88 wrote: post #64

Love where Bevy is going. On the UI/UX side it has a long way to go, but on the non-rendering backend architecture side it can beat Unity, Unreal, and Godot in the long run. Just crossing my fingers because by the time Bevy reaches that goal, compute power may have just 10x'd again, and the existing game engine giants will have added AI creation tooling by then.

Can't wait for the days when bug reports are closed with "don't know why this is happening, the AI did it, can't fix"

Re: The Bevy Foundation

#66

Post by the__alchemist »

noelwelsh wrote: post #26

I've been using Bevy recently so here are some thoughts on this: Firstly, the overall quality is high and seeing this attention being paid to the project's organization is another good sign. Documentation is not great. The Bevy book runs out of content very quickly. The "Cheat Book" has additional useful information: https://bevy-cheatbook.github.io/ . With these plus the examples I've been able to figure out everyth…

A note on the ECS: This is largely due to poor understanding on my part, but I moved my computational chemistry (egui-based) GUI program (Visualizes various wave function properties) from Bevy to WGPU directly, because the ECS was difficult to grok and debug. It felt like more work to reinvent wheels regarding rendering than manipulate the ECS. I had it working in Bevy, but ported. Not a canonical use case for a game engine!

It's been ~2 years, but my main reason was wanting to write plain rust, vice using a DSL.

Re: The Bevy Foundation

#67

Post by LegibleCrimson »

999900000999 wrote: post #60
alice-i-cecile wrote: post #42

Earlier quoted context omitted.

https://github.com/bevyengine/bevy-website/issues/1097 Yep, on our wishlist and will be added :)

Thanks, I'll donate soon. Also this is a long shot, but any chance of supporting higher level languages. Maybe it calls the underlying Rust code from C#

I think that's impossible. Bevy works heavily with Rust types and generic monomorphization. You couldn't do that in another language without literally generating Rust code and calling the compiler.

Re: The Bevy Foundation

#68

Post by mkesper »

alice-i-cecile wrote: post #49
adastra22 wrote: post #43

Earlier quoted context omitted.

The release notes are great btw. Usually if I’m doing something for the first time I look it up in the bevy cheat book, get something that doesn’t work (because it’s two or three versions out of date), then check the intervening release notes. Usually there’s enough direction to figure it out.

They're so, so much work. Carefully going over the log, and patiently explaining / showcasing and contextualizing them is even more work than writing docs for the same feature, since you don't have the API to help structure things. I'm glad it pays off! Seeing them come together makes my day every time, even when I'm writing half of it.

And I know so many people who think you could automate them from commit messages. Hell, no!

Re: The Bevy Foundation

#69

Post by james7132 »

999900000999 wrote: post #60
alice-i-cecile wrote: post #42

Earlier quoted context omitted.

https://github.com/bevyengine/bevy-website/issues/1097 Yep, on our wishlist and will be added :)

Thanks, I'll donate soon. Also this is a long shot, but any chance of supporting higher level languages. Maybe it calls the underlying Rust code from C#

A scripting language is an explicit non-goal for first-party support, but there have been tools for using the ECS entirely without Rust types which can be exposed via FFI or embedded languages like Lua.

Just search "_by_id" in the bevy_ecs docs, and you'll find all of the associated APIs for access. There are then (unsafe) APIs for creating the internal mappings necessary to use them. These are normally called via the monomorphized generics automatically, but need to be manually called since we don't have compile time knowledge of the data being stored and accessed.

Re: The Bevy Foundation

#70

Post by harrisi »

alice-i-cecile wrote: post #48
noelwelsh wrote: post #47

Earlier quoted context omitted.

Most games have different states. For example, you have the main menu screen and perhaps different levels. Each of these could be a state. I think Bevy already has an abstraction for this[0] but it only records the current state. There is no other information associated with it IIUC. What I think would be useful is essentially an arena allocator associated with a state. So any components and entities created when a s…

Ah okay! I can see the need for this. This is a large part of why the States machinery exists, but I see your point about it being error-prone to remember to tag and then despawn everything. I'll chew on solutions here: we might be able to get away with a nice well-documented convention in user-space code, or we may need to add a small extension to the internals to make this more robust.

Isn't the typical way to do this by using a janitor? This would typically need to be done in user space (the framework doesn't know what cleanup you want to do), but Bevy could provide an interface for it with callbacks or whatever is more idiomatic in Rust/Bevy.
Post reply on HN