🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Sending packets in a 2D shoot-em-up
Author
Well, my basic idea is a simple space shooter.. ie. a few players controlling ships in 2D space and shooting simple bullets.
I was hoping to use a server-client system.. Where the server has the final say.. but the clients are all running their own games in sync. ie. client A tells the server it fired a shot in a certain direction/speed etc. then the server tells the other clients when the shot was fired and from where etc.
I've thought about what kind of information I'd need to send over the network (using UDP) and that included player x/y position, direction facing, velocity, acceleration, etc.
Here is my question:
If I were to have a different kind of packet (we'll call it shotpacket) sending information about a shot fired, would it be better to keep the packet the same size as the playerpacket for some weird uniformity reason? Or just keep it as small as possible?
Thanks in advance,
Repp
Edited by - sadd3j on April 12, 2001 2:23:59 AM
Mind if I tag a little question on here?
Is it better to send a packet like "I''d like to shoot now" to the server and then have the server send packets to all clients saying "Player 1 just fired a shot at x,y heading in a,b at velocity d ... " etc
or is it better to have the client supply the information for the shot?
It would seem to me to be a bit safer to have the server keep track of everything except for input... other wise it might be possible to have a hack?
- Anyway, I''m sure this is only a realistic problem for large scale games, but perhaps there are other advantages? Perhaps less packets or smalelr packets?
Is it better to send a packet like "I''d like to shoot now" to the server and then have the server send packets to all clients saying "Player 1 just fired a shot at x,y heading in a,b at velocity d ... " etc
or is it better to have the client supply the information for the shot?
It would seem to me to be a bit safer to have the server keep track of everything except for input... other wise it might be possible to have a hack?
- Anyway, I''m sure this is only a realistic problem for large scale games, but perhaps there are other advantages? Perhaps less packets or smalelr packets?
Mind if I tag a little question on here?
Is it better to send a packet like "I''d like to shoot now" to the server and then have the server send packets to all clients saying "Player 1 just fired a shot at x,y heading in a,b at velocity d ... " etc
or is it better to have the client supply the information for the shot?
It would seem to me to be a bit safer to have the server keep track of everything except for input... other wise it might be possible to have a hack?
- Anyway, I''m sure this is only a realistic problem for large scale games, but perhaps there are other advantages? Perhaps less packets or smalelr packets?
Is it better to send a packet like "I''d like to shoot now" to the server and then have the server send packets to all clients saying "Player 1 just fired a shot at x,y heading in a,b at velocity d ... " etc
or is it better to have the client supply the information for the shot?
It would seem to me to be a bit safer to have the server keep track of everything except for input... other wise it might be possible to have a hack?
- Anyway, I''m sure this is only a realistic problem for large scale games, but perhaps there are other advantages? Perhaps less packets or smalelr packets?
Author
Hey Flanders,
While I''m NO authority on game programming whatsoever..(I just started), what I have sketched out for my game is that I''m choosing to synchronize the clients to the server "gameclock". I''m not sure how well it works.. but it sounds like at least a rough way of dealing with lag/latency. (Of course now I have to figure out a good way to sync the clocks
)
For now I''m going to ignore safety because.. frankly, if my game is good enough to hack, I would be pretty freakin happy. (If I had a player-base and it became an issue, then I''d try and fix it)
For each client:
I send a packet every 100ms with info about the player''s position/velocity/acceleration/direction and a gameclock time.
The server accepts the packets and sends the relevant info to whichever other client (ie. only send info about other ships on the screen). This packet wont be guaranteed since there are 10 per sec going out.
Now let''s say client A wants to fire.
It sends the server..
"I took a shot from x/y, facing direction theta, moving at z speed at gametime t"
I would probably flag this packet as important (guaranteed) because I wouldn''t want to start losing missiles n bombs.
The server will get the packet and probably do it''s own calculations to see how the shot fits into gametime and then sends information about the shot to the other relevant clients (those close to the shot)
client B picks up the shot packet and sees
"Ah, client A shot at gametime t" and then calculates where the shot would be now relative to gametime. So let''s say the connection is really laggy, client B doesn''t see that client A shot until 2 seconds after it was shot.. then client B calculates where the shot would be as if 2 seconds had passed. This will mean missiles appearing out of nowhere if the net is bad.. but what can you do?
If it works like Im planning (which Im betting it wont), then in theory I wont ever have to send info about the shot again over the network. Since the client knows where the missile should be, it''ll just do all the calculations client-side. Of course, the server will also be keeping track of all the objects and this is where the collision-detection for weapons will probably occur.
There''s a lot of room in there to check for validity.. the server will always have the authoratative gamestate for any conflicts.
Please post feedback!
-Jon
P.S. Also since Im using a gameclock, if packets get to the server out of order, it can disregard older ones so we dont have missiles going backwards
While I''m NO authority on game programming whatsoever..(I just started), what I have sketched out for my game is that I''m choosing to synchronize the clients to the server "gameclock". I''m not sure how well it works.. but it sounds like at least a rough way of dealing with lag/latency. (Of course now I have to figure out a good way to sync the clocks
)For now I''m going to ignore safety because.. frankly, if my game is good enough to hack, I would be pretty freakin happy. (If I had a player-base and it became an issue, then I''d try and fix it)
For each client:
I send a packet every 100ms with info about the player''s position/velocity/acceleration/direction and a gameclock time.
The server accepts the packets and sends the relevant info to whichever other client (ie. only send info about other ships on the screen). This packet wont be guaranteed since there are 10 per sec going out.
Now let''s say client A wants to fire.
It sends the server..
"I took a shot from x/y, facing direction theta, moving at z speed at gametime t"
I would probably flag this packet as important (guaranteed) because I wouldn''t want to start losing missiles n bombs.
The server will get the packet and probably do it''s own calculations to see how the shot fits into gametime and then sends information about the shot to the other relevant clients (those close to the shot)
client B picks up the shot packet and sees
"Ah, client A shot at gametime t" and then calculates where the shot would be now relative to gametime. So let''s say the connection is really laggy, client B doesn''t see that client A shot until 2 seconds after it was shot.. then client B calculates where the shot would be as if 2 seconds had passed. This will mean missiles appearing out of nowhere if the net is bad.. but what can you do?
If it works like Im planning (which Im betting it wont), then in theory I wont ever have to send info about the shot again over the network. Since the client knows where the missile should be, it''ll just do all the calculations client-side. Of course, the server will also be keeping track of all the objects and this is where the collision-detection for weapons will probably occur.
There''s a lot of room in there to check for validity.. the server will always have the authoratative gamestate for any conflicts.
Please post feedback!
-Jon
P.S. Also since Im using a gameclock, if packets get to the server out of order, it can disregard older ones so we dont have missiles going backwards
An idea for you: To cut down on traffic and reduce the probability of loosing packets, you could have the client send his location, the time_stamp, the destination of the missile, and the type of missile. The client then assumes that the server got the information and knows how to enact the trajecotry of the missile on the server side and send the information to the other clients.
The client then enables its drawing command and begins to shoot the missile to the target. The client doesn''t need to tell the server about the position of the missile because, based on the timestamp and the algorithm governing the missile, the server knows where the missile is going and who/what it will hit. The server can then advance calculate collisions based on intended ship, missile, and object trajectories and notify the client if another player gets in the way and gets shot.
Just some thoughts. It might be a good thing for me to program up to test my client/server code and UI code before applying it to the big project.
Later,
RandomTasl
The client then enables its drawing command and begins to shoot the missile to the target. The client doesn''t need to tell the server about the position of the missile because, based on the timestamp and the algorithm governing the missile, the server knows where the missile is going and who/what it will hit. The server can then advance calculate collisions based on intended ship, missile, and object trajectories and notify the client if another player gets in the way and gets shot.
Just some thoughts. It might be a good thing for me to program up to test my client/server code and UI code before applying it to the big project.
Later,
RandomTasl
How about you have a windows type messaging system. For example your packet is a struct like so:
So when you send the packet you can set the strMsg as "rocket" for example and use the other param for whatever. Of course you would need more params but that is just a simple example of what you could do.
struct {char strMsg[20];char strParam[20];}; So when you send the packet you can set the strMsg as "rocket" for example and use the other param for whatever. Of course you would need more params but that is just a simple example of what you could do.
How do you go about sending a structure of data via a socket? I thought sockets just send character information...
I''m very new to network programming, so any information would be appreciated.
I''m very new to network programming, so any information would be appreciated.
A character is one byte (at least on every PC C/C++ implementation I''ve seen) so make a character array the size in bytes of the data you must pack into it, then dump all the stuff in there at the appropriate offset (in characters/bytes) from the beginning of the array.
http://druidgames.cjb.net/
http://druidgames.cjb.net/
HAHA, right after I posted it, I thought about that, but I figured there must be an even easier way.
Thanks for the response though, it did clear that up.
Thanks for the response though, it did clear that up.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
