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.
When I first noticed Hugo's unusual indentation style, I decided that I liked it. It's not really one of my reasons for using Hugo -- to the limited extent that I use any IF development systems -- but it is a uniqueness that I like. It seems more immersive to me by vaguely suggesting the paragraph formatting of a printed book.
ReplyDeleteDon't worry about the extension stuff! I'm sure it's all more than good enough! ;)
Yeah, I like the indentation system, too. I just think it's a bit unclear to newbies, especially the idea that they should be calling the Indent routine themselves for their own prose (since DescribePlace kind of calls it behind-the-scenes). Each author also has to decide where the cut-off between indented and non-indented text is. I try to do a system of meta-command-responses-are-not-indented and in-game-text-*is*-indented, but it's not always easy to determine between the two things.
ReplyDeleteMy indentation technique is to leave messages that directly result from the player's typed commands unindented, unless of course the message is quoted dialog. That way, if an indented paragraph follows, it should be clear that the indented paragraph is either a daemon/fuse or a follow-up message triggered by the player's action in other code.
DeleteThat is a pretty good rule and something to consider.
Delete