So, when I was finishing up "The Next Day," it was irking me that my game's usage of my cover art and colorlib extensions and music options meant that the game was creating 2 or 3 data files. In Hugor, this is very obvious as the files appear in the game directory *.
* Nikos asked whether this should possibly be changed so that it emulates the regular interpreter behavior, but I thought it was good as it is. I think the player *should* have some idea what's going on, especially in games where deleting the data file is the only way to get a new clean start. Still, having the two behaviors among the two interpreters makes it harder for us authors to code for.
For "The Next Day," I ended up just replacing routines and rewriting them to account for every extension, but I promised myself I'd write some kind of configuration file manager extension that'd automatically write all of these different extensions to one file.
It took several weeks and a couple different approaches. Initially, I was trying to write the manager based on the existing extensions; that resulted in this unsuccessful system where I was using a big array to temporarily hold stuff but I couldn't keep track of where things were after a while. When I started the design from the "manager-side" of things, it was a lot simpler to design. The hard part was still adapting the old extensions to the new system, but I'm mostly done with that already, I think.
Part of the problem with that last thing is that I'm especially dissatisfied with the current state of the cover art extension. Looking at it pragmatically, some of its features shouldn't even exist. I created the thing to emulate the zblorb cover art system. There's a chance the "cover once" (show a game's cover just once) feature would be worthwhile if everyone used the official Hugo interpreter, which writes all data files to the same directory, but Hugor is just way too nice of a interpreter to act like it doesn't exist. I just recently was getting Hugo to work on Puppy Linux, and Hugor was the only one I could easily set-up (and hey, it looked really nice, too). Anyway, having all of those cover art choices in such an environment is nonsensical.
There's also the argument that Hugo games shouldn't even have any cover art at all as it can't be read by an external program (and cover art exists in the first place for the benefit of game loaders), but I dunno, I think cover art looked cool in Paul Lee's Tree & Star so I think the extension is worth keeping around.
Side thought: as far as the last sentiment is concerned, I imagine it'd very possible to have a game loader allow you to point to a Hugo's resource file, at which it could either grab the first graphic (which would likely be the title) or browse through the pictures to choose something to use as cover art. Anyhow, I guess it's something to suggest if game loaders ever really do come far enough.
My current thoughts on how the cover art extension should behave is this:
* Cover art defaults to on and shows up every time the game is opened up cleanly
* It does not show during game restarts, though.
* It can still be turned off.
Also, I'm thinking of calling this configuration file manager "config_sys.h". Funny? Or confusing?
Do people have thoughts about any of these things?
EDIT: Dang it, I forgot to mention some of the cool things my configuration file manager does that I am especially proud of, so here goes:
Especially when I was using that big temporary array to hold the configuration file info, one of my big problems was how to identify the start of this extension's info and that one's. Eventually, I came up with a routine I called "StringSum". I'd write the extension's configuration file's name to a string then add up all of the character values. I'd then write this value to the array before saving its info, so i could check for this value later. While it's entirely feasible that multiple extensions might have the same name sums, it was a semi-reasonable way to distinguish one library's info's start from the other.
In the second iteration of the configuration file manager, I also used object hierarchy as an ordering tool, so all of the configuration objects are in a config_instructions object, and I go through its children one by one. I kept the StringSum system, so between the StringSum-ing and the object hierarchy, the system should have a good grasp of what's what.