Is it possible to use TCP protocol for the game server?

Question

Game development

Wrote a simple server on TCP sockets using WinAPI. Now the code is just synchronization, in the style: clients send a packet with their character data, it is sent to everyone else, and clients update the position of this player on their own.

But I ran into such a problem, even taking into account the fact that the server performs this action every 8ms, in the game itself, the movement turns out to be too jerky (with the same period between jerks). And the delay between packets is clearly more than 200 ms.

From this the question arises, is this a drawback of TCP, or is it more likely that the code is crooked? (I have an assumption that using TCP, there is some kind of check for acceptance of the packet, and this already means waiting for a response, and this may already be 20-300 milliseconds. And so on each client in the mailing list. )

Answer 1

Firstly, collect statistics on frames, look at the graphs, almost certainly these will be periodic peaks with an excess of data delivery time
There should not be a fixed pause between frames, the correct approach is to note the time, send a request over the network, process it and then calculate how much time left to wait
Your approach is like playing on a server using remote control, the server calculates the entire state of the world, and the clients receive the full state of the world at the time (and for optimization, only the part that is needed for display). Lags in this case are the most noticeable and difficult to exceptions.
It is necessary to add behavior to the game processing logic if the packet delivery time has exceeded the allowable limit (your 200ms), and here it turns out that the correct implementation is when the client thinks out the behavior (for example, the character continues to move from the previous frame) and when the real information still reaches, the state of the world (more precisely, its part - the pawning object and the rest associated with it) rolls back to the correct state. For the player, it looks like a crack, the character is thrown back.
Just thinking logically, you will understand that synchronizing the whole world turns out to be a vicious and inconvenient practice, high network traffic (especially on the server as a square of the number of players) in itself becomes the cause of lags and you can come to the following logic:
* all clients duplicate the functionality of the server in calculating and validating the behavior of objects (an exception, results that are critical for gameplay based on 'random', this will have to be left to the server)
* the server must act as a validator, an arbitrator, from which clients ask whether all participants are correct behave, and in fact and logic - the server will be another client, with the function of establishing connections (connection) between clients
* It is enough for clients and the server to send information about actions leading to changes in the world, there is no need to send coordinates for each frame, if enough send pressed buttons (more precisely, commands for actions - start moving, stopping, starting turn, end turn, shot, etc.)
There are actions - critical to efficiency, on which the correctness of calculating the state of the world depends, and there are those that are responsible only for the visual component, for example, turning the character's head, which, for example, he does when moving the mouse - visualization, it may be late and not be accurate, but at the moment of the shot, it is necessary to send accurate and timely information about the angle of rotation
* clients must think out each other's actions, some kind of algorithm should be, in a simple form - continue the previous movement, but it is better to manually determine or collect statistics for each type of event and set your own logic (for example, a turn will continue, but a second shot is not fired)
* of course, the functionality of synchronization of the state of the world does not go anywhere, at least for the initial filling of clients, for validation and periodic restoration of the state due to errors in the network protocol
In this scheme, information about the actions of clients can be sent directly when clients connect to each other directly , if possible, unfortunately, few games implement this and act by brute force, and even physically nearby players will receive the state only through a server located far away.
With this implementation, it is no longer so important whether tcp or udp is used, more precisely, the algorithm must allow that data may be late, arrive at the wrong time or not arrive at all, which means udp becomes an ideal option.
But most importantly, network traffic in such a scheme is significantly reduced, because literally only the pressed keys and occasionally the hash sum of the state of the world are sent to validate their correctness (all clients and the server must compare each other's states at the end of each frame, for example, by calculating the hash sum of the sorted objects , all or according to some criterion, for example, those falling into the matrix cell by coordinates, if there have been changes)

Answer 2

200ms is a lot.
It is believed that 20-40 ms is enough for shooters. Less is enough for a pro-championship in LAN.
At the same time, 20-40 ms is when sending a kilobyte packet.
The question is what do you send, how often and how many clients.