Communication Protocol for 3D Game Movement

Hello,

I am currently working on a 3D engine which is meant for a small network game. I have reached the step of connecting the clients to the server, although I'm looking for the best way to communicate as far as movement is concerned.

I have been thinking a basic movement protocol and I'm not too sure about how efficient it will be. This is why I'd like to have your input on this topic, so that I can improve the protocol accordingly.

Here's the structure I have up to now:

Movement Request

Client to Server

float currentX

float currentY

float currentZ

float movementX

float movementY

float movementZ

Okay this packet is meant to be sent from the client to the server when the user changes the direction it wants to move. Maybe it is because he's now staying still, or because he's now moving backwards instead of forwards, etc... The current position is given to make sure both client and server consider the client at that position when his movement will change.

Direction Update

Client to Server

short facingAngle

This packet is meant to be sent from the client to the server when the user changes the direction it is looking at. Basically, we only send the angle he is now facing, and if he was moving fowards, the "forward" direction has now changed according to the new facing angle.

State Confirmation

Server to Client

float currentX

float currentY

float currentZ

short facingAngle

On a regular basis, a client will have to be synchronized with the server to make sure they handle movement the same way and that no gap is being created between them. Thus, the server will regularly send out the current position and facing angle of the client to him so that synchronization can be confirmed.

Movement interruption

Server to Client

float currentX

float currentY

float currentZ

When the client runs into an obstacle that prevents him from keeping his current movement , the Server sends a movement interruption packet indicating him that the movement he was performing gets him blocked at the specified direction. If the client wants to keep moving, it'll have to perform a new valid movement request.

Well this is what I have so far. Additionnally, if someone can point me to a place where I could look up the movement protocols used by some games such as Unreal Tournament, Halflife, or any of these, I'd be thankful.

Thanks in advance

-Dalzhim

[2619 byte] By [Dalzhim] at [2007-9-30 20:40:03]
# 1

> The current position is given to

> make sure both client and server consider the client

> at that position when his movement will change.

What happens if they don't agree?

You probably should allow for recovery when packets go missing. By recovery I don't mean recovering the packets, but having both the client and server be able to recover if some packets disappear between them. And also you don't want to allow a forged packet to fool the server.

paulcw at 2007-7-7 1:29:11 > top of Java-index,Other Topics,Java Game Development...
# 2

Indeed, validation has to be done on the server side to make sure the packets received aren't forged to fool the server.

As for what happens when the Server sends its synchronization packet. Well when the client moves in the same direction without changing it during a long time, there aren't any new move requests done. To make sure both the server and the client handle the movement uniformly and that when the client will change its direction, no glitch occurs, the State Confirmation packet is sent.

Dalzhim at 2007-7-7 1:29:11 > top of Java-index,Other Topics,Java Game Development...