I'd like my game to support both multiplayer gameplay (in a client-server architecture) and content modifications. This presents a problem: what should happen if a player tries to connect to a server that loads different content? Anything in this game can be modified or added, including scripts and entities.
The easiest solution is simply to reject that player if his content doesn't match. This would be done by comparing checksums of all the client files with the server files, and, if they don't match, that player is not allowed to connect. There are many drawbacks to this system, because a player can easily get himself locked out of online play if he accidently modifies a file associated with a published mod or the vanilla game.
There's also the solution in which the files are compared to the server and then downloaded if they do not match (or if they do not exist at all). This is the more attractive of the two, at least in my case. What is the best way to manage this? Should each server create its own local mod on the client's machine?
Game Mods and Multiplayer
I think it depends on the nature of the game, and the nature of the mods.
Ultimately it boils down to the communications protocol that the network is expecting.
If the simulation is done entirely on the server, and if the mods are entirely on the way the game is displayed, then there shouldn't be any problem. This would be the case for see-through-wall cheats, aim-bots, and so on. They all follow exactly the same communications protocol and the same events are always as expected.
If very much of the simulation is done on the client then there can be many compatibility problems. They may or may not follow the same protocol based on the mods and the game details. In that case it would be unwise generally to allow them to play on a shared server.
Ultimately it boils down to the communications protocol that the network is expecting.
If the simulation is done entirely on the server, and if the mods are entirely on the way the game is displayed, then there shouldn't be any problem. This would be the case for see-through-wall cheats, aim-bots, and so on. They all follow exactly the same communications protocol and the same events are always as expected.
If very much of the simulation is done on the client then there can be many compatibility problems. They may or may not follow the same protocol based on the mods and the game details. In that case it would be unwise generally to allow them to play on a shared server.
Author
You're right, I didn't factor in the differences in client-side vs. server-side simulation. Your mods wouldn't affect other players, 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.
As frob said it depends on the nature of your game.
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.
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.
In the simplest of terms, a client when connected to the server has an Area of Interest (AOI) that controls what level of state data gets transmitted by the server. There are various ways you can define an AOI, whether it be using physics collisions or some spacial index queries. In either way, objects that are of interest to a client simply have their state replicated to all interested clients as it changes per game loop. Keep in mind though what gets sent is typically some form of numerical values that the server and client both understand. The client has a local database cache of Dictionary lookups that it uses to convert the streamed data from the server to actual visual representations that can be shown to you. For example, server may send that my avatar is race 2. On the client side, race 2 is in some table that represents an Orc mesh. Another transmitted value could be 16 that represents to use the brown Orc skin rather than maybe the green skin because of my selections during creation.
HTH
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.
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.
In the simplest of terms, a client when connected to the server has an Area of Interest (AOI) that controls what level of state data gets transmitted by the server. There are various ways you can define an AOI, whether it be using physics collisions or some spacial index queries. In either way, objects that are of interest to a client simply have their state replicated to all interested clients as it changes per game loop. Keep in mind though what gets sent is typically some form of numerical values that the server and client both understand. The client has a local database cache of Dictionary lookups that it uses to convert the streamed data from the server to actual visual representations that can be shown to you. For example, server may send that my avatar is race 2. On the client side, race 2 is in some table that represents an Orc mesh. Another transmitted value could be 16 that represents to use the brown Orc skin rather than maybe the green skin because of my selections during creation.
HTH
Author
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...
[quote name='MaelmDev' timestamp='1355957005' post='5012622']
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.
[/quote]
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.
Figure out the fundamentals of your communications protocol beforehand. Figure out who is going to tell what to whom, when, and why. That will help much of it fall into place.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
