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!

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.