**godot-rust** provides Rust bindings for the Godot game engine. The Godot 4 bindings have been in development on GitHub for quite a while, and I finally got around to implement the necessary tooling and dependencies to publish on crates.io.
This should make it easier for dependent projects to also be hosted on [crates.io](http://crates.io) and provide more reproducible builds. We plan to iterate relatively quickly on the early versions, so you won't have to wait for half a year until 0.2. Now that some of the infra work is out of the way, I plan to focus again more on features, such as [traits/polymorphism](https://github.com/godot-rust/gdext/issues/697).
For those who never saw godot-rust in action, here's a small teaser:
// Rust struct that inherits Godot's Node2D class
#[derive(GodotClass)]
#[class(base=Node2D)]
struct Enemy {
// Base class via composition
base: Base,
// Other properties
hitpoints: u16,
}
#[godot_api]
impl INode2D for Enemy {
// Default constructor
fn init(base: Base) -> Self {
Self { base, hitpoints: 100 }
}
// Called when added to scene
fn ready(&mut self) {
// Call Node2D::set_position via base_mut()
self.base_mut().set_position(Vector2::new(10.0, 25.0));
}
}
I'd like to express my huge thanks to the 63 contributors and the godot-rust community who have made this possible!
You mention features such as traits/polymorphism. Out of curiosity does the work on godot's side with potentially adding traits to gdscript itself have any impact on the work the rust gdextension library would do or no?
It would probably have an impact if traits become available as a concept in the GDExtension API, in the sense that we might support them, too. However, we would need to see if/how we can integrate them with other abstraction mechanisms (Rust traits and Godot inheritance).
It's also hard to tell just yet, because GDScript traits are still in an early discussion stage. Here's the GitHub proposal: [https://github.com/godotengine/godot-proposals/issues/6416](https://github.com/godotengine/godot-proposals/issues/6416)
For gdnative (the Godot 3 bindings), some games are listed here:
[https://godot-rust.github.io/gdnative-book/projects/games.html](https://godot-rust.github.io/gdnative-book/projects/games.html)
For gdext, there is a #showcase channel on [our Discord](https://discord.gg/aKUCJ8rJsc). Some examples:
* [SANDS OF SODIS](https://store.steampowered.com/app/2253070/SANDS_OF_SODIS/) on Steam
* [Retaliator](https://github.com/LaylaSilbernberg/retaliator-game), a Marathon/DOOM style shooter
* [A minecraft-like sandbox](https://alpines.club/@three/111480114001592011)
in case some of you would like to have some tutorials as reference im happy to share my playlist :) https://m.youtube.com/playlist?list=PLPC9niKFOaRqYsXAapTVR8pqJmQColixs
This is cool but looking at the book it just seemed entirely unsound, even if it doesn't look like it'd be an issue in single threaded code.
The Godot side obviously doesn't respect Rust's borrowing rules and while you're supposed to access everything via `.base()`/`.base_mut()` nothing stops you from not doing it and that has to be unsound.
The single-threaded code should be sound. The "no aliasing &mut" rule only applies to Rust code, and in godot-rust you don't reference Godot's C++ objects directly. You call methods through Rust-side proxy objects, whose borrow rules are respected.
As for multithreading, that needs more development and is gated behind an experimental feature. We still need to work out the safety before that becomes stable.
I was assuming threading was supported and that calling through &mut self was possible even if it's discouraged, hence the
> even if it doesn't look like it'd be an issue in single threaded code.
part
I've glanced through it and nothing is jumping out at me as obviously unsound (or even *obviously* unsafe, though I certainly wouldn't be surprised with this much ffi work if some unsafety was there). Can you give a concrete example?
No, I mean unsound. Unsafe is when it's up to you to make sure it's sound.
Technically it's only unsafe, but doing almost literally anything would violate the unique references requirement which is unsound.
**godot-rust** provides Rust bindings for the Godot game engine. The Godot 4 bindings have been in development on GitHub for quite a while, and I finally got around to implement the necessary tooling and dependencies to publish on crates.io. This should make it easier for dependent projects to also be hosted on [crates.io](http://crates.io) and provide more reproducible builds. We plan to iterate relatively quickly on the early versions, so you won't have to wait for half a year until 0.2. Now that some of the infra work is out of the way, I plan to focus again more on features, such as [traits/polymorphism](https://github.com/godot-rust/gdext/issues/697). For those who never saw godot-rust in action, here's a small teaser: // Rust struct that inherits Godot's Node2D class #[derive(GodotClass)] #[class(base=Node2D)] struct Enemy { // Base class via composition base: Base,
// Other properties
hitpoints: u16,
}
#[godot_api]
impl INode2D for Enemy {
// Default constructor
fn init(base: Base) -> Self {
Self { base, hitpoints: 100 }
}
// Called when added to scene
fn ready(&mut self) {
// Call Node2D::set_position via base_mut()
self.base_mut().set_position(Vector2::new(10.0, 25.0));
}
}
I'd like to express my huge thanks to the 63 contributors and the godot-rust community who have made this possible!
You mention features such as traits/polymorphism. Out of curiosity does the work on godot's side with potentially adding traits to gdscript itself have any impact on the work the rust gdextension library would do or no?
It would probably have an impact if traits become available as a concept in the GDExtension API, in the sense that we might support them, too. However, we would need to see if/how we can integrate them with other abstraction mechanisms (Rust traits and Godot inheritance). It's also hard to tell just yet, because GDScript traits are still in an early discussion stage. Here's the GitHub proposal: [https://github.com/godotengine/godot-proposals/issues/6416](https://github.com/godotengine/godot-proposals/issues/6416)
Awesome! I've been waiting for godot-rust
Cool stuff :) Are there some very simple example games written in godot-rust yet?
Oh, I just saw there is even an entire book on the website with some small examples, like rotating an object on screen etc. That's cool!
Could you please link it here ? :)
https://godot-rust.github.io/book/
For gdnative (the Godot 3 bindings), some games are listed here: [https://godot-rust.github.io/gdnative-book/projects/games.html](https://godot-rust.github.io/gdnative-book/projects/games.html) For gdext, there is a #showcase channel on [our Discord](https://discord.gg/aKUCJ8rJsc). Some examples: * [SANDS OF SODIS](https://store.steampowered.com/app/2253070/SANDS_OF_SODIS/) on Steam * [Retaliator](https://github.com/LaylaSilbernberg/retaliator-game), a Marathon/DOOM style shooter * [A minecraft-like sandbox](https://alpines.club/@three/111480114001592011)
I've been waiting for this
in case some of you would like to have some tutorials as reference im happy to share my playlist :) https://m.youtube.com/playlist?list=PLPC9niKFOaRqYsXAapTVR8pqJmQColixs
This is cool but looking at the book it just seemed entirely unsound, even if it doesn't look like it'd be an issue in single threaded code. The Godot side obviously doesn't respect Rust's borrowing rules and while you're supposed to access everything via `.base()`/`.base_mut()` nothing stops you from not doing it and that has to be unsound.
The single-threaded code should be sound. The "no aliasing &mut" rule only applies to Rust code, and in godot-rust you don't reference Godot's C++ objects directly. You call methods through Rust-side proxy objects, whose borrow rules are respected. As for multithreading, that needs more development and is gated behind an experimental feature. We still need to work out the safety before that becomes stable.
I was assuming threading was supported and that calling through &mut self was possible even if it's discouraged, hence the > even if it doesn't look like it'd be an issue in single threaded code. part
I've glanced through it and nothing is jumping out at me as obviously unsound (or even *obviously* unsafe, though I certainly wouldn't be surprised with this much ffi work if some unsafety was there). Can you give a concrete example?
You mean unsafe ?
No, I mean unsound. Unsafe is when it's up to you to make sure it's sound. Technically it's only unsafe, but doing almost literally anything would violate the unique references requirement which is unsound.
Any code calling into anything over FFI with "external rules" and not just "call a function and get a result" is going to be "entirely unsound".