I’m now testing my first pass at the new Client Reconciliation code. The bad news is that the overall performance of the application did not improve. The good news is, the application still works. 🙂
Observations so far:
- When watching the log, I can see that every command is replayed one time. Except for the very first command. So something doesn’t seem correct here. If I just issue one command at a time, like hit the fire button and wait I wouldn’t expect a client the replay any commands. The only time commands should be replayed is if they got issued before the game update from the server has been applied. In other words, the purpose of Client Reconciliation is to reapply commands that got stomped by the server update. If you are just sitting there and slowly issuing commands one at a time that shouldn’t be the case. I’m guessing there is something in my code that is running in the wrong order. Like maybe I’m incrementing the command sequence number at the wrong time or something. I’m going to have to put together a detailed sequence diagram to visualize this.
- The overall performance of the game did not improve at all. The performance issue I’m seeing is that the game “stutters” as more players connect. It seems very linear. The more connections the worse the stutter gets. The less connections the better the stutter gets. I’m wondering if maybe this is due to the increased load on the server to have to send these updates out to more and more clients. The total output for the server is going to increase linearly with the number of connections. And my messages are horrible right now. Straight JSON! I seriously need to work on serializing the messages to greatly reduce the size. Remember, the server is trying to send out one of these messages, containing the entire game state, to all the clients twenty times a second. So any size decrease in the messages should make a big difference! I need to putting some logging in to track some stats like latency between client and server and also how often update messages are being received. The order that they are received in might be useful too. Maybe with more traffic the messages start arriving out of order?
- I noticed when I was watching the log that the client can still issue ship commands even while the ship is dead. Not a big deal but I should throw that on the bug backlog. No use sending extra traffic.
Thoughts about 1 above….
As I sit here and think about it, maybe the commands are being reapplied properly. Because, when you issue a new command, you are almost certainly going to get a new update BEFORE the new command even gets received and processed by the server.
In fact, that is certainly true. Because even if the new command is received by the server almost instantly, the client is still going to be receiving updates every 16ms. I think if the latency got really bad you would even see the number of reapplies go up.
Thoughts about 2 above…
The more I think about it, the more I think that the problem is almost certainly related to the server’s ability to serve the game updates to more and more clients. I’ll bet that as more clients connect the rate of the updates being received by each client must drop. Which results in a greater and greater disparity between the local game state and the server game state. As the disparity grows, the server state over writing the client state becomes more and more noticeable. Hence the “stuttering” affect.
When there is only one player connected the server doesn’t have to send nearly as much traffic so maybe it can send out the updates quicker? And then the client will be updating so frequently that the corrections are not even noticeable to the human eye. Like if the client state is updated every 16ms for example.
Another thing I think I can improve is the particle explosions. Right now, they are included in the game state updates. But they don’t really need to be. If the explosions look different on two different clients it doesn’t matter. The explosions are just cosmetic. So by filtering out the explosion particles from the game updates I can shrink the updates.