Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualMaelmDev

Posted 20 December 2012 - 07:53 PM

You could create your game where there are two types of game data on the client end. The first is the stock static game content that ships with the game itself. This often includes terrain-specific data, often data to help aid in physics client-side determinations, placement of world static geometry like bridges, trees, etc along with area trigger definitions, music associations, and the actual music and visual binary files. This is the content that in a client/server approach, shouldn't be modified and if a modification is detected, the server & client will handshake and exchange the right file from the server's repository to avoid clients from changing the expected behavior of the game based on the server side simulation. The second type of static content is your addons/mods which the server doesn't care about. These simply use some exposed API by the client to provide either enhanced UI options or extend the UI well beyond the shipped version for the player's experience.
In the case of where you can create your own maps and play with your friends over a network, usually the map has to be installed on both ends by players before they can join a game together. Usually this is done by some lobbying mechanic that makes sure both clients agree on simulation details before starting the match.

I know that the client and server need to exchange files somehow, but what is the best way to know how and when to do this? You don't want the server sending every data file to the client...


but if I was to use client-side prediction, I'd still like to be able to get everything synced up. As well, the server may have added entities that the client may not have on its computer, so the problem of downloading the content still stands.


What you describe above is often referred to as game state data and not necessarily "content". In networked games, the server's simulation will need to be synchronized with the client's simulation. There isn't much in the way of a standard practice here other than the notion that you want to minimize your bandwidth footprint, transmit multiple packets of data in one delivery if possible and with client-predication in place, carefully being able to interpolate between latency differences of state transmission to avoid the rubber-band effect so game play is relatively smooth.

Well, you know what I mean. But in order for client-side prediction to work, the client and server need to be using the same physics data (collision hull, friction, restitution, etc.) which may have been changed on the client machine.

#1MaelmDev

Posted 20 December 2012 - 07:49 PM


but if I was to use client-side prediction, I'd still like to be able to get everything synced up. As well, the server may have added entities that the client may not have on its computer, so the problem of downloading the content still stands.


What you describe above is often referred to as game state data and not necessarily "content". In networked games, the server's simulation will need to be synchronized with the client's simulation. There isn't much in the way of a standard practice here other than the notion that you want to minimize your bandwidth footprint, transmit multiple packets of data in one delivery if possible and with client-predication in place, carefully being able to interpolate between latency differences of state transmission to avoid the rubber-band effect so game play is relatively smooth.

Well, you know what I mean. But in order for client-side prediction to work, the client and server need to be using the same physics data (collision hull, friction, restitution, etc.) which may have been changed on the client machine.

PARTNERS