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.

turn theory

(This post actually has some cross-system theory- almost making it worthwhile to post to the JC blog- but most of it will be Hugo-specific enough that I'm just going to keep it here.)

In getting newconverse working, I had to make some small changes to both the roodylib and newconverse versions of SpeakTo. One thing I noticed was that in the regular library, variations of the command >HELLO (CHARACTER) do not take up a turn (I changed this for roodylib).

Whether or not a verb routine returns true determines whether a turn passes (if a turn passes, the turn counter increases, PrintStatusLine is run again, and event code is executed). It seems like the philosophy behind turns is that ineffectual commands shouldn't take up any game time, but important commands should. Like, the entirety of verbstub, I believe, returns false, as Hugo makes the assumption that >YELL-ing or >SLEEP-ing will just provide some snide answer and that is that. >HELLO (CHARACTER) does have a pretty meaningless default response, but the command does still set the speaking global, which seems pretty important.

This system presents several points of confusion, including:

• Any time you have to stop an action with a before rule, the "can't do" message will take up a turn while the regular action doesn't. Consistency cries! (maybe these are instances where verb routines should be replaced completely with something that always returns true)
• What's the best way to distinguish between an ineffectual command and a useful one? From the player's perspective, it can be pretty unclear.

Some people contend that verbs like >LOOK and >EXAMINE shouldn't take up a turn, either. It's an interesting idea but might be more trouble than it's worth.

Still, what is turn-worthy is one of those things I imagine Hugo inherited from Inform. Now that I'm much more comfortable with the idea of suggesting improvements for the library, it's worth nothing that, hey, if we think we can design a more consistent system, there's nothing stopping us. In the meantime, we can continue to tune the responses one verb routine at a time.