1
\$\begingroup\$

I read this: How do I handle packet loss in a client-server network model?

...But I'm looking for more advice.

Currently I'm implementing my own lazertag vests. I'm programming hardware (8051 microcontroller) with radio links. Currently the speed is 56kbps but I might have to lower it to 38kbps for longer range. Why old hardware? To save me money. Yes, I'm currently part of the "working poor".

Ok, so like other systems, my game will also be run on a client-server model. When the game starts, networking is done UDP style and is meant to happen as follows:

1. Server sends 1st client his game stats so the vest responds accordingly
2. 1st client responds with information on what client(s) shot him
3. Server sends 2nd client his game stats so the vest responds accordingly
4. 2nd client responds with information on what client(s) shot him
....
n. Server sends last client his game stats so the vest responds accordingly
n+1. Last client responds with information on what client(s) shot him

and the process repeats for at least 20 players.

I'm not concerned with stats output from the server because the same info for a client is repeatedly sent out until the client sends a request of some sort back to the server.

But what I'm concerned with is the client being able to send his request to the server and recognizing the server received it.

For example, if player 1 got shot by 3 people, then when the server sends data about player 1 to player 1, then that player will respond to the server with bits indicating that he got shot by the 3 people, but I need to create a reliable way for the server to receive this message without loosing speed.

Here's my ideas so far:

  1. Make the server designate a special bit value that the client must use when sending his data to the server and if the client can't provide this bit value with the data then the client will stall and repeatedly send the same data until the server receives it. Problem with this is that it could increase chances of mis-fires in the game and it could slow down the rate in which the client can fire. (yes I'm trying to synchronize much of the game to when the packets arrive from the master since I don't want anyone with a stolen piece of hardware to be able to use the vest properly)

  2. Have the client send back the same packet two or more times in a row. Through experimentation this seems to work somewhat better but then it forces slower speed since more bytes are being processed.

  3. This is the worst idea in my opinion but I'm putting it out here as an option: Ignore the packet. This is worst because if other clients shot this one client then no one scores points and each client's accuracy will drop when it is not supposed to.

I thought of reducing the packet size but I can't go too low or the required data won't get through in a reasonable time frame.

Any ideas how I should tackle this problem? I don't want players to feel they're shooting others right on target only to find out they're scoring nothing and I don't want the victim to gain unlimited invincibility either when its not deserved.

\$\endgroup\$
  • \$\begingroup\$ I think in your case to ensure good game experience the best approach is to factor packet loss in gameplay keep the latest state of player in the vest so that the player is deactivated/killed at the right time if it doesn't happen often then its ok if the kill will be confirmed later? Also, have the server listen for events and broadcast all player stat on a separate channel. \$\endgroup\$ – amritanshu Aug 24 '18 at 5:56
  • \$\begingroup\$ Sad news is I have only one wireless channel and memory space is low. Ill be lucky if I have 100 bytes free since the chip I'm using is at89s52 microcontroller. \$\endgroup\$ – Mike Aug 24 '18 at 13:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.