I hit what I consider an important development milestone the other day: I finally got both saving and loading working for complete StageMap (that is to say "level" or "stage") files.  Once I had that in, I adapted it into an export functionality for generating "finalized" game map files (though I've been considering coding in the slight difference in functionality that it will take to load these files back into the editor).  That means that I'm finally in a position that I could actually touch the game engine.  Of course, I get that done and I immediately decide I need one more feature (which will break everything I've done) before I'm ready to actually go to work on loading data into the game.

See, right now, everything is on a 2D plane.  Which is fine, except that I'd kind of like elevators and catwalks.  Which means that I need to be able to represent space in 3D.  That's not that hard -- mostly I have just have handle the map as a set of 2D planes stacked on each other.  Strictly speaking, the data structure to represent that isn't any harder than what I've already got; I'll just add another extent to the Boost::Multi_Array that underlies the map.  However, that change is so basic and far-reaching, it affects every place that StageMaps are modified, created, saved, loaded, or rendered.  So it's really just a lot of work, and it won't give me an immediate reward, because I won't actually want to do anything with multilayer maps for a long time.

Rendering is its own special problem that I'll have to figure out.  It's easy enough to do stuff with a z index less than the current layer: render it all, but behind the current layer with all the usual culling.  Stuff with a z index greater than the current layer is the hard part.  Cat walks should probably be rendered, and just go alpha-transparent when "important" things are under them.  But a full floor above the player should simply be invisible.  XCOM did it by just making everything above you invisible unless you moved your view up to that level.  I don't think I can get away with that, unless I also go to being a turn-based game (jury's still more or less out on that, but I'm leaning toward real-time).  (That being said, it's probably how the editor will work, at least for now, but that's okay.)  Now consider the case where the character is crawling through a vent underneath a floor.  That floor should probably be mostly visible, again an alpha-blending situation.  So maybe I'm looking at needing to have each tile have a property on it which controls whether it's always displayed, or only shown when its visible.  I don't like that solution, but I can't think of anything better at present.  Fortunately, I'll have some time to figure that out; other things, like walls that block movement -- and movement -- are much higher priorities.

I also need to add in some more administrative things, like version control on the map files.  Then the editor will be able to adapt and update existing map files and I don't have to worry about trying to load a testing file and breaking everything.  If I get in on that now, it won't be that bad to implement going forward.

In any event, I'm happy to have taken what I see as a huge stride forward after getting back to programming for just a couple days.  I'd been looking at trying to get LLVM's Clang compiler working, since it's supposed to be faster and generate more useful error messages than GCC, but so far, that's been a giant waste of time.  Getting Clang to work at all on Windows is something of a chore; and I've had zero luck getting it to know where my standard libraries are, or at least where all my standard libraries are -- sometimes I can find some of them.  While Clang's largely turned into a dead end, it got me messing with my programming again, and as a result, I got some forward motion on TD.