|
Talented DarkBASIC developer Shawn Bower of Starwraith 3D Games has written this great tutorial for the newsletter readers. It covers basic multiplayer object movement and rotation predictions, something Shawn has refined over the years in his award-winning multiplayer sci-fi epic Starwraith games. Over to Shawn...
Basic Multiplayer Object Movement and Rotation Prediction
Gamestate:
A key to solid multiplayer performance in any game's design is handling gamestate (the status and condition of player controlled objects) between retrieved packets. To do this, the game must predict how gamestate will unfold during the time it takes to receive actual gamestate data from the packets. There are a number of ways to accomplish this. But for this article, I will focus on the concepts behind a first person shooter (which can also be adapted to work with games using more complex/diverse player controls for more advanced movement and rotations, such as flight and space simulations). I also recommend referring to my multiplayer source code example as a good place to start with a raw routine to which this process can be added.
Track every Player:
The first step in creating an accurate prediction routine is to continually monitor the recent gamestate. To do this, you will need to keep track of every player controlled object's rotation and movement. It's usually good to assign these results to arrays each time a data packet is received for a player. You can then compare how that player's object changed between the last two received packets and how much time it took. And from there, you can predict how that player will likely move before the next packet is received. Although more complex then what's illustrated in this example, you can increase the tracking history of each object to improve prediction and produce smoother results. But most games can perform just fine with a routine based on a two packet history.
We'll start by tracking the direction a player moves. You can do this one of two primary ways. The easiest way is to just assign velocity and strafe speed to variables, transmit it, then have the receiving system just keep moving the player at the same speed until a packet indicates a change. This works, but can be inaccurate when a player makes sudden changes or the framerate isn't exactly the same on both systems (even for a short period of time). You can use timer based object movement to aid in prediction accuracy, if desired.
Prediction:
Another method is to simply measure the movement between two packets, then use that data to predict future movement. For example, if a player moves 5 units of distance between 2 packets, they will most likely continue moving at the same speed until the next packet is received. So you can simply keep moving the object at the same speed until a change is needed. If you are developing a flight or space simulation where velocity is far more flexible then just on and off, you may want to include measuring the acceleration and deceleration for better accuracy. So if a player moves 5 units between two packets, but the first packet indicated a velocity setting of 0 and the second indicated 10, you know the player is accelerating and will likely continue to do so. So you can continue to increase the velocity setting for that player until top speed is reached or a change is indicated in a packet. If you smooth your physics so that velocity changes are tapered, you can improve how accurate movements can be predicted between packets. If you allow for very sudden movements, then players may appear to jerk around more, making it more difficult to aim and play the game. Smoother movements can provide smoother multiplayer gameplay, not just improve realism. You'll want to balance movement performance with smooth motion. Too fast and the movement may be jerky and hard to target, too slow and players may feel vulnerable and limited.
Rotation Tracking:
Rotation tracking is done in a similar way. You basically just need to measure how far a player rotates between two packets, then continue the rotation using the time as a guide. If a player rotates on the Y angle from 40 to 50 degrees between two packets, then you know they turned to the right (since going from 40 to 50 degrees to the left in about 300 milliseconds or less should be impossible in your game) and if it took 250 milliseconds (the time between both packets), then you know how long it took. Since it took 250 ms to rotate 10 degrees, you can continue the rotation at that rate (or you can also count the number of frames over that 250 ms interval and use the result as a divider). I usually taper the rotation result a bit to smooth out the movement when the player stops rotating.
Conclusion:
By combining these two elements, you will provide far smoother gameplay, making it easier for players to track the movement of others, improving aim and overall gameplay accuracy.
You can download example DarkBASIC multi-player source code from our CodeBase.
|
