Switcheroo technique

Caution: The term "switcheroo technique" was invented for IFWiki and is not in common usage. As far as the author of this article knows, no discussions or reviews of IF have given a name to this particular programming practice.

The switcheroo technique is a programming method found in several works of interactive fiction, where two (or more) objects are programmed to represent different states of a single item, so that when the item's status changes, the first version of the item is quietly moved out of scope and the second version is put in its place. (In Quest games, often the objects don't need to be moved at all, but instead are hidden or shown.)

The most common (and acceptable) reason for an author to employ the switcheroo technique is when the status change is drastic: an NPC is killed or an item is destroyed. A living creature is usually coded very different from his corpse.

For example, a guard, when alive, will likely respond to questions and react appropriately if the PC tries to attack, kiss, or search him. But all of that should change when the guard is dead. Since the code for the living guard and the dead guard have so little in common, it makes sense to use two different game objects for the guard.

Of course, the player should never see both versions of an item at the same time. According to the New Zork Times, such a bug occurs in version 18 of Deadline (Marc Blank; publisher: Infocom; 1982; Z-code), where it's possible to encounter two versions of Ms. Dunbar, one living, and one dead.

Another reason for an author to use the switcheroo technique is when the authoring system's world model isn't robust enough to either set or test a status flag. For example, in The Crystal Keepers (Doreen Bardon; 2001; CAT), various flowers can be dried, and each of the flowers are coded twice: fresh versions and dried versions. In other systems, an author might code each flower once, and code them with a "dried" flag which can be tested for the few times the dried status makes a difference.

Whether an author makes use of the switcheroo technique or not can be a matter of taste, and it can boil down to which option is less work, less code, or easiest for the programmer to understand.

However, problems with the switcheroo technique escalate if more than one status changes. In The Mansion (Nick Dablin; 2004; Quest 3), there's a closed liquor cabinet with a bottle of whiskey inside. But Quest 3's world model didn't include concepts like containers, so the cabinet had to be encoded three times: the closed cabinet (containing the bottle), the open cabinet (containing the bottle), and the open cabinet (empty). This is a lot of work for a cabinet that essentially stays the same in most respects, and it does result in a lot of duplicated code. Worse, the author's efforts at code duplication can result in new errors if both versions of an item don't act the same way when they should. (In other authoring systems like Inform or TADS, the author would just code the cabinet once. In fact, it would never occur to the average Inform or TADS author to code the cabinet multiple times like this.)

Of course, what some authors see as a problem, others see as a challenge. In the sequel, The Mansion II (Nick Dablin; 2006; Quest 3), there's a chemistry puzzle that required the author to code twenty-eight versions of the same flask.

Another potential problem with the switcheroo technique is the disconnected pronoun bug. If the player tries to refer to an object with a pronoun ("him", "her", or "it") after the switcheroo has occurred, the game may complain that that object isn't there. Authors should add a little extra code after the objects have been switched around so that the appropriate pronouns now refer to the new object, not the old one.