Here are the options I have identified for correcting this problem:
- Change the engine's networking modules to use UDP instead of TCP.
- Rejected. This would almost certainly fix the performance problem, but would also introduce a significant amount of effort in future projects, and require a complete overhaul of much of the existing code in this one.
- Flag each shared data item on the server to indicate when the last update was sent, thereby eliminating redundant broadcasts.
- Rejected. Again, a tremendous amount of effort and significant change to the existing, functional code.
- Multi-thread the process for synchronizing the clients.
- Accepted. This was one of the first optimizations I attempted, and it provided a decent speed boost and a more friendly user interface. However, it wasn't enough.
- Reduce the number of messages sent across the network by consolidating data into larger packets.
- Accepted. This was a super easy, ten-minute experiment that provided some improvement, but it was fairly trivial.
- Decrease the maximum number of players.
- Accepted. I changed the MAX_PLAYERS constant from 8 to 4. All of my previous tests showed that each additional player had a huge negative impact on the initialization times. Four players, each with large teams, allows the levels to load in an acceptable amount of time.
- Decrease the maximum number of characters per team.
- Postponed. This change would not only improve the initialization time, but would also impact the game play considerably. The game would be much more fun if the players had fewer characters to manage, and level design would be far simpler. I will probably make this change after discussing it with the team.
So far, the change in the maximum number of players has helped tremendously. More optimization is likely, but for the moment, I'm happy with this improvement.
