---------------------------
"communists eat little kids." -The Alchemist
🎉 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!
First Person Something Something
Author
Using winsock, how would I send positional data and such without flooding the port? How would I time it and such. Also, how would I send out pings without using too much bandwidth? The speed of sending the data over a phone line is very important also.
Oh yeah. I''m also using quadratic bezier curves to remedy the lag
---------------------------
"communists eat little kids." -The Alchemist
---------------------------
"communists eat little kids." -The Alchemist
I wouldn''t claim any experience, but I know of one thing for sure : it''s much more effective to send delta than actual positions at regular intervals. It seems, the way you ask the question, you are not thinking about that, so I just remind you
Hope it helps
Hope it helps
Author
I was thinking of that, but then I remembered how easily the game would get unsynched. Maybe I''ll have to do both. Anyhoo, how should I do this? Should I just send it out every second or something or should I do it based on the given bandwidth?
---------------------------
"communists eat little kids." -The Alchemist
---------------------------
"communists eat little kids." -The Alchemist
I would recommend sending state changes. For example, in the case of a first person shooter, you have the basic state changes:
1) Character movement
- jump/crouch
- walk forward/back/left/right
- run/walk
- object collision (lava, water, powerups, other characters)
2) Weapon firing
- projectile/nonprojectile (notice how bullets in Quake automatically hit, whereas rockets, etc must collide with something in order to cause a damage reaction)
3) Level object changes
- powerup spawn
- monster spawn
- lifts/doors/switches updates
4) Character state changes
- character death
- character spawn
- character login/logout
You don''t really have to send any of these events n times per second. Simply fire off events to the server as they occur. Send data packets to each client as they come in. This way, you aren''t buffering data and getting per-second slowdowns (for folks with slower connections).
MatrixCubed
1) Character movement
- jump/crouch
- walk forward/back/left/right
- run/walk
- object collision (lava, water, powerups, other characters)
2) Weapon firing
- projectile/nonprojectile (notice how bullets in Quake automatically hit, whereas rockets, etc must collide with something in order to cause a damage reaction)
3) Level object changes
- powerup spawn
- monster spawn
- lifts/doors/switches updates
4) Character state changes
- character death
- character spawn
- character login/logout
You don''t really have to send any of these events n times per second. Simply fire off events to the server as they occur. Send data packets to each client as they come in. This way, you aren''t buffering data and getting per-second slowdowns (for folks with slower connections).
MatrixCubed
Author
heh. I kinda wrote those down in my design docs already. Anyhoo, I wanted to make sure that I didn''t bog down the server because I was sending data that much. Whatever. It looks like I''ll just have to try it and see for myself
---------------------------
"communists eat little kids." -The Alchemist
Anyhoo, I wanted to make sure that I didn''t bog down the server because I was sending data that much. Whatever. It looks like I''ll just have to try it and see for myself ---------------------------
"communists eat little kids." -The Alchemist
I guess if you don''t want to get unsynched, you''d ''simply'' make an update of the game state every so and often by sending absolute values ?
Or you can make good predictions algorithms to compensate the problem. (method used in most FPS for movements).
But at least one thing is sure, using only delta events (that is, sending only variations of states when they occur, rather than absolute states values regularly) would save you net traffic when nothing is happening ... maybe though, you would get increased traffic when everybody is acting at the same moment.
One thing I was thinking about recently, what about sending lots of absolute values at the beginning of the game, and then refereing to them during play using simple identifiers ?
This owuld be very similar to the new concepts introduced in the Halflife SDK 2. Rather than sending a string saying ''play the sound file SOUND.WAV'' you''d have a label called PLAYSOUND on the client that would, when called, play the sound SOUND.WAV
This would greatly diminish the amount of traffic, and be consistent with the philosophy of using lots of look up tables when you have predicatable events ...
waddaya think of that ?
Or you can make good predictions algorithms to compensate the problem. (method used in most FPS for movements).
But at least one thing is sure, using only delta events (that is, sending only variations of states when they occur, rather than absolute states values regularly) would save you net traffic when nothing is happening ... maybe though, you would get increased traffic when everybody is acting at the same moment.
One thing I was thinking about recently, what about sending lots of absolute values at the beginning of the game, and then refereing to them during play using simple identifiers ?
This owuld be very similar to the new concepts introduced in the Halflife SDK 2. Rather than sending a string saying ''play the sound file SOUND.WAV'' you''d have a label called PLAYSOUND on the client that would, when called, play the sound SOUND.WAV
This would greatly diminish the amount of traffic, and be consistent with the philosophy of using lots of look up tables when you have predicatable events ...
waddaya think of that ?
Author
Jesus. I didn''t know fps engines wrote so much crap in their packets! All I do is send out a byte representing a command and the parameter which is most likely compressed somehow.
Length of packet(2 byte)
Command (1 byte)
Other Data (dynamic)
Anyhoo, what I''ve got working so far is absolute positions. I don''t see how delta values would lessen trafic any less since they are both 12 byte vectors and is only being sent when the player is moving. The prediction methood that I''m planning on using is described here. Anyhoo, I think I solved my problem already. I just realized that the main thing that will be hard to do it the whole positional data. Most of the bandwith that is going to be used is from the positional data. Pings only occur every 5 seconds. Other things such as chat messages are only small packets and very unnoticable slow downs. I can''t think of anything else at the moment though...
---------------------------
"communists eat little kids." -The Alchemist
Length of packet(2 byte)
Command (1 byte)
Other Data (dynamic)
Anyhoo, what I''ve got working so far is absolute positions. I don''t see how delta values would lessen trafic any less since they are both 12 byte vectors and is only being sent when the player is moving. The prediction methood that I''m planning on using is described here. Anyhoo, I think I solved my problem already. I just realized that the main thing that will be hard to do it the whole positional data. Most of the bandwith that is going to be used is from the positional data. Pings only occur every 5 seconds. Other things such as chat messages are only small packets and very unnoticable slow downs. I can''t think of anything else at the moment though...
---------------------------
"communists eat little kids." -The Alchemist
The table idea is great and can save bandwidth. It''s a form of compression really, but rather limited to a few cases of static predefined events. The majority of the data will proably be dynamicly created state and event data created by the game, which due to their size and delivery requriements can''t be compressed well with the current technologies( say about 100 bytes having to be updated at 15 ups). It''s a difficult problem, FPS games have to update the clients enough to maintain consistency between the clients but cant use any of the call back schemes (homegorwn guarentee UDP delivery protocols) or TCP_IP due to the latency overhead, so to compenstate for potential loss they constantly send state updates to the clients. This isnt such a big deal as bandwidth is increasing all the time. To combat latency they implement client side prediction algorithims, client side event authority (such as firing a shot etc..), server side interperlation and retroactive event schemes (where event on the server can be tested against the past game states). Many of these techniques require a high accuracy timmer synchronziation scheme. All very intresting stuff and difficult to implmenet well. Good Luck.
-ddn
-ddn
Author
Tables? How would I apply this trick? Am I doing it already?
---------------------------
"communists eat little kids." -The Alchemist
---------------------------
"communists eat little kids." -The Alchemist
I think he is refering to the events I was talking about that have been implemented in the latest Halflife update.
BAsically, players have on their side a table of events that are a simple ID number, and that matches a long command (like PLAY WAV "SOUND.WAV",0,12) whatever ...
It''s basically a lookup table. All the trick is to discover what kind of event is frequent.
My idea would be to make this dynamic, by recording every event, and if they happen more than once, give them an ID so that they can be reexecuted later with a smaller use of bandwidth.
youpla :-P
BAsically, players have on their side a table of events that are a simple ID number, and that matches a long command (like PLAY WAV "SOUND.WAV",0,12) whatever ...
It''s basically a lookup table. All the trick is to discover what kind of event is frequent.
My idea would be to make this dynamic, by recording every event, and if they happen more than once, give them an ID so that they can be reexecuted later with a smaller use of bandwidth.
youpla :-P
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
