Thanks for all the useful information, I hadn't thought about some this!
I think much of the responses have been in favor of allowing players to get "stuck" as long as 1) this is a part of the game design and is taken into account with the appropriate level design, and 2) the player is well aware of this mechanic, is given useful information about such mechanics, and is given useful information about when they have reached a point where they can not make any new useful moves and must restart somehow OR this information is conveyed natural through good level design.
(4) Another option is put in the one-way doors and similar irreversables, but also allow infinite undo. (Like, say, Sokobond.) You can always get out of whatever mess you're in, but the logical structure of the puzzle is still such that there's a "one-way" door.(5) A further option, midway between suicide and undo, is checkpoints. Overt ones, like in a precision platformer (VVVVVV, YHTWTG, etc.). I can't think of a puzzler that does exactly this, but it'd be kind of interesting. So have squares that "save your progress" such that you can always return to them at the touch of a button, like a less-granular "undo".
(6) Iterating back through the player's moves and deducing at which point in the past the level *was* solvable, then, upon suicide/death, rewinding time to that point. I don't know of any game that does this, but it's an interesting idea. It ends up being a hint, of course, because once the player realizes what's happening, they understand at what point in time they made their fatal move. But depending on the game that might be an entirely appropriate kind of hint.
I like the idea of being able to "undo" certain moves. Unfortunately for my game, encapsulating "moves" is a bit difficult because the gameplay is a mixture of "continuous motion" movements (moving around the level), and discrete "level reconfiguration actions". I think the latter type of mechanics would allow for undos, but trying to convey to the player what exactly constitutes a "move" and how to undo it for continous motion is a bit difficult in my situation. I know there are some games that have done this before, but for my game I don't think it would nessesarily work well. Implementation probably wouldn't be too bad, but I'm a bit limited in user interface (it's mobile) and would like to leave the complexity in the user interface this would make out of the game. It's something I will probably explore in future games though. Also the game I have in mind should be an entire level on one screen, so checkpoints might not be easily designed.
For the one-way door, what if instead it was a door that isn't always accessible? To even reach the door, the player need to reconfigure the local area of the level sufficiently to allow access to the door.
Cool I like this concept. I'm not sure it would work in my game, but I think this would work in a lot of cases (I remember dungeons in Zelda applying this design).
Add a 'teleport pad' or something beyond the 1 way door, which carries the user back to the initial part of the level, and clearly tells them that the task has been reset.
Thanks, I'm not sure it would work in my specific case, but I might experiment with this idea.
You don't want to simply hold the player's hand and make things a cake walk, but do make the process of moving through puzzle sections as streamlined as you can. Give them clear methods to reset or revert easily if they need it, and make cause and effect fairly obvious. (Don't have a button in a 3 stage puzzle that has a 'random' effect for example on the last room, but can only be pressed in the first.)
Ya, I think finding a balance between "too hard" and "hand holding" is key. I like the idea of the player required to perform a specific set of actions in a certain order, but this needs to be clearly communicated to the player, and the player needs to know when they've gone past the point of no return. As long as that is communicated clearly, then in the absense of a notification of failure, the player will continue to try under the assumption that they haven't messed up yet. If that is not communicated and the player keeps trying despite this unconveyed information, I could see the player getting very frustrated in the wrong way.
