I didn't want to run the graphics thread as fast as possible as this is a 2D turn-based game and I only need the graphics to be 'fast enough'. An alternative might have been to set the graphics theead to update periodically (eg. 10-20 times a second) but to acquire a global lock first so that there weren't issues with accessing character positions and the like, but that doesn't really affect the implementation of the AI thread which still has to signal every time it's finished moving a single character. But, apart from that signalling, that AI routine is nice and linear, just a few nested for loops. No event queue, no storing paths with the character to be consumed over several frames, just one-dimensional code in the good old style.
And that's when it hit me... implementing this sort of thing would have been trivial back in my BASIC days. Everything would be stored in global variables, so I'd have all the persistence I wanted (ie. no pesky locals going out of scope!) and I could just use goto to switch between the 2 routines at will. Bliss! Of course, I couldn't bring myself to write code like that any more even if I wanted to. I happen to have grown quite attached to object orientation, local variables, and so on. But it's quite interesting how advances in technology make some things easier and others more difficult. For example, it seems like blitting an image to the screen using DirectX is more complex than it was 5 years ago. Yet you'd think these things would be made simpler as time goes on.
I'd be interested in learning how other people handle things like AI turns in turn-based games such as Civilisation etc. The separate thread for AI seems to be a common theme these days so maybe that's what most people do.
