• Register
Post news RSS Pulsar Weekly Update #5

3DMUVE gets Pulsar networking optimized with no more jitter. Almost ready to start load testing to see how things perform with more players. Stay tuned for more details.

Posted by on

What a crazy couple of weeks. I started minimally stress testing the networking and ran into a little caveat with what I call jitter. The remote avatars had this shaking sensation going on, especially when the local player was tailing a remote avatar at high speeds. It wasn’t lag, as everything was running over a very fast local network, but it was definitely unsettling. After trying many different optimizations and talking with a lot of people, I was finally able to resolve it, and I’m really happy with the outcome. So much so that I hoped to cut a short video this weekend to show everyone. Unfortunately, my capture card requires HDMI and none of my current systems have HDMI so I had to order a converter cable from VGA and it wont be hear till later in the week, so the video will be next weeks gift :J

Networking can be tricky, to support 10’s or hundreds of players, you can’t send network updates every frame. Instead we might send updates every 20 frames. At 60 FPS, that would be 3 times a second. However, what happens to the remote avatar the other 19 frames. We don’t want it to just sit in one place, and then update to a new location every 20th frame. That would look bad, and is a form of LAG. To make it look better while still optimizing the network we use a technique called smoothing. Smoothing calculates how many frames can be processed between previous updates, and then will move the remote avatar from its previous position to its new position over the course of time till the next network packet is received. If we don’t receive an update for some reason, we perform a prediction. Prediction is the act of guessing where the target would be based on its previous movement details. Eventually when another packet is received we again smoothly move the remote avatar from its current position (wherever that is) to the new position, over the amount of time calculated till the next network packet is received.

As you can see, it can be quite complicated, and there’s a bit more math that goes into pulling it off right. I feel at this point it’s looking and feeling really good, and I couldn’t be happier. This week I also got what I call a targeting pointer working, which works in conjunction with the targeting reticle. I showed earlier in the week choosing a target shows a reticle over the target. Sometimes if the target is off screen it can be difficult to find the target so the targeting pointer is a small arrow that shows what direction of travel will center you on the target. I’m currently clearing the target if you’re nearly centered, but it can be onscreen, and off towards the screen edges at which time the arrow will appear. The arrow will stay on screen even when the target is behind you.

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.