Something delightful about this update: it has a lot of new features, some very early, but all by different authors. Seems like such a community effort compared to most early-stage projects, which usually are driven by one author in relative secret until they are closer to some dream "1.0".
Links on that page don’t quite work like you’d expect — your link goes to the post Carter is responding to (which is worth reading too). This one goes straight to his post.
Last this project was posted I joined the Discord and it seems to be a friendly space and a LOT of people joined and shared ideas. I think given a year or two this project (rightfully so!) will ressemble Godot (its an inspiration for Bevy). I am curious if they will adopt a scripting language similar to how Godot has GDScript. I think Godot was in the right in implementing their own language that fits their engine best.
Cart explicitly rules out using scripting language and said writing games in the same language as the engine was one of the motivation for him to start a new engine.
> Turtles All The Way Down: Ideally the engine is written in the same language that games are. Being able to run an IDE "go to definition" command on a symbol in your game and hop directly into the engine source is an extremely powerful concept. You also don't need to worry about heavy language translation layers or lossy abstractions. If an engine's community builds games in the same language as the engine, they are more likely (and able) to contribute back to the engine.
I could see a Rust-like scripting language being adopted at some point, all it takes is someone building a proof of concept and before you know it, it winds up in the codebase because it's so polished. Which is another thing I love about Bevy, people are allowed to write their own projects and if they're good the Bevy team will take them into consideration (or that's the vibe I got being on the Discord) which is what makes Open Source so great. It's too early for them and them maintaining Rust is certainly a total strength at the very least.
I'm thankful this is his attitude. I think part of the appeal of Bevy is that it is built in Rust, and you are meant to use Rust in building your project. I think it pushes the design to make working in Rust as optimal as possible.
Big props to cart (and of course everyone contributing!) for putting a huge focus on community development after release. It can be challenging to set aside the fun work but it looks like it has paid off so far. The async task system and WASM work are particularly exciting community contributions -- Bevy is much closer to being a viable web-game engine now thanks to those.
We don't really have a good end-to-end demo at this point. We're still building out some of the "core" pieces of state management (namely the Scene system, which works in the current form but isn't fully featured yet). In general transitions between menus/levels will happen via Scene transitions (similar to how godot handles it).
You can also adopt a `enum State { Menu, InGame }` Resource pattern, then have your systems key off of that state where necessary.
No question, but thanks for fixing the CPU usage issues. Only seeing 0.4% CPU usage on the breakout example in release mode now. (credit to the rayon developers as well)
Github issues/roadmaps are the source of truth for the project. I totally get that its not as easily digestible as a well formatted document, but anything that isn't directly tied to the backlog is immediately out of date the second we add/remove/update something.
Adding a separate document and committing to keeping it up to date is more work than I'm willing to do right now. I've made myself a project management bottleneck in the short term, which means I need to optimize as much as I can.
We are considering async systems, but in general I do think that allowing them to suspend execution across frames would be undesirable (at least as a default).
Well, I know I just want to be able to poll futures from a system.
There's a rust FRP library called futures-signals that would be really useful for taking input from a controller and transforming it into high level, meaningful streams. I'd like to react to those streams. I don't think they'd take multiple frames to poll, but even if they did I wouldn't mind too much.
(I'm new to both rust and ECS so if you have a suggestion for how to approach this problem differently, I'd love to hear it)
They seem to share the same goals and philosophy, and it looks like the authors have complementary skills: mrDimas' technical achievements are super impressive (rg3d already has a scene editor, its own UI kit and a working example game!!), while _cart's ability to create hype and foster a large community in no time is just stunning. I'd love to see those two join efforts somehow.
It's harder to get users without, and sponsorship/funding is probably out reach.
There are a lot of technically good projects which fail because of lack of marketing, and a lot of well-marketed project that are too shallow to succeed. Having both is an incredible asset.
That's why I would be extremely excited if they teamed up.
* what platforms can the engine target (pc, mac, linux, consoles, web, mobile, etc
* does it use a typical oop approach with all your stuff deriving from entity? or an ecs? the latter can perform better but is more complex to work with usually
* how easy is it to use? does it have a graphic editor and asset manager? an easy scripting language? decent lighting system built in?
* how well does it perform
* how customizeable is it
* can you edit things while the game is running for quick iteration?
I wonder if we'll see a new entrant (commercial or not) with enough features to challenge the C++ game engine landscape. It'd be difficult to reach parity with Unreal, but perhaps something can get close to Godot.
Do you think gaming companies will start to invest in the Rust ecosystem?
Look great. I really want an alternative to unity to do ECS 2d mobile games. It's not super complicated tech (although takes time to implement for sure in a game engine), but at the moment there's not really any alternatives, so any under development is awesome!
The article mentions one example that needs to use ASCII "rendering" because Bevy lacks 2D/3D rendering support.
I'd imagine that not many projects have been built on top of Bevy yet, due to the WIP nature of the rendering. Nevertheless this looks like a really great project, as a fellow hobby game dev this is pretty exciting and might be a great way to get to know Rust from an outside perspective.
Edit: Whoops, it looks like that might be just for the WASM support. My bad.
I am really happy to see a reimplementation of Robbo as one of the examples! What a nice throwback. I used to love that game as a child on my Atari 800 XE. I should be asleep, but instead I am collecting screws. :)
