Feature parity with Amethyst

[inodentry]

Bevy is already "ahead" of Amethyst in some ways, such as, notably, the ECS ergonomics that made Bevy popular. Bevy is also lacking many useful game engine features.

While I don't want this to be treated as a competition, I want to see Bevy offer useful functionality for users in a wide variety of areas, and I think we should strive to improve on what other game engines offer.

Therefore, I think keeping a list of the areas in which Bevy is currently lacking in comparison to Amethyst would be helpful for Bevy development.

Let's use this discussion to track the features Bevy would need "to catch up" to Amethyst, functionality-wise, and file github issues or discussion posts to track each one specifically.

Here are some that I could find:

• Debug rendering (wireframe, arbitrary lines in 3d space): Wireframe rendering & Debug lines #409.
• Localization support (Amethyst has some primitive integration with Fluent): Localisation Plugin #461. We should offer more than just text/ui localization; see the linked issue. Amethyst
• Easily load app-specific arbitrary serde-deserializable data (like configs, etc.) from asset files, without having to write boilerplate for a custom asset loader: Easy loading of custom structs from RON files (bevy asset serde integration) #1265. Perhaps the ongoing Distill (formerly atelier-assets, from Amethyst) integration (Migrate Bevy Asset System to Distill #708) will help with this?
• Animation (skeletal and otherwise): Animation API #91 Skeletal Animation #95. Amethyst
• Networking: Amethyst has a general abstraction to be backed by protocol backends. They also developed laminar. For Bevy, there are external crates to experimentally integrate laminar, turbulence, simple tcp/udp.
• Setting the application/window icon (displayed by the OS in the taskbar, etc.): Add icon to WindowDesciptor  #1163 Allow users to set the window's icon #1031. Amethyst
• Mapping of input controls to game actions (remapping, keybindings): Kurinji is an unofficial bevy crate with some preliminary work on this.
• Frame rate limiting / throttling refreshes: Frame rate limiting #1343.
• Audio system improvements (volume controls, mixing, many sound sources / with world entities acting as sound emitters): Perhaps the ongoing Kira integration (Kira for audio in bevy #1304) is the way to go here.
• Support for using fonts installed in the operating system / default font: Support using system fonts #1325 Add built-in font(s) #1017 ; we might want to integrate font-kit.
• UI text input support. This will be required as part of the Editor-Ready UI focus area: Editor-Ready UI #254.
• UI nine-patch support. Some preliminary work available in the unofficial bevy_ninepatch crate.
• Physically-Based Rendering. This is one of our focus areas: PBR / Clustered Forward Rendering #179. Existing work: Basic PBR #1160 Basic PBR implementation #261 .
• Camera controls (fly camera, arcball, etc.). Currently available as unofficial crates, there is a (semi-broken) example in the cheatbook. These should probably be kept as external crates.
• In-game / onscreen FPS counter (and other performance diagnostics). A simple FPS counter is available as an example.
• Asset loading progress tracking. Useful for "loading screens" / "progress bars".

... more?

[alice-i-cecile]

• Networking is seriously lacking, although I'm not sure other Rust game engines are any further along.
• A pipeline for deployment to end users on various platforms is also critical for pushing this into production.
• It's currently possible to create particle effects, but it's neither ergonomic or performant.
• States (as of 0.4) are frustrating and confusing to use.
• Tools to control frame rate are confusing and imperfect.
• Saving and loading games is not well explored, and Scene technology is not fully adequate.
• There's no clear, ergonomic way to pause and resume games without risking lost data due to change detection and events.

[inodentry]

particle effects

Does amethyst have a particle system? I can't find anything.

(This discussion is specifically for tracking where we stand in comparison to Amethyst, not a general wishlist.)

A pipeline for deployment to end users on various platforms is also critical for pushing this into production.

Do we have any existing issues or work done towards this? What does Amethyst offer?

Networking

edited into the OP, thanks!

[cart]

There's no clear, ergonomic way to pause and resume games without risking lost data due to change detection and events.

I think pausing should be a "state", which is already possible with StateStage.

[alice-i-cecile]

I think pausing should be a "state", which is already possible with StateStage.

I agree with the former, but not the latter :) I've included my explanation in #1353, rather than derailing in here.

[kragil]

• a canvas

[cart]

I'm not specifically interested in driving a "Amethyst feature parity" list down to zero. Its worth having a discussion about "useful Amethyst features", creating new issues for those features, and prioritizing them accordingly. Thats also worth doing for other engines.

But making Bevy a "drop in replacement" for Amethyst specifically is a non-goal.

[inodentry]

Absolutely agreed. This was exactly the intention of this post. I want to identify areas in which we are lacking, using Amethyst as inspiration in this case. The intention was not to suggest to exactly match/imitate/replace Amethyst. I think we should learn from them and try to do better (and same goes for other game engines).

Thats also worth doing for other engines.

Totally. I am personally not really familiar with any of them, though, so someone more knowledgeable would have to look into that. Though, I think we should delay comparisons with the "big guys" (unreal/unity/etc.) until we are at least at the stage where we are making a Bevy Editor.

---

I also think there is value in us caring about comparisons with Amethyst specifically, because Amethyst is the other "big Rust game engine project", so naturally, people (outsiders) want to compare the two.