Okay, while in this post I’ll be talking about the games I’ve been creating in Wander, this post isn’t really about Wander specifically, but about text adventure games in general. And more specifically, about puzzle design.
While planning out one of the games I was going to create with Wander, “The Eye in the Forest”, I kind of stumbled into a stupid trap of game design. Fortunately, I think I stumbled back out of it. I’d come up with a particular puzzle I was fond of, involving the player’s reaching a certain platform, but then later on it occurred to me that, given some of the available objects in the game and their possible interactions, there was another course of action that logically should also allow the player to get to the platform. Of course, I already had a solution in mind for the puzzle, so I wrestled for some time with the question of how to rule out that unintended alternate solution. It wasn’t until the next day that the answer finally occurred to me, and when it did it was obvious:
That is, don’t rule out the alternate solution. If there’s another course of action that should logically allow the player to do what he or she has to do, then why go out of my way to disallow it? Especially since in this case, the alternate solution wasn’t really any less complicated or less clever than the solution I had in mind. In fact, the more I think about it, the more I think I actually like the alternate solution more than the solution I’d originally intended.
For the moment, though, this particular matter has become at least temporarily moot, because… well, there’s a reason I used the past tense when I said this was one of the games I was going to create with Wander. I decided that creating two games with Wander instead of one was… kind of a silly idea. And honestly, the other game I was planning, “It Should Not Be”, lends itself much better to the Wander system anyway. Even for that game, there might be a few things that are going to be tricky to implement, and it might require some creative workarounds, but several of the objects and puzzles in “The Eye in the Forest” would be very difficult to implement with Wander. Not necessarily impossible, but very difficult, and probably quite complicated and tedious, and while when creating a game with a system I do want to try to make full use of the system and take it near its limits, well, there’s a fine line between taking a system to its limits and banging my head against a wall unnecessarily. So I’m not going to write “The Eye in the Forest” in Wander after all. I’m only going to create one Wander game, and it’ll be “It Should Not Be”. Honestly, this is a decision I probably should have made some time ago, and I think the main thing stopping me was the fact that I’d already written six hundred lines of code for it. That, and the sunk cost fallacy.
That’s not to say that all the work I went into planning the game is going to waste. I’m still going to write “The Eye in the Forest”. Just not in Wander. I’ll save it for the next text adventure language on my list, which is TSAL. I think that’s a much better fit, both because some of the items and puzzles that would be very hard to implement in Wander should be much easier in TSAL, and… well, philosophically? What I mean by that is that I’ve mentioned before that I think some of the puzzles in “The Eye in the Forest” are very difficult, and some of the games written in TSAL have a reputation for extreme difficulty anyway, so I guess it kind of fits. (Though said games have a reputation for unfair difficulty, and I think the puzzles in “The Eye in the Forest”, while difficult, are fair… but of course I’m not really an unbiased judge of this matter.)
And speaking of “It Should Not Be”, I had a puzzle design experience with that, too, that I wanted to relate. “It Should Not Be” features spellcasting by magic words (effectively, though those terms aren’t used in the game), and there was one magic word that I thought was underused and wanted to come up with another purpose for. At the same time, there was one puzzle idea I had that I hadn’t come up with a solution for—that is, I knew what I wanted the player to do, but I wasn’t sure how the player was going to do it. It wasn’t until I thought of those two issue at the same time that I realized that they serendipitously canceled each other out—the magic word I wanted to find another use for could be used to solve the puzzle I didn’t have a solution for! So, hey, that was nice.