Sending objects from server to client

[wowgpi]

Godot Version

4.5

Question

How should I send objects (buildings) from a server to a client in a large open-world game? Should I use rpcs, http or develop my own solution? Rpcs don’t seem great for a server-client game.

[Sweatix]

Could you clarify what you mean by a “server-client” game, and why such a game can’t rely on the usage of RPC-based networking? Do you mean a game whose netcode is server-authoritative?

What is your own current/planned solution?

[wowgpi]

I mean a game with a dedicated server build. I wasn’t sure if rpc was right or even possible for transmitting .pngs, etc. I also thought that it wasn’t performant enough. I didn’t really have any planned solution apart from transmitting unicode across http and then converting into objs.

[gertkeno]

A separate database server for player content could be useful, and using reliable TCP instead of UDP. HTTP is a good format for distributing large files.

[wowgpi]

But isn’t ENet faster than TCP? Or are you saying to transmit objects over TCP?

[gertkeno]

ENet uses UDP, but a TCP connection is preferred for larger files over a long time. UDP each packet is sent without acknowledgement from the peer, this provides a fast (more of a lower-latency) stream of data to and from the server though it doesn’t guarantee if a packet was received, or in what order. You could see how that makes transferring large files difficult if they come out-of-order or missing data. TCP ensures each packet arrives and as the connection is sustained allows larger and larger packets as the client and server agree. ENet does provide modes for reliable transfer through UDP but they are slower than using TCP, best reserved for a rare high priority packet in-game.

HTTP is a format used over TCP connections with a widely proven track record of distributing large files.

[OleNic]

Use HTTP/TCP for assets, use UDP for real-time data transmission especially if you are doing a twitch game. Turn based games can use HTTP/TCP for a lot more use cases in that you don’t need to continuously update your clients and vice versa, as in clients sending data to server

[wowgpi]

Thanks, that’s a really useful summary.

[wowgpi]

Are there any tutorials on UPD Servers? Because all I could find is this

[Sweatix]

There’s RPC-based examples in the documentation as well. While not as low-level as your other example, RPCs provide a high-level interface through which you can integrate networking.

@Godot Docs

…using [UDP or TCP] to synchronize game state manually can be a large amount of work. Sometimes that work can’t be avoided or is worth it, for example when working with a custom server implementation on the backend. But in most cases, it’s worthwhile to consider Godot’s high-level networking API, which sacrifices some of the fine-grained control of low-level networking for greater ease of use.

You can find all the relevant information on this page:

• Godot Docs | High-level multiplayer

[wowgpi]

Doesn’t UPD have some performance gains over ENet. Should I be using UPD for a first-person shooter?

[gertkeno]

ENet uses UDP, it is probably more performant to use ENet than trying to use UDP directly as the ENet library has a proven track record for decades in games.

[Sweatix]

It likely does produce a more performant networking solution if you were to use a low-level interface. The question is whether it’s worth the effort for the small gains it likely provides (as also stated in the excerpt from the documentation).

I’ve been down the path of both networking “workflows” (if you can call it that):

• Manual creation of compressed data, packets, and sockets (in Unity)
• Unreal Engine’s blueprint-based RPC solution
• Godot’s ENet RPC interface

My latest project, while a bit old by now, is a physically driven vehicle arena game that uses Godot’s ENet RPC interface. RPCs are used to send unreliable UDP packets that update the physics state of the vehicles, while reliable UDP packets are used to update infrequent events such as health changes and collisions. It all works as intended without any latency or performance issues.

The other networking projects I’ve done in other engines have functional similarities.

Manually controlling socket connections and packing bytes into neatly optimized packets – while satisfying for your inner perfectionist – is by far the most complicated and labor intensive solution you can choose. It’s also quite prone to bugs without the proper expertise (which I’m not claiming to possess).

Unless you need to minimize processing requirements for your server (e.g. Valorant’s 128 tick servers, see blog), you’re better off sticking to a high-level interface such as RPCs to mitigate complexity and improve reliability - both of which usually go hand-in-hand.

---

However, I’m no professional. I don’t know whether there’s any real latency gains to be had by making your own manual UDP networking solution. From my own experience, the latency is the same.

…and as @gertkeno said twice, ENet is just UDP with an extra layer on top to make it easier to use.

[abitrolly]

I remember EVE Online used something like Stackless Python. Being stackless means there is no dependency on recursive calls - instead of returning, the code and data that needs to continue execution after a function ends, were appended to the end of this function. So you had a plain list of code and data, with spaceships and stuff, that you can literally move for the calculation to the closest server for the player.