The launcher that I added also does one additional thing. It scans the install directory's data folder to see if there's any datasets that needs to be copied over to local user's application data folder. If there are any, and none of them exists already on the local folder, then copy them over. This serves two purposes.
First, with newer OS, modifying or creating files in the install directory in Program Files directory is a big no-no (security risks and all that). So in order to have save files work, I've opted that the entire dataset is copied over to local folder first, then the game loads from that. Saved files will be stored there.
Second, it allows you to modify the files without needing to create a backup. Just modify the files in the local folder, and the game will not overwrite it with its initial data because it already exists. If you mess something up, or don't like your changes, you can just delete the local folder and the launcher will just copy over the standard data. You can modify the game's files in the install directory if you really want to, but to revert those changes you'll need a backup, or reinstall the game.
With that in mind, I started work on having the game load the data assets using the launcher's configuration. On completion, I realized that some of the assets it's loading from are using hardcoded paths (fonts, certain graphic files, etc), and those are used in the main game menu. The game reported errors when trying to start :(
At this point, I have two choices: Fix the hard-coded stuff so they point to the correct places, or start work on a new UI system that loads the screens from XML files which in turn loads images and resources dynamically. I decided to opt for the second option for several reasons.
First, what's the point of having a 4X space game engine if you can't modify where or what the UI look like? For example, MoO 1's UI layout is vastly different from my game, or MoO 2, or other games. If you wanted to mod MoO 1 into this game, you'd have to change the game's code to accomplish that. With this system, it'd be now possible to create a MoO 1 mod without changing any of the game's code.
Second, it'd reduce the time spent creating screens and windows, since all I have to do is modify the XML files, and the game will automatically handle it. I can easily add screens and windows without having to declare them in code, then handling all the events, etc.
I'm taking it slow and will have both old and new UI systems running together. I'm about halfway done with getting the basics of the new UI up and running. After it's working, I will re-do the game main menu so that it uses the new UI system, but when you click on "New Game", it will switch over to the old UI screens.
The game will have a list of "events" or "actions" that you can attach to an UI element, allowing you to create your own screens. In fact, you can create as many screens as you want, and have each link to other screens by "ChangeTo ScreenB" commands. There will be some hard-coded stuff, such as galaxy rendering, space combat rendering, that you can call in your UI screens. By those I mean, you can tell the game to "DrawGalaxy" in a window that's 500x500 big, instead of the whole screen.
Right now, I'm just trying to add simple buttons and event handling for those. But when I get those working, other UI elements should fall in place. Also, this new UI system uses the new sprite drawing system. So those two will eventually replace the old UI system and the old image drawing process. I won't convert everything at once.
Also, my artist just finished the artwork for the Velociraptors! He will work on Nurds next. Here's a peek at one of the Velociraptors' ships: