🔒 Locked

Basic fast paced game networking

Started by HumanoidTyphoon Apr 1, 2009 at 8:00 AM 2 replies 2.4k views

Original Post

Apr 1, 2009 at 8:00 AM

Hi Im working on a game that will hopefully have support for around 10 - 12 players, it will need to be fast paced, and will mostly be aimed at lan, and high speed internet only, atleast thats what Im currently aiming for. The program supports being run as client OR server, currently no plans for a dedicated server, unless I run outa options. Im pretty new to networking, Im trying to design the overview that will work well for a fast paced game, just getting the basics down really. input reaction and client synchonization are both pretty important in this scenario, but ofcourse its a balancing act between those two. Im using a combo of reliable/unreliable UDP. This is what Im thinking -Client receives input from user and interpolates based on input, up to a point. -Other clients interpolate based on previous packets, up to a point. -As you can see clients will be out of synch here. -Clients send their inputs to the server -The server sends all relevant state changes based on input, to relevant clients. -The clients all receive state changes and exterpolate where applicable. -State changes that are important (eg health changes) will be sent reliably and seperately to positions/rotations which will always be sent unreliably. -Additionally the server will be able to "prioritize" update frequency between players based on distance to client. players closer to the client, will be updated more frequently on that client, at a specific radius, updates will no longer happen and players will not be seen at all. There will be 4 levels of network update frequency. High, Medium, Low, None. When there are more than x amount of players in the high radius, The closest will receive high, the others medium. There will be a capped amount of players that can use high and medium updates for each client. I have noticed, that even at low interval updates, clients can jitter waiting for updates. In the above scenario, will interpolation based on current input be able to hide most of that? Suggestions? Constructive criticism? Things to watch out for? Better ways of doing things?

ddn3

124

ddn3

Apr 1, 2009 at 9:43 AM

If your targeting such a low number of peers, try a fully connected network ( ie, all peers link too all others ). Broadcast non-critical events like voice and movement events to all peers (as appropriate, i see u do some filtering based on distance), save the shooting and other authoritative events for the server.

This will reduce the interpolation error for movement at least. The server is still authoritative, but doesn't need to send as many movement updates for everyone with this scheme.

Be careful with reliable and unreliable data streams if they are dependent for instance, if you allow the client to shoot a gun locally depending upon if they have bullets or not, and the ammo is sent reliably, it could be out of sync with server and perhaps allow the user to shoot or not due to the latent reliable stream. Highly dynamic states like that I would send unreliably and for one off high powered weapons (ie rockets or the like, i would use server confirmation before firing, nothing worse than invisible rockets ).

BTW if your making a fast paced action game, you should use extrapolation (projecting the data into future or present) vs interpolation (blending between 2 known points in the past). Their basically same, except for the time component. By syncing the timers, you can project the data into the present time frame, which will give a more accurate representation of the players position on the server, as long as you have sufficient updates and low enough lag, this shouldn't cause too much error.

Also another point is to reduce as much as possible the transactional latency overhead of the application itself. Ie, how long it takes for a packet to be sent/received/acted upon in your application ( assuming 0 network lag ). Applications have natural transactional latency ( determined by their frame rate, update rate of network thread and input polling rate etc.. ).

One way of doing this is to make sure your game runs fast ( 60fps at least ), this will greatly increase the responsiveness of the game as both a fast paced action game and decrease the transactional latency for network games.

Good Luck!

-ddn