gdnative VS bevy

> Same for Godot.

While likely true that it's "Unlikely to ever be as supported" as the 4 officially supported languages[0] ("GDScript, C#, and, via its GDExtension technology, C and C++."), Godot's GDExtension technology is specifically intended for use in adding support for other languages.

The most relevant tracking issue for Rust is presumably:

* <https://github.com/godot-rust/gdnative/issues/824>

Which links to:

* <https://github.com/godot-rust/gdextension>

[0] https://docs.godotengine.org/en/4.0/getting_started/step_by_...

...Godot v3.x has Rust support via godot-rust and Godot v4.0 is released as of this month?

I was curious, and looked it up. Nothing built in, but there's an interesting project that works with godot: https://godot-rust.github.io/

Curious why you think Rust would not work with a node-system like in Godot since there are already Rust-bindings for Godot. And while I can think of several reasons for not using Rust (I don't use it myself) I never thought the lack of inheritance would be an issue at all.

Also if you want to use this as an opportunity to learn Rust, take a look at godot-rust.

GDExtension is a platform, much like GDNative. It provides tools, but additional language bindings will still come from the community. For Godot Rust you can track the progress here: https://github.com/godot-rust/godot-rust/issues/824

For what its worth, you can write your scripting for godot in Rust with godot-rust. It's not perfect cause its fitting Rust into the Godot model, but it'll also give you a "best of both worlds" type of situation if you want to get up and running quick but also do the game logic in Rust.

There's godot-rust for writing Rust components for the Godot engine.

If you desire to use Godot, as having the editor and support, while wanting to use Rust for the logic, might wanna look into Godot Rust.

Current version of godot-rust uses type-state to declare Ref references "safe to use" once the user has asserted their safety, and to switch between shared/unique/thread-local ownership.

Game engines (Bevy, Fyrox)

After the quick start there isn't as much documentation yet as one might hope, but I find you can learn to do just about anything you need by reading the extensive examples. There are tons of them in GitHub of which a subset have been turned into interactive WebGL apps on the main site.

well, wasm threads are weird for some reason. Issues like https://github.com/bevyengine/bevy/issues/4078 remind me that wasm is still a moving target.

There are some examples here: https://github.com/bevyengine/bevy/tree/main/examples/animation

Rust is much newer a language than Java. Give it time. There is clearly industry interest: check out the sponsors list on bevyengine.org.

Binaries file-sizes in debug are just insanely big, a Hello World will be around ~4MB, an empty Bevy project will be around ~600MB.

$ git clone https://github.com/bevyengine/bevy.git ; cd bevy $ cargo install --locked cargo-public-api $ cargo public-api -ss -p bevy_utils diff v0.9.1..v0.10.0 Removed items from the public API ================================= (none) Changed items in the public API =============================== (none) Added items to the public API ============================= +pub use bevy_utils::<> +pub use bevy_utils::petgraph +pub use bevy_utils::thiserror +pub fn bevy_utils::synccell::SyncCell::read(&self) -> &T where T: core::marker::Sync +pub mod bevy_utils::syncunsafecell +pub use bevy_utils::syncunsafecell::UnsafeCell +#[repr(transparent)] pub struct bevy_utils::syncunsafecell::SyncUnsafeCell +impl bevy_utils::syncunsafecell::SyncUnsafeCell +pub fn bevy_utils::syncunsafecell::SyncUnsafeCell::from_mut(t: &mut T) -> &bevy_utils::syncunsafecell::SyncUnsafeCell +pub const fn bevy_utils::syncunsafecell::SyncUnsafeCell::get(&self) -> *mut T +pub fn bevy_utils::syncunsafecell::SyncUnsafeCell::get_mut(&mut self) -> &mut T +pub const fn bevy_utils::syncunsafecell::SyncUnsafeCell::raw_get(this: *const Self) -> *mut T ...

Firstly, Bevy has an internal crate called bevy_reflect, and it can handle most of the things you would usually use reflection for. For example, https://github.com/jakobhellermann/bevy-inspector-egui exists which uses Bevy's internal reflect derive to make the values available via an egui-based UI. Changing simple values (like an f32, or a boolean) can be done at runtime, and if I remember correctly all you actually need to do is to add the plugin. Taking a look at the README https://github.com/bevyengine/bevy/tree/main/crates/bevy_reflect you can "patch" types with new values, iterate over struct fields, serialize + deserialize, and generally do stuff like that.

It doesn't work currently. The only problem is that plugin initialization must be asynchronous, so you have to pass control back to the browser to allow it to initialize the WebGPU api properly[1]. I hacked async plugin initialization into a fork for Bevy 0.8[2], but I never got it to 100% work because Chrome had already moved onto a newer WGSL syntax. In theory if you do the same changes for 0.10 as I did for 0.8 it should allow WebGPU to work (and I plan on doing this in the next couple days).

[1]https://github.com/bevyengine/bevy/discussions/3239