Trizbort! Maps!

So, first off, I had another super awesome donation to the blog, and this particular person loves maps so I thought I'd do a map-themed post.  The timing for it is great because Trizbort, the IF mapping program, recently added a feature to export maps straight to Hugo code!

One of my Trizbort maps.  Recent versions of Trizbort have the ability to declare groups of rooms as "regions," giving them whatever color you choose.  I'd like to make my old maps even prettier one day but picking colors and such is always such a headache.

Drawing a map can be a great way to get a head start on coding a game so I'm quite psyched that Hugo-code support has been added!  I tried the code export tonight; I did find some problems, but the release notes made it clear that is expected and I look forward to sharing my notes with Jason about the problems and a couple other suggestions!

Unfortunately, my map-loving patron has an Apple computer so she can't make Trizbort maps herself.  Maybe I'll try to map another, smaller game and make it as pretty as possible for her donation!

Documentation Update

Been making a lot of progress on the Roodylib documentation lately.  It's taken longer than I expected, but I'm pleased with how it's coming together and it has already resulted in some making-things-more-intuitive changes to Roodylib (with a couple more planned).  If I keep up this pace, I may have it done within a couple weeks, and Roodylib (and the Hugo notepad++ distribution) should both get official updates soon after!

so many cool-ass people doing cool-ass things

The other week, when I added a Paypal ™ button to this blog, I said something about wanting to list people I would donate money to if I could.  I didn't have links to share for everybody at the time, but I do now.  In no particular order:

• Nikos Chantziaras:  While Kent Tessman went to a lot of trouble to provide a full-featured Hugo interpreter for Apple computers, the chosen method used a software method that was largely abandoned (or, at least, if it was updated, the Hugo interpreter was not updated along with it).  Eventually, Nikos came along and wrote Hugor.  Besides bringing Hugo multimedia back to Mac and Linux users, Hugor is a very nice experiment in IF interpreters, providing several features not found in any other.  Besides Hugor, Nikos also wrote the QTads and FrobTADS interpreters.  I'd highly recommend them!
  
  You can help support Nikos at his sourceforge page.
  
• Juhana Leinonen:  Juhana has done so many cool projects, it's hard to know which ones to give top-billing.  Vorple, a javascript library for adding multimedia to Undum and Inform 7 games, has probably received the most acclaim despite having only seen a tiny percentage of its possibilities (I'm particularly impressed with some of its internet-using capabilities).  More recently, he announced Texture, an IF system designed with mobile devices in mind.  Personally, I've only recently gotten into smart phones and tablets, and I have to say that it was kind of disappointing shock to see how much of a hassle it is to play IF on them so I naturally loved this announcement.
  
  In the world of Hugo, he was the first to get Hugo games in a web browser (using a DOSbox implementation).  He also put together an online "story file parser" for checking out games' innards.
  
  Check out this page for a full list of his contributions (I really need to use that "IF Transcript Beautifier" more often).
  
  In any case, there is no way to donate money to Juhana, but he has some ideas for IF monetization in the future (especially in the realm of mobile apps), so go subscribe to his blog and watch for further developments!
  
• Jesse McGrew:  Jesse doesn't tinker in the world of Hugo, but he is cut from the same cloth as these others who improve the tools and such at our disposal out of a love for the medium.  His first wildly ambitious project was Guncho, a MUD ("multi-user dungeon") where authors can add new realms by writing Inform 7 code, making it possible to write truly-multiplayer interactive fiction using interactive fiction tools.
  
  These days, a lot of attention has gone to his ZILF compiler, a project that makes it once again possible to write games in ZIL, the same language created and used by the Infocom "Implementers."  If I was not working on taking Hugo as far as I can take it, I would probably be spending all of my time with ZIL.  While not exactly easy to code in for a non-programmer as myself, I find it wonderfully powerful in certain ways, and it's cool that once again, it is within our power to write good games that could conceivably be played on an Apple IIgs or TI calculator.
  
  You can follow the ZILF updates as he perfects his port of the game "Adventure" here, and you can donate to his IF endeavors here.
  
• Jimmy Maher:  With his blog "The Digital Antiquarian," Maher delves into classic computer gaming- both IF and not- and consistently provides enlightening forays into the stories behind the games of our youth (and a bit about the games themselves).  Of course, such a project of passion isn't going to completely free of the occasional editorial opinion, but even when I disagree with the sentiment on display, it's always great to see so much attention being given to something that also affected me so many years ago.
  
  I'm also am a fan of his Filfre interpreter for z-code and Glulx games; it's often my interpreter of choice for Glulx games that have graphics.  You can also get his King of Shreds and Patches game for the Amazon Kindle.  That is the first and only IF game I have played on the Kindle, and while a little sluggish (I had one of the earliest Kindle models), overall, I was very happy with the experience.
  
• Robb Sherwin:  For the most part, the only reason anyone even remembers that Hugo exists for the last 15 years is because of the games of Mr. Sherwin.  Anyone unfamiliar with his work should check out his games page.
  
  You can help Robb now by helping his latest game get approved on Steam Greenlight!
  
• Kent Tessman:  Of course, Hugo would not exist if not for its creator.  These days, his attention is devoted to his fantastic screenwriting program, Fade In.  I highly encourage anyone who has ever slightly entertained the "WAIT COULD I BE A SCREENWRITER?" idea to go get his program.  It continues to receive high praise from all sorts of industry greats, and compared to its competition, $50 for a lifetime license is not a bad deal at all.
  
  You can hear his latest screenplay, Chrome Noir, be given the "table read" treatment by a bunch of well-known actors (included Fargo's Colin Hanks) here. 

documentation update

So, work started off slower on the documentation than I predicted, but I'm pretty happy with the styling and approach I've come up with (lots of picture examples to show options in action with a little bit of IF theory thrown in here and there, too).  It'll probably be weeks before I'm finished, I think- and I'll probably tweak fonts and stuff to make it look as nice as possible- but I figured I'd share what I've done so far.

Check out the start of the new Roodylib documentation!

Suggestions are welcome.

Wow

Within just a couple hours of that last post, I was blown away by the generosity of a donation.  Not having any huge Roodylib-related tasks on my plate right now, I decided that it's time I put more effort into making Roodylib's documentation presentable.  I spent a couple hours already making an outline of topics I'd like to cover (with it all being easily browsable), resulting in this:

https://docs.google.com/document/d/1Il43tgoKx1urUcJMkpAJLVH9UupLFi3IL_ICEbg9QNU/edit?usp=sharing

I still have to order it so all of the things most useful to new authors and authors-getting-acquainted-with-Roodylib are explained first.  Right now, the plan is to write the entire thing in LibreOffice, but I may export to PDF for the final copy (in the past, I used an open document just because I figured I could use it basically as a fancy readme text file, but I guess there's no real reason I can't just make the whole thing look nicer).

Anyhow, one thing I'd probably like to do in the documentation is have bits of sample code here and there.  Anyone have any experience with inserting code in open documents (what styles/formatting look best, is there a nice extension for this, etc)?  So far, googling hasn't exactly been my friend, and any advice would be appreciated.

added a paypal button

Now, considering that Hugo has like 5 users in the world, I don't actually expect any money to come in, especially with everyone having mortgages and family and this and that to take care of.  Just the same, things have been tight for me, too, and I figured I might as well put the option out there just in case anyone wants to contribute but just hadn't thought of it yet.

To be perfectly honest, donations probably wouldn't make the next major release of Roodylib come out any quicker (since I work on it pretty consistently anyhow), but if any patron has a particular feature they'd like to see incorporated into Roodylib (or the creation of a useful object class), those things will be given a high priority.  Actually, even if you can't afford to donate anything, if anyone has anything they'd like to see, just let me know.  I'll probably do it, ha.

I was going to finish this post with links to other people who I feel contribute a lot (much more than myself) and would be great options to support, but finding donation buttons for them was harder than I remembered.  I'll have to edit this post after I've talked to them to see if there are pages I've missed.

Configuration Files

I don't remember what prompted it, but something got me thinking about configuration files in Hugo and how I never perfectly designed a way to detect if an interpreter fully supports them.

See, the FILE_CHECK constant-checking method described in the Hugo manual doesn't work with Gargoyle.  Not only that, but Gargoyle can read configuration files- just not write to them- so if a configuration file has been created by another interpreter, previously, the game could easily be tricked into thinking everything is working fine.  Adding even more complication is that configuration-file-writing does work in the glk Hugo interpreter (even though no one ever uses that one) so I couldn't just do a simple "minimal port"check.

So I brought my attention to this the other day.  Eventually, my fix for the problem involved using Hugo's system-time-catching functionality (along with Future Boy!'s time-handling routines) to take the current time, save it to the configuration file along with everything else, then read the time back from the configuration file.  Then it calculates the difference between the two times, and if it's longer than 5 seconds (I'm trying to account for really slow computers here even if a 2 second timer would probably still be playing it safe), it calls the configuration error routine (so a game like "the Halloween Horror" can quit out, as it relies on configuration files).

In other news

Herr Jizaboz finished his demo game about a tourist in North Korea.  I've helped him with it here and there.  I hope people get a big kick out of it!

A Day in DPRK

Also....

Looks like there was a Notepad++  update so I also updated the Hugo Notepad++ distribution.  You can get it here.

Formatting

In that last bout of Roodylib attachables improvement, playing around with the "Vault of Hugo" sample game made me check out some other things, too.  Specifically, I was reminded that Roodylib's doublespace formatting option worked imperfectly.  This is how it looked when it attempted the Vault of Hugo's "Object Room."

(there are no commands listed since it is the result of a recording playback)

As you can see, spacing is inconsistent, with no extra lines between the two items with short_desc's (and all of the non-short_desc-related objects are clumped together, too).

I set out to fix this- and not only that, as I also decided I wanted Roodylib to have an option for smart room descriptions if the player is in an object (I had gotten a test case of this working months ago but it still required some code clean-up and adapting to put it into Roodylib).

Not only this, but I also wanted to make sure that rooms printed properly with the LIST_F format option on.  This is the setting that does "tall" listings like those in Zork:

>look

West of House

You are standing in an open field west of a white house, with a boarded front door.

There is a small mailbox here.

The small mailbox contains:

  A leaflet

>

I can't remember how broke the alignment was before I started this latest wave of improvement.  Might have not been that broke, but with Hugo, "The small mailbox contains:" was indented once and the next line twice.  This was probably intentional, but to be honest, I prefer the Zork version.  Hugo also didn't capitalize the article for children like "A leaflet".  I've changed that, too, since again, I liked the Zork way.  If I had my druthers, I'd make both of these things optional but as it is, configuring DescribePlace to your needs is already going to be a bunch of global variable tinkering and flag setting.  Still, one day I might re-design the WhatsIn and ListObjects routines so they're much more configurable.

While I was at it, I also added my system for smarter listing when the player in a container in the room (it's possible to configure it to also do platforms, but it was hard to come up with a wording that'd work for all cases- if you're on a chair, do you really want to describe all other objects in the room as "off the chair"?).

FORMAT global set to DESCFORM_F and COOL_PARENTS flag set

FORMAT with LIST_F (you'll notice that I changed how Indent works with LIST_F just so the two systems use the same logic)

The cauldron and the grandstand listed are not in the original game.  I added them just to test the part of DescribePlace's code that lists the children of scenery items.

Now let's take a look at some of the behavior if the NEW_DESCRIBEPLACE flag is set.

NEW_DESCRIBEPLACE with doubles-pacing on

The new DescribePlace defaults to having children of scenery listed right away, right after children of parent-of-player.  I figured it's better for them to be closer to wherever they were mentioned in the room text.  Ideally, I'd have an extra check in there to list attachables-connected-to-scenery objects right up there, but I don't think that comes up enough to justify the extra work for now.

With double-spacing on, it only prints newlines (and the extra space) when it needs to.  All those extra spaces might look kind of ugly in that example right there (since that room has so many objects), but I'm fairly certain that it'll look quite nice in the average IF game.

I'm pretty happy with the different options I've given the DescribePlace system although the extra settings I've created could probably use some finessing.

Right now, there are the following additional Roodylib options:

• Set the "COOL_PARENTS" flag (this gives the room better relative text when the player is in a container in the room)...  My gripe about this name is that it's close to my SMART_PARENTS flag (which gives better responses when a player tries to go in an unavailable direction while, like, sitting in a chair or something).
• Give FORMAT the DESCFORM_I mask. DESCFORM_I gets rid of the extra new line before a room title is printed, based on Infocom layout (hence the I).  Just the same, the F in DESCFORM_F probably stands for "flag" so changing it to I is probably just confusing.
• Set the "NEW_DESCRIBEPLACE" flag.  This gives the extra functionality of the new DescribePlace code.  I'm pretty fine with this one.
• Give FORMAT the DESCFORM_D mask.  If the new DescribePlace system is on, this turns on double-spacing.

Beyond the probably-confusing names of my new masks and flags, I'm not sure I even want to expect new authors to know how to change this stuff- if I recall correctly, FORMAT masks are covered very briefly in the manual; pretty sure I learned most of what I know just by looking at hugolib.h.

I'd like to make it easier for authors by creating some routines that will set the game to the formatting they prefer, but even that is kind of a headache. *

* I was going to continue with the annoying aspects of trying to design and name helper routines, but I think I might have an idea I'd like to play with.  Stay tuned!