In one day I managed to sort of meet my goal. The server/client code knows enough to serialize and deserialize Units and Tiles. The map renderer functions enough to keep track of a reference tile, and build 1 line of the fan of the map.

Unfortunately I've uncovered a bug. Not a bug really, but one of those design oversights that make you go "UGH!" knowing your inexperience/ignorance/suckiness just cost you a lot of time and effort.

The problem:

The server code sits in its own little area of the code base. It has a non-main main, which is called by helper code when in dedicated mode, and spawned as a thread in non-dedicated. I abstracted communication out, so both the client and server can effectively ignore what mode they're in.

Unfortunately, so did I. While they might be effectively seperate, they're not. This mainly comes into play for the event system described a few posts below. About half of the events are static "any unit that gets created, do this" events. Static events [static anything really] get shared by threads.

Oops.

At least I caught it relatively early, and at least the way I was using them caused the problem to be a duplication error, not some threaded race condition issue... I'll have to sleep on the problem a little. There should be a not-so terrible way to create thread-specific static emulation if I'm too dumb or stubborn to find someone elses'.