Making peer-to-peer multiplayer seamless with Godot (2022)

> 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.

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.

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.

(This is how I learnt, YMMV)

Pro multiplayer Godot dev here.

Account system and matchmaker:

https://github.com/heroiclabs/nakama-godot

Top tier tutorials on multiplayer:

https://gafferongames.com/post/what_every_programmer_needs_t...

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.

What we need is widespread IPv6 support. Portforwarding isn't the problem. The terrible UX and the existence of CGNAT (carrier grade NAT) is.

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.

We preshared phone numbers

most games back in the day had to have a self-host option for lan gaming w/o internet access. this usually also works with global ip addresses

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.