gdnative VS macroquad

> 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.

It's based on macroquad and you can play the wasm version here: https://unvirtual.github.io/yinsh-rs/

The reality is that I have used unsafe that is also unsound out of convenience because fixing it is a papercut too many. And this tends to be common! I know enough to spot unsoundness in other projects (sometimes even early). But not enough to be confident in my own abilities to write sound unsafe code. Why? Because it's really flipping hard, that's why!

Given that you are making a game, you might want to consider using a game framework such as https://github.com/not-fl3/macroquad/.Macroquad has full support for WASM, and will allow you to render your game both locally and in the browser via WASM depending on how you compile it.

Compare the basic examples to draw a simple shape like a triangle in wgpu (https://github.com/gfx-rs/wgpu/blob/master/wgpu/examples/hello-triangle/main.rs), and in macroquad (https://github.com/not-fl3/macroquad/blob/master/examples/basic_shapes.rs).

Comparing raylib to bevy is like comparing a scooter to a sports car. They're not particularly comparable in functionality or design. If you want a fairer comparison, see macroquad.

Macroquad. https://github.com/not-fl3/macroquad

Macroquad is also an option.

I personally think that macroquad would be easier to deal with as a beginner. For example look at this arkanoid example (play it online here). It lets you design things as you want and also support WASM.

I think you’re looking for Macroquad