On 2/17/2019 at 12:04 AM, Hashbrown said:
If my understanding is correct, what kind of games can I reliably make with Websockets? Is the performance of websockets too bad for fps, rts, or real-time rpg games?
The big issue with TCP (and therefore also WebSocket) is retransmit time when there are network errors.
When data is flowing and there are no network hiccups, which on most networks is the situation most of the time, the data will flow smoothly.
When there are network hiccups, which can happen with network congestion, or with electrical noise, or with other issues, the problem is how data gets retransmitted.
Since these are a stream-based socket they cannot advance until that data is transmitted. The data flow will stop until the missing data has arrived.
The retransmission timeout (also called RTO) is initially 3 seconds, then 6 seconds, then 12 seconds. That is, if you don't hear an acknowledgement after 3 seconds the data is retransmitted, then again after 6 more seconds (about 9 seconds total), then again after 12 seconds (about 21 total) then wait about 12 more seconds (about 33 seconds total) before declaring the connection dead.
Contrast with UDP, where you can continue with missing data, and you can incorporate techniques to automatically retransmit data with every message until acknowledged, or not retransmit non-critical data, or to do other behavior including implement your own RTO similar to what TCP does.
Exactly how big the issue is depends on the details. Can your game design and implementation cope with a 3-second stall? Does it saturate the network, increasing the likelihood of stalls? Will your players be on networks that are more prone to communications issues?