Optimization 0: During the preparation phase, monitors have nothing to do. They do, however, receive "progress update" signals. What if we use these signals to already save information on the monitors?
Whenever something new is submitted, it's immediately transfered to all monitors. That way, when the game actually starts, there isn't much data that still needs to be send. (We "spread out" the information to keep the server faster and more responsive.)
Optimization 1: The captain has his resources constantly updated. However, its mostly small changes. It would be cheaper to only send the change in resource, instead of the whole resource list every time.
Optimization 2: Create game settings, such as turn time, map size, etc. (Prevents having to copy variables from file to file, especially as they might change)
Optimization 3: Check which information really needs to be resend every turn, and which can be inferred/saved by the client (be it a monitor or controller).
Optimization 4: Pathfinding algorithm is really fast now ... but could be faster! I declare some variables and write some statements the long way around, which could be a little shorter. It makes a big difference, because those functions are called thousands of times when pathfinding.
Optimization 5: Cache the world map on monitors. (And, if needed, on controllers.) Now it's REALLY expensive to draw the whole map the first time and keep it displayed.
Optimization 6: On the server, it's now just one HUGE file. Instead, I think I can get away with most functions being put into modules. (Create a nice folder structure as well, don't just drop the files everywhere.) The only problem could be access to the global "rooms" variable, but that can easily be passed along.
Optimization 0: During the preparation phase, monitors have nothing to do. They do, however, receive "progress update" signals. What if we use these signals to already save information on the monitors?
Whenever something new is submitted, it's immediately transfered to all monitors. That way, when the game actually starts, there isn't much data that still needs to be send. (We "spread out" the information to keep the server faster and more responsive.)
Optimization 1: The captain has his resources constantly updated. However, its mostly small changes. It would be cheaper to only send the change in resource, instead of the whole resource list every time.
Optimization 2: Create game settings, such as turn time, map size, etc. (Prevents having to copy variables from file to file, especially as they might change)
Optimization 3: Check which information really needs to be resend every turn, and which can be inferred/saved by the client (be it a monitor or controller).
Optimization 4: Pathfinding algorithm is really fast now ... but could be faster! I declare some variables and write some statements the long way around, which could be a little shorter. It makes a big difference, because those functions are called thousands of times when pathfinding.
Optimization 5: Cache the world map on monitors. (And, if needed, on controllers.) Now it's REALLY expensive to draw the whole map the first time and keep it displayed.
Optimization 6: On the server, it's now just one HUGE file. Instead, I think I can get away with most functions being put into modules. (Create a nice folder structure as well, don't just drop the files everywhere.) The only problem could be access to the global "rooms" variable, but that can easily be passed along.