init thoughts and updates

First off, I spent a good chunk of time working on the glk update of Cardinal Teulbach's "automap" extension yesterday. It no longer requires "glk.h" and now has proper message routines. As I have done with some other extensions, I changed most of the global variables to object properties, as there is a hard limit on global variables and there isn't one on properties (plus, most of the time, you can alias your new property to some pre-existing propert). I don't know if Robb Sherwin ever ran into the global variable limit on Cryptozookeeper, but judging by the game source, I'd guess it has more than a hundred global variables (and the limit is 150), so it could be a limit that nobody ever runs into but I avoid it just the same.

The coolest addition to the automap extension actually involves adding a global variable, though. If you are using the "windows.h" header file and create a window with it, you can set the map_window global variable to that window. Then, every turn, it'll draw the map to that window. The intent is to make it easy to make a game with a Cryptozookeeper/Fallacy of Dawn type screen layout and be able to use one of the windows for an automapper.

The nice thing about touching up "automap" and "boxdraw" is that I think they are getting to the point where I can demote the original files to "outdated" status on Hugo by Example. I still don't know how likely it is that anyone will use them, but it should be simpler to approach from now on.

So yeah, the other thing, init.

Considering I want it to get to a point where an author doesn't really need to think about where to throw an extra routine into init, I've been thinking that the traditional order of things in init should be shaken up a bit.

As it is right now, global variables like "player" and "location" aren't set to nearly the end of the routine, after the intro and game title have already been printed. This makes it harder to find that sweet spot to call certain routines or start fuses that rely on those globals being set properly.

I intend to tidy things up so the order is something like this:

1. Screen-clearing code and the like so games look the same for new games or restarts.
2. Set all global variables (including "player" and "location"
3. Execute any routines-to-be-called by init (like those from library contributions)
4. Print game intro and title
5. execute MovePlayer(location)

I still haven't decided if I should break any of the sections into routines themselves or any other similar organizational endeavor. It's a fine line between making-things-simpler and obfuscation.