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!