![]() This has proven to be far more difficult than I expected. I'm still looking for sponsors or advertisers. ![]() Peak moments now approach 100 simultaneous players, and there have been thousands of new subscribers. The number of players has recently been increasing. ![]() Kinematic object animations have been added, allowing moving platforms and rotating structures. In addition, numerous fixes and updates have been made to both the client and server to improve stability. Players are now ranked based on their K/D ratio, which is weighted as a function of kill count, maxed out at 1k. I've added player profiles and a ranking system. The ninja.io website has had a couple of upgrades. Hey, it's been a while since my last update. I've been distracted by other things, but finishing this project ASAP has become a main priority of mine again. Keep in mind that the server is located in Europe, so players from other continents might have latency issues. Major changes include the addition of sound effects, weapon & item updates, UI changes, AZERTY keyboard support, weapon tweaks, library updates and numerous bugfixes. Thanks! You can now test the new dev version. Networking is bitch! Just like you, I completely underestimated this part and building something decent took ages. For huge maps with more players, broadcasting 20/30 times per second would probably become the more appropriate technique. With a few players (say, under 6) this can lead to 12/15 messages per second at max, which is a nice bandwidth economy. This technique is also sweet because you don't need to send updates X times per second, you only send users actions whenever they do one. The drawback of this technique is that if you have a bad ping the character will feel slow and unresponsive, but with pings up to 80 it's very playable and players barely notice. The client presses a key (and does nothing), sends it to the server, the server plays the action and notifies everyone. To prevent the issues you mention regarding desynchronization, I completely removed client prediction. Looks super cool but you don't accept guests any more Needless to say there's still plenty of room for improvement here. To say that I greatly underestimated the difficulty of synchronizing a multiplayer physics game like this would be an understatement Bullets might occasionally end up being 'eaten' by the target without doing damage, even though the client might register a hit. The nade will then briefly appear to tumble before being corrected by the server updates. So the client might consider it a hit, causing a ricochet off the grenade, while the server considers it a miss. Another situation where minor glitches might occur is when very fast moving objects like bullets strike a small object like a hand grenade. ![]() This can lead to some rubberbanding and jittery movement in some cases. During the following server updates, the player will then feel like he's being 'pulled' off the cliff, since the server is still leading. One remaining problem is the case where a client player will stop running a fraction short of a steep cliff/edge, while the server considers the player to be past the tipping point, so on the server he falls off, while on the client he remains standing. This will inevitably desync the client and server a little, but since they are synced at 30hz this is generally barely noticeable. I also reduce floating point precision to 3 bytes before sending across the network to save bandwidth. Positions, rotations and forces calculated by the server are leading and they are synced with client at 30hz. Physics are updated by both server and client at 60 hz. If by all clients/players, then how you deal with non-deterministic math between different browsers (firefox and chrome still can produce different results using s/sin etc. Physic simulation is calculated only by host or by all clients as well?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |