Roodylib non-progress and a ZIL update (gasp!)

Since the last Roodylib update, I've been working on a couple things.  Unfortunately, none of them have been very successful which is especially unfortunate because I noticed a capitalization bug I introduced into the last Roodylib release (only seen when someone UNDOs after taking their inventory) and it'd be nice to put out an official release as soon as possible.

Plural Class Stuff

I have a folder of little bits of Hugo code to specifically test this or that functionality.  For example, since I haven't really used Hugo's plural class support much in my own games and WIPs (I have used it a couple times but nothing that'll give the code a good workout), I made a dishwashing simulation where the game begins with 3 dirty dishes and as you wash them, they turn into clean dishes.  Already this little bit of code has been useful to me since it helped me catch a typo in the original plural class code, but it never has been working perfectly so I put it aside to look at again one day.

I took that closer look a few weeks ago; actually, before I started looking at the code again, I thought there might even be a chance that my tweaks to the plural class code since then might have resolved the original issue.  Sadly, no, this was not the case, ha.

The issue was that the game wasn't recognizing the references to the clean dishes once there were 2 or more of them.  It turned out that, just how the attachables system makes the assumption that there is only one attachable in scope, the plural class system makes the assumption that there is only one item in scope with the same noun property.

Hugo's plural class system is a complicated bit of pre and post engine-parsing parsing.  Trying to fix the problem through little code tweaks was unsuccessful in the end, so I think I'll need to re-design the whole thing if I really want it to work.  Like the only-one-attachable-in-scope thing, I don't think I'll revisit this problem until someone's game in progress requires me to do so (or I get really really bored).

Accessibility

Last month, there were a couple posts to the intfiction.org forum by people who use screenreaders to play IF.  I had actually been wanting to get in touch with someone about that for months; at one point, I tried to write to the Audyssey mailing list but I think I used the wrong link and felt too self-conscious to keep trying, haha, so I was excited to finally have some people to talk to.

One got back to me right away, and I began working on extra Hugo commands to present the screen as nicely as possible to screenreaders.  Eventually, I decided the wisest thing was to test it myself, so I installed JAWS for the first time in 10+ years and was painfully reminded that no Hugo interpreters- not even the glk one- work with it.

Still, some interesting threads came up in my research:

http://www.inthecompanyofgrues.com/?p=220 (and the thread discussing it) - Makes several interesting points about accessibility and was very useful in reassuring me about the usefulness of some of my ideas.

http://www.intfiction.org/forum/viewtopic.php?f=6&t=8690&start=0 - Lists interpreters that already work well with screenreaders.  Seems like the main deciding factor is whether text is selectable in the main window (without going to scrollback).

So yeah, my Hugo code is pretty useless until there's a Hugo interpreter that works with screenreaders (technically, there's a 16-bit simple DOS interpreter that should work but I've found that it crashes for larger games), so that project, too, goes on the backburner for a while.   Possibly I'll implement it in ZIL in the meantime.

ZIL!

Speaking of ZIL, I wanted to end this post with at least one tale of success.  I was quite excited to see Jesse McGrew's ZILF 0.7 release.  It comes with his complete re-implementation of Adventure and has examples of the kind of character command code I need for my ZIL project ideas.

As I did for Hugo, I made a notepad++ ZIL distribution with some syntax highlighting and buttons for project creation, compiling, and running games.  To be totally honest, I don't always keep the same kind of functions the same color, changing it up a bit for readability, but if people find that confusing, of course, feel free to edit it to your heart's desire (and I'd be interested to see what you do with it).

ZIL notepad++ screenshot

 Unfortunately, these standalone versions of notepad++ don't seem to work for people who have notepad++ already installed (and are storing settings in user settings).  At some point, I may write instructions on how to integrate these things into your own notepad++ installation, but it's complicated as the Customize Toolbar plugin I use to provide buttons doesn't currently allow for different-buttons-based-on-the-currently-open-file.

Anyhow, if you'd like to play around with it, you can get it here.

Announcing Roodylib 4.1.1 - the "Information" release!

So, a couple months ago, I had recently added a donation button to this blog.  A generous soul jumped on that right away.  I decided the best way I could pay him back was to improve the Roodylib documentation so people wouldn't have to dig through "roodylib.h" for all of the hidden features.

It took much longer than I had predicted, but I like to think that the final product is nicer than I originally foresaw, too.  Plus, writing the documentation led to a couple updates in Roodylib itself, so all in all, I'd say this was a good deal!

Download Roodylib 4.1.1 here

or...

Download the latest Hugo Notepad++ bundle

Changelog stuff

        * updated - BeforeRoutines, AfterRoutines, RepaintScreen, DoInventory

* some additional HugoFix object tree organization, a HugoFix recording playback helper, $mp tweak

* made automatic-door-opening look nicer

* if a key_object is set quiet, it won't automatically open a door until after it has been explicitly used

* USE_SCOPE_REACT for checking react_before/after of scope objects

* changed PreParseError to BeforeParseError

* changed USE_SMART_PARENTS to SMART_PARENT_DIRECTIONS

* attachable behavior improved, especially with regards to pushable things

* USE_JUKEBOX, USE_CONFIG_SYSTEM added

* better DescribePlace configuration support

* cleaned up some rollable-objects code

* reworked how some FORMAT & LIST_F and indentation stuff works

* updated documentation

Games That Never Were

So, this post is a little late, as I've been meaning to write it for at least a week or so as followup gratitude for the last donation.  Roodylib documentation is almost done- just some section introductions to write here and there and make some final decisions on text formatting (early shout-out to Paul Lee for proofreading!).

Anyhow, I figure reading about game-ideas-that-died can be a fun read so I'll write about a couple collaboration ideas that met untimely demises.

Uncanny Valley (collaboration with Robb Sherwin)

quick description:  Deadline-on-a-spaceship

In Uncanny Valley, you would play a female officer on a big spaceship with a large crew comprised of both humans and human-looking androids.  Some murders happen.  You investigate.  The possibility is raised that some of the androids are going crazy.  Some tense almost-killed-by-androids scenes happen.  Turns out they were programmed by that evil dick captain (or somebody. I forget what we decided)!

I think we wanted to do a Deadline that played a little more fair- having time-sensitive scenes that were largely clued by game events or triggered by player knowledge.  Robb had previously brought to my attention that Suspect pretty much had the best manual ever* (despite not being a very exciting game itself), and we wanted to contribute to the legacy of those games.

* I will always laugh at mentions of "Good evening, I'm Charles Edwards. I'm an emergency room surgeon. Have you ever been in an emergency room on Saturday night?".

Plus, I've always wanted to do something with Hugo's character scripting, and it seemed like androids were especially good for that.

We were also big fans of Jason Scott's The BBS Documentary and we wanted to do a shout-out to BBS culture, so the ship was going to have a BBS-based inter-ship communication system.  The player would read through hundreds of mostly-humorous messages, many from crew members you never meet in the game.

The ship BBS would be split into multiple sections, one where everybody has to post as themselves and one where people can use handles.  As the game progressed, you'd figure out this or that person was this or that handle, and there'd be ways to unlock hidden boards on the BBS, too.

This was my proof-of-concept of the computer system, where the top window would show the protagonist's thoughts as she learned important bits of information.

I was excited about writing about a female protagonist, too, as that's something I've never done.

I had a vision for the game that when the game starts, your character would look out a porthole and see a bunch of ASCII stars, setting a desolate mood in a nicely retro way.

My star-printing proof-of-concept

I even considered writing the randomly-generated stars to arrays so if the player changed the window size, the same configuration would be printed again.

Why It Didn't Happen and What Came of It

Most importantly, UV was a break from other projects and we never really committed 100% of our attention to it.  Eventually, we were distracted by the next project I'm going to talk about in this post.

Interestingly, Christine Love's Digital: A Love Story came out within the next several months, and while I didn't play it until much later, it also did the fake-BBS-society thing that I had loved in the 1988 adventure game, "Neuromancer" (and manages to do it in an enjoyable, concise way even) and was somewhat what we had aimed to replicate (and truthfully, I wasn't super excited to write all of the computer entries the game idea deserved).

What I did notice is that two space-based AIF games came out within the following year with similarities to our idea (one murder mystery with computers and one had a similar ship layout to what I had imagined), and that also made me less excited about ours.

My star-printing code helped inspire some of the random stuff in The Next Day eventually.

getting sleepy

dreaming

Loose Cannon (collaboration with Robb Sherwin and J. Robinson Wheeler)

quick description: comedic homage to 80s cop show/movie tropes

The first PAX East attracted a bunch of us IF enthusiasts, rallied together for a screening of Jason Scott's latest documentary, Get Lamp.

A few of us made a side trip to check out Infocom's old headquarters (and I'm wearing a jacket- I wasn't trying to bring flannel shirts back!)

I had the great pleasure of meeting a bunch of awesome people for the first time but also got to see some great people again like Robb Sherwin and J. Robinson Wheeler.  At one point, somebody suggested that we all do something together.

It was going to be set in that same sort of seedy, near-future of films like "Robocop."  As you probably would have guessed, you'd play the kind of character at whom a police captain screams, "You're a loose cannon!".  There was going to be a main villain who kills your partner.  I was even looking forward to doing a sort of slow-motion-presented-textually scene where the player could earn easter egg points by typing >NOOOOOOOOO    >OOOOOOOOOO over several turns; this would have been a challenge both in properly cluing to the player and handling on a parser level in Hugo, but I was looking forward to both.

Then we were going to team up the player with an android cop, a plot point that I wasn't entirely happy with (I thought Rob already had enough androids in his games!), but hey, I really wanted to give the first partner a death scene!

I wanted each section to begin with what looks like a torn piece of paper from script- didn't perfect the effect before the game was abandoned

Several scenes were going to rely on a particular game mechanic.  There was going to be a shooting gallery shootout, a car chase, and so on.  I even wanted to do a scene in a strip club with the protagonist sitting at the bar with only the strippers' legs within game scope.

Robb wanted the score to be sort of meaninglessly insane, where you can get hundreds or thousands of points at a time.  Since Hugo integers can only go to 32767, this involved coding a special scoring system.

What little we did also inspired some updates to one of my conversation extensions (long since put on the backburner in favor of Roodylib but I'll be quite happy with it when it's done).

you can't really *see* the cool things the conversation system does here but they're there!

Why It Didn't Happen and What Came of It

I think early on it became clear that we didn't all have the same vision for it, and communication and attention to it fell away and everybody went back to their own projects.

In 2013, J.J. Abrams produced a buddy cop tv show called "Almost Human" where the protagonist gets partnered with an android.  When I first heard of it, I joked that Abrams had hacked our e-mails (Abrams is also an Infocom fan, strangely enough).

I felt some elements of this game idea showed up in J. Robinson Wheeler's 2015 work, Moonbase Indigo, so if that sounds appealing to you, you should go check that out!

Later that year (2011), Robb released Cryptozookeeper.  You can help his latest WIP get Steam Greenlit here!

Trizbort! Maps!

So, first off, I had another super awesome donation to the blog, and this particular person loves maps so I thought I'd do a map-themed post.  The timing for it is great because Trizbort, the IF mapping program, recently added a feature to export maps straight to Hugo code!

One of my Trizbort maps.  Recent versions of Trizbort have the ability to declare groups of rooms as "regions," giving them whatever color you choose.  I'd like to make my old maps even prettier one day but picking colors and such is always such a headache.

Drawing a map can be a great way to get a head start on coding a game so I'm quite psyched that Hugo-code support has been added!  I tried the code export tonight; I did find some problems, but the release notes made it clear that is expected and I look forward to sharing my notes with Jason about the problems and a couple other suggestions!

Unfortunately, my map-loving patron has an Apple computer so she can't make Trizbort maps herself.  Maybe I'll try to map another, smaller game and make it as pretty as possible for her donation!

Documentation Update

Been making a lot of progress on the Roodylib documentation lately.  It's taken longer than I expected, but I'm pleased with how it's coming together and it has already resulted in some making-things-more-intuitive changes to Roodylib (with a couple more planned).  If I keep up this pace, I may have it done within a couple weeks, and Roodylib (and the Hugo notepad++ distribution) should both get official updates soon after!

so many cool-ass people doing cool-ass things

The other week, when I added a Paypal ™ button to this blog, I said something about wanting to list people I would donate money to if I could.  I didn't have links to share for everybody at the time, but I do now.  In no particular order:

• Nikos Chantziaras:  While Kent Tessman went to a lot of trouble to provide a full-featured Hugo interpreter for Apple computers, the chosen method used a software method that was largely abandoned (or, at least, if it was updated, the Hugo interpreter was not updated along with it).  Eventually, Nikos came along and wrote Hugor.  Besides bringing Hugo multimedia back to Mac and Linux users, Hugor is a very nice experiment in IF interpreters, providing several features not found in any other.  Besides Hugor, Nikos also wrote the QTads and FrobTADS interpreters.  I'd highly recommend them!
  
  You can help support Nikos at his sourceforge page.
  
• Juhana Leinonen:  Juhana has done so many cool projects, it's hard to know which ones to give top-billing.  Vorple, a javascript library for adding multimedia to Undum and Inform 7 games, has probably received the most acclaim despite having only seen a tiny percentage of its possibilities (I'm particularly impressed with some of its internet-using capabilities).  More recently, he announced Texture, an IF system designed with mobile devices in mind.  Personally, I've only recently gotten into smart phones and tablets, and I have to say that it was kind of disappointing shock to see how much of a hassle it is to play IF on them so I naturally loved this announcement.
  
  In the world of Hugo, he was the first to get Hugo games in a web browser (using a DOSbox implementation).  He also put together an online "story file parser" for checking out games' innards.
  
  Check out this page for a full list of his contributions (I really need to use that "IF Transcript Beautifier" more often).
  
  In any case, there is no way to donate money to Juhana, but he has some ideas for IF monetization in the future (especially in the realm of mobile apps), so go subscribe to his blog and watch for further developments!
  
• Jesse McGrew:  Jesse doesn't tinker in the world of Hugo, but he is cut from the same cloth as these others who improve the tools and such at our disposal out of a love for the medium.  His first wildly ambitious project was Guncho, a MUD ("multi-user dungeon") where authors can add new realms by writing Inform 7 code, making it possible to write truly-multiplayer interactive fiction using interactive fiction tools.
  
  These days, a lot of attention has gone to his ZILF compiler, a project that makes it once again possible to write games in ZIL, the same language created and used by the Infocom "Implementers."  If I was not working on taking Hugo as far as I can take it, I would probably be spending all of my time with ZIL.  While not exactly easy to code in for a non-programmer as myself, I find it wonderfully powerful in certain ways, and it's cool that once again, it is within our power to write good games that could conceivably be played on an Apple IIgs or TI calculator.
  
  You can follow the ZILF updates as he perfects his port of the game "Adventure" here, and you can donate to his IF endeavors here.
  
• Jimmy Maher:  With his blog "The Digital Antiquarian," Maher delves into classic computer gaming- both IF and not- and consistently provides enlightening forays into the stories behind the games of our youth (and a bit about the games themselves).  Of course, such a project of passion isn't going to completely free of the occasional editorial opinion, but even when I disagree with the sentiment on display, it's always great to see so much attention being given to something that also affected me so many years ago.
  
  I'm also am a fan of his Filfre interpreter for z-code and Glulx games; it's often my interpreter of choice for Glulx games that have graphics.  You can also get his King of Shreds and Patches game for the Amazon Kindle.  That is the first and only IF game I have played on the Kindle, and while a little sluggish (I had one of the earliest Kindle models), overall, I was very happy with the experience.
  
• Robb Sherwin:  For the most part, the only reason anyone even remembers that Hugo exists for the last 15 years is because of the games of Mr. Sherwin.  Anyone unfamiliar with his work should check out his games page.
  
  You can help Robb now by helping his latest game get approved on Steam Greenlight!
  
• Kent Tessman:  Of course, Hugo would not exist if not for its creator.  These days, his attention is devoted to his fantastic screenwriting program, Fade In.  I highly encourage anyone who has ever slightly entertained the "WAIT COULD I BE A SCREENWRITER?" idea to go get his program.  It continues to receive high praise from all sorts of industry greats, and compared to its competition, $50 for a lifetime license is not a bad deal at all.
  
  You can hear his latest screenplay, Chrome Noir, be given the "table read" treatment by a bunch of well-known actors (included Fargo's Colin Hanks) here. 

documentation update

So, work started off slower on the documentation than I predicted, but I'm pretty happy with the styling and approach I've come up with (lots of picture examples to show options in action with a little bit of IF theory thrown in here and there, too).  It'll probably be weeks before I'm finished, I think- and I'll probably tweak fonts and stuff to make it look as nice as possible- but I figured I'd share what I've done so far.

Check out the start of the new Roodylib documentation!

Suggestions are welcome.

Wow

Within just a couple hours of that last post, I was blown away by the generosity of a donation.  Not having any huge Roodylib-related tasks on my plate right now, I decided that it's time I put more effort into making Roodylib's documentation presentable.  I spent a couple hours already making an outline of topics I'd like to cover (with it all being easily browsable), resulting in this:

https://docs.google.com/document/d/1Il43tgoKx1urUcJMkpAJLVH9UupLFi3IL_ICEbg9QNU/edit?usp=sharing

I still have to order it so all of the things most useful to new authors and authors-getting-acquainted-with-Roodylib are explained first.  Right now, the plan is to write the entire thing in LibreOffice, but I may export to PDF for the final copy (in the past, I used an open document just because I figured I could use it basically as a fancy readme text file, but I guess there's no real reason I can't just make the whole thing look nicer).

Anyhow, one thing I'd probably like to do in the documentation is have bits of sample code here and there.  Anyone have any experience with inserting code in open documents (what styles/formatting look best, is there a nice extension for this, etc)?  So far, googling hasn't exactly been my friend, and any advice would be appreciated.

added a paypal button

Now, considering that Hugo has like 5 users in the world, I don't actually expect any money to come in, especially with everyone having mortgages and family and this and that to take care of.  Just the same, things have been tight for me, too, and I figured I might as well put the option out there just in case anyone wants to contribute but just hadn't thought of it yet.

To be perfectly honest, donations probably wouldn't make the next major release of Roodylib come out any quicker (since I work on it pretty consistently anyhow), but if any patron has a particular feature they'd like to see incorporated into Roodylib (or the creation of a useful object class), those things will be given a high priority.  Actually, even if you can't afford to donate anything, if anyone has anything they'd like to see, just let me know.  I'll probably do it, ha.

I was going to finish this post with links to other people who I feel contribute a lot (much more than myself) and would be great options to support, but finding donation buttons for them was harder than I remembered.  I'll have to edit this post after I've talked to them to see if there are pages I've missed.

Configuration Files

I don't remember what prompted it, but something got me thinking about configuration files in Hugo and how I never perfectly designed a way to detect if an interpreter fully supports them.

See, the FILE_CHECK constant-checking method described in the Hugo manual doesn't work with Gargoyle.  Not only that, but Gargoyle can read configuration files- just not write to them- so if a configuration file has been created by another interpreter, previously, the game could easily be tricked into thinking everything is working fine.  Adding even more complication is that configuration-file-writing does work in the glk Hugo interpreter (even though no one ever uses that one) so I couldn't just do a simple "minimal port"check.

So I brought my attention to this the other day.  Eventually, my fix for the problem involved using Hugo's system-time-catching functionality (along with Future Boy!'s time-handling routines) to take the current time, save it to the configuration file along with everything else, then read the time back from the configuration file.  Then it calculates the difference between the two times, and if it's longer than 5 seconds (I'm trying to account for really slow computers here even if a 2 second timer would probably still be playing it safe), it calls the configuration error routine (so a game like "the Halloween Horror" can quit out, as it relies on configuration files).

In other news

Herr Jizaboz finished his demo game about a tourist in North Korea.  I've helped him with it here and there.  I hope people get a big kick out of it!

A Day in DPRK

Also....

Looks like there was a Notepad++  update so I also updated the Hugo Notepad++ distribution.  You can get it here.

Formatting

In that last bout of Roodylib attachables improvement, playing around with the "Vault of Hugo" sample game made me check out some other things, too.  Specifically, I was reminded that Roodylib's doublespace formatting option worked imperfectly.  This is how it looked when it attempted the Vault of Hugo's "Object Room."

(there are no commands listed since it is the result of a recording playback)

As you can see, spacing is inconsistent, with no extra lines between the two items with short_desc's (and all of the non-short_desc-related objects are clumped together, too).

I set out to fix this- and not only that, as I also decided I wanted Roodylib to have an option for smart room descriptions if the player is in an object (I had gotten a test case of this working months ago but it still required some code clean-up and adapting to put it into Roodylib).

Not only this, but I also wanted to make sure that rooms printed properly with the LIST_F format option on.  This is the setting that does "tall" listings like those in Zork:

>look

West of House

You are standing in an open field west of a white house, with a boarded front door.

There is a small mailbox here.

The small mailbox contains:

  A leaflet

>

I can't remember how broke the alignment was before I started this latest wave of improvement.  Might have not been that broke, but with Hugo, "The small mailbox contains:" was indented once and the next line twice.  This was probably intentional, but to be honest, I prefer the Zork version.  Hugo also didn't capitalize the article for children like "A leaflet".  I've changed that, too, since again, I liked the Zork way.  If I had my druthers, I'd make both of these things optional but as it is, configuring DescribePlace to your needs is already going to be a bunch of global variable tinkering and flag setting.  Still, one day I might re-design the WhatsIn and ListObjects routines so they're much more configurable.

While I was at it, I also added my system for smarter listing when the player in a container in the room (it's possible to configure it to also do platforms, but it was hard to come up with a wording that'd work for all cases- if you're on a chair, do you really want to describe all other objects in the room as "off the chair"?).

FORMAT global set to DESCFORM_F and COOL_PARENTS flag set

FORMAT with LIST_F (you'll notice that I changed how Indent works with LIST_F just so the two systems use the same logic)

The cauldron and the grandstand listed are not in the original game.  I added them just to test the part of DescribePlace's code that lists the children of scenery items.

Now let's take a look at some of the behavior if the NEW_DESCRIBEPLACE flag is set.

NEW_DESCRIBEPLACE with doubles-pacing on

The new DescribePlace defaults to having children of scenery listed right away, right after children of parent-of-player.  I figured it's better for them to be closer to wherever they were mentioned in the room text.  Ideally, I'd have an extra check in there to list attachables-connected-to-scenery objects right up there, but I don't think that comes up enough to justify the extra work for now.

With double-spacing on, it only prints newlines (and the extra space) when it needs to.  All those extra spaces might look kind of ugly in that example right there (since that room has so many objects), but I'm fairly certain that it'll look quite nice in the average IF game.

I'm pretty happy with the different options I've given the DescribePlace system although the extra settings I've created could probably use some finessing.

Right now, there are the following additional Roodylib options:

• Set the "COOL_PARENTS" flag (this gives the room better relative text when the player is in a container in the room)...  My gripe about this name is that it's close to my SMART_PARENTS flag (which gives better responses when a player tries to go in an unavailable direction while, like, sitting in a chair or something).
• Give FORMAT the DESCFORM_I mask. DESCFORM_I gets rid of the extra new line before a room title is printed, based on Infocom layout (hence the I).  Just the same, the F in DESCFORM_F probably stands for "flag" so changing it to I is probably just confusing.
• Set the "NEW_DESCRIBEPLACE" flag.  This gives the extra functionality of the new DescribePlace code.  I'm pretty fine with this one.
• Give FORMAT the DESCFORM_D mask.  If the new DescribePlace system is on, this turns on double-spacing.

Beyond the probably-confusing names of my new masks and flags, I'm not sure I even want to expect new authors to know how to change this stuff- if I recall correctly, FORMAT masks are covered very briefly in the manual; pretty sure I learned most of what I know just by looking at hugolib.h.

I'd like to make it easier for authors by creating some routines that will set the game to the formatting they prefer, but even that is kind of a headache. *

* I was going to continue with the annoying aspects of trying to design and name helper routines, but I think I might have an idea I'd like to play with.  Stay tuned!

automatic door unlocking/opening

So, in posting that "Vault of Hugo" transcript the other day, I was reminded my dissatisfaction over the messaging in my first attempt at automatic door unlocking.  Here's the applicable part again:

>dig ground
You find a rusty iron key!
(Taken.)

>e
(unlocking the vault door first)
(with the rusty iron key)
Unlocked.
(opening the vault door first)
Opened.
It's pitch black in here. Stumbling around in the dark isn't such a hot idea: you're liable to be eaten by a grue.

>

Now, the automatic-door-unlocking was one of the first things ever added to Roodylib so, of course, I've learned a lot since then and I thought it was worth taking another swing at it.  Here is a transcript of what would happen now:

>dig ground
You find a rusty iron key!
(Taken.)

>e
(unlocking the vault door with the rusty iron key first)
Unlocked.

(and then opening it)
Opened.

It's pitch black in here. Stumbling around in the dark isn't such a hot idea: you're liable to be eaten by a grue.

>

As you can see, it now combines information where it can, and I added some spacing to make it prettier.  The "(and then opening it)" message was especially tricky to do, but I think the code I threw together should work well enough (it relies on checking the parser_data[PARSER_STATUS] value, and I don't see that changing anytime soon).

I also threw in an option where, if the key object is set quiet, a regular >UNLOCK DOOR asks the player to be more specific or in something like the instance above, does:

>dig ground
You find a rusty iron key!
(Taken.)

>e
The vault door is locked.

>unlock door with key
Unlocked.

>lock door
(with the rusty iron key)
Locked.

>e
(unlocking the vault door with the rusty iron key first)
Unlocked.

(and then opening it)
Opened.

It's pitch black in here. Stumbling around in the dark isn't such a hot idea: you're liable to be eaten by a grue.

>

 I figure there might be instances where you want the player to figure out which key is correct.  After being used correctly once, it'll do automatic unlocking/locking no problem from then on.

Anyhow, I wanted to put the feature there, but I doubt many people will use it so I won't even go to the trouble of aliasing quiet to another more-apt attribute name to be used in these instances.

Attachables

In preparation of the next official release of Nikos Chantziaras' Hugor, I've been playing through Kent Tessman's Future Boy! again as it is basically the only Hugo game in existence that uses Hugo's movie feature.

In one late scene, there is a rope and a wheelbarrow (the wheelbarrow isn't especially important- I get the feeling it mostly exists just to show off Hugo's capabilities) and I found some inconsistent behavior.  This got me looking at Hugo's attachables code, in particular how it works with pushable items (like Roodylib's USE_ROLLABLES switch).

It took a couple attempts, but I eventually got Roodylib working as I would like it.  To test it out, I made the mine car in "Vault of Hugo" a pushable object.  Here is a transcript with the new code in place:

You brace yourself, check your flashlight, and, with source code in hand, prepare to enter...

THE VAULT OF HUGO
An Interactive Example
Hugo v3.1 / Library 31031

Outside a vault
Kind of that 1930s, Bela Lugosi, graveyardy motif at work here. It's a pretty creepy place. Directly in front of you is the giant door to an even more giant vault. Above the door hangs a rusty sign.

>dig ground
You find a rusty iron key!
(Taken.)

>e
(unlocking the vault door first)
(with the rusty iron key)
Unlocked.
(opening the vault door first)
Opened.
It's pitch black in here. Stumbling around in the dark isn't such a hot idea: you're liable to be eaten by a grue.

>turn on light
A beam of serviceable light appears from your flashlight.

Inside the vault
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
An old mine car sits abandoned to one side.

>push car n
Something seems to be stopping the mine car from rolling.

>look under car
You find a big rock lodged between the wheels, which you manage to wrestle out of the way.

>push car n
You push the mine car over to the...

Object Room
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
An old mine car sits abandoned to one side.
A wooden chair, a card table, a transparent box, and an opaque box are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper.
A green dart is sticking out of the old dartboard.
A heavy rope is tied to the wooden chair.

The mine car slows to a stop.

>tie rope to car
You tie the heavy rope to the mine car.

>push car s
You can't move the mine car while the heavy rope is still tied to to the wooden chair.

>enter car
You get in the mine car.

Object Room, in a mine car
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
The old mine car is loaded with a pencil.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
A wooden chair, a card table, a transparent box, and an opaque box are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper.
A green dart is sticking out of the old dartboard.
A heavy rope is tied to the wooden chair and the mine car.

>drive s
You can't go anywhere while the heavy rope is still tied to the wooden chair and the mine car.

>out
You get out of the mine car.

>untie rope from chair
You untie the heavy rope from the wooden chair.

>push car s
(with the heavy rope tied to the mine car)
You push the mine car over to the...

Inside the vault
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
A big rock and a mine car are here. The old mine car is loaded with a pencil.
A heavy rope is tied to the mine car.

The mine car slows to a stop.

>enter car
You get in the mine car.

Inside the vault, in a mine car
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
The old mine car is loaded with a pencil.
A big rock is here.
A heavy rope is tied to the mine car.

>drive n
(with the heavy rope tied to the mine car)

Object Room, in a mine car
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
The old mine car is loaded with a pencil.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
A wooden chair, a card table, a transparent box, and an opaque box are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper.
A green dart is sticking out of the old dartboard.
A heavy rope is tied to the mine car.

>get rope
Taken.

>push car s
To walk, you will have to get out of the mine car. Otherwise, try "roll" or "drive" and a direction.

>drive s

Inside the vault, in a mine car
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
The old mine car is loaded with a pencil.
A big rock is here.
The heavy rope that you're holding is tied to the mine car.

>out
You get out of the mine car.

>push car n
You push the mine car over to the...

Object Room
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
A wooden chair, a card table, a transparent box, an opaque box, and a mine car are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper. The old mine car is loaded with a pencil.
A green dart is sticking out of the old dartboard.
The heavy rope that you're holding is tied to the mine car.

The mine car slows to a stop.

>enter car
You get in the mine car.

Object Room, in a mine car
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
The old mine car is loaded with a pencil.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
A wooden chair, a card table, a transparent box, and an opaque box are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper.
A green dart is sticking out of the old dartboard.
The heavy rope that you're holding is tied to the mine car.

>drive e
You can't roll that way.

>drive s

Inside the vault, in a mine car
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
The old mine car is loaded with a pencil.
A big rock is here.
The heavy rope that you're holding is tied to the mine car.

>drive e

Character Room, in a mine car
The Character Room provides a couple of good examples of character scripts and events. Exits are north and west.
The old mine car is loaded with a pencil.
A burly guard is here.
The heavy rope that you're holding is tied to the mine car.

The guard lifts his big boot up to the mine car and gives you a firm shove back out the door. "Not in that thing, you don't, pal!"

Inside the vault, in a mine car
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
The old mine car is loaded with a pencil.
A big rock is here.
The heavy rope that you're holding is tied to the mine car.

>drop rope outside car
Dropped.

>drive e
(with the heavy rope tied to the mine car)

Character Room, in a mine car
The Character Room provides a couple of good examples of character scripts and events. Exits are north and west.
The old mine car is loaded with a pencil.
A burly guard is here.
A heavy rope is tied to the mine car.

The guard lifts his big boot up to the mine car and gives you a firm shove back out the door. "Not in that thing, you don't, pal!"

Inside the vault, in a mine car
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
The old mine car is loaded with a pencil.
A big rock is here.
A heavy rope is tied to the mine car.

>out
You get out of the mine car.

>push car e
(with the heavy rope tied to the mine car)
You push the mine car over to the...

Character Room
The Character Room provides a couple of good examples of character scripts and events. Exits are north and west.
A burly guard is here.
A mine car is here. The old mine car is loaded with a pencil.
A heavy rope is tied to the mine car.

The mine car slows to a stop.

The guard lifts his big boot up to the mine car and gives you a firm shove back out the door. "Not with that thing, you don't, pal!"

Inside the vault
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
A big rock and a mine car are here. The old mine car is loaded with a pencil.
A heavy rope is tied to the mine car.

>get rope
Taken.

>e
(with the heavy rope tied to the mine car)

Character Room
The Character Room provides a couple of good examples of character scripts and events. Exits are north and west.
A burly guard is here.
A mine car is here. The old mine car is loaded with a pencil.
The heavy rope that you're holding is tied to the mine car.

The guard lifts his big boot up to the mine car and gives you a firm shove back out the door. "Not with that thing, you don't, pal!"

Inside the vault
Standing in the middle of this dimly lit chamber, you realize that just maybe you should've splurged on a more expensive flashlight. You also realize that there are four ways you can go: a marble archway to the north, a muddy cave opening to the east, an oak door set in a brick frame to the southeast, and west back outside where you came from.
A big rock and a mine car are here. The old mine car is loaded with a pencil.
The heavy rope that you're holding is tied to the mine car.

>n
(with the heavy rope tied to the mine car)

Object Room
This room contains a collection of objects with different properties, attributes, and associated routines in order to give some idea of basic object design. In addition to the various furnishings, you notice a dartboard hanging on one wall.
A large drum--not the musical kind--is here. Attached to it is a warning note.
Lying in the corner of the room is a non-descript, unnamed object.
A wooden chair, a card table, a transparent box, an opaque box, and a mine car are here.
A deck of playing cards has been placed appropriately on the table.
Also sitting on the card table are three shiny gold coins and a pad of paper. The old mine car is loaded with a pencil.
A green dart is sticking out of the old dartboard.
The heavy rope that you're holding is tied to the mine car.

>

So, if you read carefully, you may have noticed that it mentions the attachables if the rope is being dragged or pulling something, but it doesn't if the player is just holding it (I also added some code so held attachables tied to something in the room are mentioned in the room's description).

My new code might not work in every situation (in fact, I can think of at least one instance in which it won't), but attachables are so rarely used in any case; if the day comes that an author codes something that doesn't work with the new code (specifically, the attachable would have to be tied to something in a container and the player would have to GO in a direction that leads to a locked door or something), I'll be happy to help them tweak their code so that it works.

Interestingly, playing around with "Vault of Hugo" inspired me for what I'd like to work on next, too, which is smarter room descriptions when the player is in a container or on a platform.  I've successfully coded that in the past so it's mainly a case of integrating it into Roodylib as cleanly as possible.

Roodylib 4.0 and Hugo Notepad++

So, official Roodylib 4.0 is out!  Here is my announcement from the couple places I posted about it:

"Roodylib," my collection of updates to the Hugo library files, just had its 4.0 update. I feel that it's come a long way and has plenty of nice bug fixes and added functionality. I'd hope that any Hugo author checks it out. I've uploaded it to the IF Archive (should be in "unprocessed" right now), but you can always download the latest official version here, too: https://goo.gl/0s67c4

Windows Hugo users new and old may also be interested in a Notepad++ package I've put together for Hugo (this seems allowable by its licensing as it only insists that info remains intact for finding the official Notepad++ site and I did not delete any of the included readme's). It adds several toolbar buttons for easy compilation and running games, and it handles directory management (one of the trickier things, IMO, for the budding Hugo author). Best of all, it's a standalone program so it can be put on a USB stick and carried from computer to computer. Download Hugo Notepad++

As you can see, I didn't really go into new features and fixes.  For that, you'll want to take a look at the changelog text file in roodylib_suite.zip or even look at all of the new comments in roodylib.h.

I already have plenty of ideas for the next Roodylib release.  Some are:

• Overhaul the entire pronoun system. I was going to do this for 4.0, but when I polled the public, I found there were too many competing theories on how pronouns should work. Instead of trying to sort it out all now, this task has been moved to "someday."
• Add some commands with accessibility in mind (specifically, for the visually impaired).  One thought is a "STATUS" command that reiterates the information that is displayed in the status bar.  Another idea is a "PROMPT" command to change the prompt for people with text-to-speech software (something like >PROMPT "What now?"  so the prompt is "What now?" instead of ">").
  
  This idea has actually been on my mind for months, and I've tried to get in touch with the visually-impaired gaming community for their suggestions but my attempts did not work.  Luckily, a thread about this showed up on the intfiction forums, and one fellow in particular is going to research the issue to find out what more can be done.  I'll re-visit this idea then.
•  I'd like to add FakePrompt to Roodylib, with some extra routines to automatically draw windows for whatever question is being asked (FakePrompt is a cool way to get the exact thing a player types without having to try to train them to put it in quotation marks).
• I'd like to also just incorporate a handful of other extensions into Roodylib, just so authors don't have to go searching around for too many things every time they start a new project.  Much easier to just add a flag to their code, I would think.
• It's not Roodylib, but I also need to re-visit Hugo By Example and update a ton of its pages.  The whole "replacement routines" category is pretty much what turned into Roodylib, and it'd probably be better to just have a nice Roodylib section where I explain how things work better.  That and just general updating all around.

So, I have all of those ideas, but I'm hoping to ignore them all for a while and spend some time on my own games.  I really neglect them when I have Roodylib things to work on, and it'd be good if I made some progress.  We'll see how it goes!

Disambiguation In Action

I've been keeping this screenshot on my Desktop for a few months.  It's from a soon-to-be-released game by Michael Wayne Phipps Jr.  I just thought it was great to see Roodylib's new disambiguation system in action in another person's game.

Note:  The screenshot uses a build of the game I compiled myself when I was playing around with my own color scheme so it does not reflect the color scheme of the final game.

resource file management

It can be tricky to keep files organized when creating games that use resources.  Ideally, one would want to keep resource files in their own folder, whether it be a "resources" folder in the game source's directory or a folder within the designated resource fold (the HUGO_RESOURCE environment variable path).

Unfortunately, the DOS/Windows compiler sometimes has trouble recognizing these paths.  I've found that something like:

resource "testres"

{

"test\magnolia.jpg"

}

Will work if "test" is a directory in the same folder as the file being compiled, but it won't work if "test" is a folder in the resource directory (this behavior might not be the same across all platforms, of course).

I think there are two workable methods for nice file management.  One is to do the thing just mentioned- put your resource files in a folder in your game directory.  Hopefully the above resource path works across all platforms.

The other method is compile your resource file completely separate from your game (using the same method reserved for precompiled headers).  To do this, you'd create a .hug file in your game resource directory and only have your resource definition (like the one above).

Then, compile that file with the -h switch, which should make both a precompiled header file (with the *.hlb extension)- which you can just ignore- and your resource file(s).  Then, have your game code call stuff from that resource file like it'd normally would.

Really, both methods should work.  I guess I figure one of the perks of the second option is that it forces you to not re-compile your resources any more than you need to so in the long run, it should save you some time.

Pronouns!

I've been doing a lot of pronoun-handling improvement stuff lately, and it's basically ready to add to Roodylib.  First, though, I need to gauge what people's thoughts on average-game pronoun-handling is.  Please take this survey!

https://www.surveymonkey.com/s/3TB5XX5

LinesFromTop

So Roodylib has that LinesFromTop routine that allows games to write text from the top of the screen.  Personally, I prefer that top-justified look.  The downside to using it is that it won't work with games that use PicturesInText (the routine for drawing graphics in the text window) and it can cause bad behavior in DOS interpreters.   Since some of those DOS interpreters are not "minimal" ports, there's really no easy way to check for it.

Authors who doesn't really care about whether their text is top or bottom justified should just have the LinesFromTop routine return display.windowlines.  Personally, I consider DOS archaic enough that I'd possibly release DOS versions of games just so most people get the "nice experience."

(That said, we'll probably have some online Hugo games in the near future through the use of a web DOSbox instance, so they would definitely have to use DOS-friendly code.)

Weird Parser Tricks

Originally, this was going to be like a 4 part post detailing different approaches to trying to accomplish a certain goal, but man, the problem is really obscure and I don't even feel entirely comfortable treating it like it's a real problem.

The history is, ok, so one of Hugo's early adopters (who disappeared years ago) thought it was important to be able to have a dynamic vocabulary.  He thought it was too much of a clue to be able to see what words the game understood.  I never thought this behavior was exactly worth the effort involved in creating the illusion, but I thought it seemed like an interesting coding challenge.

More recently, a friend of mine has been playing "The Lurking Horror" for the first time.  It got me thinking about whether "uhlersoth" (the password for the pc) was even in the game's dictionary table.  It isn't, and I thought about ways to do a similar thing in Hugo.

My first approach involved using ParseError (well, Roodylib's PreParseError, to be precise) to fake understood responses and then checked parse$ letter by letter to see if it matched "uhlersoth."  This worked, but the problem with doing important stuff in ParseError is that it doesn't count as an actual turn so if the player types >UNDO, it's likely that the game is UNDOing a turn they don't expect.

To get around this, I even wrote some code that I called a "fake undo" so the game, in those instances, would just give a regular UNDO response without actually doing anything.

Eventually, I decided it was altogether better to have PreParse code that forces a "hey I didn't understand that" message when your password is used outside of the password prompt.  If you really don't want the password to be in the game's dictionary table, you could also write it to the dictionary after the game has started (using dict).  The way I feel, there isn't an easily available dictionary script to use on Hugo games, and if someone goes to the trouble of writing their own, more power to them.  It's not the same IF scene that it was 15 years ago when we worried about these things (treating our games like some secret treasure).

 If, at any point, anyone wants example code on how to do any of these things, I'd be happy to share.  I just don't want to include it right now since, really, this kind of stuff isn't really important to you guys writing your games out there.

The one thing I decided is worth sharing now is actually the "fake undo"  since that PreParseError trick is sometimes used for things like calling people with phones, where you want it to seem like the game understands more answers to >CALL <BLANK> than it actually does (and after doing so, you'd like the game to pretend it's UNDOing the right thing).


Although, to be honest, I'm not entirely certain of this approach so it's still possible it could cause some headaches.

Anyhow, the next goal for me is to finally get the next version of Roodylib out. Hopefully soon!

rotating descriptions (alternate method)

A question to me got me thinking about object property arrays, and it occurred to me that'd be another reasonable way to handle rotation descriptions.  The main perk of this method is that you wouldn't have to replace the routines if you have more than 5 descriptions to work with.  The big question to Hugo coders is whether:

long_desc

Rotate

rotate_desc "It's a door." "It's still a door." "Stop looking at it." \

"I mean it." "I really do."

Is as acceptable as:

long_desc

{

rotate( "It's a door.", "It's still a door.", "Stop looking at it.", \

"I mean it.", "I really do.")

}

Anyhow, here is the entire code if anyone wants to see it!

object description rotation

This suggestion was made to me:

Another thing that would be handy would be some kind of list manager like in TADS or Inform that would make it easier to make things that change descriptions every time you look at them. For example:

long_desc

{

    rotate( "It's a door.", "It's still a door.", "Stop looking at it." )

}

Now, traditionally, you would do such a thing with code like this:


But, of course, sure, some helper routines could be written for anyone who wants the functionality of the suggestion above.  Following is some example code for doing such a thing.  I guess I could add it to Roodylib if enough people think it'd be useful.


And examples of objects that use these would look like:


So, yeah, let me know if you guys want it in Roodylib or what.

Scene Managing

Lately, I was looking at the code for a game that used constants and a global variable to keep track of scene changes, something I've done in at least one of my WIPs, too. It got me thinking that it'd be nice to have some code available for spitting scene stuff out so authors don't have to reinvent the wheel each time.

A room might check scene settings like this:



And here is the actual scene routines and code:



Anyhow, not sure how useful this will be to most people so I probably won't add it to Roodylib, but there it is!