Typed RPC (generated from `#[rpc]` methods)

[ValorZard]

Right now, to use a RPC, you have to do something like this

// Using unreliable to make sure position is updated as fast
            // as possible, even if one of the calls is dropped.
            let args = varray![self.base().get_position(), self._motion];
            let varargs = variant_array_to_vec(args);
            self.base_mut()
                .rpc("set_pos_and_motion", varargs.as_slice());

Here’s a function I used to make this easier

fn variant_array_to_vec(array: VariantArray) -> Vec<Variant> {
    let mut vec = Vec::new();
    for i in 0..array.len() {
        vec.push(
            array
                .get(i)
                .expect("Failed to get element from VariantArray"),
        );
    }
    vec
}

This is weird, because RPCs are already typed on the receiving end

#[godot_api]
impl Paddle {
    /*
    # Synchronize position and speed to the other peers.
    @rpc("unreliable")
    func set_pos_and_motion(pos: Vector2, motion: float) -> void:
        position = pos
        _motion = motion
     */
    #[rpc(unreliable)]
    fn set_pos_and_motion(&mut self, pos: Vector2, motion: f32) {
        self.base_mut().set_position(pos);
        self._motion = motion;
    }
}

Ideally we should do something like we do with signals

Probably something like

object.rpc().my_function();

For rpc_id, you could do

object.rpc_id(1).my_function();

[ValorZard]

For more context, see: https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html

[Bromeon]

The self.rpc().method() and self.rpc_id(1).method() are good suggestions from an API point of view 👍
Note that while they look simple, they still need a ton of machinery:

• One or two structs that are returned by rpc() and rpc_id(1), and keep a reference to the object.
• A list of methods annotated taken from the #[rpc] ones.
• Propagation of visibility (and the limitations/hacks).
• If RPCs should be accessible from Gd, we need a WithRpcs trait.
• ...

The typed signals API is quite nice to use; however, it was an odyssey to develop, still has some rough edges and comes with a price (heavy traits, type-state, Deref trick, visibility limitations, hard-to-reuse generically, compile times...). Signals are so central to the Godot engine that I believe it's worth it, but I'm not sure if I want to repeat the same complexity elsewhere, especially as long as we haven't yet taken the learnings.

Maybe #[rpc] can be more lightweight... but still needs a bit of configurability. Yet certain things are likely simpler:

• Inheritance (Deref) I would simply not support. Would only be a topic for Rust-Rust inheritance, anyway.
• We'd only need it for proc-macros in user-defined classes, not codegen in engine classes.
• Since all calls are remote and go through Godot, we may be more lenient on &mut borrow-checking, maybe Gd<Object> is enough.
• There is probably no need to pass through C (the class type), because you won't connect signals to methods of the same class. They just exist.

For #[func(virtual)], we do something similar, but the function itself becomes polymorphic. So obj.method() will dynamically dispatch to either Rust code or script code. Maybe we should follow this approach, or explicitly forbid direct calls to the function, to prevent accidental local usage.

---

Either way, please don't wait for me to implement this 🙂 But if someone feels like experimenting, I'm happy to give guidance. A requirement would however be that the implementation is based on existing patterns in the godot-macros crate; maybe we can also reuse some code. And like signals it would need to be incremental -- the latter were implemented over the course of ~10 PRs. Which also means that even something very simple in a first iteration would be nice.

But in general, we should see if there's even demand for this feature. Just because something is possible doesn't mean we should add it. Especially if we improve the easy-of-use around variant slices (which I plan for v0.3.x).

[ValorZard]

Having better ergonomics for variant slices would probably solve most of these issues, yeah

[Bromeon]

Type safety is still nice, but it would be interesting to see how often people use Godot's @rpc on a bigger scale 🤔 or if most games have their own serialization layer, or some forward-compatible industry protocol like cap'n'proto, flatbuffers, protobuf, etc.

[ValorZard]

Some googling reveals that @rpc is quite popular with third party addons at least
https://github.com/heroiclabs/nakama-godot
https://codeberg.org/Liblast/liblast-framework
https://github.com/foxssake/netfox