[HN Gopher] Bevy 0.9: data oriented game engine built in Rust
___________________________________________________________________
Bevy 0.9: data oriented game engine built in Rust
Author : _cart
Score : 118 points
Date : 2022-11-12 21:28 UTC (1 hours ago)
(HTM) web link (bevyengine.org)
(TXT) w3m dump (bevyengine.org)
| brink wrote:
| Pardon my lack of technical terms, but when I worked with Bevy in
| 0.7, applying a part of a texture to a surface was really
| difficult. (It wants to apply the entire texture, and stretch it
| to fit.)
|
| Has this improved?
| [deleted]
| _cart wrote:
| Creator and lead developer of Bevy here. Feel free to ask me
| anything!
| aquariusDue wrote:
| Hi, sorry if this question might not be appropriate but I was
| wondering what are the main differences between Godot's way of
| doing things and Bevy's.
|
| Also more importantly thank you for the work you've done on
| Bevy! For someone like me picking up Rust recently it's great
| knowing I can even develop games in it without going into the
| nitty-gritty part of game dev.
| _cart wrote:
| I've summarized a lot of my thoughts in this blog post:
| https://bevyengine.org/news/bevys-first-birthday/#things-
| i-m...
|
| But in short (slight copy-paste of my generic Bevy pitch):
|
| The Developer's Engine: most engines are built using multiple
| languages, with significant abstraction between "user code"
| and "engine code". Bevy is built with a consistent stack and
| data model (see the blog post I linked to for details). If
| you "go to definition" on a Bevy app symbol in your IDE, the
| underlying engine code will look the same as your app code.
| You can also swap out basically everything. We have a vibrant
| plugin ecosystem (https://bevyengine.org/assets) as a result.
| These blurred lines also make it _way_ easier for "Bevy app
| developers" to make direct contributions to the engine. Bevy
| App developers _are_ Bevy Engine developers, they just don't
| know it yet. The new Bevy renderer (in 0.6) was also built
| with this principle in mind. It exposes low, mid, and high
| level renderer apis in a way that makes it easy to "insert
| yourself" into the engine.
|
| Fully embraces ECS: No popular engines are currently all-in
| on ECS (either they have no official support ... or they are
| half-in half-out). I reflect on some of the benefits we've
| enjoyed thanks to Bevy ECS in the blog post I linked to. Note
| that there is _a lot_ of pro _and_ anti ECS hype. Don't just
| blindly follow dogma and hype trains. ECS isn't one thing and
| Bevy ECS intentionally blurs the lines between paradigms.
|
| We can't currently compete with the "big engines" on
| features, but we are adding features at a rapid (and growing)
| pace. Bevy was released about a year and a half ago. Most
| popular engines have been in development for almost 20 years
| (Godot since 2007, Unity since 2005, Unreal since 1998), so
| we have plenty of "time" from my perspective.
|
| I'm a huge fan of Godot and used it to build my game High Hat
| over the course of about 4 years. I also contributed to it
| every once and awhile. When I was initially building Bevy,
| Godot's design decisions were always at the top of my mind
| (and they still are to this day). I love they way they do
| scenes (and our system draws inspiration from it). We also
| plan on borrowing their "dogfooding" approach to editor
| building (the Bevy Editor will be a normal Bevy App).
| Waterluvian wrote:
| I know of a few ROS (Robot Operating System) community members
| that use Bevy to simulate hundreds to thousands of mobile
| robots in various commercial and industrial contexts, finding
| it operates drastically better than Gazebo Sim
|
| Does your team exclusively focus on game dev? How aware are you
| of non-gaming applications where Bevy works great?
| alice-i-cecile wrote:
| Another maintainer: very aware of it, Foresight Mining
| Software Company is a major force in the ecosystem and makes
| CAD tools! We try to be responsive to the needs of those
| communities (robotics, CAD, GIS, scientific simulation...),
| but focus on tackling the needs of game development first.
|
| Definitely naturally synergy here though, and the flexible
| model makes it very easy for different groups of users to
| pick and choose what they care about.
| mwcampbell wrote:
| How far along is the Bevy UI toolkit? From what I've heard, it
| seems fairly common to use an external GUI toolkit like egui in
| Bevy projects. Is anyone using Bevy UI in production yet?
| alice-i-cecile wrote:
| Totally fine for simple game menus, but heavy on boilerplate.
|
| It needs more widgets, the data flow needs some love, and
| text rendering is so-so. We're steadily improving it though,
| and every release it really does get better.
| DDSDev wrote:
| What are your feelings on the direction of game engines across
| the industry right now?
|
| What is an innovation you hope you see wider adoption of in the
| space?
|
| Thank you for your efforts!
| SeanAnderson wrote:
| Oh! I have so much to ask you but feel so ill prepared! I
| literally have the Bevvy website open-and-pinned in my browser
| at the moment.
|
| I have never written in Rust or built a serious game, but have
| 10+ years programming experience and have worked heavily in
| frameworkless canvas/webgl rendering. I've become very used to
| declarative programming after sinking my teeth into React. As I
| start to learn more about game programming I've realized that
| almost all engines expect an imperative approach.
|
| Recently, started poking at game engines trying to find
| something reasonable. I thought I'd start with PixiJS + react-
| pixi (not a full engine, I know), but found my FPS getting
| absolutely crushed trying to run a simulation game through
| React's reconciler. Code was simple to reason about, though! I
| started to feel like I was forcing a round peg through a square
| hole by doubling-down on React frameworks to interface with
| WebGL. So, I'm abandoning that approach and looking for other
| options that don't push me towards a fully imperative approach.
|
| Bevvy is, by an incredibly large margin, what I am most
| interested in using. If there were even vague notions of having
| a stable API in the next year I'd start building now, but I am
| trying to be respectful of the message on your website, "If you
| are currently trying to pick an engine for your Next Big
| Project(tm), we recommend that you check out Godot Engine. "
|
| Do you have any estimations on when you might reach 1.0? Do you
| have guidance on which areas you feel are most stable and/or
| experimental? If I'm a noob with game development am I likely
| to challenge Bevvy in ways that I'd regret as the interface
| changes or is it too early to tell?
|
| What trade-offs are you making in building Bevvy that would
| cause someone to choose Godot over your long-term vision?
|
| Are there any concerns specific to Bevvy around compiling its
| output to WASM? I assume not, but might as well ask.
| alice-i-cecile wrote:
| So, I'm currently part of a team making a Real Commercial
| Video Game in Bevy. The stability issues aren't bad: it's
| half a day of work fixing compiler errors every 3 months,
| even on a massive project. The Rust compiler (and tests!)
| make it way easier, and ecosystem crates are pretty good
| about updating (and will often merge PRs to do so, even if
| the author isn't super active).
|
| I would expect 1.0 in two to three years, but of course,
| that's not a promise.
|
| Missing features are definitely the larger challenge still:
| animation is crude, there's no editor yet (but
| `bevy_inspector_egui` rocks), UI is very heavy on boilerplate
| and needs widgets. But the ability to rapidly prototype and
| refactor rock-solid, high performance gameplay code simply
| can't be matched. Rust's type system makes writing robust
| code easy and Bevy's ECS nearly eliminates data plumbing
| nuisances.
|
| > What trade-offs are you making in building Bevvy that would
| cause someone to choose Godot over your long-term vision?
|
| Even in the long-term, I would choose Godot if you're looking
| for a more traditional, editor-driven approach. Bevy is
| likely to prioritize code over nodes for gameplay purposes,
| and you really want anyone implementing game designs to have
| some Rust (it's not that bad when working in an established
| framework!).
|
| > Are there any concerns specific to Bevvy around compiling
| its output to WASM? I assume not, but might as well ask.
|
| Bevy generally works quite well on WASM [0], but there's some
| frustrations. Audio has weirdness at startup, there are
| random compiler issues, some graphics APIs are unavailable,
| and of course, parallelism is still very limited. Steadily
| improving, but most of that work is being done upstream from
| us.
|
| [0]: https://itch.io/jam/bevy-jam-2
| SeanAnderson wrote:
| Awesome! Thank you for the thoughtful response. It's really
| encouraging to hear that a RCVG(tm) is building using Bevy
| and happy with it! I'll start playing this weekend based on
| that feedback.
|
| I am not super interested in an editor-driven approach at
| the moment, but perhaps I'll regret that as the project
| grows in complexity.
|
| Thanks for the specific remarks on WASM, Animation FX, etc.
| I'll be happy with those problems if I can get my project
| to the point of experiencing them.
|
| Good luck on your project! Let me know when it's out and
| I'll give it a spin :)
| User23 wrote:
| What does data oriented mean in this context? My gamedev
| experience is limited to writing MUDs and roguelikes over two
| decades ago so I have basically no context.
| _cart wrote:
| It is a pretty broad term, but it generally implies some
| combination of cache-friendly design and composable
| (sometimes component-driven) behaviors. ECS intersects with
| it, but "data oriented" is a much broader category.
| cowtools wrote:
| _cart wrote:
| Ooh this one is an easy question. No it doesn't.
| prideout wrote:
| The ECS looks really nice. Can it be used independently of the
| rest of Bevy?
| _cart wrote:
| Yup! Bevy ECS is a fully standalone Rust ECS library.
| prideout wrote:
| How are entity id's managed? When an entity "dies", can its
| id be re-used?
|
| From a Rust-on-WASM perspective, it might be useful to
| limit the entity id's to ~52 bits or less, since native
| JavaScript numbers are doubles.
| djmcnab wrote:
| > From a Rust-on-WASM perspective, it might be useful to
| limit the entity id's to ~52 bits or less, since native
| JavaScript numbers are doubles.
|
| Since compiling to web uses WebAssembly, we can just use
| native 64 bit integers for our entities. In general, we
| avoid introducing differences between web and native
| targets, and this is no exception.
|
| If you do need to round-trip full entities using
| JavaScript, you should either store them in one of the
| native non-broken integer types (such as `BigInt` or
| `BigUint64Array`), or just store the `index` and
| `generation` as seperate `number`s. It's worth
| recognising that in most cases, you should only need to
| exchange the entity `id` with different systems, as the
| `generation` is mainly used to panic on use-after-free
| conditions.
| ickk wrote:
| Entity is essentially a u64, which is composed of a 32
| bit index and a 32 bit generation. Despawned entities
| free their index, and which ever new Entity takes its
| place gets a new generation.
| pvg wrote:
| Discussed recently 4, 7 and 10 months ago
|
| https://news.ycombinator.com/item?id=32287828 18 comments
|
| https://news.ycombinator.com/item?id=31043668 63 comments
|
| https://news.ycombinator.com/item?id=29854416 89 comments
| Narishma wrote:
| Those are different releases.
| password4321 wrote:
| Per dang@https://news.ycombinator.com/item?id=23071428 [2020]
| pvg wrote:
| Yes but for the most part, releases (within a year or so) are
| HN dupes short of big doses of snee. Otherwise the front page
| would look like the freshmeat.net of yore.
| [deleted]
___________________________________________________________________
(page generated 2022-11-12 23:00 UTC)