I mean most games don't even allow you to push other remote characters, and they are pretty fine as such, I guess giving up on these things allows for a smoother experience rather than predicting them and then having to deal with inevitable corrections.
I basically want my netcode to support making games like BF/Fortnite, etc… I don't care about RTS-es or games with messy player interactions. So I assume I'm fine as such, right?
Why sync client and server tick?
BoredPerson said:
This all works well at the moment. Is there something I'm doing wrong and I'm not realizing it? Why would I sync the client and server ticks when I already have a system that works without it?
Your approach with delta compression and message numbering sounds reasonable to me. It is hard to tell, whether a complex system like your networking code is sufficient to fill your needs in the end. Your direction seems right. The client state will always lag behind the server state a bit. And server state always needs to be the state that matters.
You might find this article by Gabriel Gambetta on Fast-Paced Multiplayer helpful.
However, in a competitive FPS, consider the elephant in the room: Cheating!
Cheating players can easily fake disconnects, latency, and timestamps to their advantage. So a sync system that relies on statements from the client can backfire. It is better to handicap players with bad connections than to give cheaters a foot in the door.
Novel MMORPG design ideas: https://www.mmo-blueprint.com