Implemented proper client-side interpolation, made everything tickrate independent so you can host servers with 30hz, 64hz and even 128hz tickrate. Also changed the adaptive buffers to handle the worse internet connections, you can barely notice the rubberbanding now on a bad 4G connection for example. Here’s a test of peeker’s advantage on LAN, I measured about 15-20ms of latency for a player’s actions showing up to all other players on a stable 0ms connection
MASSIVE NETCODE IMPROVEMENTS
I made changes to how the client adjusts its input clock, instead of targeting discrete ticks, it targets time now so we can get even less latency and allows to provide a better experience for both players with a stable and poor internet connection!!
This is the same system that CS2 uses
Movement fixes and new weapon sway system
I had to fix so much of issues with the movement script that I ended up turning hackatime off for a day so it doesn’t look like fraud I swear to god this took so much time
I was so lost in the old movement code because I didn’t full understand it and the janky workarounds have started to limit the customizability of the whole thing
Sooo I spent 12 hours rewriting the entire thing so that I have it entirely like I want it to be: Source style air-strafing, Titanfall 2-like wallrunning, Apex-like slides etc
Will be interesting to build maps around this
Did some refactoring and code cleanup
Lag compensation visualization:
Blue capsule: client hitbox, Red capsule: server hitbox
Lag compensation test with friend
Works
So far I have optimized netcode with: server authoritative model, remote entity interpolation, lag compensation
It’s already a solid base for a tactial first person shooter
Weapon test, sway and bob
didn’t learn how to design and model weapons yet so I used the Phantom from VALORANT as a test
I’m done with client side prediction and reconciliation, input buffers etc.
I think I got it to work really well, on localhost you get about 3 frames of peeker’s advantage with 120fps clients which is around ~25ms, which is close to what CS2 gets - with 64 tick rate servers, you can’t really get lower than this
I’m moving onto implementing lag compensation
Here’s a video showing the peeker’s advantage
so uh turns out netcode is hard
it took me a lot of time to get the movement working on poor network conditions
i also reworked the movement
the game can withstand ping jitter and packet loss
i tested with 100ms ping, 30ms jitter and 10% packet loss, it functions amazingly
finally implemented client side prediction and reconciliation
i first tried doing this 3 years ago with no success
now the server doesnt trust clients blindly with their position, the client first predicts its position, sends its input to the server, the server performs the same inputs, sends back the position that it thinks the player is at, client checks if its at the same position, if not, it corrects itself
this was very hard
in the video the red capsule shows the latest position the client has received from the server. once i enable 50ms simulated ping (100ms rtt) you can see that the server position falls behind while the client continues moving immediately thanks to prediction
started working on my multiplayer movement shooter
first i implemented TCP and UDP connections between clients and a dedicated server
i followed Tom Weiland’s old networking tutorials for the basics, but fixed a few things because i felt there were some design issues with the original implementation
after that i added my own modified version of Dani’s Karlson FPS controller from an old fangame i made
right now players can connect to the server and see each other moving around correctly