>>51761193Well, okay, let's just start from the very beginning. This'll be oversimplified because I myself have not actually attempted the task and only know some of the caveats from my other friends, so bear with me.
We're not going to explore P2P because that's a whole fucking mess.
First, you need to communicate to the client that this is a server that is compatible with it.
Then you need to send it relevant information so the client has a ROUGH idea of what's going on with the server.
Where it gets nutty is then having to somehow synchronize the game logic with any other players on the server. When you start from the ground up as a multiplayer game, you can generally make a framework so that the server runs all of the same logic, or the logic has some way to be synchronized.
Now in Doom's case in particular, if I'm not mistaken, the way this basically worked is that you would send a packet of button inputs, and then receive back button inputs for the other players, and occasionally a status and positional update of every player to help keep desynchronization down. The server itself basically had the role of doing all of the game logic, compiling and sending the buttons inputs to every player(and then processing those packets yourself to update player positions,) kicking any players who weren't responding to the server pinging them, and occasionally sending a package to make sure everyone's still all on the same page. The clients would do most of the work, and this would happen so fast that you wouldn't notice the difference.
The main killer when developing multiplayer is almost ALWAYS RNG. If you cannot synchronize RNG, you have problems on your hands as each player will effectively have a different outcome to basically the same situation. The only way to synchronize that is to instead send a MASSIVE fucking package that contains ALL of the updates. That's called a terminal client, and it's not ideal for hopefully obvious reasons. (1/2)
