🔒 Locked

auto-adaptative net code

Started by bjogio Apr 11, 2005 at 2:22 AM 6 replies 1.1k views

Original Post

Apr 11, 2005 at 2:22 AM

In a net game in wich key-strokes are sent during gameplay (yes I know how bad is sending key-strokes) if we calculate over the time that the avg delay is N can we adapt all the source to fit this value? explanation: consider non-blocking socket [1][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ] -^ frame 1 we send keystoke caught [ ][2][ ][ ][ ][ ][ ][ ][ ][ ][ ][ ] ----^ frame 2 winsock say that the send need some other time to send the packet, we queue the value obtained at 2 [ ][ ][ ][ ][ ][ ][7][ ][ ][ ][ ][ ] -------------------^ we queue all the value 2 -> 7, at 7° frame send has finally done his work so we send all the values queued and client take care of these values for 7 - 2 frames. [ ][ ][ ][ ][ ][ ][ ][8][ ][ ][ ][ ] ----------------------^ frame 8 we begin another time this algorythm. Consider that we stop to queue value when we reach the total amount of the bytes contained in a (insert your favorite protocol here) packet in order to evitate fragmentation and that we put a inferior limit (like 2 frames in a 60 fps tipical game). What you think about this solution? I'm saying stupid things? p.s. sorry for my english and for the weird ascii notation What you think about this

doho

Apr 11, 2005 at 3:18 AM

Quote:
Original post by bjogio
In a net game in wich key-strokes are sent during gameplay (yes I know how bad is sending key-strokes)

I have sent keystrokes with a constant frequency in an 2D FPS-style multiplayer game and this actually worked great!

It's impossible to say if the technique you are describing with caching up input and then sending them in one block to decrease bandwidth is good as this really depends on how your game is structured. If you have non-realtime game and extremly tight bandwidth requirements, then it might be a good idea.

Remeber that whatever works for you is considered good. If you understand one technique very good and you'll know how to implement it, then there is no point in choosing another technieque that is considered "better". It really comes down to what works for you.

Good luck with your network programming.

bjogio

Author

bjogio

Apr 11, 2005 at 5:19 AM

sorry a question, you send the keystroke with regular frequency, so if it is 1/20 sec you send only the actual keystroke caught in that 20 frames? What about the input events that occur in the last fps - 20? You don't consider it? For you guys what's the best input that a user can accomplish? In other words how much times can a human press buttons in a sec?

doho

Apr 11, 2005 at 6:31 AM

I sent input 16 times a second.

Quote:
In other words how much times can a human press buttons in a sec?

No clue.

Nice Coder

101

Nice Coder

Apr 11, 2005 at 7:04 AM

Maybe 5, 6?

From,
Nice coder

Prototype

402

Prototype

Apr 11, 2005 at 7:18 AM

Quote:
Original post by Nice Coder
Maybe 5, 6?

From,
Nice coder

Obviously you have never seen anyone playing Hyper Olympics [grin]

MaulingMonkey

249

MaulingMonkey

Apr 11, 2005 at 7:17 PM

Quote:
Original post by bjogio
sorry a question, you send the keystroke with regular frequency, so if it is 1/20 sec you send only the actual keystroke caught in that 20 frames? What about the input events that occur in the last fps - 20? You don't consider it? For you guys what's the best input that a user can accomplish? In other words how much times can a human press buttons in a sec?

Well, people using traditional keyboards can type usually up to around 80WPM, which is 1.333 WPS - assuming the average word is about 10 characters long, which I believe quite overkill, that's approximately 13 CPS.

That said, typing with your standard QWERTY keyboard is not really a chordic use of the keyboard (that is, hitting multiple keys at the same time, although there's usually some unintentional overlap, and the occasional exception such as the shift key for CAPITALIZATION, etc...)... I'm hard pressed to think of an example that would require a full 20FPS however.

All this said, I wouldn't send raw keystrokes over the net, as then the server has to do the key mapping for the client. Although I suppose one could simply set up the key bindings on the client to map to different "virtual" keys....

bjogio

Author

bjogio

Apr 12, 2005 at 2:18 AM

no raw keys, I send a packet like this
[8][32]
in the first byte a packet identifier (1 gameplay packet, 2 load request, 3 shutdown etc), in the 32 bit integer I send packet data (with some << 1) from the game that I take from the ->GetDeviceData directinput call.
Polling (and sending) the data 16 times per sec mean that with a delay of ~60 you will not see any kind of lag right? But what about all the inputs catched in the remaining fps - 16 frames? You lost them? Queueing it and sending the queue as described by me in the first post in order to make a perfect input management is important or is an useless optimization that will not help the gameplay? In my game (not a game but an hack called fiercegear) I manage a game with very fast action. Thanks in advance for every reply.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.