Happy Thanksgiving!

So, now that all of my siblings and I are well into our adult years, we've gotten into a tradition of having "SiblingMas," where we are only responsible for the gift of one sibling (hey, I've got five siblings).  Spouses are included, too.

In the past, we've picked names out of a hat, but someone would often pick their own spouse and it was just an imperfect system.  This year, I thought, huh, why don't I write some Hugo code to fix this?

(There is also a "KidsMas," where my nephews and nieces get one cousin to get a gift for- but their own siblings should be disallowed.)

I wrote a program to handle both cases.  It uses Roodylib's object sorting code.

rot13 (string manipulation example)

The other day, I was thinking about how Robb Sherwin's Necrotic Drift paid specific homage to the old Magnetic Scrolls games.  I remembered how the MS games used a letter-substitution code for their hints (actually, the whole point of this article is that I misremembered it as rot13 but looking now, I see it was just one-letter-away substitution) and thought, huh, wouldn't it be neat if something like that was put into a future version of Necrotic Drift, where the game itself would both provide the coded text and decode it?  I thought it'd be fun to code up an example to share here.

First off, if  you're not familiar with ASCII, each letter has its own numerical value.  You can see them in this chart:

String manipulation in Hugo is mainly a matter of checking for these values and changing them to what you want.

For my "rot13" code to work, the game would have to use a "string" grammar token (the one where the string has to be provided in quoted text, like >WRITE "KILROY WAS HERE" ON ELEVATOR WALL)- something I've found is very hard to train the player to do, but, oh well, this post isn't about how to teach players to use quotation marks where we want them.



EDIT:  Ok, I was wrong about the one-letter-off thing, too, even though I guess some of the official hint books were like that.  This actually the Magnetic Scrolls code I remembered:

Of course, I'd have to find out how it worked before I could decide whether I could replicate it in Hugo!

another DoLook update

So, while testing the new Roodylib code on old released code such as Kent Tessman's Spur, I came across things like Spur's "Little Jimmy" character where the object's/character's inventory is listed in the long_desc.  The problem with that is that verblib.h (and my update to DoLook) still print a new line after the long_desc even if everything has already been listed and no object-content text is going to be printed.

Originally, I was going to make a post here about how the best solve for that is to make a before routine for the object for DoLook, have it run the long_desc and return true so the rest of DoLook is never called.  Just as I was going to write the post here, though, I thought, eh, I'll take another look and see if I can fix DoLook since the before routine method sort of seems like weaseling out.

The good news is, I think I found a solution I'm generally happy with.



You may notice that the call to WhatsIn has an extra argument.  Normally, WhatsIn goes through every child of the object and clears its already_listed attribute before going on to list things.  I updated it so it does not do that step if the second routine argument is true (which is why DoLook has to clear already_listed before the object's long_desc property is even run).

This is how Little Jimmy's long_desc would look with the new code:


(Basically, the only change is that it marks the taffy as already_listed- of course, I probably should have moved it so it's only marked if Jimmy is holding the taffy, but in this case, it shouldn't affect anything.)

the Lazy Hobo Riddle

The other week, somebody mentioned this funny coding problem on the ifMUD:

There once were 4 hoboes travelling across the country. During their journey, they ran short on funds, so they stopped at a farm to look for some work. The farmer said there were 200 hours of work that could be done over the next several weeks. The farmer went on to say that how they divided up the work was up to them. The hoboes agreed to start the next day.
The following morning, one of the hoboes - who was markedly smarter and lazier than the other 3 - said there was no reason for them all to do the same amount of work. This hobo went on to suggest the following scheme:

• The hoboes would all draw straws.
• A straw would be marked with a number.
• The number would indicate both the number of days the drawer must work and the number of hours to be worked on each of those days. For example, if the straw was marked with a 3, the hobo who drew it would work 3 hours a day for 3 days.

It goes without saying that the lazy hobo convinced the others to agree to this scheme and that through sleight of hand, the lazy hobo drew the best straw.
The riddle is to determine the possible ways to divide up the work according to the preceding scheme.

I thought it'd be cute to code it up in Hugo.



Now, that version allows for straws being the same length.  If we can assume that every straw is a different length, we can make each inside loop start at a higher value from the outside one.  We can also break out of the loops if the length on the first straw is incremented to the point that it shares a value with the first possible second straw.

parser conflict checking improvement suggestions?

One of HugoFix's useful-sounding but rarely-used tools is the parser conflict checking command.  If you provide it with an object, it checks against the rest of the game and lists any other objects with shared adjectives or nouns.  If you don't provide an object, it checks every object in the game against every other object.

Anyhow, I like what it does, but here is the current format of the output:

Part of me thinks that it can be improved so it's easier to read, but I haven't yet put too much thought into it (which is why I'm throwing it out to y'all, ha).

Roodylib developments

So, since the last official release of Roodylib, I've somehow managed to get sucked into a ton of tweaking-the-parser type stuff, things that I didn't really even see myself taking a look at just a couple months ago.  Most audaciously, I have moved some of the parsing gruntwork out of the Parse routine and into routines like FindObject and Perform (routines called after the parsing cycle is done).  There has been a lot of attention to the parsing of orders to NPCs.  I've also taken a stab at changing how the pronoun system works.  No longer will authors have to set the object global to "-1" just to make sure AssignPronoun (*) actually works like we want.

some parser responses under the new code

Now, for much of that, the responses are just what you'd expect out of a game, but, of course, that's mainly the point.

Overall, I like where this all is heading, but really, I've tweaked so many things that I could have introduced a ton of small bugs so I've been trying to get more testing of this new code than I usually ask for before an official release.  To do so, I have compiled several games with code available with the latest Roodylib code.  If interested, you can play them here (last updated November 14th with the new pronoun code):
https://drive.google.com/file/d/0B_4ZXs4Z_yoWalJZRGJIVElBbmc/view?usp=sharing

And feel free to take a peek if you are curious about new code.  Like I said earlier, most of the important stuff is in Parse, FindObject, ParseError, or Perform (and SpeakTo).

* My updated AssignPronoun uses a second argument in cases where the author wants to force the pronoun setting.