5 ms·

Bevy 0.10: data oriented game engine built in Rust

146 points by _cart 4y ago

_cart 4y ago
Creator and lead developer of Bevy here. Feel free to ask me anything!
- _ghgp 4y ago
  How far do you think you are from a 1.0 release? What areas do you think need improvement? I've been working on a project in Bevy for the last few weeks, having previously attempted it in TS+pixie.js and Godot. It's been a joy in comparison, with much faster progress - in TS I was constantly fighting the ecosystem, and GDScript is just awful, particularly it's type system. Thank you!
  - _cart 4y ago
    I think we're about 2 years away. Some areas that need work: a visual Bevy Editor (not built yet but we're shifting focus to it this release cycle), audio (we have it but users need finer control), animation (more composition tools and editor integrations), ui (needs more widgets and ux improvements), asset system (I've been working on the next iteration for awhile to enable things like pre-processing assets), nice visual scene editing workflows (implemented inside the upcoming Bevy Editor). Glad you're enjoying Bevy so far!
    - echelon 4y ago
      I'd be happy to donate money specially to support animation (especially morph targets) and drive that forward. [1] We want to make a break from Unreal pixel streaming and Rust on the frontend delivered over WASM/WebGPU would be so ideal. The rest of our stack is Rust, so it would slot right in with our Rust monorepo. [1] I was donating to one of the devs until GitHub removed PayPal payments without warning or mitigation about a week ago. I'll fix that soon.
    - _ghgp 4y ago
      What would you plan to implement in a visual editor? I've found code works perfectly.
      - alice-i-cecile 4y ago
        Scene editing, fast value tweaking (like in bevy_inspector_egui) and more powerful visualization tools for things like schedules are the big "this must be visual" features that I want to land first. Code-first is lovely, but being able to fine-tune things without a recompile is key, and the workflow needs to work for any artists on larger teams too.
- t-eckert 4y ago
  I'm looking to start learning Bevy soon in preparation for the next Bevy Jam. Where can I sign up to be notified when the jam is scheduled?
  - mahulst 4y ago
    The bevy discord has a dedicated channel for the jams!
    - t-eckert 4y ago
      Fantastic! Thank you
- trhr 4y ago
  Can you post on hn when the statement that reads like, "btw don't use this package if you're not cool with breaking changes every four days" leaves your docs? I pretty much immediately decided I wasn't cool with that, even though bevy looks like a really interesting project.
  - sho_hn 4y ago
    It's sort of a cultural tradition in the Rust community to link to interesting or potentially more stable alternatives in READMEs.
    - trhr 4y ago
      https://bevyengine.org/learn/book/introduction/ https://bevyengine.org/learn/book/introduction/ The problem is that "the prototyping phase" isn't a real phase, and this doesn't specify if breaking changes will occur between major, minor, or patch versions. It gives developers no guidance of what semver to track based on their own willingness to endure breaking changes. Using a library that still can't tell you that is just asking for trouble.
      - nicoburns 4y ago
        > this doesn't specify if breaking changes will occur between major, minor, or patch versions The entire Rust ecosystem works on a model of breaking changes for 0.x version happening in minor but not patch releases. In fact, I'm struggling to think of any software project that intentionally releases breaking changes in patch releases.
        trhr 4y ago
        I'm not sure what we're arguing about. You say "don't break bugfix releases." I say "don't break bugfix releases." Docs don't say "we don't break bugfix releases." Instead, docs say "we break all the time don't trust us" instead of "pin to a minor version if you don't want to break all the time." It's specifically not a question of knowing how the Rust community usually does these things, it's a question of "does this package conform to Rust's semver conventions, the official semver conventions, or something custom?" The statement, _as its written in the docs_ implies "we do something custom." Whether that's true or not is irrelevant. I read it, interpreted it as a lack of governance or adherence to standards, and moved on. Any professional engineer would do the same.
- politician 4y ago
  Thanks! I have some questions about integrating ECS with cross-platform concerns. How did you tackle the problem of components containing geometry for platform-specific graphics engines? Does Bevy use platform-specific components? If an application needs multiple offscreen textures to compose a frame, are there components that contain metadata for which passes they belong to (so, now, platform and pass specific components)?
  - nicoburns 4y ago
    Bevy uses wgpu as it's graphics engine, which is cross-platform.
  - _cart 4y ago
    We handle this class of problem in a few different ways: 1. We build on top of cross platform abstractions with feature detection (wgpu is our cross platform low level graphics library, cpal is that for audio, etc). We build our features in a way that adjust the ECS app logic according to what features are available at runtime 2. In a few cases we do "compile time feature/platform detection" to select the appropriate code for a given platform. But most "Bevy features" don't use this / we opt for (1) more than anything else In the case of geometry: that has a "dynamic" representation that can be adjusted according to the platform context (although in practice we don't do any platform-specific geometry transforms yet). And that gets written to the platform's gpu using wgpu. Bevy has a "render graph", which feeds on Bevy ECS data. We adapt the render graph (and the ECS data that drives it) according to the features supported on a given platform.
- bluejekyll 4y ago
  This is probably a very naive question, but for multi-platform support, is there any hope of Bevy ever being used to target consoles?
  - laundmo 4y ago
    There was a user on discord a while back who got bevy running in some capacity on, I think, Xbox and Switch. He had trouble with the PlayStation, though. Since you have to sign NDAs with the companies to do that, I don't know what came of it.
  - _cart 4y ago
    I've been talking with someone that got Rust working / rendering shaders on Playstation. In the past people have been able to target Switch in Rust and I suspect Xbox is pretty approachable with UWP. I have a lot of hope :) (not _yet_ my highest priority, but others are already investigating this)
- cpeterso 4y ago
  It's exciting to see so much development happening in Bevy! I see in the Bevy FAQ that you've contributed to other open source game engines. How did you get originally interested in game engine development? Are you developing a game yourself using Bevy? Or contracting with any studios using Bevy in their games? https://bevyengine.org/learn/book/faq/ https://bevyengine.org/learn/book/faq/
  - _cart 4y ago
    I originally got interested in middle school because I liked videogames, technology, and art. In middle school I played with game maker and a cool piece of mmo tech called RealmCrafter. That eventually snowballed into a programming obsession, a computer science degree, ~6-ish engine prototypes in various languages and stacks, a job at Microsoft, a game called High Hat (built in Godot), Godot contributions, and ultimately Bevy. Currently I only build small jam-like games in Bevy (I participated in https://itch.io/jam/bevy-jam-1 https://itch.io/jam/bevy-jam-1 and https://itch.io/jam/bevy-jam-2 https://itch.io/jam/bevy-jam-2). But I plan on picking up a larger project soon. I've got the itch :)
- artursapek 4y ago
  I’ve been learning Bevy for the last week and it’s been a lot of fun. Thanks for what you’ve done here.
- 999900000999 4y ago
  Would you suggest Bevy for people who struggle with Rust. Do I need to learn Rust first, or does Bevy use a limited subset of the language like Unity and C#. Although I'd argue till I'm blue in the face C# is a much easier language.
  - iknowstuff 4y ago
    You can't code in Rust by just trying things and seeing if they work, you'll get very frustrated. This approach works for learning other languages but you'll hit a wall with Rust. Gotta read the book.
    - james7132 4y ago
      On the contrary, about 50% of my time with Rust is spent throwing shit at the wall and seeing if it works. The great thing is that the compiler will probably tell you that what you're doing is garbage and you might want to consider redesigning, which is where the other 50% goes. If you hack works, great, just need to get it through code review, which will probably reject most other garbage. If it doesn't, back to the drawing board, and you won't have spent the time pestering someone to read your hackjob.
  - laundmo 4y ago
    It does in a way use a limited subset. Specifically, the borrow checker is rarely a concern since Bevys ECS storage abstracts that mostly away from the user.
  - nicoburns 4y ago
    You absolutely need to learn Rust first. Bevy uses it's full feature set.
  - alice-i-cecile 4y ago
    I learned Rust (and frankly, most of programming) with Bevy :) It was a good experience, although I definitely recommend learning the basics from the Rust Book as you go to reduce frustration and confusion. In simple game code you don't need to write your own traits, use unsafe, and like laundmo says, the borrow checker pains are way easier than in most Rust codebases because there's already a nice architecture in place.
- n42 4y ago
  Congratulations! I've been closely following and donating (when I can) since your launch. I'm now unemployed on a sabbatical, and looking to pour my heart into game development. Jumping into such a large, moving project can be intimidating. How can I get started effectively contributing to Bevy? I'll add, a ton of work seems to be happening in rendering. This is not an area I can contribute or know enough about, but I am able/willing to help with just about everything higher level than that.
  - james7132 4y ago
    We explicitly label easy first issues in our issue tracker: https://github.com/bevyengine/bevy/issues?q=is%3Aissue+is%3Aopen+label%3AD-Good-First-Issue https://github.com/bevyengine/bevy/issues?q=is%3Aissue+is%3A.... These should get you up to speed with the contribution process and, at the very minimum, get your feet wet with hacking against the engine, if not dive deeper into various specifics. I strongly suggest any of the docs issues, as it doesn't require you to write any actual functionality, but forces you to get to know the architecture, the language, and the core parts of the engine itself. Rendering is definitely moving really fast and we have a lot of accumulated domain expertise in the area now. If you're looking to potentially bootstrap or collaborate on design in a new space: animation or audio both need a lot more love. I'm one of the two animation SMEs and I still am playing catchup to the state of the art.
- lwansbrough 4y ago
  Hey cart, with WebGPU coming to Chrome in 113/114, how is Bevy looking for supporting the WebGPU target?
  - _cart 4y ago
    We've already gotten it working! https://github.com/bevyengine/bevy/pull/5027 https://github.com/bevyengine/bevy/pull/5027 The only reason we haven't merged it yet is we need to sort out a high level "app api" thing: WebGPU requires async init (as in the Rust async feature). The PR above solves this by making our plugin init async. This is the most straightforward, but it makes people put `.await` in their app init, which we're not sure is the right call yet. We're discussing alternatives that might "encapsulate" the async.
    - lwansbrough 4y ago
      Great news, thanks for the update.
  - rektide 4y ago
    FWIW there is a ~8 month old PR that purported to add WebGPU support. https://github.com/bevyengine/bevy/pull/5027 https://github.com/bevyengine/bevy/pull/5027
- raincole 4y ago
  While I hate Unity, I think one of the few things they did really well is the decision to make scriptable render pipeline. The game we're developing is high stylized. Istead of a shadow map for each spot light, we have a small shadow map for each character (rendered to a 4k altas). It's surprisingly easy to do that in Unity. Easier than in most engines, I believe. How is Bevy going to approach this kind of render pipeline customization? (I'm very new to Bevy. So if it's a stupid question please bear with me.)
  - james7132 4y ago
    It's turtles all the way down. You can replace the renderer wholesale, or strip out the top, middle, and/or low level abstractions. You choose how much meat you want stripped off from the bones. It's not that well-documented (something I want to address soon), but IMO it lives up to Bevy's reputation of modularity. For a comparison with Unity, it's equivalent to the scriptable render pipeline, but abandoning the default one doesn't mean you need to write your own pipeline from the ground up.
    - raincole 4y ago
      That sounds very promising. Could you point me the right direction on how to learn about Bevy's render pipeline? I've had some rather superficial understanding of Bevy (mostly just by following along the examples on the official site) And what's the equivalance of Unity's Frame Debugger? Since Bevy doesn't have a GUI editor yet, I guess the answer is just to use Render Doc?
      - james7132 4y ago
        > Could you point me the right direction on how to learn about Bevy's render pipeline? The best 10,000ft view that doesn't just point you at the code itself is probably https://bevy-cheatbook.github.io/gpu/intro.html https://bevy-cheatbook.github.io/gpu/intro.html. If you need finer details, you'll need to read the code itself, or ask in the #rendering(-dev) channels on the Discord. Again, I'm not happy with the state of public documentation for this, but as seen with this release, it's still heavily in flux. I don't think we've had a single release since 0.5 that hasn't made major architectural changes of some kind. > And what's the equivalance of Unity's Frame Debugger? Since Bevy doesn't have a GUI editor yet, I guess the answer is just to use Render Doc? Yep, just use RenderDoc right now. I don't think we'll have a good solution for this for a long while, since building one of those from the ground up is a huge undertaking.
- SleepyMyroslav 4y ago
  two questions: How big is the part of the engine that uses 'unsafe' Rust? What systems are to be multithreaded on release? Like Rendering, Physics etc.
  - _cart 4y ago
    Bevy ECS has a good chunk of `unsafe` as we're doing granular parallel data access that the Rust compiler cannot reason about. Anything related to low-level system api bindings (Vulkan, audio, etc) is inherently unsafe. But basically all "engine logic" (like our actual renderer logic, scenes, assets, etc) is written in safe Rust. We only use unsafe if we _absolutely need to_ and give it a lot of scrutiny. Impossible to avoid it entirely in the engine space though! The engine is very threaded in general. We do pipelined rendering so the next frame's logic is computed while the current frame is rendering, we multithread expensive potentially high-entity tasks like animation and transform propagation, all ECS systems run in parallel (which includes the renderer systems), etc. We'll use whatever cores you give us!
- yazaddaruvala 4y ago
  What are your expectations for Bevy's ability to compete with Unreal's Nanite and Lumen, and when might that become a priority? Additionally, while obviously not perfect, are you following new developments in AI based animation[0] and prediction based light transport[1]? Do you expect these types of automation to eventually become first class within Bevy, or any thoughts on how they can be best integrated into a Bevy game? [0] https://www.youtube.com/watch?v=L5KOQkZOusE https://www.youtube.com/watch?v=L5KOQkZOusE [1] https://www.youtube.com/watch?v=VxbTiuabW0k https://www.youtube.com/watch?v=VxbTiuabW0k
  - james7132 4y ago
    I want to step back a bit. All of these require a more involved and production ready asset system, which we've sorely needed for a few releases now. I'm one of the two developers currently behind our longer term animation efforts, and I am keeping up with the state of the art in terms of animation compression, streaming, composition, and generation, but there's still a sizable amount of groundwork and plumbing before any of that can even be attempted. We definitely need a lot more eyes on this area of the engine.
- cheeselip420 4y ago
  How long until we have a Bevy Editor? How (specifically for an Editor) can we help? I'm curious how the dynamic nature of an Editor will interact with rust.
intalentive 4y ago
How does a “data oriented” game engine differ from “non data oriented” game engines?
- serverholic 4y ago
  This is likely related to data-oriented design https://en.m.wikipedia.org/wiki/Data-oriented_design https://en.m.wikipedia.org/wiki/Data-oriented_design The idea is that you use data structures and algorithms to make better use of CPU cache.
- eastof 4y ago
  Mostly it has to do with internally storing "objects" as Structures of Arrays (SoA) instead of the traditional object-oriented Array of Structures (AoS) for more parallelization opportunities with SIMD improving cache efficiency. See https://en.m.wikipedia.org/wiki/Data-oriented_design https://en.m.wikipedia.org/wiki/Data-oriented_design
- jjames 4y ago
  I believe this refers to the Entity Component System.
- jackmott42 4y ago
  This usually means that data is organized in ways that are friendly to cpu cache, instruction parallelism, and multithreading. Lining up data in arrays, arrays of positions instead of arrays of objects each of which has a position, and so on. Usually this is done via an entity component system.
- laundmo 4y ago
  Edit: i was a dunce and explained data-driven, which it also is, but is not what you asked. Bevy is data oriented due to its ECS: roughly: which data an entity has attached to it decides which behaviours are run. Want something to have a health bar? Just attach the Health { current: 50, max: 100 } struct and it will have all associated behaviour like being able to take damage. Want to make it invincible again? Just remove the Health struct. This is different from OOP engines, where you might need to keep an is_invincible boolean around to check against.
jasonjmcghee 4y ago
There are so many great changes here, especially the API simplifications and parallelization improvements- but windows as components is huge. This was a particularly thorny area for me personally, and pretty excited to see this change.
astlouis44 4y ago
WebGPU support?
- ncallaway 4y ago
  I think it uses wgpu as it’s graphics library, so it should be there (though I don’t know if they’re targeting browsers with wasm support)
  - laundmo 4y ago
    bevy definitly runs in browsers, but since the browser support for WebGPU is limited, it currently uses the WebGL fallback.
- AndrewPGameDev 4y ago
  It doesn't work currently. The only problem is that plugin initialization must be asynchronous, so you have to pass control back to the browser to allow it to initialize the WebGPU api properly[1]. I hacked async plugin initialization into a fork for Bevy 0.8[2], but I never got it to 100% work because Chrome had already moved onto a newer WGSL syntax. In theory if you do the same changes for 0.10 as I did for 0.8 it should allow WebGPU to work (and I plan on doing this in the next couple days). [1]https://github.com/bevyengine/bevy/discussions/3239 https://github.com/bevyengine/bevy/discussions/3239 [2]https://github.com/Andrewp2/andrew-bevy/tree/webgpu-2 https://github.com/Andrewp2/andrew-bevy/tree/webgpu-2 warning extremely bad code
mwcampbell 4y ago
Particularly excited about AccessKit integration. As Bevy's announcement says, as far as we know, this makes Bevy the first general-purpose game engine with first-party accessibility support.
andrewstuart 4y ago
Tantan is an entertaining YouTube channel if you like Rust and Bevy and nerdy games programming stuff: https://www.youtube.com/@Tantandev https://www.youtube.com/@Tantandev https://www.youtube.com/watch?v=G-IuH6R-yD8 https://www.youtube.com/watch?v=G-IuH6R-yD8
dang 4y ago
Related: Scaling Bevy Development - https://news.ycombinator.com/item?id=34387062 https://news.ycombinator.com/item?id=34387062 - Jan 2023 (20 comments) Bevy 0.9: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=33577284 https://news.ycombinator.com/item?id=33577284 - Nov 2022 (50 comments) Automated testing in Bevy - https://news.ycombinator.com/item?id=32802402 https://news.ycombinator.com/item?id=32802402 - Sept 2022 (81 comments) Bevy 0.8: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=32287828 https://news.ycombinator.com/item?id=32287828 - July 2022 (18 comments) Bevy 0.7: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=31043668 https://news.ycombinator.com/item?id=31043668 - April 2022 (63 comments) Bevy game engine 0.6 - https://news.ycombinator.com/item?id=29854416 https://news.ycombinator.com/item?id=29854416 - Jan 2022 (89 comments) Bevy's First Birthday: a year of open source Rust game engine development - https://news.ycombinator.com/item?id=28132114 https://news.ycombinator.com/item?id=28132114 - Aug 2021 (13 comments) Bevy 0.5: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=26716166 https://news.ycombinator.com/item?id=26716166 - April 2021 (65 comments) Bevy: A game engine built in Rust - https://news.ycombinator.com/item?id=26131350 https://news.ycombinator.com/item?id=26131350 - Feb 2021 (117 comments) Bevy 0.4: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=25480321 https://news.ycombinator.com/item?id=25480321 - Dec 2020 (23 comments) Making a Snake Clone with Bevy - https://news.ycombinator.com/item?id=24999073 https://news.ycombinator.com/item?id=24999073 - Nov 2020 (11 comments) Bevy 0.3: game engine built in Rust - https://news.ycombinator.com/item?id=24983956 https://news.ycombinator.com/item?id=24983956 - Nov 2020 (55 comments) Bevy 0.2 - https://news.ycombinator.com/item?id=24530698 https://news.ycombinator.com/item?id=24530698 - Sept 2020 (43 comments) Bevy: A Game Engine in Rust - https://news.ycombinator.com/item?id=24334307 https://news.ycombinator.com/item?id=24334307 - Aug 2020 (42 comments) Bevy: A data-driven game engine and app framework built in Rust - https://news.ycombinator.com/item?id=24123283 https://news.ycombinator.com/item?id=24123283 - Aug 2020 (103 comments)
chaosprint 4y ago
The blog says that Bevy currently uses Rodio as the audio library. As I am also working on improving the Rust audio library for Glicol language (https://github.com/chaosprint/glicol https://github.com/chaosprint/glicol), I would like to know what features are the most required for merging this into a game engine, for example the HRTF mentioned in the blog. Another feature required is to embed scripting language like Rhai (https://github.com/chaosprint/glicol/discussions/112 https://github.com/chaosprint/glicol/discussions/112). Anything else? From my personal side, I would love to see more demos with both action and sound (then we can talk about latency etc.), not just the graphical side.
- alice-i-cecile 4y ago
  We're not thrilled with Rodio as our audio solution, and I wouldn't be surprised to see us migrate away. Definitely agree that we need more sophisticated demos, especially with audio and UI, to show (and test) how it all fits together.
adameasterling 4y ago
I recently discovered Bevy, and it's so much fun to play with. I wouldn't be surprised if in 2-4 years, we see some fantastic, revolutionary indie game coded in Bevy that totally breaks the mold in some way. The next Minecraft, basically. I say that because Unreal sucks for developers who like to code in text, want a fresh blank canvas, and don't want someone else making all the decisions about how gameplay should be created: Basically, the exact same type of person who's likely to make something really cool. And Bevy's coded in Rust! Bevy gains all of Rust's safety, ergonomics, speed; yet it avoids pitfalls with some OSS Rust products: it doesn't overuse lifetimes or macros and is relatively easy to follow. Plus, my understanding is that Bevy is way better at multithreading than Unreal and Unity; and consumer core counts just keep going up. IMO, there's a big opportunity for someone(s) with resources to invest in Bevy's development somehow.
- adam_arthur 4y ago
  I've been using Bevy recently, and definitely have the same feeling around future potential. Being designed for ECS first should in theory open up a lot of potential for optimizations well beyond traditional OO game engines. You can already see that many parts of the game loop/workflow is parallelized. I've been rendering procedurally generated chunks via Bevy's task system, and it's pretty insane how fast it is. Can generate meshes from millions of (live function queried) points and render the results with lighting, etc in a second or so leveraging SIMD and threading. Rust really feels like the ideal language to replace C/C++ for gamedev.
- james7132 4y ago
  > And Bevy's coded in Rust! Bevy gains all of Rust's safety, ergonomics, speed; yet it avoids pitfalls with some OSS Rust products: it doesn't overuse lifetimes or macros and is relatively easy to follow. Just uhhh... don't look at the core ECS implementation, haha. There's probably no other concentration that much use of unsafe in the entire Rust ecosystem, outside of the stdlib. Could always use some more eyes scrutinizing the design and API surface there. I'm saying this as someone who's wrote most of the optimizations to the ECS in the past 3-4 releases. Definitely have introduced (and fixed) my fair share of undefined behavior bugs due to hyper-aggressive use of unsafe.
Ericson2314 4y ago
https://store.steampowered.com/app/2198150/Tiny_Glade/ https://store.steampowered.com/app/2198150/Tiny_Glade/ is a very cool thing made with bevy which I think is a good example of what game industry has been missing. The whole "same engine, new assets, a lil scripting" model of game dev I can't help but think makes for a artistic monoculture. Scripting is a painkiller, not a cure, for the problem of the inflexible inscruitable C++ monster engine. If everything is modular and in the same language, we can get less "framework-y" and more "library-y", making a porous boundary between the "game" and the "engine". Tiny Glad is a perfect example of that. I didn't even know today they were making a game! Because it is started as just a little procedural modeling demo to be used in other games. It's great its getting attention as an actual game, but they can and definitely should eventually get the code out as a the library for use in other games too!

146 points by _cart 4y ago

_cart 4y ago

Creator and lead developer of Bevy here. Feel free to ask me anything!

_ghgp 4y ago
How far do you think you are from a 1.0 release? What areas do you think need improvement? I've been working on a project in Bevy for the last few weeks, having previously attempted it in TS+pixie.js and Godot. It's been a joy in comparison, with much faster progress - in TS I was constantly fighting the ecosystem, and GDScript is just awful, particularly it's type system. Thank you!
- _cart 4y ago
  I think we're about 2 years away. Some areas that need work: a visual Bevy Editor (not built yet but we're shifting focus to it this release cycle), audio (we have it but users need finer control), animation (more composition tools and editor integrations), ui (needs more widgets and ux improvements), asset system (I've been working on the next iteration for awhile to enable things like pre-processing assets), nice visual scene editing workflows (implemented inside the upcoming Bevy Editor). Glad you're enjoying Bevy so far!
  - echelon 4y ago
    I'd be happy to donate money specially to support animation (especially morph targets) and drive that forward. [1] We want to make a break from Unreal pixel streaming and Rust on the frontend delivered over WASM/WebGPU would be so ideal. The rest of our stack is Rust, so it would slot right in with our Rust monorepo. [1] I was donating to one of the devs until GitHub removed PayPal payments without warning or mitigation about a week ago. I'll fix that soon.
  - _ghgp 4y ago
    What would you plan to implement in a visual editor? I've found code works perfectly.
    - alice-i-cecile 4y ago
      Scene editing, fast value tweaking (like in bevy_inspector_egui) and more powerful visualization tools for things like schedules are the big "this must be visual" features that I want to land first. Code-first is lovely, but being able to fine-tune things without a recompile is key, and the workflow needs to work for any artists on larger teams too.
t-eckert 4y ago
I'm looking to start learning Bevy soon in preparation for the next Bevy Jam. Where can I sign up to be notified when the jam is scheduled?
- mahulst 4y ago
  The bevy discord has a dedicated channel for the jams!
  - t-eckert 4y ago
    Fantastic! Thank you
trhr 4y ago
Can you post on hn when the statement that reads like, "btw don't use this package if you're not cool with breaking changes every four days" leaves your docs? I pretty much immediately decided I wasn't cool with that, even though bevy looks like a really interesting project.
- sho_hn 4y ago
  It's sort of a cultural tradition in the Rust community to link to interesting or potentially more stable alternatives in READMEs.
  - trhr 4y ago
    https://bevyengine.org/learn/book/introduction/ https://bevyengine.org/learn/book/introduction/ The problem is that "the prototyping phase" isn't a real phase, and this doesn't specify if breaking changes will occur between major, minor, or patch versions. It gives developers no guidance of what semver to track based on their own willingness to endure breaking changes. Using a library that still can't tell you that is just asking for trouble.
    - nicoburns 4y ago
      > this doesn't specify if breaking changes will occur between major, minor, or patch versions The entire Rust ecosystem works on a model of breaking changes for 0.x version happening in minor but not patch releases. In fact, I'm struggling to think of any software project that intentionally releases breaking changes in patch releases.
      - trhr 4y ago
        I'm not sure what we're arguing about. You say "don't break bugfix releases." I say "don't break bugfix releases." Docs don't say "we don't break bugfix releases." Instead, docs say "we break all the time don't trust us" instead of "pin to a minor version if you don't want to break all the time." It's specifically not a question of knowing how the Rust community usually does these things, it's a question of "does this package conform to Rust's semver conventions, the official semver conventions, or something custom?" The statement, _as its written in the docs_ implies "we do something custom." Whether that's true or not is irrelevant. I read it, interpreted it as a lack of governance or adherence to standards, and moved on. Any professional engineer would do the same.
politician 4y ago
Thanks! I have some questions about integrating ECS with cross-platform concerns. How did you tackle the problem of components containing geometry for platform-specific graphics engines? Does Bevy use platform-specific components? If an application needs multiple offscreen textures to compose a frame, are there components that contain metadata for which passes they belong to (so, now, platform and pass specific components)?
- nicoburns 4y ago
  Bevy uses wgpu as it's graphics engine, which is cross-platform.
- _cart 4y ago
  We handle this class of problem in a few different ways: 1. We build on top of cross platform abstractions with feature detection (wgpu is our cross platform low level graphics library, cpal is that for audio, etc). We build our features in a way that adjust the ECS app logic according to what features are available at runtime 2. In a few cases we do "compile time feature/platform detection" to select the appropriate code for a given platform. But most "Bevy features" don't use this / we opt for (1) more than anything else In the case of geometry: that has a "dynamic" representation that can be adjusted according to the platform context (although in practice we don't do any platform-specific geometry transforms yet). And that gets written to the platform's gpu using wgpu. Bevy has a "render graph", which feeds on Bevy ECS data. We adapt the render graph (and the ECS data that drives it) according to the features supported on a given platform.
bluejekyll 4y ago
This is probably a very naive question, but for multi-platform support, is there any hope of Bevy ever being used to target consoles?
- laundmo 4y ago
  There was a user on discord a while back who got bevy running in some capacity on, I think, Xbox and Switch. He had trouble with the PlayStation, though. Since you have to sign NDAs with the companies to do that, I don't know what came of it.
- _cart 4y ago
  I've been talking with someone that got Rust working / rendering shaders on Playstation. In the past people have been able to target Switch in Rust and I suspect Xbox is pretty approachable with UWP. I have a lot of hope :) (not _yet_ my highest priority, but others are already investigating this)
cpeterso 4y ago
It's exciting to see so much development happening in Bevy! I see in the Bevy FAQ that you've contributed to other open source game engines. How did you get originally interested in game engine development? Are you developing a game yourself using Bevy? Or contracting with any studios using Bevy in their games? https://bevyengine.org/learn/book/faq/ https://bevyengine.org/learn/book/faq/
- _cart 4y ago
  I originally got interested in middle school because I liked videogames, technology, and art. In middle school I played with game maker and a cool piece of mmo tech called RealmCrafter. That eventually snowballed into a programming obsession, a computer science degree, ~6-ish engine prototypes in various languages and stacks, a job at Microsoft, a game called High Hat (built in Godot), Godot contributions, and ultimately Bevy. Currently I only build small jam-like games in Bevy (I participated in https://itch.io/jam/bevy-jam-1 https://itch.io/jam/bevy-jam-1 and https://itch.io/jam/bevy-jam-2 https://itch.io/jam/bevy-jam-2). But I plan on picking up a larger project soon. I've got the itch :)
artursapek 4y ago
I’ve been learning Bevy for the last week and it’s been a lot of fun. Thanks for what you’ve done here.
999900000999 4y ago
Would you suggest Bevy for people who struggle with Rust. Do I need to learn Rust first, or does Bevy use a limited subset of the language like Unity and C#. Although I'd argue till I'm blue in the face C# is a much easier language.
- iknowstuff 4y ago
  You can't code in Rust by just trying things and seeing if they work, you'll get very frustrated. This approach works for learning other languages but you'll hit a wall with Rust. Gotta read the book.
  - james7132 4y ago
    On the contrary, about 50% of my time with Rust is spent throwing shit at the wall and seeing if it works. The great thing is that the compiler will probably tell you that what you're doing is garbage and you might want to consider redesigning, which is where the other 50% goes. If you hack works, great, just need to get it through code review, which will probably reject most other garbage. If it doesn't, back to the drawing board, and you won't have spent the time pestering someone to read your hackjob.
- laundmo 4y ago
  It does in a way use a limited subset. Specifically, the borrow checker is rarely a concern since Bevys ECS storage abstracts that mostly away from the user.
- nicoburns 4y ago
  You absolutely need to learn Rust first. Bevy uses it's full feature set.
- alice-i-cecile 4y ago
  I learned Rust (and frankly, most of programming) with Bevy :) It was a good experience, although I definitely recommend learning the basics from the Rust Book as you go to reduce frustration and confusion. In simple game code you don't need to write your own traits, use unsafe, and like laundmo says, the borrow checker pains are way easier than in most Rust codebases because there's already a nice architecture in place.
n42 4y ago
Congratulations! I've been closely following and donating (when I can) since your launch. I'm now unemployed on a sabbatical, and looking to pour my heart into game development. Jumping into such a large, moving project can be intimidating. How can I get started effectively contributing to Bevy? I'll add, a ton of work seems to be happening in rendering. This is not an area I can contribute or know enough about, but I am able/willing to help with just about everything higher level than that.
- james7132 4y ago
  We explicitly label easy first issues in our issue tracker: https://github.com/bevyengine/bevy/issues?q=is%3Aissue+is%3Aopen+label%3AD-Good-First-Issue https://github.com/bevyengine/bevy/issues?q=is%3Aissue+is%3A.... These should get you up to speed with the contribution process and, at the very minimum, get your feet wet with hacking against the engine, if not dive deeper into various specifics. I strongly suggest any of the docs issues, as it doesn't require you to write any actual functionality, but forces you to get to know the architecture, the language, and the core parts of the engine itself. Rendering is definitely moving really fast and we have a lot of accumulated domain expertise in the area now. If you're looking to potentially bootstrap or collaborate on design in a new space: animation or audio both need a lot more love. I'm one of the two animation SMEs and I still am playing catchup to the state of the art.
lwansbrough 4y ago
Hey cart, with WebGPU coming to Chrome in 113/114, how is Bevy looking for supporting the WebGPU target?
- _cart 4y ago
  We've already gotten it working! https://github.com/bevyengine/bevy/pull/5027 https://github.com/bevyengine/bevy/pull/5027 The only reason we haven't merged it yet is we need to sort out a high level "app api" thing: WebGPU requires async init (as in the Rust async feature). The PR above solves this by making our plugin init async. This is the most straightforward, but it makes people put `.await` in their app init, which we're not sure is the right call yet. We're discussing alternatives that might "encapsulate" the async.
  - lwansbrough 4y ago
    Great news, thanks for the update.
- rektide 4y ago
  FWIW there is a ~8 month old PR that purported to add WebGPU support. https://github.com/bevyengine/bevy/pull/5027 https://github.com/bevyengine/bevy/pull/5027
raincole 4y ago
While I hate Unity, I think one of the few things they did really well is the decision to make scriptable render pipeline. The game we're developing is high stylized. Istead of a shadow map for each spot light, we have a small shadow map for each character (rendered to a 4k altas). It's surprisingly easy to do that in Unity. Easier than in most engines, I believe. How is Bevy going to approach this kind of render pipeline customization? (I'm very new to Bevy. So if it's a stupid question please bear with me.)
- james7132 4y ago
  It's turtles all the way down. You can replace the renderer wholesale, or strip out the top, middle, and/or low level abstractions. You choose how much meat you want stripped off from the bones. It's not that well-documented (something I want to address soon), but IMO it lives up to Bevy's reputation of modularity. For a comparison with Unity, it's equivalent to the scriptable render pipeline, but abandoning the default one doesn't mean you need to write your own pipeline from the ground up.
  - raincole 4y ago
    That sounds very promising. Could you point me the right direction on how to learn about Bevy's render pipeline? I've had some rather superficial understanding of Bevy (mostly just by following along the examples on the official site) And what's the equivalance of Unity's Frame Debugger? Since Bevy doesn't have a GUI editor yet, I guess the answer is just to use Render Doc?
    - james7132 4y ago
      > Could you point me the right direction on how to learn about Bevy's render pipeline? The best 10,000ft view that doesn't just point you at the code itself is probably https://bevy-cheatbook.github.io/gpu/intro.html https://bevy-cheatbook.github.io/gpu/intro.html. If you need finer details, you'll need to read the code itself, or ask in the #rendering(-dev) channels on the Discord. Again, I'm not happy with the state of public documentation for this, but as seen with this release, it's still heavily in flux. I don't think we've had a single release since 0.5 that hasn't made major architectural changes of some kind. > And what's the equivalance of Unity's Frame Debugger? Since Bevy doesn't have a GUI editor yet, I guess the answer is just to use Render Doc? Yep, just use RenderDoc right now. I don't think we'll have a good solution for this for a long while, since building one of those from the ground up is a huge undertaking.
SleepyMyroslav 4y ago
two questions: How big is the part of the engine that uses 'unsafe' Rust? What systems are to be multithreaded on release? Like Rendering, Physics etc.
- _cart 4y ago
  Bevy ECS has a good chunk of `unsafe` as we're doing granular parallel data access that the Rust compiler cannot reason about. Anything related to low-level system api bindings (Vulkan, audio, etc) is inherently unsafe. But basically all "engine logic" (like our actual renderer logic, scenes, assets, etc) is written in safe Rust. We only use unsafe if we _absolutely need to_ and give it a lot of scrutiny. Impossible to avoid it entirely in the engine space though! The engine is very threaded in general. We do pipelined rendering so the next frame's logic is computed while the current frame is rendering, we multithread expensive potentially high-entity tasks like animation and transform propagation, all ECS systems run in parallel (which includes the renderer systems), etc. We'll use whatever cores you give us!
yazaddaruvala 4y ago
What are your expectations for Bevy's ability to compete with Unreal's Nanite and Lumen, and when might that become a priority? Additionally, while obviously not perfect, are you following new developments in AI based animation[0] and prediction based light transport[1]? Do you expect these types of automation to eventually become first class within Bevy, or any thoughts on how they can be best integrated into a Bevy game? [0] https://www.youtube.com/watch?v=L5KOQkZOusE https://www.youtube.com/watch?v=L5KOQkZOusE [1] https://www.youtube.com/watch?v=VxbTiuabW0k https://www.youtube.com/watch?v=VxbTiuabW0k
- james7132 4y ago
  I want to step back a bit. All of these require a more involved and production ready asset system, which we've sorely needed for a few releases now. I'm one of the two developers currently behind our longer term animation efforts, and I am keeping up with the state of the art in terms of animation compression, streaming, composition, and generation, but there's still a sizable amount of groundwork and plumbing before any of that can even be attempted. We definitely need a lot more eyes on this area of the engine.
cheeselip420 4y ago
How long until we have a Bevy Editor? How (specifically for an Editor) can we help? I'm curious how the dynamic nature of an Editor will interact with rust.

intalentive 4y ago

How does a “data oriented” game engine differ from “non data oriented” game engines?

serverholic 4y ago
This is likely related to data-oriented design https://en.m.wikipedia.org/wiki/Data-oriented_design https://en.m.wikipedia.org/wiki/Data-oriented_design The idea is that you use data structures and algorithms to make better use of CPU cache.
eastof 4y ago
Mostly it has to do with internally storing "objects" as Structures of Arrays (SoA) instead of the traditional object-oriented Array of Structures (AoS) for more parallelization opportunities with SIMD improving cache efficiency. See https://en.m.wikipedia.org/wiki/Data-oriented_design https://en.m.wikipedia.org/wiki/Data-oriented_design
jjames 4y ago
I believe this refers to the Entity Component System.
jackmott42 4y ago
This usually means that data is organized in ways that are friendly to cpu cache, instruction parallelism, and multithreading. Lining up data in arrays, arrays of positions instead of arrays of objects each of which has a position, and so on. Usually this is done via an entity component system.
laundmo 4y ago
Edit: i was a dunce and explained data-driven, which it also is, but is not what you asked. Bevy is data oriented due to its ECS: roughly: which data an entity has attached to it decides which behaviours are run. Want something to have a health bar? Just attach the Health { current: 50, max: 100 } struct and it will have all associated behaviour like being able to take damage. Want to make it invincible again? Just remove the Health struct. This is different from OOP engines, where you might need to keep an is_invincible boolean around to check against.

jasonjmcghee 4y ago

There are so many great changes here, especially the API simplifications and parallelization improvements- but windows as components is huge. This was a particularly thorny area for me personally, and pretty excited to see this change.

astlouis44 4y ago

WebGPU support?

ncallaway 4y ago
I think it uses wgpu as it’s graphics library, so it should be there (though I don’t know if they’re targeting browsers with wasm support)
- laundmo 4y ago
  bevy definitly runs in browsers, but since the browser support for WebGPU is limited, it currently uses the WebGL fallback.
AndrewPGameDev 4y ago
It doesn't work currently. The only problem is that plugin initialization must be asynchronous, so you have to pass control back to the browser to allow it to initialize the WebGPU api properly[1]. I hacked async plugin initialization into a fork for Bevy 0.8[2], but I never got it to 100% work because Chrome had already moved onto a newer WGSL syntax. In theory if you do the same changes for 0.10 as I did for 0.8 it should allow WebGPU to work (and I plan on doing this in the next couple days). [1]https://github.com/bevyengine/bevy/discussions/3239 https://github.com/bevyengine/bevy/discussions/3239 [2]https://github.com/Andrewp2/andrew-bevy/tree/webgpu-2 https://github.com/Andrewp2/andrew-bevy/tree/webgpu-2 warning extremely bad code

mwcampbell 4y ago

Particularly excited about AccessKit integration. As Bevy's announcement says, as far as we know, this makes Bevy the first general-purpose game engine with first-party accessibility support.

andrewstuart 4y ago

Tantan is an entertaining YouTube channel if you like Rust and Bevy and nerdy games programming stuff: https://www.youtube.com/@Tantandev https://www.youtube.com/@Tantandev https://www.youtube.com/watch?v=G-IuH6R-yD8 https://www.youtube.com/watch?v=G-IuH6R-yD8

dang 4y ago

Related: Scaling Bevy Development - https://news.ycombinator.com/item?id=34387062 https://news.ycombinator.com/item?id=34387062 - Jan 2023 (20 comments) Bevy 0.9: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=33577284 https://news.ycombinator.com/item?id=33577284 - Nov 2022 (50 comments) Automated testing in Bevy - https://news.ycombinator.com/item?id=32802402 https://news.ycombinator.com/item?id=32802402 - Sept 2022 (81 comments) Bevy 0.8: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=32287828 https://news.ycombinator.com/item?id=32287828 - July 2022 (18 comments) Bevy 0.7: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=31043668 https://news.ycombinator.com/item?id=31043668 - April 2022 (63 comments) Bevy game engine 0.6 - https://news.ycombinator.com/item?id=29854416 https://news.ycombinator.com/item?id=29854416 - Jan 2022 (89 comments) Bevy's First Birthday: a year of open source Rust game engine development - https://news.ycombinator.com/item?id=28132114 https://news.ycombinator.com/item?id=28132114 - Aug 2021 (13 comments) Bevy 0.5: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=26716166 https://news.ycombinator.com/item?id=26716166 - April 2021 (65 comments) Bevy: A game engine built in Rust - https://news.ycombinator.com/item?id=26131350 https://news.ycombinator.com/item?id=26131350 - Feb 2021 (117 comments) Bevy 0.4: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=25480321 https://news.ycombinator.com/item?id=25480321 - Dec 2020 (23 comments) Making a Snake Clone with Bevy - https://news.ycombinator.com/item?id=24999073 https://news.ycombinator.com/item?id=24999073 - Nov 2020 (11 comments) Bevy 0.3: game engine built in Rust - https://news.ycombinator.com/item?id=24983956 https://news.ycombinator.com/item?id=24983956 - Nov 2020 (55 comments) Bevy 0.2 - https://news.ycombinator.com/item?id=24530698 https://news.ycombinator.com/item?id=24530698 - Sept 2020 (43 comments) Bevy: A Game Engine in Rust - https://news.ycombinator.com/item?id=24334307 https://news.ycombinator.com/item?id=24334307 - Aug 2020 (42 comments) Bevy: A data-driven game engine and app framework built in Rust - https://news.ycombinator.com/item?id=24123283 https://news.ycombinator.com/item?id=24123283 - Aug 2020 (103 comments)

chaosprint 4y ago

The blog says that Bevy currently uses Rodio as the audio library. As I am also working on improving the Rust audio library for Glicol language (https://github.com/chaosprint/glicol https://github.com/chaosprint/glicol), I would like to know what features are the most required for merging this into a game engine, for example the HRTF mentioned in the blog. Another feature required is to embed scripting language like Rhai (https://github.com/chaosprint/glicol/discussions/112 https://github.com/chaosprint/glicol/discussions/112). Anything else? From my personal side, I would love to see more demos with both action and sound (then we can talk about latency etc.), not just the graphical side.

alice-i-cecile 4y ago
We're not thrilled with Rodio as our audio solution, and I wouldn't be surprised to see us migrate away. Definitely agree that we need more sophisticated demos, especially with audio and UI, to show (and test) how it all fits together.

adameasterling 4y ago

I recently discovered Bevy, and it's so much fun to play with. I wouldn't be surprised if in 2-4 years, we see some fantastic, revolutionary indie game coded in Bevy that totally breaks the mold in some way. The next Minecraft, basically. I say that because Unreal sucks for developers who like to code in text, want a fresh blank canvas, and don't want someone else making all the decisions about how gameplay should be created: Basically, the exact same type of person who's likely to make something really cool. And Bevy's coded in Rust! Bevy gains all of Rust's safety, ergonomics, speed; yet it avoids pitfalls with some OSS Rust products: it doesn't overuse lifetimes or macros and is relatively easy to follow. Plus, my understanding is that Bevy is way better at multithreading than Unreal and Unity; and consumer core counts just keep going up. IMO, there's a big opportunity for someone(s) with resources to invest in Bevy's development somehow.

adam_arthur 4y ago
I've been using Bevy recently, and definitely have the same feeling around future potential. Being designed for ECS first should in theory open up a lot of potential for optimizations well beyond traditional OO game engines. You can already see that many parts of the game loop/workflow is parallelized. I've been rendering procedurally generated chunks via Bevy's task system, and it's pretty insane how fast it is. Can generate meshes from millions of (live function queried) points and render the results with lighting, etc in a second or so leveraging SIMD and threading. Rust really feels like the ideal language to replace C/C++ for gamedev.
james7132 4y ago
> And Bevy's coded in Rust! Bevy gains all of Rust's safety, ergonomics, speed; yet it avoids pitfalls with some OSS Rust products: it doesn't overuse lifetimes or macros and is relatively easy to follow. Just uhhh... don't look at the core ECS implementation, haha. There's probably no other concentration that much use of unsafe in the entire Rust ecosystem, outside of the stdlib. Could always use some more eyes scrutinizing the design and API surface there. I'm saying this as someone who's wrote most of the optimizations to the ECS in the past 3-4 releases. Definitely have introduced (and fixed) my fair share of undefined behavior bugs due to hyper-aggressive use of unsafe.

Ericson2314 4y ago

https://store.steampowered.com/app/2198150/Tiny_Glade/ https://store.steampowered.com/app/2198150/Tiny_Glade/ is a very cool thing made with bevy which I think is a good example of what game industry has been missing. The whole "same engine, new assets, a lil scripting" model of game dev I can't help but think makes for a artistic monoculture. Scripting is a painkiller, not a cure, for the problem of the inflexible inscruitable C++ monster engine. If everything is modular and in the same language, we can get less "framework-y" and more "library-y", making a porous boundary between the "game" and the "engine". Tiny Glad is a perfect example of that. I didn't even know today they were making a game! Because it is started as just a little procedural modeling demo to be used in other games. It's great its getting attention as an actual game, but they can and definitely should eventually get the code out as a the library for use in other games too!