feat(blog): godot choosing network protocol #189
Conversation
Deploying site with
|
| Latest commit: |
14ef0ab
|
| Status: | 🚫 Build failed. |
Your org requires the Graphite merge queue for merging into mainYou must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link. You can enable merging using labels in your Graphite merge queue settings. |
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @NathanFlurry and the rest of your teammates on |
NathanFlurry
force-pushed
the
05-08-feat_blog_godot_choosing_network_protocol
branch
from
57910ed
to
548dbe7
Compare
NathanFlurry
changed the base branch from
05-08-feat_blog_running_and_scaling_dgs_in_godot
to
main
NathanFlurry
force-pushed
the
05-08-feat_blog_godot_choosing_network_protocol
branch
2 times, most recently
from
f76d86e
to
1b5783c
Compare
NathanFlurry
force-pushed
the
05-08-feat_blog_godot_choosing_network_protocol
branch
from
1b5783c
to
14ef0ab
Compare
There was a problem hiding this comment.
This is rendering to an image that is too small to read. I'm curious if there is a better way to display it, or split it into a second image?
|
|
||
| ## Choosing the Right Networking Protocol | ||
|
|
||
| When setting up multiplayer in Godot, you need to choose the appropriate networking protocol by choosing a [MultiplayerPeer](https://docs.godotengine.org/en/stable/classes/class_multiplayerpeer.html#class-multiplayerpeer) implementation based on your game's requirements. Godot provides several options, each with its own characteristics and use cases: |
There was a problem hiding this comment.
Since this goes into several sections, I think it would make more sense to end with a small preface instead of just a colon.
| When setting up multiplayer in Godot, you need to choose the appropriate networking protocol by choosing a [MultiplayerPeer](https://docs.godotengine.org/en/stable/classes/class_multiplayerpeer.html#class-multiplayerpeer) implementation based on your game's requirements. Godot provides several options, each with its own characteristics and use cases: | |
| When setting up multiplayer in Godot, you need to choose the appropriate networking protocol by choosing a [MultiplayerPeer](https://docs.godotengine.org/en/stable/classes/class_multiplayerpeer.html#class-multiplayerpeer) implementation based on your game's requirements. Godot provides several options (ENet, WebSockets, and WebRTC), each with its own characteristics and use cases. Let's take a look at the each of the three different implementations. |
| - Ideal for games that require fast-paced, real-time multiplayer gameplay. | ||
| - Uses the [ENet library](http://enet.bespin.org/), which is designed for reliable, low-latency communication over UDP. | ||
| - Supports both client-server and peer-to-peer (mesh) architectures. | ||
| - Provides multiple channels for prioritizing different types of data. | ||
| - Suitable for desktop and mobile platforms. |
There was a problem hiding this comment.
This might be personal preference, but I think the first few bullet points of each section would do better as a paragraph, followed by a list of the pros and cons.
However, a list could make more sense if we could directly compare each of them in a table sort of form.
| - Efficient bandwidth usage. | ||
| - Supports multiple channels for data prioritization. | ||
| - Cons: | ||
| - Does not work with web. |
There was a problem hiding this comment.
small clarity change
| - Does not work with web. | |
| - Does not work when exporting to web. |
|
|
||
| ### `WebSocketMultiplayerPeer` (WebSocket) | ||
|
|
||
| - Ideal for games that need to support web browsers and doesn't require peer-to-peer. |
There was a problem hiding this comment.
The first few bullet points here talk about where it works, but not really what it works best for. I know in cons it mentions that latency will be higher than UDP, but it could be worth mentioning that it's good for certain games (say turn-based games), or that it might be limiting when playing real-time games because of TCP overhead.
| - Uses the [WebRTC protocol](https://webrtc.org/), which enables direct peer-to-peer connections. | ||
| - Supports NAT traversal in order to allow peer-to-peer connections from behind a firewall. | ||
| - Suitable for web-based games or games that require advanced peer-to-peer functionality. | ||
| - Pros: |
There was a problem hiding this comment.
Might be worth adding latency info here?
|
|
||
| For more information, see the [WebRTCMultiplayerPeer documentation](https://docs.godotengine.org/en/stable/classes/class_webrtcmultiplayerpeer.html). | ||
|
|
||
| ## Conclusion |
There was a problem hiding this comment.
An idea, it might be good to add some examples
- **Competitive first person shooter for Windows**: Using ENet is likely the best option here. ENet checks the boxes for the need of real-time gameplay, and server-authoritative physics to prevent some types of client cheats. If the game was cooperative without worry of cheating, WebRTC could also be a good option.
- **Card game in the browser**: In this case, WebSockets could be a good solution. Since latency isn't the primary focus in the turn-based genre, better browser support for the WebSocket spec will come in quite helpful.
No description provided.