Pulsar is a modern team based space combat game. There will be 4 different game types but Domination is what makes Pulsar really special. In Domination the objective is to destroy all the competing team’s base and take control of the system. However, it’s not just about combat; we’ve added a touch of strategy through the use of team resources. Teams will need to reach a science level of 10 before they’ll acquire the right weapons necessary to take out an enemy base. To reach each science level teams will need to acquire resources. The more resources, the faster your team can level up. Use your resources wisely because too few spent on upgrades can leave you vulnerable to attack, but spend too much on upgrades and your leveling will take too long. Die too much and lose valuable resources to respawn. With each new science level also comes new upgrades, so don’t waste time, help with mining to speed things along. Fierce dogfights will ensue while teams race to reign victorious.
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 3dmuve on Feb 17th, 2013
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.