This week I’ve made massive progress within the network of my game. I started this week with fully implementing the entity interpolation. What it does is smoothing out everyone else’s movement, this is important since one only get fragments of data which results in very ‘jumpy’ position if not handled correctly. So when I’ve received two or more updates (I have a lerp time on 100ms, updates being received every ~50ms) one can take out positions in between the updates which leads to smooth movement.
The next thing I worked on was client-side prediction. This is for making you feel in control of your own character, actually simulating the actions before he receives validation from the server. This is important because it is annoying to feel that one’s input is slightly off when looking at the time between pressing a button before something actually happens on the screen. So by starting to move the ship before receiving answer from the server this is solved.
The prediction causes a problem though, because it’s just a prediction. So I had to introduce something called correction / movement-correction in order to make sure that the client and server actually were on pretty much the same positions. This is done by every time an update is received from the server the client looks at what input number/sequence the verified update had. By using the correct positioning from the update, he can apply all newer, non-verified input after that to get another, more accurate, predicted position. He saves this position as a target and will move towards it every update. This makes the client’s predicted ship end up on the same track as the one the server is simulating for it.
No pictures on the updates, the game look like it did at the last pictures except the movement is much smoother. The core network is pretty much done and I will hold on extrapolation, because for now I don’t feel like it is needed. So I will focus on the entity system and how to render text for now.
Now the week is over and on Monday milestone 2 is due. At this milestone we are to deliver a proof of concept, something that shows that our projects are viable.
Since last post (Tuesday) when I had some working movement I have been working on moving the ‘moving’ part to the server instead of the client. What I had was the client moving his ship, sending the position to the server who them forwarded it to everyone else. This is called client authority since it’s the client that determines where he will move, this allows people to modify the client or its packets in order to cheat. What I want is server authority where the server does all the moving of the players, all the clients does is sending their input. So this is what I’ve implemented, I have the clients generating input about 30 times each second. These inputs are sent to the server about 20 times each second (only the new ones are being sent). The server applies the movement and tells everyone of the position in the next update.
For feeling more in control of your own spaceship I have some client-side prediction, where your ship moves directly at your input without waiting for the server to answer. But because this is only a prediction the movement can go wrong and has to be corrected, we must do that too. So we keep a buffer with previous inputs so when the actual position we got from a certain input is returned, we simply correct our movement at that input, then apply all newer inputs after that which gives us our new predicted position.
This is what I have for milestone 2, a game supporting 4 players over the network, with server authority, some client prediction and movement correction.
Fixing my network problem that I had last week took less time than expected, by doing some more research and changing some code I got it up and running again. And after fixing some other issues (like the client was only able to send one packet each frame) the network base feels pretty solid. I corrected the ping functionality so users could be timed out and implemented a sort of ‘global’ state, enabling my program to always handle general stuff like Ping messages independent of what state the game itself is in (menu, settings or in-game etc.).
Connecting to the server works, so I implemented functionality for server to shut down, clients to disconnect and server to disconnect clients. This makes the network much easier, no crashes when clients disconnects or restarts of the program to try again. Together with the time out functionality of the ping messages, the joining and leaving works seamless.
This week’s work is dedicated to the things I’ve mentioned above and actually getting something visual from the network to the second milestone on Monday. So I implemented some basic functionality for adding spaceships and making them move across the network. I’m using Valve’s article about their Source Multiplayer Networking as a guideline. I’m currently sending about 20 updates per second from each client to the server, and the server sends everyone’s position and rotation twenty times each second. This works for now but it uses client authority, I will have to make it server authority later on or else there’s a possibility for cheating. There is no entity interpolation yet so the other player jumps between their positions, but I think it works as a proof of concept.
So what’s up next? Well I’m thinking about trying to implement a more correct movement method using server authority. Maybe it would be fun to be able to firing some lasers in the concept too, but then I have to create a better entity system and that’s up next week.
Four players connected
Four players moving around
So the rest of this week I’ve spent on trying to Implement a basic network structure. The network uses UDP and I find it kind of tricky to get up and running. I could send data back and fourth for a while and it worked really well, however the client broke down after a while and said that it had a bad address to the host. So I’m currently working on rewriting that at the moment, not very much to show. I have however implemented a Ping sequence, assuring that no one stays quiet for to long, and it will only start pinging in the absence of packets. I’ve also made a sort of handshake protocol when a client connects to a server where they exchange information,
I will continue the work on network next week, trying to fix so that the client can retain the host’s address and keep sending data. Then I will make sure that the basic sending and receiving data works flawless and that users can successfully connect and disconnect. I will also try to use the network to show something visually next week.