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?
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.
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
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.
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.
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.
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.
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.
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.
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/
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
Your reply was insightful until i read the last part:
> 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
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
In general in Rust game engine culture right now there is a strong trend towards using entity component system based design. Sometimes this is a definite good thing, for certain kinds of games it can have benefits both for performance and coding niceness. Entity component systems also play nicely with Rust's borrow checker.
But, in my half educated opinion, it creates a massive amount of unnecessary complexity for many types of games. If you are making something pretty basic like pong/pac man/ simple 2d rpgs, etc, you just have all this infrastructure and all these new paradigms when all you wanted was a way to efficiently load and draw sprites and play sounds.
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.
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.
You'll find a very good introduction to ECS in Rust in the book "Hands-on Rust: Effective learning through 2D Game Development"¹. 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).
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.
66 comments
[ 3.2 ms ] story [ 143 ms ] threadBevy’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?
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
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?
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.
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.
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.
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
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
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.
[1]https://pragprog.com/titles/hwrust/hands-on-rust/
[0]: https://bevyengine.org/news/bevy-0-6/#the-train-release-sche...
"written in Rust" won't make the game by itself
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.
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.
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
Unity in particular was a meme for the last generation due to CPU-based stuttering.
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
> 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
Rust people gotta be Rust people, that's sad
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.
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
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.
So, doing something like:
Does exactly what you'd expect.You can set the console variable `tickrate' and, that too, does exactly what you'd expect.
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.
It's nice that you've found your niche, but Bevy attempting to follow would be a big mistake.
The abstractions you use work OK in a world where everything looks like Quake, but they're simply not universal.
An engine like yours should be built on top of Bevy, it shouldn't be part of Bevy.
And that feeling that it needs to be abstracted/genericized might be the same reason why it never gets done.
> 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
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...
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.
Once it's not prohibitively expensive to run raytracing in VR, we're going to see some cool stuff.
https://github.com/peterholko/bevy_tokio_tungstenite/blob/ma...
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?
But, in my half educated opinion, it creates a massive amount of unnecessary complexity for many types of games. If you are making something pretty basic like pong/pac man/ simple 2d rpgs, etc, you just have all this infrastructure and all these new paradigms when all you wanted was a way to efficiently load and draw sprites and play sounds.
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.
These are absolutely reasonable concerns, and a centralized, first-part introduction to the core concepts is essential.
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).
¹=https://pragprog.com/titles/hwrust/hands-on-rust
[1] https://community.amethyst.rs/t/bevy-engine-addressing-the-e...