[HN Gopher] Bevy 0.12
___________________________________________________________________
Bevy 0.12
Author : przmk
Score : 229 points
Date : 2023-11-04 19:39 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!
| andrewmcwatters wrote:
| Have you considered moving off of 0.x.x? You have people
| consuming this software, it's public, and if you plan on
| breaking it quarterly, just be upfront with people and move
| through major versions.
|
| LOVE made the same mistake for years, and their version history
| looks odd as a result due to the sudden jump from 0.10 to 11.0.
|
| You'll be working on Bevy for years. When do you decide it's
| ready for public "stable" usage, and how do you plan on
| communicating this to users?
| ncallaway wrote:
| > and if you plan on breaking it quarterly, just be upfront
| with people and move through major versions.
|
| Isn't that exactly what a 0.x version means? This seems far
| more up front with people that releasing a 1.0 that bumps to
| 2.0 3 months later.
|
| I think until the engine is baked enough that the API avoids
| breaking changes for years at a time it should remain pre
| 1.0.
| andrewmcwatters wrote:
| What will most likely happen is that there with be large
| subsets of Bevy users who never use a formally stable Bevy
| codebase, and then leave for something different, because
| there are no guarantees.
|
| Maintainers of all sorts of different projects also signal
| to their users their investment value in working with a
| large critical dependency.
| CooCooCaCha wrote:
| I think it depends on how the developer views 0.x
| releases. In Bevy's case there has been discussions
| around backwards compatibility and I think it'll happen
| but right now it doesn't make sense until the major
| systems are in place.
|
| My impression from being in the community for awhile is
| that the devs don't want to perpetually stay with 0.x
| releases. It's just that a game engine is a big thing
| with a lot of moving parts.
| unshavedyak wrote:
| > What will most likely happen is that there with be
| large subsets of Bevy users who never use a formally
| stable Bevy codebase, and then leave for something
| different, because there are no guarantees.
|
| But naming it 1.0 won't give them guarantees either. If
| it's assumed, it would just be annoying when breakages do
| occur. What you're really asking for (it sounds like) is
| for there to be less breakages or longer term releases ..
| and that's a staffing issue imo.
|
| If users avoid it because they don't want churn, and the
| devs are choosing churn - then everyone is in agreement
| currently, no? The bevy devs are writing software in a
| way that fits them currently, and users who prefer to
| wait for 1.0 are doing so currently. Everyone gets as
| advertised.
|
| Do you see it working differently?
| alice-i-cecile wrote:
| We've discussed this pretty recently on GitHub [0].
|
| I'm personally in favor of shipping 1.0 within the next year
| or so. The most interesting part of that to me is figuring
| out how to decouple the crates without creating major
| confusion, in order to reduce trivial plugin churn.
|
| For the most part, this is just marketing and semantics, but
| Bevy is nearly ready for commercial users and we should start
| communicating that. Quite a few brave users are already
| _building_ production games (and non-games), and feedback is
| generally very good! [1]
|
| [0]: https://github.com/bevyengine/bevy/discussions/9789 [1]:
| https://github.com/Vrixyz/bevy_awesome_prod
| Tade0 wrote:
| Any chance for some sort of "Bevy Studio" app to appear in the
| future?
|
| It's not that I don't like programming, I'm just brutally time-
| constrained (kids).
| przmk wrote:
| Not the author but there's a Bevy Editor on the roadmap.
| pests wrote:
| Yep. Built with Bevy similar to how Godot is self-hosted.
| They are still figuring out the details like which UI
| framework to use and how to save scenes. Which abstractions
| to introduce - nodes like Godot, objects+components like
| unity, etc? Then debate on how "prefabs" are designed - are
| they just bundles? Entity and component serialization....
| Tons of architectual decisions.
|
| It's coming together.
| IceSentry wrote:
| The UI framework will be bevy_ui just like godot uses
| godot ui library. What needs to be done is improve it so
| it can actually work for making a complex app.
| _cart wrote:
| Yup! The Bevy Editor is our current highest priority. The
| first step is building out a new Scene / UI system that will
| serve as the foundation for the editor (as the Bevy Editor
| will be built as a Bevy App).
|
| I have a post about this (with working prototypes) here:
| https://github.com/bevyengine/bevy/discussions/9538
| Tade0 wrote:
| Oh wow, that is a _detailed_ post. Thank you for your hard
| work!
| sdwr wrote:
| Thanks for posting - hobby game dev here, know just enough to
| be dangerous.. if I was going to start a new project, it would
| be in your engine, seems like it splits the diff between Love +
| Godot, more robust than Love, not as geared towards novices as
| Godot.
|
| How opinionated is bevy? Have you ever had to make tradeoffs
| between features and developer accessibility?
|
| What is the "ideal" project to use bevy for right now?
| _cart wrote:
| Bevy tries to have its cake and eat it too. We have a large,
| opinionated featureset (ex: how should rendering code look,
| high level materials, sprites, meshes, animation, scenes,
| etc) where everything works nicely together. However we are
| extremely modular to the point that you can do pretty much
| anything in Bevy. People build their own renderers, do
| command line only terminal UIs, custom UI systems, etc etc.
|
| We make tradeoffs all the time. We prioritize accessibility /
| developer UX to a pretty high degree. But this very rarely
| means cutting features. The hard part is generally _how_ we
| expose a feature, not _if_.
|
| "What is the "ideal" project to use bevy for right now?"
|
| Bevy is well suited to many project types. The biggest
| missing piece is a lack of a visual editor (we are working on
| this, and while you wait you can use programs like Blender or
| ldtk to compose your scenes). I'd say the ideal project is
| (1) Small-to-medium-sized in scope, to help mitigate the risk
| of using a younger engine (2) doesn't need a full Bevy Editor
| / can get away with code driven or external-editor-driven
| scenes.
| alice-i-cecile wrote:
| Yeah, that's not a bad way to describe its positioning.
|
| Currently not a lot of batteries included: the experience is
| much more like "writing a web app using a framework" than it
| is "boot up RPG Maker".
|
| Generally speaking, Bevy is extremely flexible, with pretty
| generous defaults for enabled features to let beginners avoid
| worrying about toggling feature flags and controlling
| plugins.
|
| In game engine development, features are typically strictly
| additive, so features vs developer accessibility isn't a
| great way to frame the tradeoff. Instead, we often push work
| into the third-party plugin ecosystem to ease maintenance
| burden or let it mature.
|
| As for the ideal project, I would either say "solo programmer
| who wants to learn Rust and game dev for fun", or "small,
| serious team looking to build an unusual systems-heavy game".
| Buttons840 wrote:
| I'm put off by the limited docs. I've read the Bevy book, only
| takes a few minutes, and just like that I'm out of resources to
| turn to when I get stuck.
|
| When will the docs improve? I look at the release notes and
| ideally every one of those features would have several pages of
| docs. I understand that's a lot of work, and maybe things will
| have to stabilize before we get full docs?
| CooCooCaCha wrote:
| The examples in the github repo are fantastic and cover a lot
| of ground. That's usually my goto when trying to figure
| things out.
| przmk wrote:
| There's an unofficial complement to the docs that covers a
| lot of different topics here: https://bevy-
| cheatbook.github.io/introduction.html
| _cart wrote:
| Among Bevy contributors (including myself) there is a general
| hesitance to invest too much time in official learning
| material that will be obsolete by the next release. Bevy's
| APIs are beginning to stabilize ... and the appetite (both
| from users and from Bevy devs) for official material is
| increasing. The time is coming (soon)!
|
| While you wait, there are a sizeable number of tutorials on
| YouTube, and we have learning material linked in
| https://bevyengine.org/assets/#learning as well.
| oh_sigh wrote:
| Nit: developers who use bevy should be called bevy devys.
| IceSentry wrote:
| Bevy does have plenty of documentation here:
| https://docs.rs/bevy/latest/bevy/
|
| What's missing is tutorial type documentation, but individual
| features are generally documented.
| mahulst wrote:
| Sweet! Always a suprise to see how much ends up in a release.
| It seems like the last three weeks there are as much features
| merged as in the rest of the release window.
|
| Technical question: will there ever be a guide that talks
| through how the rendering part of bevy works? The graph and all
| is great, but really difiicult to get into without the help of
| discord.
| _cart wrote:
| Haha yeah we have a tendency to merge a lot of "ready" work
| near the end.
|
| We do plan to have a thorough rendering guide. We've just
| been putting it off as the renderer has been (and still is)
| in flux. Once the dust settles a bit we'll start investing in
| "documentation on-ramps".
| bigyikes wrote:
| What (dis)advantages does writing a game in Rust (with Bevy)
| have compared to other languages? Keen to hear about
| performance, safety, and dev velocity.
| alice-i-cecile wrote:
| I gave a talk about this recently![0]
|
| But, to answer your question directly:
|
| - Rust performance is comparable to C/C++, but Bevy has had
| much less time to get optimized than C/C++. Our ECS is fast,
| but slower than flecs, and our rendering performance is about
| Unity level IIRC.
|
| - Safety / correctness is a huge benefit. Memory safety is
| obviously nice for reducing horrible segfaults, but
| ultimately I end up really loving enums, traits and the ease
| of unit testing to make refactoring games (and the libraries
| they rely on).
|
| - Talking to experienced game devs, velocity is quite good!
| Once you're off the ground, a ton of your time comes from a)
| refactoring b) bug fixing c) adding bog-standard but tedious
| functionality like localization. I've talked about the first
| two, but Rust's first class packaging ecosystem (and Bevy's
| modularity) means that you can actually share work for that,
| rather than rewriting it at every company like you see in a
| lot of other game dev.
|
| Gameplay features are wildly easy to write, but GUI creation
| is still miserably tedious with a fragmented ecosystem.
|
| On development velocity, I will note that Linux's compilation
| times for Rust are meaningfully better than Windows, although
| M1 Macs are compelling too. The lack of visual editor tooling
| definitely slows things down too, even though good ecosystem
| options for that are emerging.
|
| [0]: https://elk.zone/mastodon.gamedev.place/@alice_i_cecile/
| 1113...
| Keyframe wrote:
| Also, consoles are out of the question, right? Well, maybe
| Xbox.. maybe. And what about mobile?
| CooCooCaCha wrote:
| That's a big leap, what makes you say consoles are out of
| the question?
| alice-i-cecile wrote:
| Steam Deck functions great, Xbox is a well, maybe.
| Playstation and Switch are "negotiate with the console
| owners" situation.
|
| Mobile is functional but immature, same with XR.
| pornel wrote:
| You need to be comfortable with Rust _and_ with ECS.
|
| If you're coming from a GC language and `Player extends
| Entity` mutable OOP approach, you will have to completely re-
| learn how you architect games.
|
| The upside is that Rust is pretty fast, and Bevy takes
| advantage of Rust's relatively easy multi-threading.
| Thaxll wrote:
| The biggest disavantage is that no one uses Rust to create
| games, it's all C++ or C#. So all the documentation,
| knowledge, libraries etc ... are missing and / or different.
| leetharris wrote:
| Or JavaScript, surprisingly. Vampire Survivors is the most
| famous recent one. Pretty cool to think about.
| metabagel wrote:
| I'm a rank beginner at game programming, GPU programming, and
| Rust.
|
| Is it possible to access compute shader functionality through
| Bevy / Vulkan? Basically, offload arbitrary GPU appopriate
| calculations to the GPU?
| _cart wrote:
| Yup! Here is a Bevy example that simulates Conway's Game Of
| Life in a compute shader: https://github.com/bevyengine/bevy/
| blob/main/examples/shader...
| metabagel wrote:
| Thanks!
| echelon wrote:
| We're building a fairly big WASM app in Bevy (relative to our
| company's size), and it's been a pleasure to work with the
| engine.
|
| Bevy and the community are awesome. We needed a couple of
| tickets worked on, and it was so easy to find one of the core
| contributors to sponsor and push our request over the line
| (morph targets).
|
| Thank you so much for everything, Carter! You're building
| something incredibly important that has fantastic momentum
| behind it.
|
| Bevy is wonderfully easy to deploy to the web, and people
| should be checking it out. The community is great, and it's
| easy to find help.
| _cart wrote:
| Thank you for the kind words! Messages like these are what
| help me push through the hard days.
| flandish wrote:
| Learning here - long time sw eng, but mostly back ends. So I'm
| starting down the emulator path. Would this work with the
| display/ui portion of an emu like an 8080/chip8? Since the
| logic is in the opcodes, most of what I think is needed is
| displaying vram, ui, windowing (screen, options, stack etc). It
| is still fuzzy where "ui" ends and "game engine" begins.
|
| Your pages are great and readable!
| _cart wrote:
| I suspect that as a visualizer for an emulator, Bevy would be
| a reasonable fit. You could use Bevy UI or build your own for
| the emulator interface. You might want to build a custom
| shader to display emulator outputs. You could also consider
| doing a custom renderer in Bevy if you see the need. Theres
| also always the option of dropping down a level and using a
| graphics api like wgpu (which is the "low level" api we use
| under the hood that allows us to target Vulkan / DX12 / Metal
| / OpenGL / WebGL2)
| liquidise wrote:
| Fantastic release notes.
|
| Perhaps some of this is too introductory for seasoned game/engine
| developers, but as someone who doesn't live in those worlds
| regularly i found this struck an excellent balance between
| discussing changes and explaining topics in a consumable way.
| Bravo!
| random_ wrote:
| Very cool!! On the last update 0.10 -> 0.11, I had to make quite
| a few changes on my app, but this time it compiled out of the
| box!
| devit wrote:
| The article claims that deferred rendering doesn't support MSAA,
| but this is only true for a naive implementation.
|
| You can, for example, generate a stencil mask of complex pixels
| in the prepass and use hierarchical early stencil reject to run a
| per-sample pass for complex pixels and a per-pixel pass for non-
| complex pixels (with imperfect SIMD lane utilization).
|
| You can also use a pass to process the complex pixels mask and
| collect a buffer of (x, y, sample) coordinates to allow a later
| single hybrid per-pixel/per-sample compute shader pass with
| perfect SIMD lane utilization.
| _cart wrote:
| Noted!
| plopz wrote:
| I was looking at the web examples and saw the ui section which
| seems to all be done inside the canvas. Is it possible to do the
| ui in the dom instead and hook it up to the wasm?
| _cart wrote:
| Yup I've seen this done before! You need to build a way to pass
| information to/from the UI to Bevy. Plenty of ways to do this,
| both from the Rust (wasm) side (ex: web_sys) or the Javascript
| side (invoking wasm functions)
| dcsommer wrote:
| Amazing progress. Any updates on UI overhaul or planned timeline
| for it? I'm looking to make Bevy my go-to for GUI as well as for
| games (sometimes the line is blurred).
| dist-epoch wrote:
| I saw a joke that there are 5 games written in Rust, and 50 game
| engines.
|
| Is there a list of actual games written in Bevy?
| _cart wrote:
| Plenty!
|
| Tiny Glade (https://pouncelight.games/tiny-glade) Super popular
| ... lots of social media presence. Uses Bevy ECS / Bevy App + a
| custom renderer.
| https://store.steampowered.com/app/2198150/Tiny_Glade/
|
| tunnet (https://puzzled-squid.itch.io/tunnet)
|
| Noumenal (https://noumenal.app/) Foresight Mining
| (https://www.foresightmining.com/) Mining "CAD" software.
| Employs a number of Bevy devs
|
| Axie Infinity: Homeland
| (https://app.axieinfinity.com/games/homeland-alpha/). Uses Bevy
| ECS + Unity Shifting Chamber
| (https://maciekglowka.itch.io/shifting-chamber)
|
| Hytopia (https://hytopia.com/)
|
| Titleless Comfy City Builder
| (https://twitter.com/i_am_feenster/status/1710714877231186323)
|
| Molecoole
| (https://store.steampowered.com/app/1792170/Molecoole/)
|
| Titleless industrial revolution builder
| (https://twitter.com/ElmoSampedro/status/1684920884811698176)
|
| Jarl Game (https://twitter.com/jarl_game) Dwarf Fortress-like
| with cool dynamic lighting
|
| The "bevy" tag on itch.io has hundreds of games:
| https://itch.io/games/tag-bevy Also lots of activity in the
| #showcase channel on the Bevy discord.
| tasubotadas wrote:
| >Bevy is a refreshingly simple data-driven game engine built in
| Rust
|
| All frameworks set out to be simple, clean, and fast
| implementations of something more established but they lack more
| fancy bells and whistles. Then as they catch up in features, they
| became the same complex beasts and the cycle repeats.
| _cart wrote:
| This is a reasonable "broad strokes" view of the lifecycle of a
| software project. But it could be applied to literally any
| claim about software simplicity / ease-of-use, so I don't find
| it to be a particularly helpful critique. The takeaway appears
| to be "all easy-to-use software that adds features is doomed",
| which seems a bit dramatic.
|
| Do you have specific ideas (or concerns) about how Bevy is
| architected (or how it adds new features)? We're doing our best
| to avoid this fate.
| armchairhacker wrote:
| To me, Bevy is a completely different way of making games vs
| traditional engines like Unity, Godot, etc.
|
| There's no UI or scripting, everything is done in Rust code. This
| makes it more like more like libGDX and Cocos2D-x.
|
| But unlike those engines, it uses ECS and Rust which makes coding
| in it completely different. So it's kind of in its own little
| island.
|
| I'd love to see successful indie games use Bevy. However, I know
| most game developers aren't going to prefer it over the more
| traditional tools which they've been taught and everyone around
| them is using. I'm not sure the intersection of people who want
| to make games and people who prefer Rust is large; and even
| within this intersection, most people aren't going to dedicate
| considerable amount of time and effort into learning and using an
| experimental new engine, they're going to use something with
| existing trust and resources.
|
| Personally I think Bevy needs a sort of IDE and scripting
| language which is powered by Bevy and Rust. This won't remove the
| "considerable effort into a new project" obstacle, but it would
| make Bevy much more inviting to newcomers who don't have
| experience with Rust and who would be too intimidated to start
| from a wall of code (vs a canvas like Unity or Godot where you
| can have a very basic prototype within hours). Plus, I believe
| the developer is against scripting languages, but I really think
| that hot reload and more invasive debugging is necessary and
| can't be effectively done in Rust (plus as just mentioned, many
| game developers will be overwhelmed with Rust and it's borrow
| checker). But those are just my thoughts, and right now I don't
| have the time, resources, and dedication to implement them
| myself...
___________________________________________________________________
(page generated 2023-11-04 23:00 UTC)