Sorry your browser is not supported!

Anybody who has seen my threads here knows all I ever ask about is Newton and Multisync, this time it is multisync. I don't need anyone to fix my code or anything, just an idea, sort of. My question is, what's the fastest way to handle data with a server and a bunch of clients. I'm making an FPS, and I made a multiplayer mode, it had up to 10 players, 6 guns, 5 maps, all that good stuff, but it lagged a lot. Basically, the clients would do their own thing, send their data to the server, and the server would send it to everyone else, so everybody would get everybody else's positions. Is it better to do this, or send keystates and stuff to the server and have it do everything and send stuff to the players? Would the server slow down significantly if I did that? I also thought that sending the floats with fewer decimal points would speed it up, because there would be less data, but I wasn't sure how many decimals you would need for it not to be too jerky. Or is there some other way? Sorry if that didn't make any sense, but I'm tired. Anyway, thanks in advance

Only my theroy...........but it would proboly be faster to have everyone process their own stuff. That way the server doesn't process "all that good stuff" 10 times over before updating everyone. And make it peer to peer(Just have everyone send their positions to everyone else, not through a server.......unless you need it to be for some other reason.).
I think that'll give you a speed up.

Peer to peer wouldn't be the way to go. To many connections to worry about, and to many things to go wrong. That's why commercial games don't use it.

If players are going to be hosting the server (as in the client can also serve as a server) then there's no reason to not have the server do all the collision and hit checks, since it's already got all the data and models loaded.

If the server is to be a standalone application, then let the clients handle collision and hit detection. That leaves the server to do nothing but shuffle data back and forth. In this case there should be a minimal text display on the server to show who is connected, but that's it. Set Sync Rate to 0 and only call Sync once a second. That will keep your server's network code running as fast as possible and you'll experience less lag. Don't load any 3D objects and your code will scream.

I'm doing that with my server and it performs 24,000 loops per second on average. That gives the speed boost I need to handle the number of players I'm hoping to handle.

For static data, periodic updates, or shot and hit data, use TCP packets to guarantee it gets to everyone.

For player movements use UDP, but don't send player movements (or anything else) every loop, that's just way to much data and you'll choke the server. You have 2 options for timing the movement packets. You can either do some testing and find a good interval, such as every 250ms, or you can code something fancy that will dynamically adjust the interval based on some other criteria like ping rate or something.

Take a page out of the playbook of John Carmack. Have the clients predict movement wherever possible. Then let the server updates issue corrections.
Kistech has some good advice.

Never let the clients do this, as you can then introduce cheats which trick the players into thinking there has been a legitimate hit.

What you should do is have the server send out a timestamped snapshot of each players position, rotation and state. (Walking running, crouching shooting ect) Each client will update everyone according to the snapshot, then process their own movement, and send it to the server with the previous timestamp. (To calculate ping rates)

That way the server gets the correct positions/rotations of each player as quickly as possible.

Each client can then take the last X snapshots to predict where each player is in the event of packet loss so they appear to be moving correctly.

You need to send the absolute minimum amount of data as possible. That's why you should only send player X/Y/Z positions, Y Rotations, and player state. (Which could be a binary number. for example 110: Crouching = 1, shooting = 1, jumping = 0 etc)

Suffice to say there is a lot involved in multiplayer. Much more than anyone ever imagines until they start doing it.

@Dark Dragon I figued having the clients do everything would be better, but mobiius has a good point.
@Kistech P2P is a bad idea, got it. 24,000 is a lot
@Mobiius Cheating would be bad Your method sounds like the best. How often should you send each timestamp though? I'd imagine sending them too seldom would cause the player to teleport a lot if they change direction inbetween timestamps, and too often would be too much data for the server. What's a good balance?

Thanks for the responses, guys