New newmenu stuff

So, some days ago- I've taken my time getting around to write this blog post about it- I was working on porting John Menichelli's HugoZork to Roodylib. One of the last additions I plan to do involved transferring his menu code over to my newmenu format. This, in turn, got me thinking about newmenu for the first time in a while.

alt_title property

First off, his menu pages often have a different title from the link name that led to them. In the past, with newmenu, I've just kept an extra CenterTitle call in the page text. This has the downside of possibly getting double-titled in a simple terminal interpreter. Converting HugoZork was the straw that made me go, eh, I might as well add another property to menu option objects. Behold, the alt_title property (I actually gave it an alt_name alias in case I forget what I called it along the way)!

(Also, hey, look, I found a better way to share code)

option amusement_option "For Your Amusement/Words To Try"
{
    in main_menu
    alt_title "For Your Amusement"
    menu_text
    {
        "Have you ever:\n"

        "\_  ...opened the grating from beneath while the leaves were still
        on it?"
        "\_  ...tried swearing at ZORK I?"
        "\_  ...waved the sceptre while standing on the rainbow?"
        "\_  ...tried anything nasty with the bodies in Hades?"
        "\_  ...burned the black book?"
        "\_  ...damaged the painting?"
        "\_  ...lit the candles with the torch?"
        "\_  ...read the matchbook?"
        "\_  ...tried to take yourself (or the Thief, Troll, or Cyclops)?"
        "\_  ...tried cutting things with the knife or sword?"
        "\_  ...poured water on something burning?"
        "\_  ...said WAIT or SCORE while dead (as a spirit)?\n"

       ! "\nPress any key for more..."

       ! pause
            CoolPause(1)
        CenterTitle("Words To Try")

        "Words you may not have tried:\n"

        "\_  HELLO (to Troll, Thief, Cyclops)"
        "\_  ZORK"
        "\_  OIL (lubricate)"
        "\_  XYZZY"
        "\_  WALK AROUND (in forest or outside house)"
        "\_  PLUGH"
        "\_  FIND (especially with house, hands, teeth, me)"
        "\_  CHOMP (or BARF)"
        "\_  COUNT (candles, leaves, matches, blessings)"
        "\_  WIN"
        "\_  MUMBLE (or SIGH)"
        "\_  LISTEN (especially to the Troll, Thief, or Cyclops)"
        "\_  REPENT"
        "\_  WHAT IS (grue, zorkmid, ...)"
        "\_  YELL (or SCREAM)"
        "\_  SMELL\n"

        CoolPause(1)
    }
}

So, the name of the object represents how the choice will be listed in the menu itself, and the alt_title property is how the page is titled when you are reading it (if you don't provide an alt_title property, it just uses the link name).

TopPageMargin routine

I also added a routine called TopPageMargin. It is to newmenu what LinesFromTop is to Roodylib. I give it its own routine for two reasons- 1) newmenu does not require Roodylib and 2) I find that I sometimes like menu pages to have a slightly different margin than the game itself.

Right now, TopPageMargin defaults to returning 2 so page text automatically starts 2 lines down from the top. If your menu page text already does its own carriage returns for proper spacing, you can always replace TopPageMargin to return 0.

Glk menus

I also tweaked the glk behavior for better detecting when there are too many options and the menu has to be drawn by the "cheap" non-windowed method. Right now, it only draws the cheap menus as needed, so it's entirely possible that mid-menu, it'll jump from one kind to the other. I'm considering having it decide before it even gets started if it'd ever possibly use the cheap menu (and then just use that throughout), but that leaves the window open for game crashes if the player resizes the window mid-menu.

Other thoughts

Looking at the code again, I was reminded how newmenu is currently a mix of array and object hierarchy design. Given that I've done much more object-hierarchy organized design since I initially wrote newmenu, I started wondering, hmm, maybe I should just switch newmenu to doing everything by object hierarchy.

After thinking about it, my initial conclusion was that all of the necessary object-organization routines would complicate things more than necessary, and the end result would probably be more memory-intensive than the existing system so I've given up on that idea for now. Still, it seems like it might be possible to design something that only rearranges itself as necessary and largely works without writing values to anything.

I'll probably get back to this as some point when I have something else I really should be doing instead.