Sending Game Data
Author
I'm writing a client/server game in C# with DX9, and was wondering if I have the right kinda idea with what the server should send to the clients and when. Basically each client (maximum of like 10 connected at once) clicks where they want their player to move to, and there is also text chat. At the moment I'm thinking of something like this:
Chat text is sent to the server when the 'send' button is clicked, and the server then sends the chat text to all clients. When a client clicks on their screen, the click position is sent to the server for processing.
The server is running a loop, computing movement vectors from the click positions. Every so often (how often, a few times a second?) the server sends the state of each player (position, movement vector...) to all of the clients.
Each client is running a loop that renders each of the players on screen using data held in its local player state database, running its own simulation of movement using the given position and vector, and being updated every so often from the server.
Does this sound OK? Could it be improved?
Should I use TCP/IP for all of it, or maybe UDP for sending the player states and TCP/IP for chat?
How should I be using threads; one for each client on the server?
Should collision detection be done by the server or on each separate client?
Does the server need to run its own simulation, or just pass the data to the clients to use?
Sorry for all the questions but I don't know what's best.
All of those will "work." Which one is best depends on what your specific goals are.
If you want a fairly easy model to work with, without worrying too much about cheating hackers or server-side authority in physics, or accurately depicted distributed collisions, then I'd suggest this:
- Chat, and movement are all treated the same: receive from one player, echo to all other players.
- On each client, each player entity has a target location they want to go to. This is updated by packets received from the server.
- On each client, you run path-finding from the currently displayed player position to the desired target, and walk the character over there.
This will meant that all clients will be largely in sync (because they'll all be walking towards the same place), but it means you may see slightly different things on different clients (because you don't do any special timing management, etc). Overall, for an RPG, MUD or chat game, I think this is the way easiest.
If you want to add server-side authority, you do the same thing on the server as you do on the client, and make any decision about what you can do (cast spells, open doors, whatever) based on where the player is on the server, before you send out the results to the clients.
If you want a fairly easy model to work with, without worrying too much about cheating hackers or server-side authority in physics, or accurately depicted distributed collisions, then I'd suggest this:
- Chat, and movement are all treated the same: receive from one player, echo to all other players.
- On each client, each player entity has a target location they want to go to. This is updated by packets received from the server.
- On each client, you run path-finding from the currently displayed player position to the desired target, and walk the character over there.
This will meant that all clients will be largely in sync (because they'll all be walking towards the same place), but it means you may see slightly different things on different clients (because you don't do any special timing management, etc). Overall, for an RPG, MUD or chat game, I think this is the way easiest.
If you want to add server-side authority, you do the same thing on the server as you do on the client, and make any decision about what you can do (cast spells, open doors, whatever) based on where the player is on the server, before you send out the results to the clients.
Hi,
I just wanted to add a few things to what hplus said.
One thing you should watch out for is how often your clients sends a packet to the server. For instance, if 10 players decides to click the screen a gazillion times a second, it may flood the server (note: a large number of individual, physical UDP packets, although small, may still cause problems for the server -- at least in my testing it has).
The easiest thing to do is just to limit the amount of clicks the user can do a second.
However, another problem that crops up is that if you use UDP (and I think you really should), then the packets may not arrive in time. What if a player clicks on location X and then quickly clicks on location Y. The server may see it as "player clicks on Y then X."
You can go into all those mechanisms for handling in-order delivery, but if it's the end result you're after (ie. what was the last position the user clicked on?) then an easy way to solve this is to simply send the current click position at regular intervals to the server. The added bonus of this is that it solves the first problem (the gazillion click problem).
Also, I strongly advise that you do not use threads so you do not have to worry about race-conditions, deadlocks, and all the other associated hairyness of multithread/multiprocess programming.
Hope this helps!
-j
I just wanted to add a few things to what hplus said.
One thing you should watch out for is how often your clients sends a packet to the server. For instance, if 10 players decides to click the screen a gazillion times a second, it may flood the server (note: a large number of individual, physical UDP packets, although small, may still cause problems for the server -- at least in my testing it has).
The easiest thing to do is just to limit the amount of clicks the user can do a second.
However, another problem that crops up is that if you use UDP (and I think you really should), then the packets may not arrive in time. What if a player clicks on location X and then quickly clicks on location Y. The server may see it as "player clicks on Y then X."
You can go into all those mechanisms for handling in-order delivery, but if it's the end result you're after (ie. what was the last position the user clicked on?) then an easy way to solve this is to simply send the current click position at regular intervals to the server. The added bonus of this is that it solves the first problem (the gazillion click problem).
Also, I strongly advise that you do not use threads so you do not have to worry about race-conditions, deadlocks, and all the other associated hairyness of multithread/multiprocess programming.
Hope this helps!
-j
Author
ok thanks, but if i use UDP alone how do I guarantee that some packets like chat arrive?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement