colorlib coordination

Yesterday, I was thinking how I probably should have coded the "colorlib" extension so that it saved and checked the input color (what the player types), too. I pretty much skipped it since, in my experience, it is not used a whole lot, but Robb Sherwin has used it a couple times in his games to nice effect.

It would have been nice had I coded it right the first time, but oh well. Anyhow, the main reason I'm posting here is to share a bit of advice that I learned in my colorlib-writing process. If you create a global variable meant to hold color values (example: TEXTCOLOR, MENU_TEXTCOLOR, etc.), it is best to define it with a default value, like:

global TEXTCOLOR = DEF_FOREGROUND

(TEXTCOLOR is defined this way. MENU_TEXTCOLOR is not.)

The importance of this is because later on, you might want to check if a global has a value, but this is easily confused by the fact that the color BLACK equals 0. Giving it a default value (default interpreter color constants range from 16 to 20) ensures that a 0 value always means BLACK.

a color conundrum

In a game that uses non-default text/background colors, UNDOing after a full-screen-color-change will result in "islands" of the old colors on a screen  of the new backgound color. This works in contrast to systems like TADS where changing the background color can be done without clearing the screen. The way Hugo handles it is not necessarily a detriment; I have an idea for at least one game idea that wouldn't work if Hugo worked the other way.

Still, it introduces an interesting dilemma- is there a way for the library to handle such UNDO situations in a non-obnoxious manner? I've been thinking about this since yesterday.

Instead of trying to design some complicated word-array-saving technique to keep track of colors (as the word array is one of the only things not affected by UNDOs, RESTOREs, and RESTARTs), I eventually decided that the best way to handle this will be to write a configuration-file-writing library extension. All of the Hugo ports that I know of that support color also support configuration files, anyway.

The hardest part will be deciding what kind of naming scheme I want for the configuration file so it plays nicely with other games that use the same extension.

Anyhow, when it's written, it should be appreciated by color-lovers and color-haters alike (as it will also give players options to "opt out" of color changes).