next »

[Jesseyay]

Hey everyone.

I'm currently working on a multiplayer top-down shooter, and was wondering if sending player/bullet position and information everys 1/60th of a second is too much?

If someone could tell me how much/often they would normally send in a regular fps that'd be great.

Thanks in advance.

[george]

I don't know if this is helpful but I've been playing a game recently with the ping in the HUD. On average it runs around 150 (about 1/6th, right?) for me, which I take to mean that one-way transmission (of just the ping packet, nevermind actual data for a moment) is roughly 1/12th of a second. Point being that even if you do send data every 1/60th of a second, can a client use that information really? (and someone please correct me if I'm misinterpreting something here, networking isn't really that clear to me).

[Ciardhubh]

... which I take to mean that one-way transmission (of just the ping packet, nevermind actual data for a moment) is roughly 1/12th of a second. Point being that even if you do send data every 1/60th of a second, can a client use that information really? (and someone please correct me if I'm misinterpreting something here, networking isn't really that clear to me).

Ping just means that it takes this many milliseconds for a packet to travel to the server and back, i.e. the delay between the sending of some information and its repsonse. That doesn't mean that you cannot send a 1000 pieces of data per second; only that all of them will be delayed depending on how good/bad your ping is.

The restricting aspect is bandwidth. If you send more data than the connection of a client or your server can handle, you'll run into problems. Also the amount of data your server can process may be important to determine how often to send data.

In the case of bullets it may be sensible to only send where the bullet has been fired and calculate its trajectory on the server and the client. Both the client and the server can calculate where the bullet would go based on where it had been fired. If the client calculates a hit on an enemy, it would have to check back with the server to prevent cheating. If the shot missed, you wouldn't even have to send anything at all.

[Saint]

If you can send and receive data in 60 fps, that's fine - the important part is what you're doing when you can't. What protocol and methods are you using?

If you play on a LAN it doesn't matter so much but over the internet you need to deal with slow lines and packet loss - if a few packets are lost or the line is clogged (leading to lost packets), the client won't get any new information and you need to be able to handle that gracefully and not just re-send the information - that will clog the line further and slow the game to a halt.

For an internet game, I would suggest doing a simulation with prediction on the clients to account for latency, and only send the information that's actually changed. You could also try to send only the key commands from each client and occasionally send a checksum to verify that the game state is correct. There are some more information in these papers...
http://www.gamedev.net/reference/articles/article1370.asp
http://www.gamasutra.com/features/19990903/lincroft_01.htm
http://www.gamasutra.com/features/19970905/ng_01.htm
http://www.ddj.com/184410430
http://www.gamasutra.com/features/19970919/aronson_01.htm
http://www.gamasutra.com/features/20000511/bernier_pfv.htm
http://www.gamedev.net/reference/articles/article712.asp
http://www.gamasutra.com/features/19970801/ng.htm
http://www.gamedev.net/reference/articles/article1138.asp
http://unreal.epicgames.com/Network.htm

Also remember that packet headers can be brutal. On the XBox 360, for example, the protocol header is close to 1 kb, meaning if you send 60 packets a second the overhead alone amounts to around 512 kbps. So, less is more.

... Hope that helps.

[Jesseyay]

Well currently the game is just going to be over LAN but I plan to eventually make playing over the internet possible.
I'll probably do some sort of interpolation on the client side to make everything smooth, so it doesn't matter as much if packets don't get through.

I'm using UDP by the way.

Thanks for the advice (and links).

[postlogic]

I'm in no way adept at network programming nor concepts, but why not just send the bullet angle, speed and such when it fires and let the other clients figure out the rest? It's supposed to end up at the same place anyway, no? That way you're got a lot less of info to have to send.. I have no idea really.. Just my two cents.

[Eclipse]

I'm in no way adept at network programming nor concepts, but why not just send the bullet angle, speed and such when it fires and let the other clients figure out the rest? It's supposed to end up at the same place anyway, no? That way you're got a lot less of info to have to send.. I have no idea really.. Just my two cents.

yes it's the best method for bullets, but there's no guarantee that it will end up on the same place, for a player a bullet can hit someone and for another one just miss him, there's also need for a server side synchonization.
For player movements, you have to send and receive packets everytime you can, be sure to do another thread for that if you can.
Also, Dead reckoning is the first thing you will need to implement if you want to play your game via internet.
Via lan only sending positions will be a "just works" solution, via internet it will be a totally unplayable thing

[MekanikDestructiwKommando]

yer I thought the best way to do it was show player/direction (assuming each client already has an x/y/z value for the player), then they would shoot the bullet from there. Clientside "hit detection" might show bullets hitting people or walls etc, but actual calculations and effects would be done on the server.
I did play one game where hit detection was all client-side -- except it was for bullets hitting *you*, not the other way around. Made for some interesting times when you had lag.. and then a swarm of bullets appeared, all undodgeable  :D

[Graham Lexie]

Personally, I would recommend sending and receiving player actions exclusively. If your game is only keyboard controlled, you could most likely send all necessary information in a single byte.

It depends on what scale you are making your game. Are you going to have one single server that all clients connect to, or are you intending to use a client/server model where one player is the server, or are you using a peer to peer model? The only reasons I can think of to not use a peer to peer model are if your game is massively multi-player(too much traffic), or to prevent cheating, and then only to restrict hidden information that players aren't meant to see(prevent maphacking).

The method I suggested works well to stop any other kinds of cheating, because any cheat has to modify the way the game responds to input, which would just desynchronize the cheating player(easy to detect and drop the desynchronized player). It also has the advantage that you don't have to do extra coding to implement interpolation on the clients. And I for one would prefer an occasional lag spike slowing down my game over having positions of objects suddenly update in an unexpected manner, only to find out that I just died. You can also implement a delay between the time when player actions are sent and the time when they are used, to avoid lag spikes.

Well, I'm no expert, but I have implemented this method and it seems to be successful, so there are my thoughts.