8 ms·

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.