I'm working and learning on a Grand Strategy game of the Civilisation / Paradox interactive genre, in C++, although my first goal is just to model some simple unit/ unit combat and movement on a hex terrain grid.

Now as it stands as you would expect all messages come through WndProc. Now I don't know if its because its a strategy game but I'm quickly going to end up with a profusion of states. Has the player highlighted a unit or a stack, or a hex province or a building, are they at some point in a menu hierarchy, or are they saving or loading a game. This is pretty quickly going to end up in a horrendous mess.

I was reading one of the gamenet resource articles, which I can't seem to find now, and it suggested putting the main (peek / translate / dispatch) message loop into its own thread. I don't see what this achieves, but then I don't see what use the message loop is doing at all apart from to catch a termination that couldn't be handled automatically by Windows.

So I was thinking, what would make sense to me would be to put rendering into its own thread, while the main programme logic would wait for input, process that input and then wait for more input. However, say the user clicked on a unit the thread would call a "unit selected" function and then wait for input at that point of the thread. The processing of that input when it arrived, could cause the programme to stay where it is, go down into a sub function or if the selection was simple undone pass control back up to the top. I guess this is state, imperative or menu structured programme logic. The way you would use say a scanf function. You process to certain point and then sit and wait for input. However I can't see how to marry this up with WndProc. Do I have to create my own internal buffer in some way? Can I not get a message directly?