> If you’re looking for a way to have peer-to-peer multiplayer without setting up your own server, have a look at Steam’s Networking API which also has a Godot integration via GodotSteam, or have a look at the Epic’s NAT P2P API. Both provide NAT hole punching support with relay services as a fallback.
Steam used to work this way iirc, but they now always use a relay. This is user friendly, because with normal peer to peer your IP address is given to other players. DDOSing, bringing down Twitch streams, and all sorts of unfun things can result from that. Of course, this does give steam your users' IP addresses.
> Of course, this does give steam your users' IP addresses.
A rendezvous is unavoidable, even for UDP P2P. The hole puncher server would be the rendezvous -- or the STUN (P2P) / TURN (TCP) server if you wanted to make the smarter choice and use an existing protocol. Either way, the rendezvous gets the IP no matter what.
The only way to avoid leaking the IP to some middle party is to use port forwarding and manual communication of the IP.
IIRC, Twilio offers a paid STUN/TURN service. But you could also self-host it using some open source TURN server, since all it requires is a public IP address (with the caveat of course that it might not be geographically close to the end user).
Working in games is an amazing way to discover abusive behaviour and the value of defensive programming, and that is just for dealing with your colleagues (may not be joking).
Gamers are incredible at breaking things when using your product legitimately, once they decide to look behind the curtain you are in trouble. One of the big advantages (acknowledging the downsides) of in cloud gaming is it dramatically reduces the scope for this.
I’m not familiar with Godot networking primitives in 3.X, but 4.0 contains WebRTC support which, combined with a STUN/TURN server, solves the hole-punching problem. You need to run a signaling backend to pass connection info between the peers, but you’ll probably want to build a messaging service anyway for matchmaking.
This is awesome! As someone new to Godot that wants to learn how to build multiplayer asteroids, should I try to build something standalone or browser based? Do you recommend any tutorials to get started?
Godot 3's browser support is currently better than Godot 4's (it was when I tested anyways, this changes every day and I don't use Godot 4).
Making multiplayer work really well usually requires a dedicated server and client side prediction. There's a lot of complexity to making that happen however.
You can use nakamas' messaging system as a transport layer for a game hosted on a user's device. Or you can use nakamas' match API to host the game in nakama, but then the game logic needs to be written for nakama in go, js, or Lua, which you can't then run locally in Godot.
As another beginner, you need not worry much about the platform unless you have a very tight platform integration. Which means, as long as your code dependent fully on Godot, everything works fine. So there is no difference.
For the tutorial, once you read the basic syntax of GDScript, you can directly start coding a game of your choice and reading the docs on need. Or use the official 2D and 3D tutorial.
While I agree with you, having a globaly routable address doesn't help you if you can't accept incoming tcp/udp connections.
My ISP blocks such connections on LTE mobile network. Maybe so you don't pay a lot of money for traffic if people DoS you? It doesn't make sense, since ICMP ping packets are allowed.
Well, it's either my ISP or the android phone I have. Does android have any firewalls enabled by default?
The problem is NAT as it makes it impossible to directly address, and NAT doesn’t exist in IPv6 (because NAT is primarily needed to workaround limited public addresses).
IPv6 support is pretty 'widespread' at this point. >50% last I did a quick test
You unfortunately need ubiquitus IPv6 support to actually rely on IPv6, which isn't going to happen anytime soon.
So you really need to consider the benefits of dual stack v4 and v6 simultaneously within the same group of players. Might be useful, but it adds a whole heap of complexity.
Back in the days of Duke Nukem, Quake and Unreal, we connected with no NAT using 1400 baud modems, if we were lucky ;-). Honestly though, I played direct (peer 2 peer) with Duke Nukem and conected over a centralized server for Unreal, but I hardly ever played Quake. I did this, with a 1400 baud modem and a phone-line that I paid for myself, with the earnings I made from a paper route job. It was the 90s and it was something special, for me at least.
A game requiring infrastructure means that the game requires someone to support the infrastructure, even if it's simple. For small projects or free games, your game can continue to have life if it doesn't require anything but the software to play it. And a $30/mo server cost is not cheap for a game that provides zero revenue (or even upfront-only revenue for a small indie game).
I'm always super happy to see when a game supports zero-internet LAN play. That means I'm still going to be able to play it in 15 years if I want.
Steam used to work this way iirc, but they now always use a relay. This is user friendly, because with normal peer to peer your IP address is given to other players. DDOSing, bringing down Twitch streams, and all sorts of unfun things can result from that. Of course, this does give steam your users' IP addresses.