Are You Sure You'd Like To Read This Post?

I've recently been playing around with a version of the ProcessKey routine, part of my compartmentalized-version of EndGame that tries to make it easier to add new choices to the "The game has ended. Do you want to (R)ESTART, R(E)STORE a saved game, (U)NDO your last turn, or (Q)UIT?" text.

In this latest version, opting to restart or quit brings up a "Are you sure?" prompt just as it is in-game. My thinking is that, hey, even though it's the end of the game, we still want to make sure the player really wants to stop the party before we let him.

Of course, some of the appeal is that while the original version of ProcessKey rehashed a lot of the code from DoRestart, DoUndo, and DoQuit (with the exception of the prompt text, of course), the new version is really simple and looks like this:

replace ProcessKey(entry,end_type)
{
    local r

    if not entry
        return -1

    select entry
        case "restart", "r" : r = &DoRestart
        case "restore", "e" : r = &DoRestore
#ifclear NO_UNDO
        case "undo", "u" : r = &DoUndo
#endif
        case SpecialKey(end_type) : r = &SpecialRoutine
        case "quit", "q" : r = &DoQuit

    if not (call r) : return -1 : else : return true
}

The bonus of this is, if your game does anything special with any of these routines, ProcessKey automatically inherits the (hopefully) wanted behavior.

Anyhow, for now, I think I'm only going to keep this code in my "undolib.h" library extension because I can see how the new behavior might be controversial. If a couple other people like it (I figure 2 other people is almost a Hugo-users-majority), I'll probably end up adding it to roodylib.

roodylib listening

Okay, this post is mainly just because I feel guilty when I go too long without writing something here. The excuse I'm using for writing this is just a recent decision I made concerning roodylib's handling of listening.

Now, for those that remember, Hugo's old listening behavior was to direct players to object-listening when they do location-listening (listening without an object). I thought location-listening was pretty important so I made it possible in roodylib.

Lately, I've been working on a WIP that tries to be realistic and arty and all that crap, so I've had to pay special attention to sensory verbs (not that I've done much about it yet). Anyhow, pretty early on, I changed the default object-listening behavior to a variation of "Why do that?" since really, inanimate objects are generally not worth listening to.

Anyhow, I recently decided that, hmm, maybe something like that should be the default object-listening response. Let's kill those dreams before they become our nightmares!

In the end, I'm going with "That would serve no purpose."

IF, the harsh mistress

Anyone who knows me as an IF enthusiast has probably heard me speculate that maybe we writer fans are all suckers, as implementing a game to satisfactory levels can be suck both time and creative energy. Here I am, about 15 years past the point in my life where I realized hey, *I* could write these text games! Only within the last couple years have my coding and writing improved to the point where writing games is not a horribly slow process; now it's just a somewhat horribly slow process. Still, from time to time, I am reminded of all of the game ideas I've had over the years, many that I will likely never get around to writing. I have to wonder, have I dedicated myself to the wrong medium? Is there an easier/better way? Every time I design a game with only 1 or 2 really important verbs, I start to think, hmm, probably!

There have been several attempts to solve this problem. Most promisingly, there's the BloomEngine guy's stuff, where he has made a couple games that tell IF-esque stories with the use of hyperlink-esque links. The main drawback is that it seems like it might best be limited to tightly looping stories. The first game, Vicious Circles, had a just-large-enough loop to be only barely tolerable. Still, maybe this kind of interface could be saved by a good method for saving games.

There's also the option of creating a game that recalls IF tropes with a CYOA system like Twine or Undum. The drawback to this is that you are responsible for the whole feel of the world model yourself. It's the CYOA version of having to write your own parser for each game. That isn't very appealing to me.

Ideally, as far as these types of interfaces go, I think it'd be cool if such a system had a regular IF world model underneath where, as an author, you control which command buttons are available at any given point (and yeah, commands would be buttons, not hyperlinks).

Of course, the other approach of simplifying IF keeps the parser intact but limits commands. Interestingly, Phoenix games don't allow for examining objects. On one hand, this goes against deeply rooted IF expectations. On the other hand, while playing some Phoenix games, I found that, in the end, it didn't bother me as much as I would have guessed (the author just needs to make sure that all necessary information is within the object's name or short_desc). Other old games have a world model where just holding an object is interpreted as using or wearing it.

These kinds of things might seem ridiculous, but writing a game is probably much easier when you only have to write an average of 2-3 descriptions and important responses for each object, instead of 6 or 7. I hope to write at least one Phoenix-style game in the future just to see how the style feels on me.

So, the question is, can the IF interface be more perfect with less wasted effort? Time will tell, I guess.