[HN Gopher] Bevy 0.5: data oriented game engine built in Rust
___________________________________________________________________
Bevy 0.5: data oriented game engine built in Rust
Author : _cart
Score : 120 points
Date : 2021-04-06 19:19 UTC (3 hours ago)
(HTM) web link (bevyengine.org)
(TXT) w3m dump (bevyengine.org)
| aimor wrote:
| I've been anticipating this, glad it's released! I started using
| Bevy a few months ago on version 0.4 and have had a really great
| experience learning the tool and getting help from the community.
| The documentation isn't as full as I'd like, but there's lots of
| examples and people available to answer questions. This post is
| just to encourage anyone interested to go ahead and try it out.
| TheRawMeatball wrote:
| Check out https://bevy-cheatbook.github.io/ ! It's a WIP, but
| it covers all the basics very well.
| terafo wrote:
| Are there any benchmarks of Bevy ECS v2?
| alice-i-cecile wrote:
| There are some in the blog post, with more details in the
| corresponding PR: https://github.com/bevyengine/bevy/pull/1525
|
| Ctrl+F for "Benchmarks" to find the right section :) Eventually
| it would be nice to update the cross-engine ecs_bench_suite
| fully to reflect the changes.
| argv_empty wrote:
| What does it mean for a game engine to be data oriented or data-
| driven?
| brundolf wrote:
| Broadly it means there's an emphasis on creating your content
| declaratively, often in a config file format (i.e., not in
| code). Saying "there's an entity X, it has these behaviors, it
| has these properties" in XML or JSON or whatever else. And then
| actual code is written separately, to handle specific logic
| that uses those declarative properties.
|
| I'm sure somebody else can give a more precise definition
| Narishma wrote:
| I think what you describe is "data-driven". This engine is
| "data-oriented", which is a different thing.
| jamadazi wrote:
| It's in contrast to Object-Oriented Programming. In OOP, you
| define classes of objects, with behaviors/functionality
| attached to them.
|
| In Bevy, the focus is on the data. The ECS is like a big table
| (if you are not familiar, you can think of it by analogy with a
| database or spreadsheet). It stores all your data. Components
| are like the columns of the table, and entities are like rows.
|
| You then write functionality separately. You can _query_ the
| ECS to get the data you need. Your logic is not attached to any
| particular "object instance" or "object type".
| kgeist wrote:
| Their ECS implementation sounds like a full-fledged in-memory DB.
|
| Have there been serious attempts to use ECS outside of gamedev?
| The concepts are pretty interesting.
| sylvain_kerkour wrote:
| Congrats!
|
| For people (like me) who want to see what can be made with bevy,
| have a look here: https://github.com/bevyengine/awesome-bevy
| dang wrote:
| _Bevy 0.4: data oriented game engine built in Rust_ -
| https://news.ycombinator.com/item?id=25480321 - Dec 2020 (23
| comments)
|
| _Bevy 0.3: game engine built in Rust_ -
| https://news.ycombinator.com/item?id=24983956 - Nov 2020 (55
| comments)
|
| _Bevy 0.2_ - https://news.ycombinator.com/item?id=24530698 -
| Sept 2020 (43 comments)
|
| _Bevy: A Game Engine in Rust_ -
| 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 - Aug 2020
| (103 comments)
| yagizdegirmenci wrote:
| Bevy: A Game engine built in Rust -
| https://news.ycombinator.com/item?id=26131350 - February 2021
| (117 comments)
| reitzensteinm wrote:
| The activity on this story seems to have triggered the flamewar
| protection mechanism - any chance of vouching for it to get it
| back on the front page?
| jamadazi wrote:
| For anyone interested in learning / trying out Bevy, have a look
| at The Unofficial Bevy Cheatbook (i'm the author): https://bevy-
| cheatbook.github.io.
|
| I did a major overhaul of the book for the new 0.5 release, and
| it's better than ever! Many pages were expanded or rewritten, new
| content added, and community feedback addressed. This is now one
| of the most detailed learning resources for Bevy.
|
| Enjoy, and have fun making things with Bevy!
|
| (the book is a continuous work in progress, even more content and
| improvements coming soon!)
| serverholic wrote:
| Huge release. Glad to see this engine is still making progress.
| gwittel wrote:
| If you can't get to the bevyengine.org web site, you can view the
| release announcement in the Bevy projects' web site Github repo:
|
| https://github.com/bevyengine/bevy-website/blob/master/conte...
| 1-6 wrote:
| It's easy to market what Bevy is when it's called a 'Game Engine'
| but I hope this platform can really become the next Omniverse-
| type collaborative 3D environment for the
| Architecture/Engineering/Construction market. Right now, there
| isn't a great place to park BIM files.
| alice-i-cecile wrote:
| Yeah, there's been a ton of interest in using Bevy for non-game
| applications.
|
| We have at least two projects doing CAD with it, several trying
| to use it for machine learning, exotic high-performance
| database-like applications, and some interest in using it as an
| ergonomic fully cross-platform GUI builder once our UI solution
| is built out.
| adamnemecek wrote:
| Can you link the CAD projects?
| alice-i-cecile wrote:
| Contributor here: there's _so_ much cool stuff in this release.
|
| I was personally most involved in improving the docs, the
| reliable change detection work (you can now detect changes no
| matter when your system runs, even skipping arbitrary numbers of
| frames), and a great deal of the other ECS work. AMA if you have
| any questions or requests ;) I'm particularly curious about "I'd
| like to use Bevy but..." stories.
| beatothewitch wrote:
| I'm a novice game dev and I'm currently using Godot so i'd like
| to use Bevy but i'm waiting for an editor UI. What's the
| roadmap looking like for that?
| alice-i-cecile wrote:
| Great question; it's hotly awaited by a lot of the community.
| Rough (and very unofficial) road-map is looking like: 1. 0.6
| (June 2021): First-class ECS-integrated UI solution is
| architected and released. Asset management, animation and
| scenes are improved. Plugin architecture and data-driven
| workflows get a closer look. 2. 0.7 (August 2021): Editor MVP
| launches as a separate application built in Bevy, focusing on
| supplementing code-first Bevy workflows with things like
| property inspectors, scene management, system visualization
| and so on.
|
| Once that's launched, I expect that we'll be working on
| making Bevy more usable through the editor for low-code
| users, although the goal is to ensure that pure-code (and
| pure Rust) Bevy games have feature parity with anything you
| can do in the editor.
| anchpop wrote:
| Thank you for your contributions! I'm most excited about
| labeled run criteria and the other ECS improvements. For those
| not following along, the goal is to eventually implement
| statecharts [0], which are kind of a generalization of finite
| state machines that are more practical for specifying the
| behavior of complex systems. I think that's going to really put
| Bevy's ECS above most of the competition and push the field
| forward.
|
| [0]: https://statecharts.github.io/
| kodablah wrote:
| > I'm particularly curious about "I'd like to use Bevy but..."
| stories.
|
| I am a game dev novice, but the concept I am wanting to develop
| requires mesh loading (fbx/dae), animation/skeleton/bone
| loading, and custom bone manipulation. Granted Bevy does seem
| to have the physics I need via the rapier plugin. I have been
| working with Godot to achieve my PoC, but would love to use
| Bevy instead. I admit to not keeping up with the current state
| of these features.
| alice-i-cecile wrote:
| Thanks for chiming in :) Animation is a common request, and
| definitely still not-very-usable.
|
| Thanks to the work of lassade, our resident animation expert,
| I expect we should have basic animation in place for 0.6. For
| skeletal animation in particular, they've been prototyping
| with a crate of their own [0] to hook into Bevy that seems
| like an excellent proof-of-concept.
|
| 0: https://github.com/lassade/bevy_spine
| hn8788 wrote:
| I've been using Godot for some small gamedev projects, but have
| been interested in Bevy because Rust is my primary language.
| The Bevy Book stil says that Godot should be picked for any big
| projects; is there a rough estimate of when Bevy would be at a
| point where you'd be confident recommending it for a Next Big
| Project(tm)? I know timelines can be tough to nail down, but
| even something like "a very long time" or "a couple of years"
| would be helpful. Thanks for your work btw :)
| alice-i-cecile wrote:
| Depends on your iteration speed, exact needs, and willingness
| to work on engine development.
|
| Personally, I'm building my turn-based tactical RPG in it,
| which is absolutely a Big Project, but I'm not planning to
| release for a year or two, don't need complex 3D features and
| am devoting half of my effort to engine dev.
|
| For single-player games that aren't very asset-heavy, I would
| say 3 months or so for UI to stabilize is a safe point to
| start work.
|
| For games that have complex animation or sound needs, require
| networking or want to use a ready-to-use physics library, I'd
| estimate about 2 years from now.
|
| If you're trying to build a game with very-little coding (and
| want something comparable to Unity or Godot), "a very long
| time" :)
| kibwen wrote:
| Off-topic, but is your game open source? I'd love to see
| more examples of Bevy being used in the wild.
| adamnemecek wrote:
| If you re interested in Rust game dev, check out the rg3d engine
| https://github.com/mrDIMAS/rg3d.
|
| Join the rg3d discord channel https://discord.gg/xENF5Uh
|
| Here's a sample game made with rg3d
| https://github.com/mrDIMAS/StationIapetus
| serverholic wrote:
| It seems a bit tasteless to promote another game engine in this
| thread.
| adamnemecek wrote:
| I'm mentioning alternatives.
| the_duke wrote:
| You constantly promote other libraries in semi-related topics
| on Reddit as well.
|
| I find this quite weird, what's the point?
|
| At the very least post a comparison of why X is better/more
| interesting than Y.
| alice-i-cecile wrote:
| As a Bevy contributor, I can say that rg3d is much more
| mature and feature-complete than we are right now. They're
| substantially ahead on animations, UI, sound and rendering.
|
| That said, the engine isn't ECS-based (they use a scene graph
| instead), the community is much smaller, and the engine as a
| whole seem to be much more narrowly focused on a specific
| type of 3D game, exemplified by the shooter example.
| adamnemecek wrote:
| Is it weird? Alternatives are mentioned in HN threads all the
| time.
|
| I mean you can make the comparison yourself.
| serverholic wrote:
| It's one thing to mention alternatives but "join the
| discord" is straight up promotion.
| adamnemecek wrote:
| That's a weird line to draw.
| serverholic wrote:
| Alright, well if you ever release ngrid I'm sure you
| won't mind if I post about alternatives right?
|
| Maybe include some links to some competitors, and an
| invitation to their discords. Also I'll be sure to not
| mention your project at all in my post. Hope that's ok.
| adamnemecek wrote:
| I'll release it soon. I can tell you can't wait for it.
|
| Also the scenario you describe is a different thing since
| one is commercial and one is open source. But I wouldn't
| be particularly upset about you mentioning your product.
|
| Also I'm not going to mention alternatives but I wouldn't
| be butthurt if they post it themselves. Is that a hard
| concept?
| _cart wrote:
| Lead Bevy developer here. Feel free to ask me anything!
| CJefferson wrote:
| Is it a good idea do you think to use Bevy for a game yet?
|
| I don't expect a concrete promise, but is to reasonably bug
| free, and is it likely to be "not too hard" to upgrade to new
| versions in future? Or should I wait?
| alice-i-cecile wrote:
| Depends on how quickly you're moving and how much polish you
| want :) Great for game jams and prototypes, not there yet for
| published games.
|
| Reasonably bug free, yes. Not too hard to upgrade, yes. Are
| critical features missing or inadequate (audio, animations,
| networking, UI...), also yes ;)
|
| But, just like making a game engine, there are a huge number
| of parts to making your game. If it's a weekend project, you
| can patch it up with 3rd party integrations and focus on the
| parts that are currently _great_.
| jamadazi wrote:
| Bevy has no stability guarantees. APIs will be broken.
|
| However, that said, many of us are already building "real
| games" with Bevy. I've been using bevy almost since day-1,
| and none of the updates have been particularly
| difficult/painful. The changes have always been easy to adapt
| to, especially with the Rust compiler helpfully pointing out
| everything you need to fix ;).
|
| In terms of features for building "real games", bevy is still
| lacking in many areas:
|
| - UI is very primitive (this is the next focus area to be
| worked on)
|
| - animation (already in progress)
|
| - audio (community-made plugins are available)
|
| - advanced rendering features and performance optimizations
| (also already being worked on)
|
| - there is no editor yet
|
| Given the super active development pace of Bevy, many of
| these areas will greatly improve soon.
|
| If you want to make a content-focused game with lots of
| assets and requiring a level/scene editor, Bevy is not ready
| yet. However, if your game is more code/programming/logic
| heavy, I definitely recommend that you try Bevy already now.
| The programming experience is _awesome_ , the ECS ergonomics
| are _really good_. It 's really easy to code game logic.
| setr wrote:
| With the implementation of Change Detection + Sparse sets, does
| that mean that using components to handle entity state (e.g.
| flags like is_hungry) is recommended? And then a system
| querying for Changed<is_hungry>
|
| With archetypes alone, I believe this would have been highly
| undesirable (causing the entity moving back and forth between
| archetype tables)
| alice-i-cecile wrote:
| Yep, marker components is a _much_ more feasible pattern now,
| and I tend to prefer tiny, granular components when writing
| Bevy apps as a result.
|
| The only drawback to this design is that you can't add /
| remove components instantly[0], and instead need to wait for
| the next "hard sync point" at the end of the stage.
|
| 0: https://github.com/bevyengine/bevy/issues/1613
| TheRawMeatball wrote:
| Yes! Marker components, as we like to call them are a common
| and encouraged pattern :)
| EamonnMR wrote:
| What have the biggest challenges been?
| ibdknox wrote:
| You mention: The solution is to build a
| "graph" of archetypes to cache these results... If ComponentIds
| are densely packed, you can use sparse sets to cheaply jump
| between archetypes.
|
| I couldn't quite figure out from the description how the edges
| are actually stored and I was curious why having the
| ComponentIds densely packed helps. I'd love to hear more about
| how the graph is represented. :)
| _cart wrote:
| We ended up cutting some of the technical ECS details from
| the blog post to make it more easily-digestible. The
| description in this pull request is effectively a stand-alone
| blog post describing things like the Archetype Graph:
| https://github.com/bevyengine/bevy/pull/1525
| pointernil wrote:
| Kudos! What an impressive collection of features and display of
| substantial development in almost all areas of the framework!
|
| What's the current status of OpenGl Support? Any progress
| there? It would be really "cool" and inspiring to be able to
| develop on older yet otherwise good-enough hardware... thinking
| about all those very young future devs stuck with all that
| otherwise good-enough hardware here ;)
| TheRawMeatball wrote:
| We let wgpu https://github.com/gfx-rs/wgpu-rs handle our
| graphics backend abstraction, so our OpenGL support will come
| whenever they implement and release it. Currently, it seems
| to be a WIP.
| smusamashah wrote:
| Has basic 2D drawing (lines, rectangle, bezier curve etc) added
| yet? I remember it was in the plans in the very beginning.
| jamadazi wrote:
| Officially, not yet, but there is a good community-maintained
| plugin: `bevy_prototype_lyon`.
| TheRawMeatball wrote:
| No, but the https://github.com/Nilirad/bevy_prototype_lyon
| crate does a very nice job here :)
| sercand wrote:
| Is it currently possible to use Bevy with given MTKView on iOS?
|
| We have already an app with thousands lines of code and we need
| to render a game like experience on a just single page. We can
| achieve this with SpriteKit or SceneKit but we need something
| on android as well. So we are investigating a cross-platform
| tool.
|
| The given iOS example on Github repository creates the window
| itself but it not possible for us.
|
| edit: It looks like bevy uses winit for windowing and it
| doesn't support this. So winit is the blocker here.
| jamadazi wrote:
| Bevy is modular, in the sense that you can remove higher-
| level parts/layers if you don't want to use them.
|
| For example, you could use only the Bevy ECS if you didn't
| care about the rest.
|
| You could replace `bevy_winit` (window creation using the
| winit library) with your own alternative.
| the_duke wrote:
| I'd just like to mention that the release notes are one of the
| best I've read.
|
| Same goes for PR descriptions like for the ECS v2 PR [1].
| That's more text than half of open source libraries have
| documentation.
|
| [1] https://github.com/bevyengine/bevy/pull/1525
___________________________________________________________________
(page generated 2021-04-06 23:02 UTC)