ZeroTixDev
commented
2 years ago I can't fix stuttering, it is the nature of the internet. The client-Server approach is the best for this type of game (PVP game with a huge arena and tons of players). If it's stuttering, just get a better internet lol. Client prediction is NOT a better netcode design, it is really just an illusion and would create more problems than it fixes. I can only really see client prediction working in cases like fps games and games where you can't necessarily see everyone in the game all the time. Bonk violates both of the former principles but it has a determinstic lockstep method where you predict other players alongside predicting yourself. For bonk, client prediction is likely needed and would lose a lot of the appeal if you had delayed inputs when bonking other players. Bonk can only really do this by limiting rooms to have a player limit of 8. I have made multiple multiplayer games that utilize determinstic lockstep so I do have some experience I guess but I really don't see it working in this game. Rather suggesting pure client prediction, determinstic lockstep would be a better approach given the game had rooms of 8 that players could join rather than an open arena and defly.io-like. But anyways, that could happen but why do that and add the problems of people dying when it doesn't look like they die, shooting an arrow at someone but they suddenly teleport to miss it, etc. That's why I decided from the start of the game that it would be client-server based and this makes the game more fair with the slight disadvantage of input delay which is barely noticeable unless you live with Putin.
10maurycy10
The current netcode works by sending user inputs to the server which in a few (16-30) ms sends movement updates back.
This causes stuttering and can make the game unplayable on a bad internet connection.
A better netcode design would be to process player inputs on the client, and sending the new position to the server to be distributed to other players.