What needs to be sent?
Author
Hello, I'm strongly considering adding a multiplay aspect to the strategy game I'm developing but for quick glance at the faq its more clear then ever that I have alot to learn before I can develop that part of the game. So for now I just want to do the design work for it and leave the implementation to later in the development life of the project.
My main question for now is, what dat should be sent between the clients and host? The game use very little in the way of random factos and for the random parts the game, they it uses a fixed seed system assigned when the game is created. So each player will have the same seed meaning everything should play out the same on each machine. If this is case I should only need to send the game messages corresponding to each users actions to the other machines. Will just sending those message allow the games to stay in synch? Or am I vastly underestimating the communication required?
Depends on your game. The way I've seen it working elsewhere is that change in player movement is sent across from client to server and client makes suposition on available data. Every so often the server sends out the entire gamestate to make sure clients are all in sync.
The general concensus is probably that the client should send user input. This means that the client will send "Build building X at position (X,Y)". If you were to calculate the result at the client and then send it to the server ("I've build building X at p(X,Y)."), it's far too easy to intercept packages and change or produce them to cheat.
Thus the client would send user input, whereas the server will send it's results of it's own game's simulation to the client. This ensures the server checks all actions taken ingame which may prevent a lot of cheating and may ensure fair-play.
Bandwidth concern-wise, you may want to try unloading as much work on the client as possible (such as storing maps on the client's machine), but you should always think of the consequences it may have (fair-play wise / cheat wise).
There are a lot of articles around GameDev.net about exactly this. Read some for hints and tips. Don't be scared of the multiplayer aspect, it's very do-able if you're able to make a decent RTS anyway. Good luck!
Thus the client would send user input, whereas the server will send it's results of it's own game's simulation to the client. This ensures the server checks all actions taken ingame which may prevent a lot of cheating and may ensure fair-play.
Bandwidth concern-wise, you may want to try unloading as much work on the client as possible (such as storing maps on the client's machine), but you should always think of the consequences it may have (fair-play wise / cheat wise).
There are a lot of articles around GameDev.net about exactly this. Read some for hints and tips. Don't be scared of the multiplayer aspect, it's very do-able if you're able to make a decent RTS anyway. Good luck!
Author
Quote:Original post by Stemic
The general concensus is probably that the client should send user input. This means that the client will send "Build building X at position (X,Y)". If you were to calculate the result at the client and then send it to the server ("I've build building X at p(X,Y)."), it's far too easy to intercept packages and change or produce them to cheat.
Thus the client would send user input, whereas the server will send it's results of it's own game's simulation to the client. This ensures the server checks all actions taken ingame which may prevent a lot of cheating and may ensure fair-play.
That was my original though, but after considering my design some more I just don't think it would be possible to cheat in that manner, since any attempt at cheating would cause inconsistency errors. Which I could handle by polling all clients games stats and comparing them to the host game state to arrive at game state conscences and then redistubuting the game state to all clients. Along with an an appriote global message.
What I mean by inconsistancy is this:
Lets say you are cheating so that buildings cost nothing. The client sends a message to the sever "building building A at X,Y" this message is then processed independently on all machines. So if you have insufficent funds an error will be flaged on all other machines since you can't build that building despite the fact that your modified game would allow you. This would then create an inconsistancy error and result in a game state polling and and redistrubution. To many inconsistancy errors generated by a client could result in the other players being asked whether or not kick the potential cheater from the game.
Am I missing something with this logic? Not that it should really matter but the game I'm working on is 4x strategy game, where I predict a maxium of 1 message per second sent from a client at the most active of momemnts. But then I could still be very wrong about all this.
Well, it sounds stable enough. What I told you was actually a tad inaccurate because what I said was in case of a dedicated server - but later I realised you may have been talking about direct connections, as seen in (ex.) StarCraft through a LAN. Obviously there's no point in having a single host do most of the simulations, because then this machine could easily cheat.
Your theorism sounds plausible, but maybe you may want to send gamestates from clients to all other clients (unless you're the one running a server who does that for the players). Because otherwise, the host (acting as a server), may distribute false gamestates and still cheat.
What I'd send in case of direct connections (not going through any type of server) would probably, for an RTS, be changes in the game. It's not something like an FPS, an RTS is fairly predictable :P. And sends of changes in (ex.) pathing are smaller than sends of changes in coordinates.
On a side note, I want to tell you that I have no experience with networking in games yet. I recently programmed a dedicated server for handling users, which only means I'm reading and thinking of theories myself (just like you now). Thus be a critic to what I say eh, don't take my words blindly :P
Your theorism sounds plausible, but maybe you may want to send gamestates from clients to all other clients (unless you're the one running a server who does that for the players). Because otherwise, the host (acting as a server), may distribute false gamestates and still cheat.
What I'd send in case of direct connections (not going through any type of server) would probably, for an RTS, be changes in the game. It's not something like an FPS, an RTS is fairly predictable :P. And sends of changes in (ex.) pathing are smaller than sends of changes in coordinates.
On a side note, I want to tell you that I have no experience with networking in games yet. I recently programmed a dedicated server for handling users, which only means I'm reading and thinking of theories myself (just like you now). Thus be a critic to what I say eh, don't take my words blindly :P
It seems to me that just sending the commands is definitely an easy option.
The only problem is, that although if you just send active commands (like build this here, send those troops over there etc), you do nothing to prevent hacked clients from revealing all the map. This is of course not a problem in games where the whole map is visible anyway.
In fact there's very little you can do to do that, unless you run the sim entirely on the server and send updates to the clients (of course, only sending updates to items which are within the clients' visual range).
This latter approach sounds significantly more complex.
If each client independently runs the sim, that's going to work pretty well as long as:
- There are no nondetermistic events - it sounds like you already know how to handle that - by using a well-behaved PRNG and a known seed
- All clients have IDENTICAL versions of the software
In any case, you should probably put some checks in to determine if the clients have become out of sync with the server - I believe hashing together various game info and sending it to the server periodically together with the frame number should do it - the server computes the same info, and if they're different, you have a desync.
Mark
The only problem is, that although if you just send active commands (like build this here, send those troops over there etc), you do nothing to prevent hacked clients from revealing all the map. This is of course not a problem in games where the whole map is visible anyway.
In fact there's very little you can do to do that, unless you run the sim entirely on the server and send updates to the clients (of course, only sending updates to items which are within the clients' visual range).
This latter approach sounds significantly more complex.
If each client independently runs the sim, that's going to work pretty well as long as:
- There are no nondetermistic events - it sounds like you already know how to handle that - by using a well-behaved PRNG and a known seed
- All clients have IDENTICAL versions of the software
In any case, you should probably put some checks in to determine if the clients have become out of sync with the server - I believe hashing together various game info and sending it to the server periodically together with the frame number should do it - the server computes the same info, and if they're different, you have a desync.
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
