What kinds of packets do you send?
Author
For in game play what kind of packets do you send?
For example: If the user presses the up arrow to move forward do you have the client side create a packet that has a specific request (to move) or do you simply send a packet with the key that was presses as input and have the server determine what is being requested?
For now I''m planning on a packet of type PLAYER_REQUESTS_MOVE
so that when the server sees that packet it will know how to handle it instead of having to decide what is to be done. This would take a bit of work off of the server I think.
So in theory, my program will have a different packet type for every single action possible in the game and will send the specific action packet to the server. This would aid in a lot of things. Like hotkeys. Can cast a spell either by pressing a keyboard button or by clicking an icon. Client can determine the action and send the exact action to the server.
The more I think about it, this seems like the preferred method to me. Still want opinions however.
Thanks,
Webby
Thing is, you don''t want to have the server mess with the various combinaisons and permutations of keyboard remappings, sensitive repeats, sticky keys for the dexterity impaired, and multi-language OS issues. Keep it simple and debuggable, regardless of the client machine.
-cb
-cb
I''d completely avoid having the server mess with anything related to actual input.
The server should only handle things at a level as high as possible. This way, you lessen the load on your server, which is important even if you want to use low player numbers per server.
I''d recommend you at the very least send the (request move) packets, and I''d also recommend that you take it a level higher, by allowing the client to calculate the movement, and then send a (player moved) packet, including all the details. This way, you could have the server just check the packets to make sure no one is cheating. More importantly, this way you can start moving the client side before the server ever receives the packet, let alone answers it. This would provide much smoother play, and would lessen your dependency on the actual connection speed.
Hope this helps
.
Sirob Yes.»
Footman, at large.
The server should only handle things at a level as high as possible. This way, you lessen the load on your server, which is important even if you want to use low player numbers per server.
I''d recommend you at the very least send the (request move) packets, and I''d also recommend that you take it a level higher, by allowing the client to calculate the movement, and then send a (player moved) packet, including all the details. This way, you could have the server just check the packets to make sure no one is cheating. More importantly, this way you can start moving the client side before the server ever receives the packet, let alone answers it. This would provide much smoother play, and would lessen your dependency on the actual connection speed.
Hope this helps
. Sirob Yes.»
Footman, at large.
Author
Thanks CB. There''s a few reasons I hadn''t thought about.
So the other part of the question. Do you create a structure for every type of packet possible? Or do you use a limited number of packets inside of which you set flags depending on what you are sending?
Right now I am using a custom packet for every command.
Move forward and move backward would each be unique packets so that when the server gets them it will be easy to figure out what needs to be done.
Thanks,
Webby
So the other part of the question. Do you create a structure for every type of packet possible? Or do you use a limited number of packets inside of which you set flags depending on what you are sending?
Right now I am using a custom packet for every command.
Move forward and move backward would each be unique packets so that when the server gets them it will be easy to figure out what needs to be done.
Thanks,
Webby
>Right now I am using a custom packet for every command.
That's what I do too. I have about 50 different types of packets, each of which does a specific thing. When the server gets a packet, it has to do minimal manipulation to respond to it. I figure it's best to keep as much of that sort of work client side as possible.
>For now I'm planning on a packet of type PLAYER_REQUESTS_MOVE
>so that when the server sees that packet it will know how to
>handle it instead of having to decide what is to be done. This
>would take a bit of work off of the server I think.
I also have the client send commands rather than keystrokes (ie a PLAYER_MOVE_FORWARD packet rather than an UP_ARROW packet). I let the client figure out what was meant and send the resulting request to the server. That way the server doesn't need to know how each particular client has mapped their keys (not that I have implemented custom keymapping yet, but it's on the TODO list somewhere, heh).
[edited by - RonHiler on July 9, 2003 4:13:22 PM]
That's what I do too. I have about 50 different types of packets, each of which does a specific thing. When the server gets a packet, it has to do minimal manipulation to respond to it. I figure it's best to keep as much of that sort of work client side as possible.
>For now I'm planning on a packet of type PLAYER_REQUESTS_MOVE
>so that when the server sees that packet it will know how to
>handle it instead of having to decide what is to be done. This
>would take a bit of work off of the server I think.
I also have the client send commands rather than keystrokes (ie a PLAYER_MOVE_FORWARD packet rather than an UP_ARROW packet). I let the client figure out what was meant and send the resulting request to the server. That way the server doesn't need to know how each particular client has mapped their keys (not that I have implemented custom keymapping yet, but it's on the TODO list somewhere, heh).
[edited by - RonHiler on July 9, 2003 4:13:22 PM]
Never directly send input...even in you think your logic will sort it out at the other end it will not always(and less often than it will) happen this way.
send EVENT REQUESTS from client -> server.
send GAMESTATE EVENTS from server -> client.
An EVENT would be, by my definition, something that has occured as a result of input. As an example, never send "My player is pressing up. sort it out" send "My player requests to be moved *20 units straight ahead (an EVENT REQUEST as a *result* of pressing up.)" Meanwhile, you go ahead and move *20 units straight ahead and await judgement from the server.
*note that you would first consult your last known gamestate to check if you could move ahead 20 units in the first place.
When the GAMESTATE EVENT returns from the server it's contents must be considered the real truth because that's the gamestate that everyone else has.
Also, use UDP! If you are, good. I just see a lot of people on here that use TCP because its "better" but aren't aware of TCP's cons, such as the fact that a TCP connection can be disconnected beyond your control. Of coarse, TCP has its benefits such as being in-order and being correct, but I recomend emulating the good features yourself via a custom protocol using UDP.
Ravyne, NYN Interactive Entertainment
HTTP://nyn.studio42games.com
[edited by - Ravyne on July 10, 2003 3:38:49 AM]
send EVENT REQUESTS from client -> server.
send GAMESTATE EVENTS from server -> client.
An EVENT would be, by my definition, something that has occured as a result of input. As an example, never send "My player is pressing up. sort it out" send "My player requests to be moved *20 units straight ahead (an EVENT REQUEST as a *result* of pressing up.)" Meanwhile, you go ahead and move *20 units straight ahead and await judgement from the server.
*note that you would first consult your last known gamestate to check if you could move ahead 20 units in the first place.
When the GAMESTATE EVENT returns from the server it's contents must be considered the real truth because that's the gamestate that everyone else has.
Also, use UDP! If you are, good. I just see a lot of people on here that use TCP because its "better" but aren't aware of TCP's cons, such as the fact that a TCP connection can be disconnected beyond your control. Of coarse, TCP has its benefits such as being in-order and being correct, but I recomend emulating the good features yourself via a custom protocol using UDP.
Ravyne, NYN Interactive Entertainment
HTTP://nyn.studio42games.com
[edited by - Ravyne on July 10, 2003 3:38:49 AM]
quote:Original post by free lancer
My packets do not request. My packets demand .
OK...I just find that hillarious...Mostly because I have a friend who I can just see saying that in his usual hillarious way. So I''m gonna make a T-shirt...seriously...I''ll post pics... lol.
check back tomorrow night.
Ravyne, NYN Interactive Entertainment
HTTP://nyn.studio42games.com
quote:Original post by free lancer
My packets do not request. My packets demand .
and this is what makes for a very vournable game
OK...too busy today. Check back tomorrow.
Ravyne, NYN Interactive Entertainment
HTTP://nyn.studio42games.com
Ravyne, NYN Interactive Entertainment
HTTP://nyn.studio42games.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement