A slow weekend, nothing much done on Civil, but I intend to get some stuff done today. The source has been neglected for a while and with a few months distance to it I can see some things I want to clean up. The graphics could be separated a bit better in "setup dialog graphics" and "in-game graphics". Those two share very little apart from some mouse pointers, so they should IMHO be separated.
Sourcewise I started looking a bit at the new server that has to be created. It'll be brutally simple and just contain the main game engine and a minimal amount of extra code to provide for the necessary networking system to be set up.
I'd also like to clean up the setup dialogs a little bit to make them clearer from a UI perspective. The data that is shown on each dialog isn't always that clear and the player can be a bit confused at times. This may also have to wait for a while until I have the main game up and running again.
I've been thinking a bit about the RTS engine, and come to the conclusion that it doesn't need to be as "realtime" as many other engines. One second in the game propably simulates 1-10 seconds real time, and there isn't too much that happens on a strategic scale in 10 seconds. Thus the engine can propably do its updates only about once a second and the players can see units perform actions at a maximum of once per second. Having the engine calculate updates once a second also takes away some of the effect of network lag. One player always has to connect to the other player's computer to play, and thus is at a network latency disadvantage compared to the player that has the server locally. But if the server performs updates once a second it has some time to receive the orders from the remote player too. Of course, if the order misses the current calculation turn it will be mercilessly delayed for one second. If this is very bad, I don't know.