Okay I've started to use Raknet to undergo a networking project. I will be doing some of the coding for a fps style game (ala gta). Basically i'm wondering about sending data and what is the most flexible, light and simpilest way to do so. I looked at the FAQ and from what I found the tribes protocol is basically what i'm looking at, obviously there is data that needs to be sent, some data that could be sent, etc... Basically i'm wondering what should be sent in a packet... if that makes sense, like I'm assuming I should make some form of protocol like first 5 digits is message typ then next 4 is the second id for that type etc and send the data afterwards. Send messages constantly. Someone prior to me mentioned sending chuncks of data via sockets and recieving them on the other side. So I guess its basically a chunky vs chatty interface discussion. Which is the more flexible approach? the one which would scale more easily for larger number of players? Aswell if I asked something stupid or if you need clarity please feel free to ask/point it out =P

You need three pieces of data:

1) how fast response time you need from client->server (discounting propagation delay). Something on the order of 20 packets per second for a typical FPS.

2) how many players you need to be able to see when connected to a server, something on the order of 16 players for a typical FPS.

3) how much downstream bandwidth you can use per connected client, Typically either 5 k/s for modems, or 25 k/s for broadband.

Given these three pieces of data, you can easily calculate how big each packet can be:
5 k/s / 20 pps / 16 ppp == about 15 bytes per player per packet on modems, or about 75 bytes per player per packet on broadband.

Sending one packet per little message would waste a lot of bandwidth on packet headers; you want to send packets exactly at your desired quality rate.

Scaling is not about how you frame your network packets; it's about what you put into those packets.

I guess my main concern is making something that is scalable and not having to rewrite it 4 months from now if/when the project changes. Aye obviously the data in the packets is important, basically Its better to put as much data into a packet as possible. So anything I can compress into smaller data then it really is, is what I want to try to plan my code around...

So basically if I find x amount of messages fit fine try to send that x amount every y times per second. So really I want messages to be as thin as possible correct? like instead of "playerismoving" use "1" or something along those lines, basically making it as small but informative as possible.

along with the above poster...

Look up Dead Reckoning. It helps you cut down on chattiness, while keeping your movements within a certain threshold.

aye anon that was my plan, to go pure binary and based off earlier sets of numbers it will dictate where the numbers belong etc
cool thanks =P