The 2016 Hugo Holiday Newsletter

December offers an exciting challenge to finish or improve the projects one has worked on through the year, and it's a great time to look back on progress already made. It's actually been a pretty exciting year for Hugo! Let's recap!

• Nikos Chantziaras has continued making improvements to the multi-platform Hugor.  The opcode system he introduced in recent unofficial builds should make for a smoother player experience in the long run.  Some of the logistics of the opcode system are still being worked out (see below), but we probably can expect to see a new official build released in the coming months.
• Robb Sherwin's work in progress, Cyberganked, has been greenlit on Steam.  Cyberganked is an IF/RPG hybrid like nothing the world has seen before, taking inspiration from games such as Wasteland and Bard's Tale.  The secret word on the street is that Sherwin's next game may be a sequel to one of his earlier works, so anyone who would like to see any of these things come to fruition should get involved with the Cyberganked community and help make this thing happen!
• Jizaboz continues to work on his multimedia-enhanced North Korea simulator, A Day In DRPK.  From what I've seen of the work in progress, I believe it's more than two-thirds complete and most likely will be released in 2017.  You can check out the game's original demo here and check its progress here.
• Juhana Leinonen accomplished the Herculean task of writing a Hugo interpreter in JavaScript.  HugoJS has a page where you can play any of a pre-selected list or use the link tab to play any .hex file from a URL.  The interpreter itself is quite snazzy.  Juhana had previously provided an Emscripten DOSbox solution which used the Hugo DOS interpreter.  HugoJS blows the old method away in speed, presentation, and ease-of-use on mobile devices.  My limited experimentation also led me to believe it should work decently with screen readers.
  
  Juhana has been updating HugoJS with Nikos' Hugor opcodes, and we've been in the process of adding new ones.  When all is said and done, Roodylib should work nicely with all existing and future opcode-enhanced interpreters.  It may even have multimedia support at some point, too.
• Kent Tessman, author of Hugo, is busy updating and promoting his screen writing software, Fade In.  In recent years, it has been embraced by some of Hollywood's best screenwriters (and many others more) for its ease of use and astounding list of features despite being much cheaper than old "industry standard" solutions.

As for me, I'm working on updating Roodylib to incorporate the new opcodes and fixing some bugs.  I hope to have another official release within the next month or two, at which point I'll re-release all of my games so people can see all of the new functionality.

roody labs

My latest bit of Hugo coding has been comprised of distracted yet productive meandering.

*  * *

Roodylib takes several important Hugo library routines and breaks them up into several routines for the sake of readability and modification (I'd rather provide authors with a method to change just the important thing instead of having to switch out the entire 126 lines of FindObject).  Of course, one side effect of this is that it greatly increases the starting number of routines in any given game.  The Hugo default max limit of routines is 320.  Now, this is a changeable, soft limit, but it worries me when a Roodylib game creeps up to that 320 limit; I don't want it to get to the point where my beginning advice to new authors includes how to raise the routine limit.  They have enough things to take in at that point.

DescribePlace, the routine responsible for room descriptions, was one that I split into several routines so authors had the ability to change the order in which things are listed.  To combat the creeping-routine problem, I redesigned the routines as objects with one routine to execute them.  It's actually been done for a while, but I didn't mention it because it's kind of a useless modification, all things considered, and the number of routines probably only bothers me.

* * *

I also modified the "shell" files included with Roodylib to automatically compile with the -s switch.  This provides compilation statistics like number of objects, routines, etc.  I always find this useful; I figure others will, too.

* * *

Sir Jiz has a lot of timers in his game- most of which he's been handling with the room each_turn property.  I usually do this by keeping the number-of-turns-spent-in-room in the misc property so the each_turn property routine can have some "select self.misc" code and go from there.  Long story short, Jiz was getting sick of reminding himself where the best place to set the misc value was.  I figured, ah, yeah, I guess Roodylib could do something about that.  So now there's a RoomTurnCount thing so nobody has to mess with misc anymore.

select RoomTurnCount

case 0

"Runs as soon as player enters room."

case 1

"Runs after first turn."

case 2

"And so on."

Although maybe I should have pushed him towards using a daemon instead.  Ah, well, always nice to have multiple ways to do things.

* * *

Some months ago, someone expressed interest in there being a Hugo Comp this year, so I tried to gauge interest from everybody at the joltcountry.com forums and throw some theme ideas around.  I had been in the middle of playthrough of "Spellcasting 201: The Sorcerer's Appliance" so I figured a magic-themed comp would be fun.  I even offered to throw together an extension for authors to use so they wouldn't have to write the magic system themselves.

I started off by looking at Cardinal Teulbachs' (yes, back in the olden days, we used to have an IF community member named "Cardinal Teulbachs") take on a spellcasting system.  His code strictly prohibited modification, though, so I was going to have to write my own thing by scratch (I don't always honor code licenses, but hey, this time I did).

I think I came up with the base design for my system, but I decided I needed to refresh my memory on how spells worked in the Enchanter trilogy (how many memory slots the player has, if all spells can be memorized multiple times- stuff like that).

The funny thing, though, is that I found myself super distracted by the fact that you could not read dropped scrolls in Teulbachs' sample game which was a departure from expected Infocom behavior.  Just the same, it made some sense, and I decided it'd be nice to write an object class system for objects that had to be held to be read (like a pamphlet) while still allowing for ones that don't (like a billboard).

More difficultly, I wanted to do this on the grammar level so all "You don't have that." messages didn't use up a turn.  Truthfully, it's not easy to have varied behavior when it comes to held/unheld verbs.  I knew that when I did get around to writing this system, I'd have to use my Roodylib "routine grammar helper" system.

I finally got around to looking at this problem yesterday.  It was one of those funny times where you return to an old problem a bit smarter and almost resent the obligation to improve your solution ("WHY CAN'T I JUST STAY STUPID FOREVER?").

First, to help me design the readable object classes, I looked over some grammar classes I had made previously for containers that are emptied in different ways (those that had to be held vs those that don't and so forth).  In my testing, though, the "empty" code wasn't working, and for a while there, I thought maybe I had broken FindObject somewhere along the way (and getting FindObject to do the things I already have it do was a scary, confusing journey so I wasn't looking forward to working on it again).

It turned out that a call to FindObject from AnythingTokenCheck (which itself is called from within FindObject) should have used the "recurse" argument.  Whew!

I also decided that half of my original "routine grammar helper" code was unnecessary.

But anyway, that's all working better now, although I might redesign the routine grammar helper again, possibly to use attributes instead of variable masking.

And, oh yeah, if you were curious, no, I don't think the Hugo Comp is happening.  That discussion fizzled out pretty quickly.

* * *

STATUSTYPE is a global variable that determines what kind of information is displayed in the upper right corner of the status window.  One of the several options displays a game clock like in the game Deadline.  Since the HoursMinutes routine used to print the time could also do military time, a while back, I added a STATUSTYPE value that provides a military time clock (like in Border Zone).   It kind of bugged me that the code didn't have an easy way to switch between the military time with colon and without.  While easy enough to provide a choice for the author, I really wanted it to be as unobtrusive as possible because, really, there's like no chance anyone is going to write a military time game again, and it'd just be embarrassing to show that I spent much time doing some sort of time-configuration system for a feature no one would ever use.  I ended up with just going with a #set NO_MILITARY_COLON flag.

* * *

There are a couple other things, but I'm getting tired of writing.  Anyway, probably will try to put out a Roodylib update within the next couple weeks and then maybe do a round of uploading-stuff-to-the-IF-archive.  Then, maybe, write some IF?  (gasp)

Summertime Frolicking

One of my favorite things about frolicking is how quickly I get sick of it and want to return to my projects.  That said, August is lousy with birthdays among my friends and family (of course, I mean that in the quantitative, Catcher in the Rye sense and not the qualitative one), and I've still got some pool parties, a "pedal tavern," and possibly a trip to the Renaissance Faire in my future.

Still, I can't wait to submerge myself in something Hugo again.  Earlier this week, I made some progress in my most recent problem; I had noticed how horribly broken the baby-naming code was in my silly, nonsensical game, "Baby Uncle New Year," and I wanted to fix it up.

I was hoping my new code would be general enough that I could easily throw it into Roodylib for everybody to use, but it ended up being too specifically purposed.  When I get back to coding, writing that general purpose system will probably be my next task.

Ideally, I'd like it to do these things:

1.  If the game is being played on an interpreter that supports Hugo's timing system (and accessibility mode is not turned on), it would throw up a floating window like in my game "The Halloween Horror" and use my "fake prompt" code to capture the input and writing it straight to an array.
2. If the game is being played on a glk interpreter or has accessibility mode turned on, it has a prompt in the main window.  Actual Hugo prompts are tricky because unless the text is within quotation marks, Hugo can only keep track of one unrecognized word.  I'll have to find a tactful way to instruct the player accordingly.
3. Both of these will result in a, "'<blah>'? Is that correct?" response so the player can double-check how it was received.  Even with whatever nudging I give, the main window Hugo prompts have a fair possibility of being wrong, like if the player used any of the "removal" words ("a", "an", "the", "some", "of") that Hugo automatically drops from input lines.
4. Include an option to write all unrecognized words to the game dictionary and apply them to an object.

At least one game in progress by another person uses my "fake prompt" code so I figure this system could be useful to others as well.  Besides this, I need to reacquaint myself with my Hugo "to do" list and see if there's anything else I'd like to add before the next Roodylib release.  I also have some real world research I want to do on one of my game ideas.

Here's to ending 2016 with a little more Hugo in the world!

some progress summer

Since the last post, I helped that friend with that problem (GAME'S LOOKING GOOD, JIZ) and made some Roodylib progress (fixed some bugs, redesigned some stuff, and incorporated one or two new extensions).  I have an out-of-town friend coming in this week, and I'd been meaning to recompile all of my old games with my default menu code and just try to make them look as consistent as possible.

I've actually been meaning to do this for years, but this friend really doesn't know anything about IF so I kept putting it off because I wanted the consistency between games to be perfect...  and honestly, I usually like to give a middle finger to perfection.  It's too damn  hard to finish projects in the first place.

Still, applying something like Roodylib to old code is always interesting.  It's getting to the point where the library application is a lot more seamless than it used to be, and I even found the culprit in my update to Christopher Tate's "converse" extension that was keeping it from working straight out of the box.  That's been irking me for years, but now that it's fixed, my version is just about ready for public release, I think.

Anyhow, despite all of that Roodylib work, I'm getting to the point where I feel I need to give more attention to my WIPs.  One disappointment was the reminder that all of them are missing some big mid-game chunk of design.  The plan is to sit down with some flowchart software one day and stare at the screen until inspiration strikes.

But hey, it's summer and the days are beautiful, so it's been hard to make IF a priority.  Have to enjoy these few months of sun and warmth that we get, so I'm trying to get out as much as possible.  Frolicking, even.

So much frolicking.

Roodylib 4.1.2

I'm several months late in helping someone code a scene in their game, so me being me, that means I went and got Roodylib ready for a new release!  SORRY, JIZ!

The three main elements of this new update are:

• Incorporated the accessibility code mentioned one or two posts back into Roodylib and made them available by default.  I may add another accessibility feature at some point- some kind of spelling system for uncommon words (as discussed on the intfiction.org forums)
• Code supporting Nikos Chantziaras' Hugor opcodes system
• Incorporated "newmenu.h" into Roodylib so one doesn't have to include the extra file.  I added mouseclick support to menus sometime within the last handful of months, too.

Roodylib 4.1.2

Latest Hugo Notepad++ Bundle

Hugo Notepad++ Add-on

"sandbox" modes

After completing Michael Berlyn's Suspended, a player is given a special command that allows configuration of the main game- moving robots here and there, changing the timer, etc.  I heard about this feature many years before I actually beat Suspended.  At the time, it sounded like overkill for a game that I had bashed my head against (although in hindsight, it's really not the Herculean effort I thought it was).

I have to admit that, having beaten the game and finally being familiar with how things fit together, the extra challenge mode seemed like a cool idea.  Wow, a player could really make this game as hard or easy as they want to; I could see a fun optimization puzzle emerging.  I have to admit that I never actually played much with this extra mode, but it was cool to see and finally understand.

I've pondered nice ways to provide a similar experience for players, and the easiest answer I came up with was to give the player a magic word when the game is completed that turns on debugging mode.  They'd be able to look at the object tree, move objects or the player around, or even control how daemons run.  I thought this would be a fun way to share the innards of the game with the player; for some reason, having game source available doesn't provide the same thrill unless it's, say, in Hugo and I'm applying new Roodylib functionality to it or something for my own curiosity.

Today's code sample supplies this magic word debugging system.



Now I just need to write a game that players would want to dig into!

general update and "bags of holding"

Some interesting news in Hugoville.  Nikos Chantziaras has added an opcode system to Hugor, allowing for some special behavior here and there.  Unfortunately, along with posting here about stuff more often, I've been meaning to update the Roodylib documentation to cover all of the new stuff and put out a new release.  So, more news down the road!

In the meantime, I thought I'd share some code examples I put together the other month; well, one now, one next time I write here.

Today's bit of code will be for what IF lingo calls a "bag of holding."  I'd say they were first popularized in late era commercial IF although they first showed up a bit earlier than that.  Players still had set carrying capacities so object-management was required, but one object in the game- usually a bag or knapsack- could carry a limitless number of objects.  As soon as you couldn't pick up anything more, you'd stick stuff in the bag of holding and, yay, looting can recommence!

Bags of holding got even cooler when the game would automatically stick stuff in them for you.  Today's code sample will be an automatic bag of holding system in Hugo.



Just set the bag_of_holding global to your bag of holding object, and there you go!  Now, admittedly, this system is pretty simple. It only allows for swapping one object that, when moved, will create enough space for the new object. I considered writing another pass if the first one didn't find a suitable most, but I figured that this behavior would fit most games.  If a game has large variance in object sizes, the large objects probably should get special treatment through before routines and such.  Plus, it's always kind of ugly when you try to pick something up and then half of your inventory is moved to the bag of holding so I didn't want to encourage that.

Announcing the Hugo Notepad++ add-on

Some people were unable to use my standalone Notepad++ package because they already had Notepad++ installed.  I finally got around to putting together a package adding (most of) its functionality.  Just download the following file and follow the instructions in the .pdf file!

https://drive.google.com/file/d/0B_4ZXs4Z_yoWclhaOFFYQ3JScjg/view?usp=sharing

It includes the compiler, an interpreter, and library files, so once installed, you'll be ready to start writing your Hugo game!  As mentioned in the .pdf, all of the new commands will be under the Macros tab when you're done.

new ZIL blog

Just a quick note that I've started an additional blog where I'll write about my experience exploring ZIL, the language used to write the Infocom games:

ZIL Crazy After All These Years

Feel free to tag along!

Updates in Accessibility

I spoke about accessibility in the last post.  It was brought to my attention that NVDA, another screen reader, does in fact work with some Hugo interpreters.  This was exciting news as I could finally test my new accessibility code.

For one thing, I was pleased to discover that my option to disallow screen-clearing was in fact justified; in-game screen clearing occasionally causes NVDA to lose track of the text.  For the meantime, I'm taking the "clear every turn" option out until I learn of screen reader software that might work with.  I'm also pretty pleased with the switching-the-prompt command; "Your command..." sounds a lot better than "greater than."

If anyone wants to try NVDA out themselves, you can download it at http://www.nvaccess.org/download/

You can get the add-on someone wrote for several IF interpreters at http://jeff.tdrealms.com/Add-Ons/IfInterpreters-1.1.nvda-addon

I found finding the place to install the add-on in NVDA was a bit of a search, but dig enough, and you'll find it.

The add-on specifically targets the winglk Hugo interpreter which can be downloaded at http://ifarchive.org/if-archive/programming/hugo/executables/hugov31_winglk.zip

Lastly, download any of the following games, compiled with Roodylib's new accessibility code.  Now, they're not my games (I'd much rather have people play something good) so please don't redistribute; these are just for personal use.

Spur: https://drive.google.com/file/d/0B_4ZXs4Z_yoWOFg2b2FUZVBXeTQ/view?usp=sharing
Guilty Bastards: https://drive.google.com/file/d/0B_4ZXs4Z_yoWNG5TX1BMem9TWmc/view?usp=sharing
Down: https://drive.google.com/file/d/0B_4ZXs4Z_yoWZkVtUndXQ0VUcGs/view?usp=sharing

Accessibility commands are listed if someone types the suggested "INFO" command.

Moving your mouse reverts NVDA to "hover over words" mode, so for best uninterrupted behavior, leave your mouse alone.

These accessibility commands will be on by default in future releases of Roodylib.