Starting My Online Multiplayer System
- reynosorobertov
- Nov 1, 2024
- 3 min read
This week overall I didn’t have too much time to work on the actual code for my system, though I was able to get a better idea of how I am going approach the structure of this project. I went about gathering many different resources that would help me understand the edge cases that may come up when I start building this system in code. The edge cases have to do with having delay, unresponsiveness between the client and the server and more. There are many different methods on how we could approach resolving the delay/unresponsiveness issue. We could do an approach which is called the dumb terminal method, where the client only sends input data to the server, though this method will lead to an unstable gaming experience, because of the time it takes to send the client data to the server, which will lead to delays in responsiveness for the player. Client-side interpolation can help smooth transitions for the client when they input some sort of action in the game, while this does help smooth the transition of in game actions, it still has the issue of a delayed experience for the player. There is an extrapolation method that some developers use, it is referred to as Dead Reckoning (DR). This technique involves predicting a game object’s future position, rotation, and velocity based on their last known values. While this can work great it can become desynced if you try to predict to far into the future, a few frames is more or less what we should be aiming for, though there is also another issue where the data packet which is being sent to the server doesn’t end up getting sent in time or at all within the few frame threshold we set, DR over all can be helpful, but it isn’t as precise as interpolation. This is where Client-Side prediction comes it, if done correctly this prediction will be almost identical to the server’s calculations, which is what we want, though even with this, we still need to compensate for lag and in this case the server can recreate the world state at any time, though with this method we choose to trust the clients when they go about sending in their timestamps, this can unfortunately lead to cheating, since players could possibly fake a performed input at some timestamp before it was supposed to happen.
In terms of getting started, I am going to use Winsock, which is part of the Windows Socket API, which allows me to make HTTP/HTTPS requests and responses which is needed to have the communication between the client and the server. I am first going to get that started, so I can get the requests and responses working correctly, once I get that working, I believe I can then start working on a Client-Server system, though I will focus first on a peer to peer system and get that working before I think about adding a feature that will allow the use of a dedicated server. Though from my previous work when working in Unity’s net code for game objects, I believe setting up a dedicated server is relatively straight forward, since instead of having a client act as the server we introduce another source (like for example google firebase) that is the server, which will receive the input data from clients and then manage them accordingly. I am going to focus on initially working with sending position, rotation, and velocity data from clients to the server and then work on synchronizing that data across all clients, so that all clients are caught up with where the server is at, since the server is where the game is truly at currently, I will worry about managing delay between sending and receiving responses at a later time.
References:
https://medium.com/my-games-company/unity-realtime-multiplayer-part-1-networking-basics-88226b961a95
Comments