Bevy: A game engine built in Rust
github.com
github.com
If I was making a game today, I’d probably pick Unity. A year from now? I’d take a good look at where Bevy is then. Good luck to cart and the other contributors.
The API looks very clean and the development speed is outstanding for an open-source product.
After reading that Rust now plays in the C/C++ league I'm really excited about Bevy.
I was talking about performance.
Many game studios won't bother using it if it doesn't come on the console vendors devkit, just like it happened with C, C++, or middleware like Unreal and Unity.
But it also doesn't have to put up with 30 years of legacy cruft.
Godot is in a much better spot at being the next Unity and it took a long time. It's still not there because of assets availability: you can find assets for anything for cheap on Unity.
For an indie developer with little budget and time to build complex features, it's a life saver.
For a mid-size studio (Embark?), happy to build their own technology, Bevy could be a great starting point, but the feature set is still not there.
As a solo developer trying to build a game, I tried going Bevy / Godot / tons of others and ended up back to Unity: I don't like it and it's a complete disorganised and buggy mess but it gets stuff done incredibly quick.
I didn't pick Unreal Engine because of the 5% cut over 3k. It's a marginally nicer environment to work in but I don't think it's worth the price tag over Unity (free under 100k revenue).
Is out of date by almost a year now, Unreal is now royalty free until 1 million dollars of revenue, at which point they take a 5% cut
They even backdated the change to start of the year so that developers who were charged under the 3k arrangement got refunds
The documentation is very good(!) and the approach is very interesting imo, iteration times disappear but you can keep all your performance (by moving the logic into rust as you settle on a design).
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=116971...
So it’s not really an option if you’re targeting ios.
Here, Rust is, AFAIK, far behind other languages. C lacks expressiveness, but C++ and C# seem popular for the purpose, and their build time is good. Incremental compilation is sometimes available, potentially avoiding a slow, non-parallelizable link step.
Rust is promoted for security, but I have not heard of that as a criterion for game work, and it seems like the first criterion to be jettisoned vs. any other.
What makes Rust's slow build times tolerable for this use? Has it had more progress in incremental building than I know about?
So I am with you that Rust has a very uphill battle for adoption in any game console devkit.
Check out our most recent efforts in our last blog post, where we added easy dynamic linking for a massive compile speed boost: https://bevyengine.org/news/bevy-0-4/
I also discuss the perception that "Rust is slow to compile " in the original Bevy announcement post: https://bevyengine.org/news/introducing-bevy/
In short: fast compile times in Rust are possible. As long as your core libraries do the "right things" when it comes to design, writing user code can be extremely productive. The compiler has also gotten a lot faster over the last couple of years.
To make a game (even a tiny one) you need artists, sound designer, designers and so on and that's what makes it significantly harder
Here’s a sample game made with it https://github.com/mrDIMAS/StationIapetus
I consider building on Unreal to be an (acceptable) risk, but I'd prefer to build on something not owned by another company.
I'm really hoping some of these Rust projects start to focus on rendering, not just the game pieces.
If you only need multi-platform rendering (including Emscripten, and a shader abstraction), have you looked into BGFX, or even Sokol GFX? They provide the bits you need to render. Unity is even using BGFX in its "Tiny" version. Sokol GFX is new but very easy to use.
I believe both have Rust bindings if this is important to you.
Most distributions have an LTS that is supported for 5 to 10 years. You won't get the newest, hottest compiler on those platforms.
> So what?
Rust is a great language, but y'all need to calm down with the hype. "Not Rust" != evil.
> Most distributions have an LTS that is supported for 5 to 10 years. You won't get the newest, hottest compiler on those platforms.
Yes, you do, because you won't be using the distribution-supplied compiler because like the entire rest of the rust developer community you are using rustup.
This issue certainly occurred with a lot of C/C++ projects over the past 30 years, why would Rust be exempt of that issue in the future?
there are plenty of companies when you don't have the right to import any new executable code (coming from "outside") in office computers.
Application was built using Java/SpringBoot, and the CI/CD was based on Jenkins.
We had no control over the version of maven/jdk installed within the Jenkins, and the network policies did not authorize outgoing traffic (so no curling rustup). Only one company repository (based on Nexus) was available.
Basically, we were users of a company provided/constrained platform to build our applications using a curated list of tools that has been audited by another team.
If we wanted to add a dependency not present in the provided repository, it would require time for the audit and integration. Time we did not necessarily had.
Now, with Rust/rustup/Cargo, the company would have provided a specific set of Rust versions and a private crate repository. I doubt that the auditing team would have time to add a new Rust version every week.
If a crate present on the private repository is updated upstream and requires a more recent Rust version, the crate update will be delayed until the Rust version is audited/validated/integrated.
IMHO, this is a very common use case, since companies like to split concerns in different specialized teams.
One of the core issues here, imo, is that it is unclear which Rust is the oldest one to be supported. That requires a clarity in understanding the pros and cons of each one, and simply due to there being more releases of rustc, it’s a little less clear which version gets you the most bang for your buck here.
I agree that some of this is a function of the new-ness of the language. I think once (if) we start an LTS program, that will help, and is partially why I desire such a thing. https://rust-lang.github.io/rfcs/2495-min-rust-version.html is an example of a feature we’re adding to help people do this kind of thing. It’s small but it’s a start.
Unfortunately HN attracts the very vocal minority...
(Note also it is the compiler, not a runtime. Big difference when it comes to things like deployments, IMHO.)
In a precise sense, any non-assembly language, including C, has a runtime. In practice, this makes the term "runtime" not super useful to many folks, so they mean "virtual machine" or "large, featureful runtime that's required to support critical language features" when they say "runtime."
Rust is the same as C in this regard. It technically has a runtime, but not in the way that many people mean.
In that context, I don’t see the issue with Rust codebases depending on the latest compiler. I understand that it’s done differently with C/C++ and that’s fine. I don’t see why both models can’t work.
The normal philosophy on typical Linux systems is in fact _not_ to require bleeding-edge compiler versions; there’s no “gccup” program. It’s the rust project that is proposing a new and different model.
For example, NEVER install a Python package globally with pip on a Debian System, it WILL conflict with Debian packages (and you'll be very unhappy and confused on the next apt remove or pip uninstall).
It seems that rustup itself is not currently packaged by debian or other linux distros which seems to be a bigger issue. If you could `apt install rustup && rustup install stable` then that seems preferably in pretty much every way to `apt install rust` and getting an old version.
Anyone not doing it this way is just making life needlessly hard for himself and his problems should be ignored entirely.
No. The big deal of Rust 1.0 is that a 6 months old Bevy can compile on the latest version of the compiler. Since new features regularly get added, codebases which use the new features will naturally not work with compiler version predating those features.
It is a concern (as seen with the recent cryptography hubhub), but it's a project-specific concern: projects have to decide on their compiler compatibility range.
Though you could say that it's an ecosystem problem, outside of specific projects I don't think there any sort of badge or way to assert compatibility with specific compiler versions. Since distros are starting to ship rustc (and are unlikely to track the standard mainline), I expect awareness of this issue will grow over time.
I think it's something to do with outdated dependencies of winit running into namespacing issues with macros that were added to the standard library
There was a post stating Amethyst was basically in need of a re-architecture that could never be resourced and because Bevy was already based on that “new” architecture it was easier to switch all development effort over.
But maybe this thread is out of date.
https://community.amethyst.rs/t/bevy-engine-addressing-the-e...
From outside at this point, the rewrite looks like a mistake , given the lost momentum and the current state of the project, but maybe when they finally get it out it'll turn out differently in 6 months.
It seemed like an inevitability that some other library would come along that would move forward a bit quicker.
Once it gets to a 1.0, that adoption of new features may slow down.
https://gist.github.com/cart/96b1d39cd04274da566dbf28bf87c2a...
This enables us to (statically) extract information from the type signature of the function and use it to populate the relevant values using the ECS. We also use this type information to automatically (and safely) parallelize system execution based on what ECS resources are accessed (and if they are mutated).
We do (internally) use macros to implement our IntoSystem trait for all relevant function types, but there are no macros in user-facing code.
But I would never use such a feature, it increases the code mental load (what you should know before being able to read the code).
From one codebase to another, I can't even keep the same assumptions.
I swear, people behind Rust would replace every single textual keyword with a symbol if they could.