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:
- Screen-clearing code and the like so games look the same for new games or restarts.
- Set all global variables (including "player" and "location"
- Execute any routines-to-be-called by init (like those from library contributions)
- Print game intro and title
- execute MovePlayer(location)