Won't get fooled systematically

I once had an idea for a game about deception. It would be like a tutorial for an ordinary game, but the instructions would be wrong, and the game would berate you for trying to do it the right way. This wouldn't be too interesting, though, as the instructions would simply become noise, and the player would ignore them. But what if the instructions were needed, somehow, such as to guide your character through an invisible random maze? If the instructions were simply wrong, or intentionally misleading (as fitting the "deception" theme), then the instructions would be totally useless and the game would be impossible. But what if there was a consistent method to the wrongness? Then it becomes a much more interesting exercise.

Consider a game with a top-down view of a standard square grid world. You need to maneuver along a narrow, twisting path over a bottomless pit (or lava). You can easily walk off the path and fall to your doom, but control isn't hard if you are going in the right direction (a block-at-a-time move system as in early Dragon Quest or Final Fantasy would be best here). While you can easily see your way, the game also gives you directions. The directions are mirrored, however, so north is south, east is west. Because it is easy to see what you actually need to do, the system becomes clear.

In the next phase, you must navigate the same sort of path, but without being able to see where you're going. Here you need to rely on the "wrong" directions, so you will use the decoding system that you had worked out previously. It should be possible to switch back to the visible maze for more practice if you hadn't figured it out or memorized it completely. Since it is fairly uninteresting and error-prone to run through the whole maze, we will offer a way to automate it. You can set up a mapping between the "wrong" directions and the correct ones (NORTH => SOUTH, SOUTH => NORTH, etc), and the game will automatically run through the maze, translating the directions as you instructed.

At the next level, we present the same setup again, only this time with a somewhat different mapping, maybe a rotation: NORTH => EAST, EAST => SOUTH. The same game would play out: you need to discover this rotation, then either do it step-by-step or automate it, though the game will ultimately require the automation. A helpful tool might be to build a table showing each "wrong" direction given and the correct direction that the player was able to take, given his knowledge of the context. When setting up the automation, it could indicate which lines of the table the current mapping satisfies. Another form of illustration is to overlay the result of the automation on top of the visible maze. This could show, for instance, that a turn was taken too early or a step was missed; the rest of the path would appear correct, but offset.

Following levels of play will involve increasingly complicated encodings, a few examples:

There are a few important points to this progression. First, we attack the idea that the directions are anything but arbitrary symbols. It may be valuable (as I mentioned in this post) to not have them be expressed as "directions" at all, but I think that for a first level it would be good to have the directions say only exactly what they mean, just to introduce the interface. Still, very soon the player finds that these symbols can mean anything. Second, while the encodings become somewhat more complicated, they are not layered in a way such that they are combinations of everything that came before. Thus the RLE mode may have directions that mean exactly what they say, except for certain "escape sequences". Lastly, the progression is designed around the idea of introducing new mechanisms in the automation toolkit, so we will not provide these mechanisms before they are actually needed.

It is a hard but fascinating problem to consider how to build visible mazes that explain the encodings to the player. With a narrow path we quite straightforwardly indicate what the result should be in some scenario. We can also provide branches and wider paths where multiple interpretations may be valid; these can either end in a pinch point where we eliminate other possibilities, or the system may admit to multiple solutions. Even in a straight corridor, a useless direction to go backwards might be valid, or it might signal something unusual. One interesting aspect is the overall feel of the maze. The RLE level will likely have a visible maze with an unusual number of long straight corridors; this befits its usefulness as a compression scheme to describe data with long runs of a single value.

We present the player with two related problems. He must figure out how the given representation relates to the real maze he finds in front of him. He does this with the help of an automation system that we also expect him to learn to use. It is interesting to consider that the processing of a data stream is naturally a stream or dataflow programming problem, and as such it lends itself to expression as a flowchart. This suggests a straightforward graphical representation for user programs.

I think that this is considerably more interesting than the common cryptogram puzzle. While these can be somewhat fun, they rely on knowledge of various letter frequencies which have to be known in advance. With an unknown language, it becomes the much more difficult and interesting decipherment problem. The combination of visible mazes and encoded directions form a kind of bilinguis: we know that the directions are somehow indicating how to solve this maze, and we can check how well our attempted translation succeeds at this. Additionally, the encoding is conceptually interesting in its own right, which is valuable here where the thing being described (the maze) is rather dull. Even so, the maze is explicitly designed to help the player figure out the language, so we ought to make it a fun system to learn with.