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?

TCP can work OK, at least for good internet connections (wired.)

Note that, in general, you get the best gameplay if you design the rules of the game to match the specifics of your networking solution and simulation engine. There's not one solution that makes everything "Just work" -- there needs to be a compromise somewhere in the chain.

There are many other ways to do networking, though; we would need to know a little more about your particular requirements to give any better suggestions.

What platform are you developing on? Using what tools? Are you using any particular networking library, or raw sockets?

Knowing nothing else, I could recommend ENet, which will use UDP, but can also implement reliable delivery.

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

What problem does this solve?

I would recommend that you send an event from the server to each client each time a shot is fired. That way, each client can create the appropriate effects/graphics/instances.
Your packet could contain the time and position the shot was initiated, and thus create (and likely fast-forward, for hit detection) the appropriate instance.

There are many, many, ways to solve the various discrepancies and opportunities for cheating that come up here. Check out the FAQ at the top of the multiplayer and networking forum for some links.

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.