Red herrings

Sometimes a game can contain elements that are not part of the gameplay. Usually they are decorative, but if the player can do things to/with them, they can distract the player from the normal or intended way of playing. Some call them red herrings (I don't know the etymology of the term).

Players can feel a bit cheated when they spend a long time trying to use it or discover their function, when in fact they could or should have ignored them. The problem is worse in puzzle games, if an element that is usually part of the mechanics appears in a particular puzzle where it does not serve any function or even makes it more annoying to reach a solution with the other elements.

Avoiding red herrings can be difficult when designing puzzles manually. it's more difficult when using procedural generation, but we can mitigate the problem adding filters to the generation or evaluation processes that ensure there are no unnecessary elements. Even when manually designing the puzzles, we could use such filters as a tool for detecting irrelevant things and suggest their removal.

In particular, for this game I use a "blind" generator coupled with an evaluator that ensures each puzzle has a solution, and then a classifier that sorts the puzzles different categories. The blind generator makes levels almost at random, so to detect red herrings I focus in the evaluator phase: once I know a level has a solution, I try to "prune" the level removing elements, one by one, while keeping the existence of a solution (and making sure the puzzle doesn't become trivial). This ensures that the final puzzle will have a similar solution as the original, but without the irrelevant elements.

Sometimes, however, a totally pruned level will feel a bit dry; so perhaps I will add some randomness to the pruning process to allow for some red herrings after all...