I'm no good at versioning

I recently ran into some annoyances with my WIP where I realized that Hugo's default message for GO-ing at a non-enterable object is "You can't enter that."  I think, more often than not, GO TO <object> will be typed by an IF newbie unfamiliar with IF's world model.  I have updated DoGo to reflect this.  It now results in a "<the object> is right here." message.

Anyhow, I had forgotten that I had already uploaded a version 3.5 of Roodylib (in my memory, I was still sitting on some changes for the next version), so I have uploaded another version 3.5.  Don't care enough right now to change it.

Other things:

• Been meaning to write a game design theory post with thoughts about designing routines for jumping around your game.  My WIP has several dream and flashback sequences that can be triggered almost whenever so debugging theory has been on my mind.
• I asked Kent for some ideas for responses for the "You can't enter <the object>." replacement mentioned above.  Besides giving several responses, he jokingly suggested randomizes between them.  It didn't sound like a terrible idea, though.  While I wouldn't provide multiple, random responses to something like verbstub verbs, I could almost imagine randomized responses for some hugolib-centric messages, like ParseError or something.  Ideally, it could give the illusion that the parser/library is more robust than it is.  Still, at the moment, it's probably not worthwhile to go through hugolib and decide which responses could be multiplied.  More important things to do.

"You can go"? We can do!

So, Robb Sherwin's game, Necrotic Drift, was recently available in a games bundle. One of the perks of buying the "deluxe" version that was included was the original game source. I picked up a copy myself, and lately, I've been updating ND to use Roodylib and attempting personal challenges like tweaking the window sizes to work better with multiple displays.

Necrotic Drift uses Cardinal Teulbach's can_go.h extension. I've already forgotten if I had specific gripes, but I've long thought that we could improve on its design. A couple days ago, I decided to finally do something about it.

I had some ideas for things that'd improve can_go, but my plan quickly morphed into something I'd have to write myself. I never liked how YouCanGo (the routine that prints the "You can go" message) does all of the exit-figuring calculations every time it is called, and I liked it less now that I have personally run into problems from writing to too many array slots between turns.

I decided to implement a system where, on the entrance to a room, I'd move around some objects to save the configuration of available exits, so then, every time I want to print the exits, the printing routine can just go look at the relevant objects.

Here is the new can_go.

I also did a version that is an update to Teulbach's can_go. While I changed the behavior of how the preposition property is handled, the new version should be mostly compatible with games written for the old system. Besides adding some feature, I optimized the code a bit here and there to cut down on unnecessary loops.

Here is the update to the old can_go.

I originally forgot to put door support into my new design. In adding it, I discovered an existing problem in Roodylib's DoGo's handling of non-door items with door_to properties. See, &object.door_to refers to door_to property routines while object.door_to refers to simple properties. It is important to check for both in your code.

Anyhow, Roodylib on bitbucket has already been updated, and the fix will show up in the next official upload to HbE (it'll be version 3.2).