space layout, the final frontier

When I released my first work of IF, I think the concept I was most lost with was how to do proper spacing in my game. There really aren't any guides on the different styles you can use for your game, and I found my game was really inconsistent and wished one existed. I eventually would learn that it boils down to "try to figure out the assumptions your language already makes and copy that." Still, even after all of these years, I can imagine some merit in such a guide.

Hugo, in particular, is especially confusing, as it introduces indented text, and there isn't really a large body of work out there to fully get how it's to be used, especially since it clashes with the Infocom games we grew up with. Over the years, I have come to respect the indentation system and appreciate the look it brings to the system. Just the same, if only to better understand the different styles, I've made it a quest to better support Infocom-style spacing in Hugo games.

Out of the box, Hugo can do some Infocom-style spacing things if you give the FORMAT global the DESCFORM_F flag. When that is set, the text in the status line is offset by a space, so it is not right up to the edge of the screen. Also, there's an extra line between the room description and the room contents listing.  My DescribePlace  replacement has furthered this, by including an extra line between every type of object in the room content listing.

A few days ago, I continued refining this "Infocom style Hugo mode", mainly because one of my WIPs is an homage to Infocom. The big change is that there is no longer an automatic empty line before a room listing. Coupled with the NOINDENT_F flag, it looks quite Infocom-y.

At first, I tied this behavior into DESCFORM_F, but I then decided that that was too much Infocom all of the time as I have come to appreciate the semi-Infocom look in some of my other games. I decided to give that behavior to a new flag that I called DESCFORM_I.

Anyhow, the new changes have been making me tweak this and that, as now it's up to any code that prints something before DescribePlace to also print an extra line. I'm liking the new behavior, but figure it'll be some time before this has settled in right among all extensions that call DescribePlace.

I think I'm due to upload several updates. I noticed some horrible behavior in the default menu for newmenu.h. I've since fixed it, but it's one of those things that makes you scratch your head and wonder how it got out the door in the first place. I think newautomap.h had some kind of update, too.

Anyhow, the work on this extension stuff has been kind of disheartening, what with all of the leaks that have popped up. I hope to get some good WIP progress done soon.

just WIP it

I spent a fair amount of time yesterday updating on older WIP to be roodylib-compatible. Initially, this meant more deleting than anything else, as it had a lot of the routine replacements and various code that were eventually incorporated into roodylib.

The first thing I learned from the process was that I was not happy with how newautomap.h interacts with newconverse.h, statusline-wise. I found myself wishing I had documented it better when I wrote my new PrintStatusLine replacements system. Eventually, I remembered that its current behavior has the map still show up when conversation options are present. Sure, the two windows were drawing fine, but in my false memory, I thought I had created a system to block the map from showing up at all under certain circumstances. In the end, I spent several hours tweaking newautomap.h to work better and do just that. I'm not sure it's the best-it-can-be yet, but it's better.

The other thing my old code reminded me about was how it had some code to allow clumping items-in-a-room's short_desc all to one paragraph, like:

      A giant spoon lies on the ground, as if discarded by some humongous spoon musician. Your friend, the giant raisin, is here, lying on its side.

 (the above is the clumping of two objects)

Traditionally, nice looking room prose like that has to be hardcoded into the room's long_desc property, but this little venture has me thinking that maybe I'll take this task on again. The way it's handled in my WIP right now is kind of ugly, but I'm thinking I might be able to handle the challenge a bit better now. We'll see.