[HN Gopher] Bevy 0.7: data oriented game engine built in Rust
___________________________________________________________________
Bevy 0.7: data oriented game engine built in Rust
Author : _cart
Score : 165 points
Date : 2022-04-15 18:16 UTC (4 hours ago)
(HTM) web link (bevyengine.org)
(TXT) w3m dump (bevyengine.org)
| andrewmcwatters wrote:
| Any plans to provide out of the box multiplayer? Lots of engines
| today don't think about it at all, and instead seem to focus on
| the sort of feature set provided by Unreal and Unity.
|
| I don't think there's a whole lot of value in that design, but
| that's my personal opinion having built an engine for the Lua
| community that did somethings no one else was doing.
|
| Mainly, providing an out of the box experience for, typically,
| hobbyist developers who don't actually know anything about
| multiplayer serialization or prediction, etc.
|
| The sort of younger developers and people who are playing around
| with code and posting on Reddit and such.
|
| A lot of engines are just wrappers around popular libraries and I
| don't know if there's a tremendous value around that sort of
| thing.
|
| Consider, for example, audio. It's really easy to provide audio
| bindings to, I don't know, let's say OpenAL, because I don't know
| what else is used these days. But game developers eventually
| mature enough where they don't just care about playing audio.
|
| What they'll eventually want is to play a sound, with DSP, and
| have that audio automatically networked by the engine to play on
| different connected client's based on visibility rules or at
| least a simple emit sound networked event.
|
| There's an entire class of hobby engines that don't consider
| these things, and leave it as an exercise for the user to
| implement. They are entirely non-trivial features that the users
| will never implement, though, and instead just never pursue that
| feature because the engine doesn't provide it.
| hnuser123456 wrote:
| I recognize your name from the facepunch days. I think you
| updated my early SWEP templates, which AFAIK were the first
| "full-featured" template published on the forums and
| proliferated everywhere. I didn't know you made your own GMod.
|
| I wrote a VR GMod clone[1] based on Source2/SteamVR
| Environments, mostly in lua, with some basic HTML/JS/CSS for
| Panorama UI components, incorporating the usual art assets
| updated/ported for Source2 made by kind artists from the
| community with their permission. My work was mostly to re-write
| the physics gun and toolgun with UI/controller input bindings
| to the physics engine and my custom UI. Of course, all of the
| hard work is credit to the teams at Valve.
|
| [1]
| https://steamcommunity.com/sharedfiles/filedetails/?id=20429...
| andrewmcwatters wrote:
| I'm not sure if I edited yours. I created one of the first
| ports from C++ to Lua of the Half-Life 2 and Counter-Strike:
| Source weapons that allowed you to mod those.
|
| I'm also the author of Planimeter's (previously Team
| Sandbox's) Half-Life 2: Sandbox reference implementation,
| which was the first Source engine game to use LuaJIT.
|
| We also ported the base code to allow users to use Lua in
| other games as a Valve Server Plugin. It relied heavily on
| reverse engineering.
| hnuser123456 wrote:
| Wow, I wish I stayed closer to gamedev. I would love to see
| (MP) VR dev made more accessible. The Source2 used in HL:A
| doesn't support MP (and still has many missing tools), and
| the Source2 used in SteamVR environments is very barebones
| and an earlier version of the engine. It looks like Garry's
| S&box is going to be the "most-feature-complete" version of
| Source2 for modding/additional development. Using Unity for
| VR seems silly if not used for VRchat where the social
| scene already is, unless making a new unique standalone
| title from near scratch. Using UE5 seems tempting, if a bit
| corporate, but I'm not sure how far their VR/VR-MP
| integration is, plus UE5 seems overly heavy for VR on
| typical hardware.
|
| Once it's not prohibitively expensive to run raytracing in
| VR, we're going to see some cool stuff.
| faitswulff wrote:
| I'm no gamedev, but multiplayer seems very dependent on the use
| case. Is your game turn based? Real time? In the case of a
| fighting game, do you need millisecond resolution? I'm not sure
| a satisfactory out of the box multiplayer experience would be
| something a game engine could abstract.
| andrewmcwatters wrote:
| It's a good point, but something is better than nothing. For
| instance, in our engine my team provides those mechanisms
| from the network variables associated with an entity/actor.
|
| So, doing something like:
| entity:networkVar( "health", 10 ) -- ...
| local health = entity:getNetworkVar( "health" )
| entity:setNetworkVar( "health", health - 2 )
|
| Does exactly what you'd expect.
|
| You can set the console variable `tickrate' and, that too,
| does exactly what you'd expect.
| lwansbrough wrote:
| Something isn't always better than nothing. When it comes
| to networking, I personally think it's better to give
| people who are new to the space a lay of the land before
| letting them choose a path. For instance, in your example:
| is that information sent reliably or unreliably? Why one
| way or the other? Would your answer change for a different
| piece of data? All those questions are relevant and often
| worth asking up front, depending on what type of game
| you're developing.
| andrewmcwatters wrote:
| I think this is a weak answer. Too many engines simply do
| nothing and provide you at best raw sockets. That's not a
| solution, and most of the time people use arguments like
| this, and they're not valuable, either.
|
| It's like saying "The problem is difficult," it doesn't
| inform anyone and no one learns from it.
|
| Further, most advanced engines simply allow you to
| construct payloads and `setReliable( true/false )` or
| something similar.
| valorzard wrote:
| I can tell you right now that there's an entire channel in the
| Bevy discord server dedicated to making an out of the box api
| for multiplayer. If you want the current state of it, check out
| this RFC. https://github.com/bevyengine/rfcs/pull/19 I'm really
| excited for it when it eventually comes out.
| forrest2 wrote:
| Arguably needs to be abstracted out to some kind of multiplayer
| middleware; multiplayer sounds like one-size-fits-all but it's
| very nuanced.
|
| And that feeling that it needs to be abstracted/genericized
| might be the same reason why it never gets done.
| djmcnab wrote:
| To copy from another comment[0] elsewhere in the thread from
| cart:
|
| > The story is similar for networking. Ultimately we will have
| a built in api, but we're focused on more fundamental things at
| the moment. There are _tons_ of community-developed networking
| plugins though: https://bevyengine.org/assets/#networking
|
| That is, we do definitely want to make multiplayer work
| properly, and our data design should give us inherent
| advantages here. But it hasn't been a priority so far, as we've
| had other more pressing requirements (e.g. animation this
| release).
|
| But a lot of what you want should in the medium term be
| provided by external crates; our use of systems as the unit of
| logic should make this viable, as behaviour implemented by the
| engine is not special. These external crates could potentially
| be made official if that made sense, but that's for much longer
| time scales.
|
| [0]: https://news.ycombinator.com/item?id=31044108
| izend wrote:
| I spent quite a few hours working on an example of Bevy 0.5 and
| Tokio for multiplayer backend server.
|
| https://github.com/peterholko/bevy_tokio_tungstenite/blob/ma...
| malwrar wrote:
| This is exciting! Bevy is the rendering engine equivalent of
| python's Flask module in terms of ease-of-use & flexibility, and
| if you're looking to render things I think it's a pretty solid
| bet to put your time into.
| capableweb wrote:
| Isn't Flask a web framework for python, and at that, a quite
| small one? Not sure how that compares to a game framework,
| especially one that "forces" you to one architecture (ECS in
| this case). Games will always be more complicated to create and
| maintain than web services.
| james7132 wrote:
| I think it's more in terms of the ergonomics and developer
| UX. Both Bevy and Flask have a very minimal and surprisingly
| idiomatic "hello world" example, and both rather seamlessly
| and progressively introduce concepts, which helps onboard
| developers into the framework/engine.
|
| In Bevy's case, it also helps onboard the developer into
| _engine development_ too, since engine code is entirely ECS
| based, so engine code looks nearly identical to both user and
| plugin code. For your typical user, this is a bit odd, but
| speaking as someone who went from new to the engine to
| helping write the headliner features for this release in the
| course of just a few months, this is a surprisingly
| empowering experience.
| rosenjcb wrote:
| This reminds me a lot of Amethyst.
| qchris wrote:
| That's very understandable--there has been a significant amount
| of influence from Amethyst on Bevy's design[1], and a number of
| members in that community have ended up joining the Bevy
| project in one way or another. Cart, the lead Bevy dev, has a
| comment in the linked thread.
|
| [1] https://community.amethyst.rs/t/bevy-engine-addressing-
| the-e...
| [deleted]
| Sparkle-san wrote:
| I'm impressed by the speed of this release. I started checking
| out Bevy after reading Hands-on Rust[1] and wasn't expecting any
| updates given 0.6 came out in January.
|
| [1]https://pragprog.com/titles/hwrust/hands-on-rust/
| MiniaczQ wrote:
| That's because with 0.6 Bevy moved onto a 3-month release
| schedule :)
| djmcnab wrote:
| Yes, indeed. This was mentioned in 0.6's release notes[0].
| However, this is the first actual stop of the train, so we
| probably could have mentioned it in these release notes as
| well.
|
| [0]: https://bevyengine.org/news/bevy-0-6/#the-train-release-
| sche...
| OnionBlender wrote:
| I've been trying to learn Bevy on and off for months but I'm
| finding it difficult. The official Bevy Getting Started tutorial
| is very short. I've looked through many of examples but I find
| them difficult to follow because I'm not familiar with how Bevy
| wants you do to things. I find that the API docs don't explain
| what things are used for. I feel like I'm missing some core
| concepts but I don't know where I'm supposed to learn them.
|
| Some examples. What are commands? What is the world? How should I
| be creating and destroying objects? How do I ensure some systems
| run before others? How should I delay loading most of the systems
| until a button is pressed on the first screen? How do I unload
| systems? How do I pass information between systems?
|
| I'm not looking for someone to answer all of these questions, I
| just want to know where I'm supposed to read about them because I
| feel like I'm missing some important docs.
|
| The Unofficial Bevy Cheat Book looks promising because it appears
| to explain some of the core concepts. However, it is weird that I
| have to read an unofficial book to learn these things. Without
| the Unofficial book, where was I supposed to learn the coordinate
| system convention or how to use events?
| alice-i-cecile wrote:
| I'm leading our docs effort, and work on a much expanded
| version of the official book is in progress (and should be
| launched for 0.8).
|
| These are _absolutely_ reasonable concerns, and a centralized,
| first-part introduction to the core concepts is essential.
| _cart wrote:
| I'd like to call out that Alice's doc-leadership is a "new"
| thing and we're already seeing a lot of progress on the new
| Bevy Book, our API docs, and our examples. I've noticed a
| huge uptick in community documentation contribution /
| participation in the last couple of months.
| tomtheelder wrote:
| As another commenter suggested I think a really solid
| foundation in ECS architecture will get you some of the way,
| but you're totally right that the documentation is sparse. I
| think the engine should really be thought of as being in alpha
| right now given how rapidly it's evolving and how unstable
| different APIs are. I suspect at some point the docs would
| stabilize.
|
| IMO you should only really bother with Bevy right now if you
| find it inherently interesting and you are down to dip into the
| source sometimes. Even in the universe of Rust based ECS game
| engines there are more stable and documented options.
| dhruvdh wrote:
| You would probably benefit from watching a talk or two on ECS
| (Entity component system).
| pizza234 wrote:
| You'll find a very good introduction to ECS in Rust in the book
| "Hands-on Rust: Effective learning through 2D Game
| Development"1. It's based on Legion, which (AFAIK) is now
| discontinued, but the book/project has such a smooth design,
| that it makes working with an ECS really a pleasure (to be
| fair, Legion is less ergonomic than Bevy, but it's not a big
| deal).
|
| I'd be cautious towards Bevy; it's a product that capitalized
| with great success on hype; there's nothing inherently wrong
| with that (I don't doubt at some point it will reach a stable
| point), but it should be clear to users that it's currently
| "very alpha" (that said, I'm happy to report that Bevy made
| huge strides in stability/usability between v0.5 and v0.7).
|
| 1=https://pragprog.com/titles/hwrust/hands-on-rust
| gameswithgo wrote:
| _cart wrote:
| Lead Bevy developer (and creator) here. Ask me anything!
| karmakurtisaani wrote:
| What does data oriented mean in practice?
| elanning wrote:
| This chapter encapsulates much of data oriented design:
| https://www.dataorienteddesign.com/dodbook/node5.html
| The_rationalist wrote:
| dukeofdoom wrote:
| How hard would it be to port a pygame to this? What would be
| the advantages?
| alice-i-cecile wrote:
| It would be a full rewrite, so moderately easier than writing
| it from scratch.
|
| The main advantages right now would probably be improved
| performance, better cross-platform support and access to a
| wide collection of interoperable community plugins.
|
| The ECS architecture and the fact that's in Rust could also
| be serious benefits, but for small games, those are really a
| matter of taste.
| piefayth wrote:
| One of my grievances with most engines is a poor story around
| networked physics. It's desirable to me to be able to leverage
| historical physics states in a performant way, sometimes
| querying or stepping many modified versions of those states at
| once.
|
| Bevy's data oriented design seems great for the kind of
| stateless physics required here, but I couldn't find any
| physics OR networking features in a quick five minute browse.
| Is this something that is well supported by Bevy today, or will
| be in the future?
| _cart wrote:
| We haven't (yet) prioritized an official physics plugin for
| Bevy, but the Rapier physics engine has their own official
| Bevy plugin, which is the de-facto standard at this point.
|
| It supports opt-in determinism, which should be great for
| some networked physics scenarios.
|
| https://rapier.rs/docs/user_guides/bevy_plugin/getting_start.
| ..
|
| The story is similar for networking. Ultimately we will have
| a built in api, but we're focused on more fundamental things
| at the moment. There are _tons_ of community-developed
| networking plugins though:
| https://bevyengine.org/assets/#networking
| lazypenguin wrote:
| Hi Cart, have you considered giving a presentation or writing
| an article about how you successfully manage the project? I
| remember when you first publicly released bevy and the
| onslaught of support you received. I'd be curious how you were
| able to successfully manage that as it's clear you've done that
| well as Bevy continues to grow at an incredible pace.
| _cart wrote:
| I'd consider doing that once I feel like I've actually
| "solved" this problem. Adjusting to this scale of community
| development has been a slow and sometimes painful process. I
| started with a "benevolent dictator for as long as I can
| manage it" model and we have slowly been transitioning into a
| more distributed decision making process where more people
| are reviewing code and more people have merge rights.
| Currently these merge rights are very "scoped" and I am still
| making basically every "controversial" call when it comes to
| code and api design. This means that I am a bottleneck, and
| the pressure to resolve this increases as the community
| grows. I have "big plans" here that involve continuing to
| expand the scope of the other maintainers (Francois and
| Alice), pulling in even more maintainers, and empowering
| "working groups" to make decisions more autonomously. Expect
| to see significant progress here in the very near future.
| the_duke wrote:
| I still haven't been able to use Bevy yet, but as always: the
| release notes are a joy to read and the speed of development is
| impressive.
|
| The only question concerns the missing last paragraph: what's
| next on the roadmap? Is a UI overhaul (and an early stage
| editor) happening soonish?
| _cart wrote:
| Haha that was definitely a miss. We normally do include that
| section at the end. From a high level, breaking ground on the
| Bevy editor is my priority. But getting there still requires
| some intermediate steps (finalizing UI, scenes, and assets,
| which are all functional at the moment but still need some
| work).
|
| Some of my priorities for the next 3-month release cycle are:
| high level render targets, asset preprocessing, a new
| "stageless" ECS scheduler, multi-track animation playback /
| blending, and bevy organization scaling.
| Waterluvian wrote:
| What's the largest or most impressive game shipped that uses
| the Bevy engine? (Open or closed source)
|
| I like asking this because while a whole bunch of smaller games
| do a great job showing examples of how to use the engine,
| larger games practically demonstrate the scalability of the
| engine.
| tomtheelder wrote:
| I doubt there are projects of significant scale right now.
| This is a very, _very_ young engine.
| alice-i-cecile wrote:
| The largest "game" that I'm aware of is a piece of closed
| source CAD software [0]. They've been thrilled with the
| performance and ergonomics of the code, although they're
| relying on egui [1] for the UI.
|
| As to scale, they crunch absolutely absurd amounts of data,
| seem to have an impressive amount of functionality, and are
| regularly hiring new folks from the community onto their
| team.
|
| [0]: https://www.foresightmining.com/ [1]:
| https://github.com/emilk/egui
| Waterluvian wrote:
| Wow. What a great example. Thank you!
| _cart wrote:
| As a disclaimer: Bevy is still very new, our apis are still
| in flux and incomplete, and we actually recommend that people
| don't use Bevy for "serious projects" yet in our official
| docs. Don't expect to see Elden Ring equivalents in Bevy for
| a long time. People shouldn't be staking their livelihoods on
| Bevy yet (although some still do because they see our value
| and potential ... there are a surprising number of paid Bevy
| jobs out there).
|
| There are very few "complete games / apps" built in Bevy.
| We're still very much in the "enthusiast / jammer" phase, but
| we're dangerously close to working our way out of that.
|
| To my knowledge there are only a couple of "released" full
| games / apps: Molecoole was very recently the first Bevy game
| released on Steam:
| https://store.steampowered.com/app/1792170/Molecoole/
| Noumenal is a really cool "constructive solid geometry" Bevy-
| based 3D modeler on the iOS app store: https://noumenal.app/
|
| That being said, we just had a very successful first Bevy
| game jam: https://itch.io/jam/bevy-jam-1/
|
| We also have a number of nice open source games listed in
| Bevy Assets: https://bevyengine.org/assets/#games
|
| And there are a lot of Bevy games listed on itch.io:
| https://itch.io/games/tag-bevy
| Waterluvian wrote:
| Thanks for all the links! This is certainly helping me get
| a feel.
| Shadonototra wrote:
| other than "written in Rust", what it does different than the
| billion other open source game library?
|
| "written in Rust" won't make the game by itself
| atoav wrote:
| From what I gathered the ECS (Entity Component System) it uses
| allows for great performance.
|
| This aside: if we assume the speed gains in future computing
| will be more about number of cores than CPU frequency then
| using a language which has some guarantees around concurrent
| code and data races is probably not a bad idea. It is really
| quite easy to shoot yourself into the foot when you run
| parallel code in traditional systems programming languages.
| andrewmcwatters wrote:
| The issues hobbyist game developers face don't typically have
| anything to do with performance, though. The issues they face
| are that no one plays their games, sometimes because they're
| too simple, and the software toolchain they're using isn't
| powerful enough to help them.
| alice-i-cecile wrote:
| I definitely agree that performance is really not the thing
| that hobbyist game developers need. However, hobbyist game
| devs aren't (our only) target market.
|
| Right now, the team who is seeing the most success with
| Bevy are actually building CAD software! They needed
| something powerful, fast, incredibly flexible with "game-
| like" functionality.
|
| That said, from talking to the hobbyists in the community,
| they like Bevy because it's:
|
| - code-first
|
| - written in Rust (C# is fine, but Unity's C# is something
| of a DSL, and game engine C++ is really rough)
|
| - cares about good documentation and a helpful learning
| experience
|
| - supports them in contributing fixes to issues they run
| into
|
| - is incredibly flexible: you can just swap in your own
| physics or rendering to realize that weird idea you had, or
| just for the learning experience
| atoav wrote:
| Who says this is targeted at hobbyist game developers?
|
| Someone liked the idea of writing a game engine in Rust and
| so they did. I wrote my own sidescroller engine when I was
| 16 as well, although there were existing things around and
| it thought me a great deal about how to tackle multiple
| classes of problems.
|
| Now the bevy devs seem way more experienced and if there
| was already a game engine that ticked all their boxes they
| might not have started developing a new one. But the point
| here is: Not everything is a product with an clearcut
| target audience -- and not everything has to be.
|
| Projects like these ultimately help the whole field of game
| engines to move on and innovate.
| andrewmcwatters wrote:
| Most non-commercial game software is. I think it's
| meaningful to note that, because it helps clarify the
| authors' intentions.
| Yuioup wrote:
| Is the ECS paradigm useful in enterprise situations e.g.
| database driven (web)applications?
| james7132 wrote:
| Most ECS implementations realistically are high-performance
| in-memory columnar databases, where systems use granular
| mutation patterns. Hell, the main access pattern is
| literally a called a Query. It's become quite a meme to
| call bevy_ecs "turning games into SQL databases". If you've
| used BigQuery or Redshift, you've basically just used a
| super-scaled up ECS engine.
| nicoburns wrote:
| I think to some extent that's still an open question that
| hasn't been fully explored. I've seen a lot of people
| suggesting it could work well for application UI
| development, but nobody has proved it out with a solid
| implementation yet.
| minimaxir wrote:
| Also, the gaming industry has shifted such that performance
| _is_ important. Go on any gaming forum and assert 30fps and
| 60fps are equivalent, or a 60fps that 's not stable is OK.
|
| Unity in particular was a meme for the last generation due to
| CPU-based stuttering.
| pcwalton wrote:
| The type system of Rust requires you to be clear about which
| data your code is touching, and whether that code can mutate it
| or is just reading. This allows a sufficiently smart task
| system--like that of Bevy--to automatically distribute work
| across threads for better hardware utilization.
|
| Also, one of the main reasons I'm interested in Bevy is that
| the engine is modular, pluggable, and extensible at the core
| renderer level, which is nice for those of us experimenting
| with different rendering techniques. Unity in particular is not
| a good fit for this type of thing.
| n42 wrote:
| why don't you click the link and find out?
| alice-i-cecile wrote:
| Fundamentally, Bevy prioritizes different things than many of
| its competitors, and is actively experimenting in all of its
| domains.
|
| Some of the larger distinctions:
|
| - Everything lives in the ECS
|
| - The ECS is incredibly ergonomic: basically just structs and
| functions
|
| - Systems are automatically run in parallel based on their type
| signatures
|
| - Rendering is powered by a composable rendering graph
|
| - Everything is modular, and engine code looks like user code
|
| - A culture that cares about genuinely good, up to date docs
|
| As we grow to properly cover more areas, this list will grow.
| I'm one of the core contributors to Bevy and I can assure you
| we're not interested in writing "yet another game engine" <3
| djmcnab wrote:
| A change I find interesting in this release is the addition of
| `Deref`/`DerefMut` derives[0]. It addresses a very real pain
| point in bevy, due to `#[derive(Component)]`'s interaction with
| the orphan rules requiring newtypes[^1].
|
| But it's potentially not idiomatic within the Rust language, at
| least at the moment (as mentioned in the OP). However, I think
| that the tide is likely to turn on that; for example, in the api-
| guidelines repo, there's a PR[2] to remove this advice. This
| appears to have stalled, although that appears to be not for
| reasons of it being controversial, just lack of reviews; the
| discussion had broad support.
|
| We have discussed (in Discord[3]) a kind of 'internal' `Deref`,
| which would use lenses to do automatic unwrapping for queries.
| See #4413 [4] for an example of what this would look like. I'm
| not sure how necessary that is if we can just use `Deref[Mut]`,
| but it's definitely another angle we could go down long-term.
|
| [0]: https://bevyengine.org/news/bevy-0-7/#deref-derefmut-derives
|
| [^1]: This newtype requirement isn't a negative for bevy, since
| it makes it much easier to avoid interoperability headaches
| between different crates.
|
| [2]: https://github.com/rust-lang/api-guidelines/pull/251
|
| [3]: https://discord.gg/bevy
|
| [4]: https://github.com/bevyengine/bevy/pull/4413
| ______-_-______ wrote:
| I hope the tide does turn and then keeps going. I think the
| language restrictions around Deref(Mut) and Index(Mut)
| originally borne of purism are just not all that helpful in
| practice. I can make a network request in my Deref impl, but I
| can't return a smart pointer?
| Kinrany wrote:
| The danger with DerefMut is that one may accidentally allow
| violating the type's invariant. Same with Deref when interior
| mutability is present.
| alserio wrote:
| For everyone who's following this awesome tutorial has been
| updated: https://mbuffett.com/posts/bevy-snake-tutorial/
___________________________________________________________________
(page generated 2022-04-15 23:02 UTC)