I am building my client/server realtime MMO game using websocket which is based on TCP. My game will be server authoritative and will use non-lockstep. That means all game logic (not graphical) will run on the server and players can join and leave the game any time they want.
Although I have read the Valve Network model and Quake 3's snapshot architecture and all the entity interpolation stuff on http://gabrielgambetta.com/, I am not very clear about the actual communication between the server and the clients because the models are specifically targeted against UDP transport.
One question is that do I still need to synchronize the ticks on clients and the server if I use websocket? So far as I know, TCP guarantees that the packets are sent orderly and if part of the packets are lost they will be resent. With this in mind, the state (of other players) on the client should always be one tick before the state the server is ready to send out to the client. Please correct me if I am wrong. And the server will probably need to maintain a queue to store all the input commands the client just sent out. On the next tick of the server, the server executes the input commands and send out new states to the client.
So I imagine the process should look like this:
- client send input commands to the server =>
- server receives commands and queue the input commands =>
- on next tick server update the game state using all the input commands in the queue and send the game state out =>
- client receives new game state and interpolate other players on client from current state to the new state.
I am not sure if this is the correct way to do it. How about the edge case? When the game starts new player joins the game after the server has run certain amount of ticks, I guess I wouldn't need to worry about the tick number? Hope someone can give me some guidance here.