Player-hosted by p2p about message-io HOT 3 CLOSED

There is an example named distributed that shows what I think you are searching for.

Anyway, from my knowledge, making a peer-to-peer game with more than two players (maybe even with two 😄 ) is more difficult than making a client-server architecture with a lot of clients. This is because you need to synchronize the state in some way among all the players, that is not trivial. On the other hand, using a client-server architecture facilitates the architecture, the synchronization and it scales better (adding a new player implies 0 costs).

I mean, I would start from the beginning with the client-server architecture. It is not harder than making by peer-to-peer (it's even simpler), and have a lot of more benefits.

And, if you trust in your clients, you can avoid sharing some computation among the server to the clients. i.e the own clients can check the collisions, there is no need to send the action to the server to ensure if the action is valid or not.

from message-io.

The article about https://medium.com/bumble-tech/webrtc-making-a-peer-to-peer-game-using-javascript-f7123aed769e is quite interesting. In that example, you are removing the need for a server by making use of STUN and ICE, that is integrated into the browser. Until I know, out of the browser, you are on your own. And these tools should be implemented/used according to your to needed. It is out of the message-io scope, which only now about messages, but you can use these message to build some behavior similar to ICE or STUN offers.

To clarify, I think that here there are 2 different concepts that maybe are mixed:

1. The game network topology (In this case, client-server, or distributed peer-to-peer)
2. And how you said, how to bypass port forwarding (that doesn't imply peer-to-peer).

The first is related to your network game architecture: how it works, how the state will be share, and things like that.
The second is about the network itself, out of your game: how an endpoint can know and reach the other.

For example, you could have a client-server architecture using ICE and STUN tools. One of the clients run the client and the server (transparently) on its side. It connects its client to its server directly because is in the same location, and by using ICE & STUN tools, the other client can connect to you. It seems to be peer-to-peer at the high level but remains client-server from the game view.

Maybe, is the latter what you are searching for?

from message-io.

I would start from the beginning with the client-server architecture. It is not harder than making by peer-to-peer (it's even simpler), and have a lot of more benefits.

Hmm you’re right, it’s the better option to start with. I’m still quite keen on p2p for my Shotcaller game further down the line though. Since it’s strictly 1v1, deterministic and turn-based (sort of), it should work well with p2p. It’s just nice to have a hosting option for the game that can actually scale infinitely, even if it’s not the best default.

This cleared up a few things about the application of p2p:
https://github.com/ValveSoftware/GameNetworkingSockets/blob/master/README_P2P.md
https://medium.com/bumble-tech/webrtc-making-a-peer-to-peer-game-using-javascript-f7123aed769e

I guess what’s actually most important to me is that it would be simple enough for players of my game to essentially do cargo run --example tcp serverfrom within the game’s UI so they could set themselves up as the host. Though they’d probably have to deal with port forwarding, which is very technical. p2p via WebRTC seems to bypass port forwarding entirely.

from message-io.