The screenshot below shows the visually underwhelming result of a few days work on the servers. Yet to me, it's a significant step forward.
Previously, the game's servers were all implemented as console applications - a watchdog, a gateway, another for authentication, another for chat (per server cluster), and a series of world servers for serving the world(s) in that cluster. The problem, of course, came in trying to debug the suckers, since they all can possibly interact with each other in some way or another, and getting one process to stop when I'm breaking into another was nigh on impossible. I guess if I'd thought through the design a bit more I'd have realised this early on, but you know, hindsight's 20/20 and all that...
To simplify things then, I modified the application class the console processes shared into something that I could integrate into a single windows application.
Now, I can:
- start this ServerHost application up with a commandline parameter, to automatically load one or more selected servers.
- use the arrow buttons to cycle through the console windows of each running server
- load or terminate servers while it's running
- load servers from a batch
- enter commands on any server's console (or on the serverhost to query the main process)
- break into the servers and have the debugger stop all running server threads.
Amusingly, I did all of this using what seems a by-now antique Win32 approach (message pump, WM_COMMAND, etc etc). I didn't want the overhead of MFC, I didn't want to mixed-mode into C# (I still wanted the servers in C++), and after all, given the servers are console apps, the user interface is 'just' a simple dialog, right?
Turns out I've forgotten more about Win32 programming than I care to admit. There was a time when it was all I was doing, all day, every day. But it's been... more than a decade? really? So just getting this little baby to this stage took more work than I expected.
But it's a baby I'm quite happy to play with now