Multiplayer / sockets

I think the most efficient way of doing things, is to only send player actions across the network. Maybe a full scene sync every once in a while.
For example:

Player x moves
player x rotates
player x shoots
player x changes weapons
Player x is hit by y
etc

The receiving clients are responsible for receiving the action data, and updating their scene info. Usually clients also perform some sort of dead reckoning to guesstimate where the other players are moving to.

Yeah, that is basically what i had in mind. But the players position/rotation etc must be send continuesly, right? And how do you do that when there are like 10 or more players in game? Do i send a string string like:

PlayerID,12,20,100,50,sword|PlayerID,34,150,256,180,bow

Which the client has to split up again and basically says:
PlayerID = 12
posx = 20
posy = 100
rotation = 50 degrees
weapon = sword

So now i have enough info to draw the position of the player
The same protocol is used for PlayerID 34.

So basically i will have one big string when there are like, 40 people in the server. But i'm not sure if this is the way to go, with splitting up every bit of the string etc.

See article here:

http://gafferongames.com/

Also, try the networking forum, not the game programming forum. They have a FAQ too.

Look at the concept of serialization, it will help. :)

I don't think you should continuously send position, rotation etc. Only send actions. Let the clients calculate the positions.
If you send all positions, your bandwidth usage will take a HUGE hit.
Also, sending data as strings, is not the best way to go.
Once in a while let all players send their calculated positions, and check for inconsistencies.
The url jdindia gave, is also very good.

1) send binary data.
2) serialise / deserialise the objects you need to sync across the network.
3) identify objects via GUIDs.
4) use delta-compression.
a. via unreliable UDP, send only changes of the latest server state, from the last state aknowledged, for each client.
b. via TCP / reliable protocol, broadcast the changes of the latest server state, from the previous server state, to every client.
5) run client-side prediction and lag compensation, as explained in the gaffer article.

Raknet has delta-compression technology, as well as NAT punch-through, serialisation, and so on.

apart from data marshalling and transport, it's up to you and your game to convert those serialised bit streams into valid object states.

Quote:

I don't think you should continuously send position, rotation etc

So if a player is always moving and rotating, your not going to tell the server that?

You need to have the server do updates. Think about when someone lags for a second, you cant let them still move around and kill people, when everyone else just sees them standing still.

There are a few ways to deal with things on networking, but basically you send updates when you need. If its an fps, then your sending data all the time.

Thanks all, i think i have enough to start with :) That link, gafferongames.com is really a nice read. I'm also going to look into serialization.

Quote:

So if a player is always moving and rotating, your not going to tell the server that?

I think what Fase meant was that, instead of sending the players new world position ( say, a 3D vector of floats ), the client just tells the server that the player moved forward. The server looks at the clients current position and rotation locally, and then tells the client what it can see.