Beginning with sockets...
Author
Hello everyone! :-D
Alright... I have a question. I'll do a game that is sort of like Counter Strike and MTA, many clients connect to a server and they kill each other, etc... :-)
My question is, how should I design it? I've never done network programming before, should I do it so that each time the character moves, it sends the information to the server, then the server sends the information to all of the other clients, and the character appears on the screen... You know, if I do all the movement handling within the client, the user may cheat with some memory hacker or something... Or no? How should I do it? Thanks! ;-)
BTW: Is DataReel a good socket lib?
One absoulte method is that the server should not send all the information that it recieves from all the other players. Client A that is in one location of the map can care less what Client B is doing on the other side of the world. Bad example, since I am sure that the it would be nice for the human player controlling Client A know where everything is but it is impossible to keep updating all the clients all the time with everything.
The server should only give the client the needed information to basically render the scene. Now a problem also arises when there are several hundred objects in the area that need updated. In these cases, prioritize what needs sent out to the player and send little bits of information to the client during each update, this will take some trial and error testing.
As for the client, there is a term for that which you can google but right now it escapes me. Dead Reconing comes to mine but I am not sure if that is it. but you would allow the client to accept all the movement input into a buffer and assume that the server has verified it as a possible move. Also send the move to the server. while the server is processing that move you can still move around etc. but when the server says that you should not be here or you cannot do that here, you look at the buffered moves and roll back the commands back to the last good input.
Hope this helps.
The server should only give the client the needed information to basically render the scene. Now a problem also arises when there are several hundred objects in the area that need updated. In these cases, prioritize what needs sent out to the player and send little bits of information to the client during each update, this will take some trial and error testing.
As for the client, there is a term for that which you can google but right now it escapes me. Dead Reconing comes to mine but I am not sure if that is it. but you would allow the client to accept all the movement input into a buffer and assume that the server has verified it as a possible move. Also send the move to the server. while the server is processing that move you can still move around etc. but when the server says that you should not be here or you cannot do that here, you look at the buffered moves and roll back the commands back to the last good input.
Hope this helps.
Well, I am just taking a stab at this, but feel free to shoot holes through my theory.
The server should ultimately "know" which way your camera is facing, and from that information you should most likely only send updates that are relative to the person's camera (frustrum) right? This would eliminate the problem that existed in Diablo 2, and to an extent Counter-Strike. You are going to base sounds by distance right (e.g. player footsteps, gunshots, etc) you could do the same thing about player movement updates. That would put some more of a strain on the server I suppose, but in the end it might be worth the price.
If you decide to break away from the traditional Client-Server model, and move towards a P2P model you could have the clients sending movement updates to the relative players. So the client could base their player movements by the other clients (multiple) updates. This would of course take a lot more logic, testing, and planning but its just a thought. I would personally stick the the Client-Server model unless you're just testing stuff out for giggles.
The server should ultimately "know" which way your camera is facing, and from that information you should most likely only send updates that are relative to the person's camera (frustrum) right? This would eliminate the problem that existed in Diablo 2, and to an extent Counter-Strike. You are going to base sounds by distance right (e.g. player footsteps, gunshots, etc) you could do the same thing about player movement updates. That would put some more of a strain on the server I suppose, but in the end it might be worth the price.
If you decide to break away from the traditional Client-Server model, and move towards a P2P model you could have the clients sending movement updates to the relative players. So the client could base their player movements by the other clients (multiple) updates. This would of course take a lot more logic, testing, and planning but its just a thought. I would personally stick the the Client-Server model unless you're just testing stuff out for giggles.
The problem that also lies with p2p is that the more code that you place on the client to do the work. The easier it is to hack or cheat in the game, it is always recommended to do as much on server side as you can. As well with p2p you said just the relative ones. Meaning the ones close by? How would that work though when someone goes out of range, how do they know when they are back in range without continually sending the updates to say where they are? Therefore your not helping or limit anything. Though I could be wrong and someone will most likely say that it is very possible.
The client says to the server, 'I'm moving over here.'
The server figures out whether or not that's actually possible based on where it knows the client to actually be.
If it is, the server relays the information to any other clients that are close enough that they need to know about it (no need to tell someone on the other side of the map, they'll never know the difference).
Otherwise, the server says to the original client 'You are really here.', so that the client can get back on track, assuming it was an honest mistake because they some how got out of sync, and that they weren't trying to be malicious.
The server figures out whether or not that's actually possible based on where it knows the client to actually be.
If it is, the server relays the information to any other clients that are close enough that they need to know about it (no need to tell someone on the other side of the map, they'll never know the difference).
Otherwise, the server says to the original client 'You are really here.', so that the client can get back on track, assuming it was an honest mistake because they some how got out of sync, and that they weren't trying to be malicious.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
