Victor
This is one of those ideas that is too clever for its own good, but it is at least slightly amusing.
When you first encounter a 2D game, without reading any instructions, there is a potential for ambiguity. Is this a top-down view or a side view? Are these things walls or floors? This stuff looks like dirt, will the game let me dig into it? On a bus ride between Houston and Austin I came up with the idea of allowing these ambiguities to be resolved depending on the first few moves the player makes. If you indicate you want to go "up", then the game would assume you want a top-down view, since otherwise you couldn't have moved in that direction (barring ladders or similar). If you just move "right", you might be either in top-down or side mode. If you press A while you're running towards what would be a pit from the side view, the context would suggest that you want A to be the jump button, and the game would assume side view physics from then on. If you press A while next to an enemy, though, then A would forever be the attack button. And so on, the engine would try to create a game consistent with what you appear to be trying to do.
Funny as that idea was, I never came up with any interesting scenarios for it. It did, however, morph into the next stage: a game concept I call Victor. The previous idea would attempt to make any initial input valid, and assumed that interesting play would come out of this, especially once contradictions come about. Victor would strive to make absolutely any input result in some kind of progress, automatically generating an insultingly easy game. I've described this as "overbearing DDA", since the game turns a wrong move (indication that the player's skill is too low) into a right move, but without the corresponding increase in difficulty if everything is going smoothly. Another angle is to have a built-in walkthrough telling you exactly where to go, perhaps through narration, and correcting itself (and the level layout) when you go the wrong way.
That idea was sort of funny, too, as a one-shot joke about games being too easy or bossy. Loved and You Have To Burn The Rope do this much better than I could ever hope to, though, and I'm sure there are other exemplars I haven't seen. One way of making it more gamelike would be to allow the player to make a mistake and die, but then the level would be rebuilt to make that kind of death impossible. The goal would be to find every possible way to die in a particular stage. I got about one level out of this approach before giving up on it.
While trying to come up with "inverse level design" mechanisms that build the level around the player, I hit on a strange possibility: What if the algorithm that dynamically generates the level has intentional bugs? If you maneuver just right, you could work the engine into a corner, or catch the game in a contradiction. A contrived example: Consider a top-down viewpoint of your character in the middle of a rectangular room, which is so large that the walls are off-screen. The room is designed, for "dramatic" purposes, so that the door will be in the last wall that you encounter. Now suppose that once you have checked two walls you move diagonally, so that you encounter the last two walls simultaneously. A sufficiently buggy algorithm might show you both of these walls as doorless before it decrements its "walls seen" counter. But now the algorithm is stuck; it can't put a door anywhere because you have already seen all of the walls. The only thing to do is to invoke a deus ex machina: maybe a door magically appears, or a wall blows up. If we are using a narrator, he may become irritated at his character and skip on to the next part of the story. I consider this a way for the game to admit defeat, and thus this is the only way that the player can meaningfully succeed.
I haven't made this game for a few reasons. First, it doesn't have quite the same impact if the player expects the game to be doing these manipulations. Most of the reason to play the game is because of this amusing system, but if I can't talk about it beforehand I'm unlikely to get many to try it. More importantly, the contrived example above is the best idea I've had, and it is really lousy. It would pretty much require the player to read the source code or a walkthrough to figure it out. I also prototyped a platformer that starts with a blank screen; if you fall into a blank space, the game places a platform under you, if you otherwise move into a space it is filled in as background. This was sort of fun to poke at but it was far too easy to break. Many other mechanics never made it out of my notes. I don't see much hope in ever getting this one off the ground, but at least it was a fun design exercise.