Code-worthy gameplay
In 2008, Jonathan Blow, the author of Braid, gave a talk in which he described two "guiding skills", the latter of which was pushing. This is meant in the sense of pushing a concept to its utmost; given an idea, follow it through to its conclusion. Chris Hecker ranted similarly at GDC 2010. Pushing is what turns Braid's rewind from a gimmick into a gameplay mechanic. Rewind has the scary outcome that the designer can't really threaten the player with anything. Rather than shy away from this by limiting rewind, Braid actually illustrates it with the first few levels. World 2 is all about tricky platforming that would be tremendously frustrating to play through flawlessly. Since rewind allows unlimited rapid retries, though, it becomes a much more natural and forgiving problem solving experience.
One conceptual issue for the game I'm trying to design is that computation has a number of similarly "scary" implications that make it difficult to design around. Foremost is something you see frequently in robot-commanding games such as ChipWits: why do I need to write a program to do something that I can very easily do by myself? It can be very frustrating to have to build a program to do something straightforward. As Sid Meier has said, The player should have the fun, not the designer or the computer.
One of the great joys of games is the direct manipulation of the character, in artificially enforcing a disconnect between the player and character we aren't playing to the strengths of the medium. This is the complement of Blow's complaint about Prince of Persia: Sands of Time. PoP was constrained by game convention, so it limited the player's rewind ability in order to retain a more traditional play experience. With robot programming, we are eschewing good game interactivity practices for the sake of our high concept.
There's a good reason we're doing it, though. The programming interface is tremendously more powerful than direct manipulation, that's why we use it, and we think it will be fun for the player once he gets into it. The silly little intro levels are there for tutorial purposes; if we let the player play through those directly, then he will likely not be prepared for more complex issues later.
There are two approaches we can take to reconcile this, and I think a combination of them would be best.
We can make the tasks to be performed larger, duller, and less interesting to play out manually. For conceptual integrity, we might still allow the player to chip away at them if he so insists, but the tasks will be much better to perform through automation. This provides a motivation for programming in the first place, since this is why we actually bother with machines: to do things we could technically do by hand, but much more quickly and accurately. There is always some danger in intentionally making things dull, however. I consider this similar to the approach taken by Braid: rather than shy away from the difficulty, go ahead and explore it. If making the tasks to achieve dull is what is required to make programming appropriate, then maybe we need to find dull tasks that are nevertheless interesting to code solutions for. At the limit of this approach, you have infinite tasks like I mentioned here.
Another approach is to make the programming activity more game-like, through more responsive, animated visual elements. My old favorite Rocky's Boots is a good example of this, though clearly limited by technology. Being able to immediately see the results with highly interactive debugging and edit-and-continue features would help. This means that the programming environment must itself be a game world. In the interest of conceptual integrity, wouldn't it make sense for this to actually be the same game world in which our robots do their work? As I mentioned this briefly in an earlier post, I think there is a lot of potential in the programming system wrapping around to affect itself.