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.

finishing touches

Ok, I did those things I mentioned in the previous post, as far as newmenu.h goes. I'm pretty much happy with everything. I did notice that there is some odd behavior in Hugor where the following code:

                    print "[N]ext item"; to 24; "[Q]uit menu"
                    print "[P]revious item"; to 24; "[Enter] to select"

 Occasionally results in:

[N]ext item             [Q]uit menu
[P]revious item          [Enter] to select

(Where [Q]uit is not aligned with [Enter])

Now, the font is PROP_OFF at the point in question. The only way I've found to fix it is to print a blank line beforehand (""). Somehow, I guess, Hugor is getting confused about cursor position or something. Maybe it's a result of the newly-supported realtime transcripting; I haven't checked it in older versions yet. Anyhow, it seems like it might be a tricky bug to track down so I'm going to see how simply I can replicate it before I send it on to Nikos.

Anyhow, my point is, other than that, I'm pretty happy with the current state of newmenu.h. I think all I really need to do now is perfect all of the default messages. I'm still not sure what the best "press a key to continue" text should be, and my "what is IF?"/"how to play IF" stuff in the default menu could use some polishing.

Again, the latest version is at http://roody.gerynarsabode.org/hbe/newmenu.zip. Everybody is invited to weigh in!

updates

A lot has changed since I uploaded "newmenu.h" to the IF archive, and I'd like to make sure it's in a good place before I upload it again. After working on the transcript stuff, I doublechecked that it worked ok with and without roodylib.h. This brought me to the auto-generating help menu thing that I set up some months ago. I was reminded that there should be a way for game-specific menu options to take precedent over the generic ones; in fact, the author should have complete control over the order of all of the options, right?

So yeah, I made a "priority" property for menu options- the higher the number, the earlier an option is listed. Coming up with a solution was trickier than I had predicted as I originally wanted to do it with regular arrays (and even modified my SortArray routine to allow for starting at an element other than 0), but since newmenu currently keeps track of its menu choices using two arrays, it was easier to just write the choices to a property array and use SortProp to re-order them.

As far as newmenu goes, I seem to be running out of hugolib-defined properties to alias to. Not aliasing is no big deal, but I try to do it when possible. Still, you don't want to accidentally alias something with a property that might be interpreted another way or otherwise interfere. I found one such overlap today, when checking to make sure that the roodylib-enhanced version of newmenu didn't run the MenuInit routine after UNDOs and RESTOREs.

So, the main thing is, the latest versions of newmenu and roodylib can be found at http://roody.gerynarsabode.org/hbe/newmenu.zip and roody.gerynarsabode.org/notdead/roodylib_suite.zip, respectively.

I've got some things to do with newmenu before I upload it to IF archive, yet. I have to make sure that the different-color-scheme-per-menu-page code still works and that the "cheap"-mode codes still works. Plus, just now, it occurs to me that maybe I should cut it down to use one array, so yeah, maybe I'll do that.

simpler yet

I decided that my menu output could also ignore choices and just give titles to selected pages. The latest version looks like this:

>thoughts
[OPENING MENU]

[”Fatty Arbuckle”]
Blah blah hooray!

[”Whoa, a Helicopter!”]
Blah blah blah

[LEAVING MENU]
Returning to the story...

I think I'm on the right path.

EDIT: I didn't like how titles looked in the simple interpreter especially, so I switched it to something that looks more "title-like":

Transcription on.

>thoughts
[OPENING MENU]
                                                           Fatty Arbuckle
Blah blah hooray!

                                                         Whoa, a Helicopter!
Blah blah blah

[LEAVING MENU]
Returning to the story...

I'm keeping the menu "bookend" texts since I feel it's important to distinguish the menu from the rest of the game.

tales from the script

I've been fixing up "newmenu.h" again. I've got the screen-clearing mentioned in another post all sorted out; lately, I've just been touching up transcript behavior again.

In Hugo's original menu code, menus are kind of funky in game transcripts since most of the options are printed in the status window, which means that they don't show up in the transcript, so you get clumps of unlabeled text. In my menu update, I've been trying to make it so transcripts are easier to read by printing "invisible text" that only shows up in the transcript.

Here is how menu currently looks in a transcript:

Transcription on.

>thoughts
[MENU CHOICE: “BB Studios”]

[MENU CHOICE: “Fatty Arbuckle”]
Blah blah hooray!

[MENU CHOICE: “The Chase”]

[MENU CHOICE: “Whoa, a Helicopter!”]
Blah blah blah

[LEAVING MENU]

Returning to the story...

BB Studios
  According to local signage, one of the giant buildings that holds several of the lot’s stages is to the north. A fancy building for the top brass is to the west.

The "blah blah" parts are where there would be a page of menu text. All lines enclosed in brackets only show up in the transcript.

I'm happy with how it's shaping up. At one point, I had it print the name of the current page, too, but that made the transcript really ugly fast so I cut it down to just writing something when you make a choice.

I like how it is now, but if people have suggestions on how menus in transcripts could look better, I am open to suggestions. Let me know.

Huh, I just learned something as I was writing this post. I was going to post a transcript of how the menu looks in a simple interpreter where things like colors aren't supported. Throwing a transcript together just now, I was kind of surprised to find out that despite the environment's hacky way of showing the status window, it follows the default behavior of not-printing-status-window-text-to-the-transcript-file. Since "invisible text" (where I print text with the same foreground and background color) is not a possibility in a simple interpreter, I'll have simple interpreters automatically get the "cheap mode" treatment.

Anyhow, that is good to know, as I had been wondering whether I should do that anyway. This thing might actually be finished one day!

that menu thing

Ok, so yesterday, my prime coding time was spent at a coffee house where my laptop didn't have a lot of privacy. In such scenarios, being a full grown man (fuller than I'd like, even), I don't like people to see that I am obviously working on a game. As my current WIP has cover art and music and looks much too "game-like", I jumped right into working on that menu thing right away, as I basically knew everything I wanted to do and could spend most of my time in my text editor.

Doing the auto-generating thing was easy. The hard part (which I got to today) was writing the rest of the menu, which was the "About Hugo" and "How to Play Interactive Fiction" sections. Anyhow, I just finished working on it for today. Some of it needs to be completely rewritten; the current "About Hugo" page reads: Hugo is an interactive fiction authoring system written by Kent Tessman. It supports graphics and music!. The "What is interactive fiction?" page could use a lot of work, too, and honestly, everything probably needs some smoothing over.

Still, I'm pretty pleased with how it came out. You can take a look at it yourself by downloading the file at http://roody.gerynarsabode.org/notdead/colortest.hex. Inside the game, type "ABOUT".

The third option in the first menu is the auto-generated one. It has two groups of commands in there, based on the fact that colortext.hex was compiled with colorlib.h and cheaplib.h.

Anyhow, feel free to give me your thoughts or provide me with a nice, professional sounding "About Hugo" page or something. I should get all of the updated files uploaded in the next day or so. After that, it'll just be a matter of writing Hugo by Example pages that cover all of the new stuff.