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.