There is a sort of unofficial rule about save-game functionality that I learned once, long ago, but which I still have a hard time applying: from day one of coding on your game, try to maintain the ability to save and load your game at all stages.

It's a tough rule to follow because it takes discipline and work, but it can really, really save you some effort down the road. It's a rule that, unfortunately, I haven't been following with GC. I've built some pretty complex systems and frameworks, I've fleshed out combat structures, implemented some spells and skills, but I still don't have the ability to save and load.

When prototyping a game, I have the unpleasant tendency to do lots of one-off, hand-constructed code to do things like build an enemy, build a test skill, etc... I'll construct an object and manually add components, initializing those components with hard values and magic numbers, in order to test out some aspect of the game. This tends to grow the code in a hideous, spaghetti fashion where lots of so-called temporary code infests the code-base like some kind of parasite, becoming harder and harder to eradicate.

Well, I've come to a point where I need to test some things that are getting a bit complicated, so I've decided to finally start on the saving and loading. And, as expected (and as taught to me many times in the past through bad experience) it is much harder to shoehorn saving/loading later in the process than it is to just design and build the framework from the start with saving and loading in mind. As I've pondered and thought and written pages of notes and ideas, I've come up with a plan. It's involving a relatively small yet fundamental change to the underlying component system on which the whole game hangs. It's going to take a bit of work, though.

I haven't touched the existing codebase yet; I've just forked the framework, and am testing it thoroughly before I start modifying a bunch of components.

As part of the change, though, I am redoing the way I handle engine interfacing, state management, UI, etc... So far, the component system has been strictly for game objects: mobs, triggers, player, etc... In the new system, though, everything is an object, including state context, world generators, etc...

A big part of the change has been to draw up a set of rules for creating new components, rules that have to be retroactively applied to the existing ones. This includes functionality that every component must provide: specifically, streaming. A component has to be able to load all of its data from a Lua table, and has to be able to stream all of its data and state (or, at least, what it requires to reconstruct itself) to a Lua table. This, of course, is where the discipline comes in. It's easy to just whip up a new component and toss it in, but writing the code to stream it requires a bit more work and foresight.

While I test this system and start phasing it in, I won't be adding anything new gameplay-wise to GC. I'll probably continue to tinker on the graphics a bit, but no new code until theold stuff is up to date and I have phased out all of the ugly manual constructions.