2024 update

 Well, it's been three years since the last one, so I guess I'm due for a new Not Dead Hugo post.  In the past few months, I have been cracking open some Hugo code once again.

First off, a special shout out to the hundreds of bots who visit this blog every month.  Thank you, Hong Kong!  

I still have never learned any general purpose coding languages to the extent that I know Hugo.  I mentioned on here at one point how I wrote a Hugo "game" to coordinate my family's Secret Santa program.  It allows me to easily disallow Secret Santa matches from previous years so people don't get the same pick, and using game transcripts, it writes all of the picks to text files so I can be as surprised as everyone else, as far as who has picked whom.

In the last year, I decided that it would be nice to have a companion compilation that would allow my family members to look up Secret Santa's on their own (for the times you have a really inspired gift idea for someone so you would like to pass the idea on to their actual Secret Santa... or whatever other reason you might want to know).

So, I wrote this companion app.  The two programs shared a file that both could write to or read from (like I did in my joke game "The Halloween Horror").  For some reason, though, at first, values were getting overwritten by the second one.  I decided this merited some more in-depth examination of my "configuration file helper" extension, but by the time I got around to doing the deep dive, I had already redesigned my pair of "games" and was no longer able to replicate the issue.  Sometimes it's kind of disappointing when everything works, no longer able to figure out why anything ever went wrong.

Hugella over at the Jolt Country interactive fiction started a project to review all of the IF Archive's uploaded Hugo games at the tail end of 2022.  One of the early games covered was Robb Sherwin's port of the BBS door game "HAMMURABI."  Opening up the game myself reminded me that I once thought it'd be a good coding exercise to add some perks.  The main thing I wanted to do was to have the game use the normal Hugo engine game loop instead of 'while' loop so that meta commands like SAVE, RESTORE, and (most importantly) QUIT worked.  I also wanted to stop it from accepting negative numbers and other things that could easily mess up the game.

I thought about this idea in 2023 but I think I actually even gave up on it at some point, since Hugo only understands a few numbers as dictionary words by default and commands need to be understood for the game loop to work.

But there I was, in 2024, with new ambition and grit!  And I was successful (the new version is now up at the IF Archive, I believe)!  So that was fun.

There was a snag at one point, though.  My Roodylib code that turns inputted-numbers into actual numbers expected unrecognized words in the word array to have the value 0, and in my code, they were coming up as -1.  Part of me remembered seeing parse$ (the variable where Hugo saves unrecognized words) having the value -1 in the past, but I just figured I must have gotten something wrong.

So this (and another sort of meaningless update- just added some additional information at the start of game transcripts in games compiled in debug mode) caused me to upload a new version of the Roodylib suite and updated the Notepad++ packages.

Only after all of this was done did I discover the true culprit.  parse$ in a word array filled by the parsing engine gets the value -1, but parse$ in a word array filled by the input command has the value 0.  So future releases of Roodylib will allow for both values (since no legitimate dictionary word will ever have those values) but I'm not going to upload a new Roodylib suite right away.

In other Hugo news, I recently made the acquaintance of a blind IF fan so I was excited to share some Hugo games I've compiled with some accessibility stuff that strives to make games work better with screenreaders.  I don't think he noticed any of those features (which isn't a big deal since they are barely noticeable, to be honest), but he did notice that a daemon wasn't triggering properly in the game Spur.  While I was quick to suspect that some of my Roodylib updates had broken something, it turned out that some of Spur's 1999 daemon code doesn't play nice with the modern Hugo library.

It was easy enough to replicate the intended behavior in other ways, though, and I made a note about this Spur code over at Hugo By Example.  I've been trying to update Hugo By Example more in general.  Among a handful of pages, I added a step-by-step walkthrough on using the Windows Debugger as I get the impression that many Hugo authors don't take advantage of it.

In other project news, as someone who feels he has awful time management, I coded a thing in Hugo that randomly picks tasks I want to do and rewards I could have (again, I don't know any general coding languages well).  I used Hugo's system time stuff to determine what day of the week it is and what time of day so that some tasks can be limited to day or night or weekday or weekend, if need be.  Finding online equations for finding the day of the week was fun; I can't remember the last time I've needed the mod function for a game.  Still, it's unlikely that any game most people write will care if players are playing the game on a Monday so I don't think I'll be adding that code to any of the Roodylib libraries.

The plan is that I will work on my own game ideas at some point, but since working on my own games is the worst, I'll probably find one or two distraction projects to do before that happens. 

More Necromancy

In awesome news, Juhana Leinonen was able to convert my old Hugo By Example backups and give it a new presence on github.  Hugo By Example was a wiki created by Royce Odle for learning Hugo, but sadly, it has been unavailable for several years now.  The things I learned while writing for it were largely responsible for the creation of Roodylib.  Even as one of its more prolific contributors, back in the days where I actually wrote games (gasp!), there were certain pages I referred to all of the time.  It's just great to have a resource where things like error message numbers and constant values (things that are not always covered to the full extent in the Hugo Book) are cleanly listed without having to dig through the Hugo library every time.

Hugo By Example was last updated in 2013 so in the coming weeks, I'll be focusing my attention at correcting statements that are no longer true, fixing dead links, and updating it with all of the changes we have seen since then.  I hope the site becomes as useful to someone else as the original was to me.

Beyond that, we also have a new hub (also created by Juhana) for all things Hugo collecting links to the current interpreters, repositories, and other resources that a Hugo user might need.

Personally, I'm very excited about these things.

>FOLLOW SO-AND-SO "Which way did he go?"

 To be honest, returning to game design hasn't been going all that well, so recently, I thought I could distract myself by looking over an old Roodylib "to do" list to see if there was anything I still wanted to add.

The first thing that sounded appealing was trying to come up with a solution to Hugo's default handling of >FOLLOW, as a game seems kind of dumb when you have just seen a character leave a room and >FOLLOW responds with "Which way did he go?"

I wrote a system that relies on using CharMove to move your NPCs.  The code takes note of the direction the NPC left in, and unless the NPC returns at some point, >FOLLOW will result in going in the same direction.  There was no ultra-clean method that didn't involve replacing some routines, but this was the most elegant solution that I could come up with.  Beyond including this code, authors would just need to remember to give their roaming NPCs the "last_dir" property that I have defined.

After writing this, I wanted to test it out in a game.  I first tried "Guilty Bastards" because I incorrectly remembered being able to follow someone at some point (although it definitely has a character following you).  I then tried "Spur," which I was reminded was actually the game that inspired this whole better-following thing in the first place, but I couldn't even use my code with it as it completely substitutes another character script routine for CharMove.  I mean, sure, I could have rewritten it all so my code would still have worked, but in my sandbox version of "Spur", I had already written a >FOLLOW SO-AND-SO workaround anyway.

So I just had to test it with my own code, and hey, everything seems to be working fine.  I'll probably just throw it in the "extensions" folder in my Roodylib distribution at some point.

4.2.1

So, I was testing the latest Roodylib with Juhana Leinonen's HugoJS interpreter, and it turned out that I had forgotten to incorporate some code from last fall which prevented Roodylib from causing games to hang.  Anyhow, it's in there now.

I also added an "opcode alternative" folder to the extensions so people can use Nikos Chantziaras' opcode-calling routine if they find Roodylib's less-direct method too confusing.

Yes, I skipped from 4.1.9 to 4.2.1 because even though I thought an April 4.2.0 release would be funny, I forgot about that whole Hitler thing and thought best to avoid it altogether, ha.

Roodylib 4.2.1 is here.  I've also updated the Hugo Notepad++ bundle and the Hugo Notepad++ add-on (for preexisting Notepad++ installations).

Back From the Dead

So, first off, my apologies to anyone who was looking forward to more posts here during the last several years.  I was overwhelmed with some of the big changes I wanted to make to Roodylib to begin with, and then first my grandmother and then my father had health issues that took up all of my attention.  Sadly, they both passed away last year, but I'm thankful for all of the time I was able to spend with them.

I've had more time to get back to Roodylib in recent months, and I'm happy to be able to share the results.  I've uploaded a new version of Roodylib here.  I've also updated the Hugo Notepad++ bundle and the Hugo Notepad++ add-on (for preexisting Notepad++ installations).

As issue-tracking and version-numbering aren't really my forte, I have bumped this new release up to Roodylib 4.1.9, as it's basically an alpha I'd like to get out into the open (and my juvenile sense of humor thought it would be stupidly funny to put out a final 4.2.0 release later this month).  I've run it through a bunch of games with pretty much no issues except for changing how files are included, but one never can tell with these things.

Changes in this new release:

• Right after the last official release, I noticed that Roodylib didn't handle multiple AGAIN/Gs in multi-command input.  Originally, I thought it was something I broke, but it seems that Hugo's library never handled it quite like I would want.  Anyhow, that's working now.
• I moved whatever I could back to extensions for overall better code-readability for both Roodylib and the extensions themselves.  As much as I have loved the simplicity of just adding a flag to include functionality in my games, I decided that I have to keep future authors in mind so it's easier for them to see how each system works.  One side effect of this is that certain routines had to be broken up even further, so this new version of Roodylib grows in routine declaration despite being pared down in size.
• Similarly, I redesigned some of the Hugofix stuff so extensions can easily add more debugging options without having to replace the entirety of some Hugofix routines.
• I added some pronoun-choosing helper routines so games seem smarter.
• Opcode functionality should be up to date and working on all existing opcode interpreters.
• Improved some attachables stuff.

I didn't go all-out crazy making the documentation as perfect as possible, but a lot of this is covered in more detail in the Roodylib documentation.

There has been some other exciting Hugo news in recent months:

• Juhana Leinonen released Borogove, which allows people to write Hugo games online (among several other types of game)!
• Tristano Ajmone put The Hugo Book online.  With Kent's permission, updates and fixes have been made, making it the most accurate version of the book available.
• Steps have been made to centralize the Hugo code base, and discussion of Hugo's future is underway.

So yes, exciting times.

Anyhow, to warn you, I don't really see myself updating Roodylib or this blog in the future with the same frequency as I did in years past.  While nothing is ever perfect, this version is basically the culmination of years-spanning intentions, and now that I've reached this point, it's likely that I'll move on to something else- whether that is back to game-writing or something else entirely, we shall see.

progress report

In recent months, I've seen Hugo mentioned in some unexpected places, and Dannii Willis is working on a glk interface Hugo web interpreter (to which I say, the more the merrier!).  The downside of this is that it has made me more frustrated with the ways Roodylib might be unaccommodating to beginners.  I've decided against my previous "throw it all in" philosophy for Roodylib and have been moving whatever code I can to extensions, and taking out code I'm not 100% satisfied with altogether.  I just want the heart of Roodylib as simple and readable as possible.

Unfortunately, this calls for even more updating to the documentation, so that'll be yet another process.  As much as I'd like to get a new Roodylib out the door, the interpreter opcode side of things isn't as hammered out as I'd like it to be, either, so it'll probably be some time yet.

Just to make this post fun, I thought I'd share some Hugo games hard-compiled with the HugoJS behavior that should work by default once the opcode stuff is all working right.

The first game is "The Hugo Clock" by Jason McWright.  Written for a Hugo minicomp we held a handful of years ago, it's a good example of a game that, despite lacking deep narrative machinations, hits that sweet spot of just being fun to poke and prod around with: The Hugo Clock

The second game, "ScepterQuest", was originally written with Hugo 1.2, back in Hugo's DOS-only days.  I ported it myself as a coding exercise some years ago (and because I find the game very silly and funny), but I intentionally never uploaded it to the IF Archive.  Still, check it out, and if you like it, go ahead and break out DOSbox and try out the original: SceptreQuest

In other IF news:

• Bob Bates' Thaumistry: In Charm's Way hit its kickstarter goal.  People can still donate through PayPal to hit the stretch goals.
• Jesse McGrew released version 0.8 of his ZILF compiler.  I'm well overdue to post to my other blog, ZIL Crazy After All These Years, but I'm really happy with how ZILF is coming along.
• Andrew Plotkin and Chris Spiegel have been looking for official platform builders for the Gargoyle interpreter, and any steps toward more timely updates of one of the most popular offline IF interpreters are greatly appreciated!
• The 2017 Spring Thing competition is just about to start.  I'm so glad that Aaron Reed has kept it running all these years.
• One of my favorite videogame publishers, Devolver Digital, released a compilation of text adventures from a game company called No Code.  It's called Stories Untold.  Unfortunately, even with my settings set way low, it runs too slowly on my computer (I'm not so nostalgic for early 80s text adventures that I want to bring back waiting minutes between commands) but I look forward to trying it again if I ever get a nicer computer.

Apologies to all of the cool IF news things I am missing!

down the rabbit hole of parsing

I've been wanting to write an update post just to assure those that care that I have been working on Roodylib stuff, but it's been hard to pull the trigger as I imagine parsing quirks isn't very interesting to most people.  Then again, if I knew of some blog that was one author's exploration of parser theory or battles against an existing parser, I'd probably read it.  Just the same, anyone who doesn't care can skip down to the "In other news" section below.

So, what with the release of HugoJS, I really want the next version of Roodylib to be as flawless as possible, both for the possible re-release of older games (so they operate best in all kinds of interpreters and make use of Roodylib's accessibility options) and for future games.  To this end, I've been making "recordings" (*) of games with available source and testing the playback against both the original and Roodylib-compiled version and then checking for errors.

( * In several IF systems, typing "RECORD" in a game will begin a transcript that only writes commands to a file.  Then, the next time you play the game, typing "PLAYBACK" will allow you to select the file.  At this point, the game plays all of the commands from the recorded file,  This is a great way to see how the same set of commands affects different versions of the same game.)

Luckily, several of the games have available walkthroughs to make this easier, but it's still slow going; many of the games have random elements so I "normalize" the random number generator to make them predictable.  Several of the games use a conversation system that handles choice entry through GetInput which isn't caught by recording/playback so I wrote a modification to the conversation system to allow making choices from the regular prompt.

I had finished going through a couple games (and, in the process, found a couple Roodylib bugs) when I caught a conversation where Jesse McGew speculated about optimal ZIL behavior when it comes to disambiguation questions within multiple-command inputs.

Say you have a command like this:

>EXAMINE BOX. GET IT. DROP IT.

The issue was, if the game responds with "Which box did you mean, the cardboard box or the glass box?" and the player chooses one, should it then proceed to process the rest of the command?  Inform does proceed, but making the player re-type the rest could be seen as a viable approach, as it is an error of sorts and every IF language is allowed its own expectations of how to handle such situations.

This got me curious about how Hugo/Roodylib currently handled it.  I found that if the player used the disambiguation system added by Roodylib (using "1", "former","2", "latter" and such to refer to listed options), it cleanly stopped processing the rest of the command, but if the player used the engine-based disambiguation system (typing in "glass" or "cardboard"), the rest of the word array got mangled and resulted in a "I didn't understand that." response.

First, I added some hacky code so the engine-based disambiguation also exited cleanly, but then I decided that I preferred the "KEEP ON PROCESSIN'" behavior and modified both versions to do that.

Unfortunately, this opened up another can of worms as I then noticed that the "G"/"AGAIN" code was somewhat broken.   Fixing this took quite a while as I had to re-acquaint myself with all of the parsing code.

Now, everything works again and, in fact, works better than it did before I started.  The old code, borrowed from the original Hugo library, only restored the last command when "AGAIN" is used, so a multiple command input like >SHAKE CAN. G.. OPEN IT.  would lose track of the rest of the command before it got to "OPEN IT". As in, when AGAIN is called, the entirety of the word array was replaced with just "SHAKE CAN".  Now successive commands are not lost and are properly parsed.

Now that I have it working, I plan to clean up the code a bit and maybe put in some hooks so authors can easily put in optional behavior.  For instance, if an NPC is given a command that is an xverb ("save","undo","restore"), Roodylib intentionally gives the error "That doesn't make any sense."  The previous Hugo behavior was just parsing it like all is well, likely leading to a "So-and-so ignores you." response.  So, I'm sort of considering putting in some kind of hook so authors can re-direct it to some kind of "So-and-so says, 'Do what now?'" response if they'd like.

As soon as I'm done with that, it's back to testing games, followed by more general code clean-up and documentation updates.  Given that real life has been fairly hectic and will be for the foreseeable future, this will be a multiple month process.

In Other News

Hugor's Nikos Chantziaras is credited on the development team for a new TADS 3 game by Bob Bates (of Infocom and Legend Entertainment fame).  "Thaumistry: In Charm's Way" is currently being funded on Kickstarter.  I was lucky enough to be in its first wave of alpha testers and found it to be quite a fun romp.  I've been watching the kickstarter progress obsessively and am really looking forward to the finished product.  I'm sure almost all readers of this blog have seen an announcement for it somewhere else, but I just wanted to throw my personal recommendation out there!