Hey,
right now, I'm currently sending a TCP event, when shot happens to the server and server sends it to all the players by also using TCP. I'm not using UDP, because I don't want it to get lost. But I'm not feeling, that TCP is the right solution. What could you suggest?
Aiming iOS and Android, WIFI + LTE. Using kryonet. And by the way, those bullets cannot be raycast'ed, they are slow moving ones.
EDIT:
how does this idea sound like? When server is spamming update packets, add a "lastShootTimestamp". This way client checks if it changed, if it did - boom, new shot happened. Plus, I would have the time, so I could extrapolate the position. The only problem is that it will probably not work fine if shoot interval is really small...
When server is spamming update packets, add a "lastShootTimestamp". This way client checks if it changed, if it did - boom, new shot happened
When server is spamming update packets, add a "lastShootTimestamp". This way client checks if it changed, if it did - boom, new shot happened
What problem does this solve?
Separate TCP event wouldn't be needed, also less data requiring, because player id, position, angle is already being sent. But not sure, this route seems too risky and inaccurate...
What you explained, I'm doing it right now, but using TCP, that's why I'm not sure about it.
if you're making a fps or some fast paced game, udp is probably better. To add more reliability:
1) associate a 16-bit ID with each client, each client knows their own.*
2) associate a 16-bit ID with each packet, server stores last packet ID for each client
3) server sends an acknowledgement packet for each packet sent by client**
4) client sends an acknowledgement packet for each packet sent by server**
5) each time server gets a packet from client, it checks the ID against its stored ID, if no packets were missing it updates ID value, otherwise it waits a set time for missing packets before updating
6) if client does not get an acknowledgement packet within a certain acceptable timeframe, it resends packet repeatedly for a set time or until acknowledgement is recieved
7) server drops packets below the stored ID
might take some fudging to work with integer wraparound, might need to use bigger IDs based on your packet transmission rates. It might also be wise for the client to send packet requests to the server if it thinks it missed something, IE have the server have an outgoing packet ID for each client too.
* - I'm assuming this is an FPS game with less than 65,366 clients per game. If I'm wrong, it may be necessary to use a 32-bit client ID.
** - some messages might be considered unimportant enough not to bother acknowledging and resending. Acknowledgement packets also should not get their own acknowledgement packet.
Depends on what you are trying to achieve and how accurate you want it to be.
- Send shot events. Costly with high ROF. includes timestamp (should be in packet header already), shooter ID, position, direction, bullet type...
- high fidelity. Eats bandwidth / introduce lag if TCP.
- send ammo count separately to keep ammo in sync when packets are lost.
- Send ammo count / last_shot_fired_timestamp, that sort of thing.
- cheap.
- Very innacurate. It's just to make the game more interesting visually.
- Games like counterstrike need good accuracy. People will see bullet holes, so even shot randomisation will affect spray pattern and players notice that kind of discrepancy.
- Games like TF2 don't care. Minigun / scattershot firing can be simulated less accurately.
- BTW, if you use a server / client model, you don't need to be always accurate on clients, as they should be doing nothing. The server should be in charge of the entire logic (ammo, who hits who, reloads, ect...). The server needs to send what is relevant to each player. Meaning, Projectiles need to be done correctly, some hit-scan weapons as well (sniper shots), some can be simplified to save bandwidth (high ROF guns). Depending on what you think it 'relevant' for your game.
