Showing posts with label DescribePlace. Show all posts
Showing posts with label DescribePlace. Show all posts

Saturday, July 18, 2015

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!


Tuesday, May 28, 2013

listing discontent

So, a couple things to talk about today, but one of them is more useful to Hugo users everywhere so I'll cover that one first.

As mentioned in another post, Roodylib now automatically lists the contents of the room's (non-quiet) platforms in a room's description. This might give some pre-existing games some unexpected behavior, but logically, I don't know why platforms should be treated any differently than containers.

Still, this puts some in an awkward position, because they are not familiar with the ways to avoid listing contents. Of course, the quiet attribute will prevent content listing until the player explicitly looks into the object (at which point it'll list the contents at every opportunity).

To have full control over when contents are listed, you have to use the list_contents property.

To only allow content-listing when the player explicitly LOOKS IN/ON:

list_contents
{
if verbroutine ~= &DoLookIn
return false
else
return true
}

To allow content-listing only for EXAMINE or LOOK IN:

list_contents
{
if verbroutine ~= &DoLookAround
return false
else
return true
}

So yeah, the three times that contents are listed are room descriptions ( &DoLookAround), object descriptions (&DoLook), and when looking in objects (&DoLookIn). Knowing that, you can write your own list_contents rules. Of course, you can still use list_contents to print your own content listings before you return true.

The other thing is that, while applying Roodylib to another game, it became apparent that there was a problem with my new DescribePlace system when the USE_PLURAL_OBJECTS flag is set. I had copied over some code from the old one that checked for identical objects without finessing it into the new code. When this error made me take a look at the code again, I had to calculate exactly how useful the code was.

In the old DescribePlace, the lines in question prevent identical objects from being listed among objects-with-short_desc's. I started thinking, well, hey, why can't we have it both ways? I then altered my code to allow identical objects with short_descs and found that, ok, ListObjects (the routine that tallies the identical objects) lists the same total regardless of which objects have already been described. So, long story short, there's now some code in there preventing that from happening.

There's still some work to do with the new DescribePlace. Right now, I think objects and characters with descriptions always have to be listed before their description-less counterparts. Eventually, I should see if I can make the order truly interchangeable. I'm not sure how often that situation comes up, but it'd be good to support it just the same.

Tuesday, April 2, 2013

new_desc

In one of my WIPs, I did some hacky things to my code so that in any given room, objects with short_descs are grouped together into one paragraph. Since I've been adding DescribePlace-related stuff to Roodylib lately, I thought, hey, let's see if I can make this an official option in there!

In my WIP, I defined my short_descs like this:
    short_desc
    {
        "A giant spoon lies on the ground, as if discarded by some humongous
        spoon musician.";
    }

With Roodylib, I didn't want to task the author to add the semi-colon each time, and DescribePlace and ShortDescribe really expect short_desc to be a property routine (and not just a regular property). I found that it's pretty much impossible to get the code to play nicely with both.

In the end, I had to create an optional new property and new DescribePlace helper routines to  Roodylib (luckily, I had already designed a DescribePlace that'd allow easy inclusion of such). A game compiled with NEW_DESC set would allow the following and give it proper spacing:

    new_desc "A giant spoon lies on the ground, as if discarded by some
    humongous spoon musician."

Anyhow, this is a feature that will probably only be used by me, but I thought I'd announce it just the same.

Monday, April 1, 2013

more roodylib updates

I added a lot to Roodylib today. The biggest chunk of code was probably my new (optional)  DescribePlace system. All in all, Roodylib went from 160 KB to 181 KB.

I also "released" my port of Cardinal Teulbach's SceptreQuest, which I uploaded to http://roody.gerynarsabode.org/games/squest.hex (I use quotes because I don't intend to announce the game any where besides here and my twitter account, as the copyright on the game doesn't technically allow re-release like this). Writing that inspired several Roodylib updates today. We'll get to that in a bit.

First off, I added an AMERICAN_ENGLISH flag to Roodylib. It really doesn't change as much as you'd think. All it really does is move quotation mark placement for statements such as "I don't understand the word 'blah.'"

As mentioned I also added that DescribePlace stuff. When I ported SceptreQuest, I also coded its odd color handling. I found that this involved changing color at places that forced me to replace whole hugolib routines, so among other things, I added calls to RLibMessages to handle different printed tasks for DescribePlace (such as the printing of the room name), WhatsIn, and ListObjects. As far as ListObjects goes, there are probably more bits of text that I could sent to a message routine, but I'll add those as needed.

 I also finally added that DESCFORM_I constant to act as a FORMAT mask. When enabled, DescribePlace does not print the blank line before printing the room name. It now does this check (in RLibMessage):
                    if not (FORMAT & DESCFORM_I) or (verbroutine ~= &MovePlayer and
                    verbroutine ~= &DoLookAround and a = location)
                        print "\n";
The location check allows one to use DescribePlace to fake movement to rooms (where it should not print a new line) but still prints a new line for when things like newmenu.h call DescribePlace after having printed "returning to the story...".

The next thing I'm considering working on is a combination of Future Boy's time object class and improved resource.h  routines where things like audio.current_music is automatically cleared after the song is over. Going over it in my head, though, has me thinking it might be too bulky for Roodylib-inclusion so I may just improve my already-existing-but-separate jukebox system to do that. We shall see!

Wednesday, March 20, 2013

Describe-re-Place

I have to admit it. I love "to do" lists. This is one of the reasons I'll miss iGoogle when it's gone, as it provides a "to do" list app for the unobtrusive Chrome home page I have set up. That list is great, but I also have to admit that some of my most effective "to do" lists are just a couple text files I have on my desktop.

I've been revisiting those desktop lists lately to make sure I've accomplished everything listed there. I was able to delete a good deal of what they listed, but at least one of them reminded me of an unsuccessful bid to redesign DescribePlace into something that'd allow the addition of extra bits of text, like something that'd call that CanGo routine that lists room exits.

I like running DescribePlace with the DESCFORM_F format mask which gives room contents a sort of "double spaced" look to it. The heart of the DescribePlace problem is that you really need to know when stuff will be printed and when it will not to properly space it all.

Even though I really had no intention to return to the problem any time soon, I happened to lie down for a late afternoon nap yesterday, and almost instantly, I was hit by a DescribePlace replacement idea. Instead of having it be one routine, I thought I'd give it a main routine that calls routines that does the actual object listing. Then we have the benefit of returning true or false to determine whether or not to print extra lines.

I spent some time today putting the idea to action, and it already seems to be in a usable state. I think I even fixed some problems with the old replacement which required some elements to be listed after certain other ones. I have a feeling some of the routines could be more efficient or cleaner-looking, but that's for another day.

What does this mean for the average author? Well, since they probably won't touch anything, it doesn't really mean anything. Everything should work the same, although there are also some fixes in there for when using-DescribePlace-to-describe-a-room-that-isn't-your-location.

Like the old replacement, it should be helpful for games that like to change up the order in which things are listed, like Robb's games where characters are sometimes listed last. To change the order, just add something like this to your init or SetGlobalsAndFillArrays routine:
    DescribePlaceArray[0] = &CharsWithoutDescs, &ObjsWithoutDescs,
    &ParentofPlayer, &CharsWithDescs, &ObjsWithDescs, &AttachablesScenery
 (Except in whatever order you want)

Being so modular, it should also be easier to change the behavior of just how certain things are listed.

I also think that this will added to Roodylib, but I have to first decide if all of the new spacing behavior should fall under DESCFORM_F or if I need to come up with a new Infocom-spacing format mask called DESCFORM_I or something. I'll have to look at my old notes to see what I decided with that.

Anyhow, here's the code so far:
! This constant needs to be declared with something higher if you are
! adding additional elements into the mix
#if undefined DESCRIBEPLACE_ELEMENTS
    constant DESCRIBEPLACE_ELEMENTS 6
#endif

attribute already_printed
array DescribePlaceArray[DESCRIBEPLACE_ELEMENTS]

replace Describeplace(place, long)
{
    local obj,  didprint
    local need_carriage

    parser_data[PARSER_STATUS] &= ~PRONOUNS_SET

    ! Since, for example, a room description following entering via
    ! DoGo does not trigger before/after properties tied to looking
    ! around:
    !
#ifclear NO_VERBS
    if verbroutine = &MovePlayer ! was "if verbroutine ~= &DoLookAround"
    {
        if place is not visited and verbosity ~= 1
            return Perform(&DoLookAround)
        elseif long = true or verbosity = 2
            return Perform(&DoLookAround)
    }
#endif

    if not light_source
    {
        Message(&DescribePlace, 1)     ! "It's too dark to see..."
        return
    }

    place is known

    ! Print the name of the location as a heading
    Font(BOLD_ON)
    if not (FORMAT & DESCFORM_F)
        print "\n";

    print capital place.name;

    ! Print ", in <something>" if necessary
    if location = place and player not in place
    {
        if parent(player).prep
            print ", "; parent(player).prep; " ";
        elseif parent(player) is platform
            print ", "; ON_WORD; " ";
        else
            print ", "; IN_WORD; " ";
        print Art(parent(player))
    }
    print newline

    Font(BOLD_OFF)
    override_indent = false

    if place is not visited and verbosity ~= 1
    {
        if &place.initial_desc or &place.long_desc
            {
            didprint = true
            Indent
            }
        if not place.initial_desc
            run place.long_desc
    }
    elseif long = true or verbosity = 2
    {
        if &place.long_desc
            {
            Indent
            didprint = true
            }
        run place.long_desc
    }
    elseif place is not visited and verbosity = 1
    {
        if &place.initial_desc
            {
            Indent
            didprint = true
            }
        run place.initial_desc
    }

    if &place.list_contents and (FORMAT & DESCFORM_F) and didprint
        print ""        ! for double-space-after-heading formatting

    ! A location may contain an overriding listing routine, as may any
    ! parent, in the list_contents property
    !
    for obj in place
        obj is not already_printed

    if not place.list_contents
    {
        list_nest = 0
        local a
        while a < DescribePlaceArray[] and DescribePlaceArray[a]
        {
            need_carriage = call DescribePlaceArray[a](place)
            if (FORMAT & DESCFORM_F)
            {
                if need_carriage and didprint
                    ""
            }

            if need_carriage
            {
                need_carriage = false
                didprint = call DescribePlaceArray[a](place,true)
            }
            a++
        }
        print newline
        need_newline = false
    }
}

! routine for listing the player's siblings when he or she is in or on an
! object in the room
routine ParentofPlayer(place, for_reals)
{
    local obj
    if not for_reals
    {
        if player not in place and place = location
        {
            for obj in (Parent(player))
            {
                if obj is not hidden and obj ~= player
                    return true
            }
        }
        return false
    }
    else
    {
        list_nest = 1
        if WhatsIn(Parent(player))
            return true
    }
}

! routine for listing characters with short_desc descriptions
routine CharsWithDescs(place, for_reals)
{
    local obj
    if not for_reals
    {
        for obj in place
        {
            if (obj is not hidden and obj is living and
                 obj ~= player and ((&obj.short_desc and verbosity ~= 1) or
                (obj is not moved and &obj.initial_desc)) and
                obj is not already_printed )
            {
                return true
            }
        }
        return false
    }
    else
    {
        ! List all characters, if any
!        count = 0
        for obj in place
        {
            if obj is hidden or obj is not living or
                player in obj
            {
                obj is already_listed
            }
            else
            {
                obj is not already_listed
            }
        }
        local ret
        for obj in place
        {
            if obj is not already_listed
            {
                print newline
                if verbosity ~= 1 or (obj is not moved and &obj.initial_desc)
                    ShortDescribe(obj)
                if obj is already_listed  ! did we print something?
                {
                    ret = true
                    obj is already_printed
                }
            }
        }
        return ret
    }
}

! routine for listing characters without short_desc descriptions
routine CharsWithoutDescs(place,for_reals)
{
    local tempformat, count, obj
    if not for_reals
    {
        for obj in place
        {
            if (obj is not hidden and obj is living and
            obj ~= player and
            (not &obj.short_desc or
            (&obj.short_desc  and verbosity = 1)) and
            obj is not already_printed)
            {
                return true
            }
        }
        return false
    }
    else
    {
        for obj in place
        {
            if (obj is not hidden and obj is living and
            obj ~= player and
            (not &obj.short_desc or
            (&obj.short_desc  and verbosity = 1)) and
            obj is not already_printed)
            {
                obj is not already_listed
                count++
            }
            else
                obj is already_listed
        }
        if count ! list_count      ! if characters are to be listed
        {
            list_count = count
            tempformat = FORMAT
            FORMAT = FORMAT | FIRSTCAPITAL_F | ISORAREHERE_F
            FORMAT = FORMAT | USECHARNAMES_F
            if (FORMAT & LIST_F)
            {
                FORMAT = FORMAT & ~LIST_F       ! clear it
                FORMAT = FORMAT | TEMPLIST_F
            }
            Indent
            list_nest = 0
            ListObjects(place)
            FORMAT = tempformat
            return true
        }
        return false
    }
}

! routine for listing objects with short_desc descriptions
routine ObjsWithDescs(place, for_reals)
{
    local obj, ret
    if not for_reals
    {
        for obj in place
        {
    #ifset USE_ATTACHABLES
        ! Exclude all attachables for now (and characters)
            if obj is not living and not obj.type = attachable and
                player not in obj and obj is not hidden and
                ((verbosity ~= 1 and &obj.short_desc) or
                (&obj.initial_desc and verbosity = 1)) and
                obj is not already_printed
    #else
            if obj is not living and player not in obj and
            obj is not hidden and
            ((verbosity ~= 1 and &obj.short_desc) or
                (&obj.initial_desc and verbosity = 1)) and
                obj is not already_printed
    #endif
            {
                ret = true
                obj is not already_listed
            }
            else
                obj is already_listed
        }
        return ret
    }
    else
    {
        for obj in place
        {
#ifset USE_PLURAL_OBJECTS
                    ! ...And don't list identical objects yet, either

            if (obj.identical_to).type = identical_class
            {
                if obj is not hidden
                    count++
            }
            elseif player not in obj
#else
            if player not in obj
#endif
            {
                if obj is not already_listed and
                    obj is not hidden and obj is not already_printed
                {
                    if verbosity ~= 1 or (verbosity = 1 and
                        (obj is not moved and &obj.initial_desc))
                        ShortDescribe(obj)
                    if obj is already_listed ! did we print something?
                    {
                        ret = true
                        obj is already_printed
                    }
                }
            }
        }
        return ret
    }
}

! routine for listing objects without short_desc descriptions
routine ObjsWithoutDescs(place, for_reals)
{
    local obj, tempformat, count
    if not for_reals
    {
        for obj in place
        {
#ifset USE_ATTACHABLES
            ! Exclude all attachables for now (and characters)

            if obj is not living and not obj.type = attachable and
                player not in obj and obj is not hidden and
                obj is not already_printed and
                (not &obj.short_desc or (&obj.short_desc and verbosity = 1))
#else
            if obj is not living and player not in obj and
            obj is not hidden and obj is not already_printed and
            (not &obj.short_desc or (&obj.short_desc and verbosity = 1))
#endif
                {
                return true
                }
        }
        return false
    }
    else
    {
        for obj in place
        {
#ifset USE_ATTACHABLES
            ! Exclude all attachables for now (and characters)

            if obj is living or obj.type = attachable or
                player in obj or (&obj.short_desc and verbosity ~= 1) or
                obj is already_printed
#else
            if obj is living or player in obj or (&obj.short_desc and verbosity ~= 1) or obj is already_printed
#endif
                obj is already_listed
            else
            {
                count++
                obj is not already_listed
            }
        }

        if count
        {
            list_count = count
            tempformat = FORMAT
            FORMAT = FORMAT | FIRSTCAPITAL_F | ISORAREHERE_F
            if FORMAT & LIST_F
            {
                FORMAT = FORMAT & ~LIST_F       ! clear it
                FORMAT = FORMAT | TEMPLIST_F
            }
            Indent
            list_nest = 0
            ListObjects(place)
            FORMAT = tempformat
            return true
        }
        return false
    }
}

! routine for listing attachables and contents of scenery objects
routine AttachablesScenery(place, for_reals)
{
    local obj, ret
    if not for_reals
    {
#ifset USE_ATTACHABLES
        for obj in place
        {
            ! Print attachables last
            if obj.type = attachable and obj is not hidden
            {
                return true
            }
        }
#endif
        for obj in place
        {
            if obj.type = scenery
            {
                if player not in obj and
                    (obj is open or obj is not openable)
                {
                    local a
                    for a in obj
                        {
                        if a is not hidden
                            {
                            return true
                            }
                        }
                }
            }
        }
        return false
    }
    else
    {
#ifclear NO_OBJLIB
#ifset USE_ATTACHABLES
        for obj in place
        {
            ! Print attachables last
            if obj.type = attachable and obj is not hidden
            {
                ShortDescribe(obj)
                if obj is not already_listed
                    Message(&DescribePlace, 2, obj)
                obj = already_printed
                ret = true
            }
        }
#endif
        print newline
        override_indent = false

        ! Finally, list contents of scenery objects (unless we've
        ! already done so as the parent of the player)
        !
        for obj in place
        {
            if obj.type = scenery
            {
                obj is known
                if player not in obj and
                    (obj is open or obj is not openable)
                {
                    list_nest = 1
                    if WhatsIn(obj)
                        ret = true
                }
            }

            ! For scenery-derived objects that may change the type
            elseif obj is static, hidden
                obj is known
        }
        return ret
#endif  ! ifclear NO_OBJLIB
    }
}

Monday, March 11, 2013

what now?

With my last Roodylib update, I hit version 3.0. Admittedly, my version numbering is nothing more than adding a .1 with every release. Still, the next things on my Roodylib to-do list are inconsequential enough that I may make use of the clean version number and finally upload a version of Roodylib to the IF Archive.

One of the things I'm debating adding to Roodylib in the future is some replacement of DescribePlace. The problem is, I think that my "does everything" version of DescribePlace is kind of an eyesore so I'd like to either clean it up or put a somewhat less feature-ful version in Roodylib. The recent configuration-file-writing stuff could be cleaner, too.

As far as new extensions go, the remaining ideas are ones that I'm comfortable putting on the backburner for a while, so I really have no excuse to not dig big into my game ideas. Just the same, I'd like to mention them here right now as a bit of a teaser.

The first extension idea is a "Scott Adams game" extension, which would hopefully make it easy to hide a Scott Adams-type game in another game. Basically, I thought it'd be hilarious if multimedia-using games opened up as Scott Adams type games in multimedia-incapable terps.

There have been a couple difficulties with this. The first was figuring out a way to make the Scott Adams game grammar coexist with the regular game grammar. I'm pretty sure I've come up with a good solution for this.

The second one is a bit harder. Somewhere along the way, I decided that I wanted to copy actual-Scott-Adams-game behavior by putting all of the non-prompt game text in the status window (which would take up the top half the screen). I think that last time I worked on the extension, I began a string saving system to handle this, but I haven't gotten the extension into a compilable state yet. Part of the difficulty has been trying to decide if default messages should ever be anything other than "OK!" and "I CAN'T DO THAT!" or whatever.

Anyhow, as much as the idea behind the extension amuses me, I'm not currently working on any multimedia games that would use it, and I am likely the only person who would use such an extension.

My other extension idea is a "beginner interface" that could be popped into most games that'd show basic information that player's could click to add to the command line. This idea grew out of the idea that most plain text Hugo games played in a fullscreen or near-fullscreen window have more space than they know what to do with (at least if you aren't using Hugor's cool margin size feature). The general layout of the interface would look like this:
There are several things that have kept me from writing this one, too. For one thing, I've been avoiding the headache of writing the code that figures how many windows are available with the given space. Something like the inventory window would be especially troublesome, where it could conceivably be a long list comprised of long names.

I also had this idea before I did the "default menu" for newmenu.h. That provides a page with common commands, and doing that took some of the wind out of my sails for this project.

Lastly, I think this design demands the use of at least three colors, and I don't even want to think about how I'm going to determine that third color.

So, yeah, there are those things. Hopefully, the next time you hear from me, I'll be knee deep in game code.

Friday, November 16, 2012

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.

Monday, June 25, 2012

DescribePlace musings

Tonight, I was working on my "Frankenstein monster" version of DescribePlace (http://hugo.gerynarsabode.org/index.php?title=Replace_DescribePlace). Beyond the things already listed by DescribePlace, I was thinking it'd be cool to add two additional configurable things to check, so conceivably, you could put one right after the room description to call routines like YouCanGo ("You can go east to the lake or north to the parking lot.") without having to edit each room's long_desc to call it. On the other end of the spectrum, you could call routines like score notifications or footnote stuff so they are printed after all room description stuff but before event/script stuff.

My test code was working great until I remembered that YouCanGo, my test routine, prints messages every time and that my code wasn't prepared for situations where something may or may not be printed (btw, sorry I'm so italics-intensive). To do proper spacing, there are parts of DescribePlace where one should only print a new line if something else is going to be printed, so it's important to know whether something will print before you call it. I tried to get around this uncertainty by using "text to <array>" to hide all text when the routine is called, using its return value to determine whether it was successful- and if so, running the routine again once I stopped writing to array. Unfortunately, even when writing to an array, carriage returns are processed normally, so there was no way to avoid ugly, extra space in my game.

Anyhow, I'm not really happy with my options at the moment. For the meantime, I'm throwing my whole idea to the backburner until I come up with something more appealing.