Still struggling to really get in the flow of where what data should live, but with time it's getting easier. The realization that you don't need all data to be in components also really helps. For example for my game grid I store it as a Resource and inside I store entities I care about such that I can run a normal path search algo.
Overall very impressive and fun project and the discord community is active and friendly.
That being said, Legion (another rust ECS framework) recently added a similar approach. But they use macros instead of pure Rust, which is slightly more verbose.
That's the entire main file for a simple demo with rectangles, some of which oscillate, and you can touch to remove (multitouch supported).
Bevy ECS relies solely on the type system, which means these additional annotations are not necessary.
I think it is an awesome project and I'm looking forward to trying it out soon!
But for future releases ill keep that in mind.
(Don't burn out!)
Fortunately I've largely sorted out a workflow that works for my mental health, (i think) works for the community, and still leaves me plenty of time to do dev work. It helps that I can make this my full time job thanks to all of my awesome sponsors.
I am currently the only member of the Bevy organization that can merge prs, but a number of people have stepped up to review prs which helps a lot.
Eventually I do want to grant more people merge rights, but I'm holding off for as long as possible because I think having a single filter that ensures a cohesive vision is valuable.
First we do plan on exposing hooks to allow scripting languages to be plugged in to Bevy. We actually already have a pull request out for that.
However my default answer to the scripting question is that it is a non-goal for Bevy, and is in fact maybe even an anti-feature. I want Rust to be the "one language" people use to build Bevy games. I think a cohesive ecosystem is an incredibly important part of an engine's success. If half of Bevy devs use rust and the other half use C#, then compatibility and interop become a huge problem. The Rust language choice does set a high bar, but Bevy doesn't need to be all things to all people. Additionally, the Bevy API is a Rust API. Defining FFI on top means we need a second api surface that is the "lowest common denominator" (aka a C api). This both increases maintenance burden and creates the "rust experience" and the "everyone else" experience.
In the near future 3rd party Bevy scripting plugins will start popping up, but I doubt I will ever officially endorse them.
Adding scripting languages into the mix removes this benefit and cuts down on the number of people capable of contributing back to the engine.
If it were possible, your iteration times could be ridiculously low. Play the game until the bossfight you're iterating on. Dump it out to disk. Edit the code, recompile and run from saved state in a couple of seconds? That sounds amazing.
Unity has pretty good edit and continue for simple stuff, but it quickly falls apart once you start doing non trivial things.
Plus, in Rust, if you mark types as Serialize you can serialize nearly anything you want. And it seems like Bevy makes full use of the powerful Rust type system.
So I’d guess “yes, you can probably easily serialize the game state in most cases”.
If the base engine supplies you with full serialization support for the inbuilt features and a list of rules to follow to maintain it, you're golden.
Just a single anecdote but can be important to keep in mind. As well, some types of scripting languages can have their own productivity problems as projects get large. Lack of types making code hard to follow, bugs harder to track down, refactors riskier etc.
What was the machine's spec to run the benchmark on the ECS? I don't mean to pour rain on the parade, but 1 millisecond to retrieve a component looks really slow. Was it mislabeled as in 1 microsecond? For a game with a 1000 entities, there would mean one whole second to process one component of all the entities.
edit: but i do agree that the title is a bit unclear. ill fix that now
For my use case, Bevy web (and mobile is nice too) support would mean switching from Godot, 100%.
It will be interesting to see if cross platform support will trickle down to amethyst (I think they share the gfx upstream), who is currently migrating to a faster ECS library (legion).
We also have a work-in-progress WebGL2 backend (which will eventually become a desktop OpenGL backend too).
We're using Unity, and optimizing for wasm performance and size is so awful (they don't have a good solution for streaming).
Our parent company uses a js engine, which has meant a far better story on the web, but porting successful games to mobile is awful.
You could quite easily become the natural choice to develop a decent cross platform game in.
Here is a link to a conversation we had about this in the Amethyst community: https://community.amethyst.rs/t/bevy-engine-addressing-the-e...
I really want to learn low level programing, but I learn best when building a project.
Does it have networking support ?
The anti-rust backlash is so interesting to me because the Rust community is by far the friendliest programming community I've been a part of. And theres so much high quality new and interesting work being done. Trivializing that really rubs me the wrong way.
Join the discord channel https://discord.gg/xENF5Uh