Could a Peer-To-Peer network architecture be good for my fighting game

Question

I am looking forward to developing a 2D spaceship-fighting, brawler game and I have so many ideas about it. I am going to make a single-player component anyway, but the core of this game would certainly be its multiplayer. For this game, I was inspired by Brawlhalla and its dynamic play-style. In my game, there has to be real-time action features such as attack, dodge, getting hit, killed, so a reliable networking needs to exist. I have thought initially about a client/server architecture, but a peer-to-peer connection would be in my opinion more easily for me to implement. I have read this article and it proves encouraging for me to go on with this simulation solution.

Let me describe my concept:

A client initializes a room and using sockets, IP, port and the other players would after connect to him. Therefore, there is always a Master Client that handles the new connections and gives signal to other clients about a new existing player. Then, as the game is running, the byte data-packets would stream each player's input, his position, his ship rotation, his ship status and so on, so that each of the other clients could run a perfect simulation of the initial client. In other words, this data packets would trigger all the actions on each client. As network protocol, I am thinking about TCP/IP and should someone be willing explain to me in more practical terms the difference between this and UDP, I would be thankful.

I have even computed how much data it would take to transmit over a second: assuming a byte[256] array that holds all the data at one time multiplied by the number of calls per second (about 32 times) multiplied by the number of clients the data should be broadcasted to (3-4) results in about 32 kb/s. It might be a dummy result, i might have left a lot of things out, but again, I am ready to learn.

As a note, I do not intend to make at this moment a professional multiplayer system, but rather, I would like to learn more about this programming part of applications and I think this is a very good project idea to enhance my skills. Of course, I am opened to any advanced tips, solutions, materials and should I add anything else about my concept, please let me know.

How is my theoretical model so far?

Answer 1

You have multiple problems with your current implementation.

First of all, the biggest problem with peer-to-peer (or P2P for short) networking is, that it isn't designed for games. Due to it's nature, nobody has authority over the data being sent and received. If one of the players decides to cheat (always assume this), then there's nothing you can do against it. If you try to look up some guides to P2P networking in games, they'll have a sentence along the lines of "...assuming a reliable and non-cheating peer".

Second, your current approach isn't a P2P one. It's just a dynamic-host-based authoritative one. Instead of having a separate server software running somewhere separately from the game, you just couple it together with the client and make one of the players run it. The difference can be seen on the following image (from left to right: authoritative, dynamic-host and P2P):

As a general rule of thumb: only choose the second option, if 1.) running separate dedicated servers is out of the question (e.g. it's too expensive), 2.) releasing the server software doesn't solve the first problem (E.g. running a server for a mobile game doesn't really work) 3.) you don't care about cheating. The only positive thing you can say about it over the other two solutions is the reduced cost on the developer's side. It makes one of the users run the server, which can cause performance problems. It relies on every user having a good internet connection, which never happens irl. The server has to survive even after the host user leaves, which means the other users have to check the host server every X milliseconds and if it doesn't respond, they have to choose the next best user to host the game. This can take up to 500 ms during which nothing happens.

Three, your calculations about the necessary internet speed doesn't matter nowadays. The games rarely cap the upload and download speeds of users, latency is the problem. The biggest advantage of P2P is the small latency. It basically halves it relative to the authoritative solution.

So, first you should definitely design an actual P2P network if you still want to use it (look up how a P2P network usually looks like). You'll still have problems with cheating though. There are simply no solutions to that.

And to answer your question about TCP vs UDP briefly (for a longer answer, see here): TCP and UDP are very similar with 1 difference: TCP makes sure the packets (the blobs of data) always arrive and in the order they were sent. This makes it lot slower. UDP on the other hand doesn't try to do these. If a packet arrives, but it got damaged, then it simply throws it away. As a general rule of thumb: if speed matters in your game and UDP is available, use it.