[HN Gopher] Bevy 0.13: ECS-driven game engine built in Rust
___________________________________________________________________
Bevy 0.13: ECS-driven game engine built in Rust
Author : _cart
Score : 90 points
Date : 2024-02-17 20:01 UTC (3 hours ago)
(HTM) web link (bevyengine.org)
(TXT) w3m dump (bevyengine.org)
| _cart wrote:
| Bevy's creator and project lead here. Feel free to ask me
| anything!
| Jamustico wrote:
| What did you have for lunch
| _cart wrote:
| Haven't eaten yet, but I'm planning on having a lentil / beef
| / mushroom curry I made earlier.
| stefanos82 wrote:
| That sounds delicious! Recipe please ^_^ !
| _cart wrote:
| Pretty straightforward process / I just made it up. Throw
| some olive oil in an Instant Pot, add beef and sear (no
| need to fully cook, just brown it), add ~4 cups of water
| and ~2 cups of lentils (I eyeball these), throw in
| chopped onions / bell peppers / mushrooms / garlic, add
| spices (plenty of turmeric + generic store bought "curry
| powder", garlic powder, dill, cayenne pepper, salt), and
| the secret ingredient: ~1/2 cup of smooth peanut butter
| (trust me this is very important ... when in doubt add
| more).
|
| (edit: I keep the Saute setting on while im adding
| ingredients and occasionally stir. Then I seal it up,
| turn on the "bean chill" mode on high. And wait 40
| minutes for tasty goodness)
| hasty_pudding wrote:
| This looks like a really cool project!
|
| Is it portable to Browser? Or is that on the roadmap?
| _cart wrote:
| Yup we support both WebGL and WebGPU browser deployments via
| WASM
| hasty_pudding wrote:
| Glorious. This is exciting. Looking forward to seeing
| youalls progress
| iknowstuff wrote:
| I gotta ask newbie questions.
|
| Any concrete plans for a GUI editor?
|
| Does stuff like Lumen/Nanite from UE5 have any chance of
| existing in Bevy?
| james7132 wrote:
| The blog post directly mentions efforts towards a GUI-based
| editor in the "What's next" section.
|
| We can definitely deliver on global illumination in some way,
| as shown with the irradiance volume support added in this
| release, though it may not match Lumen 1:1. Nanite is
| definitely more involved, but worth investigating.
| pcwalton wrote:
| Here are the plans for the editor prototypes: https://github.
| com/bevyengine/bevy_editor_prototypes/discuss...
|
| As far as Lumen goes, there are a few experimental early-
| stage projects that add real-time global illumination to
| Bevy, such as bevy-solari [1]. Most of them rely on hardware
| raytracing support, as this simplifies a lot of things, and
| the new baked GI stuff that just shipped in 0.13 is fine for
| non-RTX. Besides, there's a good chance that hardware
| raytracing support will be very commonplace by the time any
| of this reaches production quality.
|
| For Nanite, the closest thing that's being actively worked on
| is meshlets [2]. These actually are pretty close to ready and
| likely to land in 0.14 (no guarantees of course). These
| provide some, but not all, of the benefits of Nanite. LOD
| features can potentially be layered on top of meshlets in the
| future to provide a solution to roughly the same set of
| problems that Nanite solves, with some advantages relative to
| Nanite and some disadvantages.
|
| [1]: https://github.com/jms55/bevy/tree/solari
|
| [2]: https://github.com/bevyengine/bevy/pull/10164
| mochathoughts wrote:
| In two / three years, where do you see the project?
| _cart wrote:
| Core pillars (including WIP things like Scene, UI, Editor,
| Audio) are in place. Partial or full engine stability (see my
| "partial stabilization discussion:
| https://github.com/bevyengine/bevy/discussions/9789). More
| than a few fully released quality games. More than a few
| fully released quality non-games / tools (we're already
| seeing Bevy being used as a foundation for things like CAD
| software and modeling tools).
| mattcanhack wrote:
| No question, just want to say thanks! I've had a lot of false
| starts trying game tutorials but the ones I found for Bevy were
| really easy to follow. I was working two versions behind and
| the changelog for Bevy was so well done that I was able to
| figure out most of what changed. Bevy was also just
| straightforward to use.
| gaganyaan wrote:
| Are there any good "end to end" examples that show things like
| a splash screen, main menu, pause menu, video settings, that
| sort of thing?
| _cart wrote:
| We don't have a "complete" official example of those things,
| although the "game menu" example has some of that: https://gi
| thub.com/bevyengine/bevy/blob/main/examples/games/...
|
| I recommend checking out Bevy Jam games (which are pretty
| much always open source) for more complete / real world
| examples: https://itch.io/jam/bevy-jam-4
|
| Definitely a bit of a gap in our official learning material.
| Hopefully we can close it soon!
| CrimsonCape wrote:
| Any idea why the example image in the OP link appears to be
| running at sub-optimal framerate?
|
| What is the expected ECS overhead per frame (not including
| graphics interaction, i.e. code specifically in the ECS model)?
|
| Since an ECS is typically a flattened scene graph, is there
| still a game loop? Wouldn't be necessary, correct? You only
| need to respond to the inputs...
| _cart wrote:
| That is a size-optimized webp / gif that isn't running at 60
| fps. The game is butter smooth in practice:
| https://twitter.com/jarl_game
| _cart wrote:
| I would say that the systems in the ECS _are_ the game loop.
| The ECS overhead per frame is kind of hard to measure / it
| depends on the scale of usage. To establish the scale of
| operations: Random single-entity ECS data accesses are a
| sparse array lookup to find the table the entity is in, and
| then an array lookup to find the component in the table.
| Iterating components in a query is roughly the same as
| iterating an array / is very cache friendly. Running
| individual systems is _slightly_ more expensive than a
| function call. Scheduling systems in parallel does introduce
| some overhead (which is currently higher than we'd like /
| we're working on optimizing it), but when you pay that cost
| you get the benefits of everything running in parallel.
| james7132 wrote:
| There is still a game loop that runs every tick. The engine
| wouldn't work so well if we only responded to inputs as they
| come in, event pub-sub style.
|
| As for ECS overhead, I've made it one of my top priorities to
| eliminate it wherever possible since it underpins the entire
| engine. We're at the point where most optimizations are
| saving a few tens or low-hundreds of microseconds per frame
| in your average game/app (i.e. lowering context switch costs
| from parallel system execution). If you're pushing below 60
| FPS in your app, chances are the performance issues are not
| coming from the ECS, but some other part of the engine, or
| the app's own code.
| SkiFire13 wrote:
| > Since an ECS is typically a flattened scene graph, is there
| still a game loop? Wouldn't be necessary, correct? You only
| need to respond to the inputs...
|
| How do you plan to have stuff moving then? You need to update
| their position every frame, so...
| mrec wrote:
| > The built-in collection of primitives is already quite
| sizeable
|
| And yet no teapot! _Literally unusable._
| mochathoughts wrote:
| Love the way the Bevy project is moving. In a year or two, this
| project will be a serious alternative to the current Unity /
| Unreal / Godot engines. Getting it right first is vital, and I'm
| glad the team is spending a lot of time perfecting the nitty-
| gritty details before adding features like UI / Editor / etc.
| CooCooCaCha wrote:
| As usual bevy is moving at an impressive pace. Excited for them
| to break ground on the new scene/ui system
| martin-t wrote:
| Honestly, if you wanna see impressive pace, look at Fyrox. It
| has had scenes and UI for ages.
|
| While bevy is a decent piece of tech, it gets way more hype
| than it deserves, especially when there are more mature and
| capable alternatives.
| CooCooCaCha wrote:
| Sure if you only care arbout surface level details like "has
| scenes" and "has a UI system".
| pcwalton wrote:
| I wrote the lightmaps, reflection probes, and irradiance volumes
| support for this release! Bevy has really been a joy to work
| with, and the community is fantastic.
| skybrian wrote:
| What's a gizmo? It seems to be some kind of 3d graphics term, but
| I didn't find a good definition.
| pcwalton wrote:
| The term is kinda fuzzy and means different things in different
| engines, but in Bevy it refers to lightweight 3D wireframe
| overlays that you can use for visual debugging.
| martin-t wrote:
| To the uninitiated, bevy is one of Rust's two main game engines,
| the other being Fyrox.
|
| Bevy, despite being written by an army of contributors is
| continually behind Fyrox which is developed mostly by one guy.
| Fyrox not only has an editor and a UI toolkit, both of which bevy
| devs keep just talking about, it recently also added a UI editor.
| In addition the author is writing 2 games to dogfood Fyrox.
|
| Yet despite all this, Fyrox gets a fraction of the attention and
| money. Maybe it's because it uses proven old tech instead of
| being a resaerch project, maybe it's because the author is
| russian, maybe because people are afraid of a 3D-first engine,
| maybe fyrox doesn't focus on promotion enough. Idk, but here i am
| doing my bit to make the world a tiny bit more fair even if I
| annoy all the bevy fans who kept posting about bevy on every
| single fyrox post that wasn't completely downvoted and ignored.
| whateveracct wrote:
| > Yet despite all this, Fyrox gets a fraction of the attention
| and money.
|
| Heh Bevy sounds like Rust itself. Good PR with money behind it
| is its no1 cause of adoption.
| charlotte-fyi wrote:
| What PR money has been behind Rust?
| charlotte-fyi wrote:
| Your conspiratorial framing here strikes me as odd, as well as
| unnecessarily denigrating Bevy as a "research project." Isn't
| the answer quite obvious, which is that if someone wants to use
| an engine built off "proven old tech", they should probably
| just use one of the major players in the space, and that Bevy's
| uniqueness/commitment to the ECS model is precisely what causes
| it to generate more hype and energy? Is this really an issue of
| "fairness"?
| mcjerry wrote:
| > Isn't the answer quite obvious, which is that if someone
| wants to use an engine built off "proven old tech", they
| should probably just use one of the major players in the
| space
|
| All of the major engines are written in C++. I've tried
| Unreal, Unity and Godot. They all have their flaws. With
| Unreal and Godot those flaws are mainly the scripting
| languages BP and GDScript which one can get tired of quite
| easily, especially BP. You can of course use C++ for all your
| scripting but both engines strongly encourage you to use
| their scripting solution for a big chunk of your game. (Unity
| has a bunch of other issues and isn't source available,
| although C# is fairly pleasant to work with IMO).
|
| There is definitely need for an OOP engine in Rust just as
| there is need for an ECS engine in Rust.
| charlotte-fyi wrote:
| > There is definitely need for an OOP engine in Rust
|
| _Is_ there a need for an OOP engine in Rust?
|
| I don't want to be too negative here -- the developer of
| Fyrox seems like an incredibly talented and productive
| engineer and they can work on whatever they please, more
| options in the ecosystem is always a net good -- but in my
| experience attempting to model OOP patterns in Rust is
| almost always the wrong decision.
| Deukhoofd wrote:
| Looks to me like Fyrox is competing more with Godot or Unity,
| than it is with Bevy. The cool part about Bevy is its ECS
| handling. There aren't a lot of ECS-first game engines, and
| Bevy is one of the few that do exist.
| timeon wrote:
| While I think Fyrox is impressive, reading your comment felt
| like: Sir, This Is A Wendy's
| SeanAnderson wrote:
| I've been building My First Game(tm) using Bevy after teaching
| myself Rust last year. I feel super cool running Rust in WASM in
| the browser! It's been a great experience overall and I highly
| recommend exploring what Bevy has to offer.
|
| The community is really exceptional. I ask questions daily and
| get helpful responses usually within minutes. Bevy hides some of
| the complexities of Rust, such as lifetimes, away from normal
| development. This was a pleasant surprise for someone coming in
| with little awareness of Rust.
|
| Writing in ECS is pretty confusing to begin with and, IMO,
| represents the steepest part of the learning curve. After a while
| ECS starts to feel more natural though and you'll wonder why you
| were ever comfortable doing OOP.
|
| The main sore spots for me are: UI needs a lot of work to be
| ergonomic and beautiful, there's a lot of footguns related to
| performance and event handling/change detection, which do have
| workarounds, but at the cost of ergonomics, and, specifically for
| WASM, everything (including rendering) is still single-threaded
| which makes the app perform worse than well written JavaScript
| for now.
|
| I'd be happy to try and answer any questions about my experience
| as a complete noob to Rust/Bevy/ECS/game development and having
| immersed myself ~full time on a game for the past year.
|
| FYI, you can browse my game's code here:
| https://github.com/MeoMix/symbiants
| mikercampbell wrote:
| Hey!! I'm on the same journey! Yew, but with Bevy ECS and HTML
| as my "rendering engine".
|
| Keep me posted!!
___________________________________________________________________
(page generated 2024-02-17 23:01 UTC)