This post has very minor mechanical spoilers for the game.
Earlier this week, I teased that I had found a solution to a lingering design issue:
The issue itself I’ve talked about in a previous blog post. You can read all about the problem there, but to briefly recap: I have a mechanic where depending on if a symbol is white or black, this indicates whether the tile containing it should be lit or unlit:
The correct combination is “black means lit” and “white means unlit”, but the issue is that some players find the opposite to be more intuitive, for perhaps obvious reasons. This means that those players will continually input solutions that are technically correct, but are logically reversed from one that the game will accept.
This is a particularly nasty issue, and solving it seems to require a compromise of aesthetics or intuitiveness. Again, I’d suggest you read the original post if you want to understand more, but in summary: none of the possible aesthetic solutions I could think of really worked well.
So why do I think I have a solution now?
Partly, I think I mistook the domain of the problem. I believed that what I had was an aesthetic issue, and so I was trying to solve it in the aesthetic domain. But in fact, I believe that the core of the problem is mechanical.
See, the dice face mechanic has two aspects. The first one is the one that we have already mentioned: a black symbol means that a tile should be lit and a white one means that it should be unlit. The second aspect, I don’t want to spoil here, so bear with me if I’m being vague (although I have talked about it previously on this blog).
The solution is that I need to decouple those two aspects. If I simply remove the lit/unlit requirement from the mechanic, it solves most of the problems. The only downside that I can see is that I will have to redesign the early puzzles in the area (about the first 10 panels or so), as those panels mostly focused on this aspect of the mechanic. For the later puzzles, I believe I can make most of them work by using the separate mechanic of locked tiles (tiles on the panel that the player cannot toggle from their starting state) in order to force a certain dice face to be on or off.
In some sense, this is a realization of my failure to enforce orthogonality (one of the aesthetic virtues outlined in this talk, which I also share)Â between the dice face mechanic and the locked tiles. In fact, I mentioned this exact possibility in a previous post about orthogonality:
Second, I felt like the “is it lit up or not” aspect was an additional point of overlap with the dice faces, which already care about being lit up. It may come to a point where I want to separate out that aspect of the dice faces themselves, but at this point, I’m letting them care about what’s lit up or not, so it seemed like the new mechanic shouldn’t care.
So when I said “win-win-win”, what are the 3 wins here?
- Removes confusion. By simply locking the tiles whichever way they need to be for any given puzzle, I remove the cognitive overhead of the player having to remember which is which, and put the focus on the actual content of those puzzles.
- Removes busy work. At the moment, a skilled player starts one of these panels by immediately turning all the black marked tiles on and all the white marked tiles off, because no matter what, the solution will always require them to be that way.
- Larger possibility space for solutions. The fact that, by default, the tiles no longer care about whether they are on or off, allows the player to have more flexibility in the way that they choose to solve a puzzle. This also gives me as a designer more room to play with the player’s expectations, and create puzzles where the solution may require some thinking about which colors to choose.
There’s also an additional and more subtle win across the rest of the game, in that as long as the dice face symbols were always suggesting that “white means black” and “black means white”, there would always be a bit of incoherence to other puzzles in the game that might simply require the player to match colors.
All the way back in the second devlog update, I mentioned that “the best ideas are the ones that solve like 3 problems at once and in hindsight just seem stupidly obvious.” Admittedly, I haven’t done a full pass on the entire area, so I may be putting the cart before the horse, but I feel pretty strongly that this is another example of that phenomenon.