Thinking Like a Programmer

I’ve started to dabble a bit in interactive fiction. My tool of choice so far has been Inform 7, which allows you to write Z-machine based games (they’ll operate like Infocom games of the 70s and 80s, like Zork).

The scuttlebutt is that you don’t have to be a programmer since Inform 7 uses “natural language” instead of some obscure programming language. As nice as a sentiment as that is, it’s not exactly true. You can learn Inform 7 easily with no programming experience, but you’ll advance quicker with it if you have programming experience.

For example, in a game I’m coding right now, the player has to pick up an object from a high rock shelf. I haven’t the faintest clue what item that’s going to be yet, so I refer to it as a “MacGuffin” for right now.

In the game world, the MacGuffin is atop a rock shelf that the player can’t reach from the ground. I have a rather clever puzzle where the player has to construct a makeshift lever from a board and rock picked up elsewhere, and then pry a large boulder free so it rolls down the hill and comes to rest against the rock shelf. Now the player can climb onto the boulder and snag the MacGuffin.

How’d I do that? Well, simple. Here is the code for the MacGuffin:

There is a MacGuffin in Bottom of Hill. "The MacGuffin sits on a very high rock shelf, just out of your reach." The description is "It's an undefined MacGuffin. We're just testing a theory here."

Before taking the MacGuffin:
if the player is on the big rock:
continue the action;
otherwise:
say "The MacGuffin isn't reachable from the ground. You'll need to find a way to get up to it.";
stop the action.

That will work just fine for the initial puzzle. But what happens if the player drops the MacGuffin in a different room, then later returns to pick it up?

Well, here’s where knowing some programming logic comes into play. Conceptually, you think that once you nab the MacGuffin from the rock shelf, if you drop it you drop it on the ground. So a non-programmer would be just find leaving the code as-is, and he probably wouldn’t understand why it doesn’t work.

The game engine has no concept of “high up” or “ground.” Before the player tries to pick the MacGuffin up, the player must be standing on a supporter called “big rock.” If that condition isn’t met, then the engine won’t allow the player to pick it up. I tested this by moving into a different room, dropping the MacGuffin, then trying to pick it up.

So how do you solve that problem? I could add a line of code to check the location. If the MacGuffin is in the room called Bottom of Hill, then make the player go through the rigamaroll of standing on the rock. Except that I much doubt when a player drops the MacGuffin he’s expecting it to float back up to the rock shelf. So that isn’t the most elegent solution.

The easiest way, I think, is to check the “handled” property of the MacGuffin object. Objects that players can take have a property called “handled.” If true, it means the player successfully added the object to his inventory at some point during the game. Handled remains true even if the player subsequently drops the object.

So, change the “before” line to read, Before taking the MacGuffin when the MacGuffin is not handled. Everything else remains the same, and then if the player decides to drop the object later he will still be able to pick it up without having to stand on a rock.