Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Game Mods and Multiplayer


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 MaelmDev   Members   -  Reputation: 198

Like
0Likes
Like

Posted 19 December 2012 - 03:42 PM

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?

Edited by MaelmDev, 19 December 2012 - 03:49 PM.


Sponsor:

#2 frob   Moderators   -  Reputation: 22770

Like
1Likes
Like

Posted 19 December 2012 - 04:20 PM

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.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#3 MaelmDev   Members   -  Reputation: 198

Like
0Likes
Like

Posted 19 December 2012 - 04:43 PM

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.

#4 crancran   Members   -  Reputation: 416

Like
0Likes
Like

Posted 20 December 2012 - 12:30 PM

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.

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

Edited by crancran, 20 December 2012 - 12:32 PM.


#5 MaelmDev   Members   -  Reputation: 198

Like
0Likes
Like

Posted 20 December 2012 - 07:49 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.

Edited by MaelmDev, 20 December 2012 - 07:53 PM.


#6 frob   Moderators   -  Reputation: 22770

Like
0Likes
Like

Posted 21 December 2012 - 12:38 AM

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.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS