malvasia bianca

In my previous post on Blue Prince, I talked a little about how it was both a roguelike and a puzzle game, how it was an odd example of both, but that they nonetheless managed to work together. And I wanted to say a little bit more about that now that it’s been bouncing around in my head for a while.

One problem with puzzle games is that you get presented with a puzzle, you fixate on it, and then you either solve it or you don’t. If you do solve it, then great! (Though even that can turn out to be a bit much if you’re going from puzzle to puzzle to puzzle without a break.) If you don’t solve it, the sensible thing to do is usually to sleep on it for a while, but usually I’m a little too hyped up to actually want to do that; and of course sleeping on a puzzle doesn’t always work.

So then I end up banging my head against the puzzle more, getting frustrated. Maybe I eventually solve the puzzle, but it hasn’t been a good experience; maybe I look up the answer, and that’s a worse experience, one that frequently ends up poisoning the game for me.

I mean, I like puzzle games and I’m pretty good at them, so usually it actually turns out fine. But still, these scenarios are real ones, and they’re a real problem.

So what would we do if we wanted to design a puzzle game that was less vulnerable to this problem? You want to discourage players from focusing on puzzles: so don’t put them front and center in players’ faces. Make the players discover the puzzles, make the players come at puzzles obliquely, make it so the player sometimes isn’t even sure if something is a puzzle at all.

Once a player has discovered a puzzle, though, you don’t want them to just bang their head against it. So put in limits to prevent that. Make it so a player is discouraged from, or potentially even can’t, try a puzzle too many times; make it natural for them to stop trying; and, when that happens, don’t throw the same puzzle at the player in their next session, give them a cooling off period instead.

And normalize failure. Maybe make it so you can’t even solve every puzzle you encounter no matter how hard you think; make it so there’s enough other interesting things going on that players still find the experience rewarding even if they were looking forward to solving some particular puzzle but weren’t able to.

But how exactly do you do that? For the first part, embed puzzles in the environment; the fuzzier the boundary between what’s puzzle and what’s environment, the better. For the second and third parts, however, you want something a little more structural. Put in resource limits; have randomized resources required to solve a puzzle; don’t have a given puzzle even appear on every session, maybe not even on most sessions.

Those latter points dovetail well with a roguelike design: roguelikes normalize the idea of repeated runs, runs that will be failures most of the time when you’re learning the game, and runs with randomized environments and items. So yay, problem solved.

If you’re really leaning into oblique puzzles, though, puzzles that you’re trying to help the player be interested in but not fixated on, then roguelike design is a mismatch in other ways. Roguelikes have you working towards gaining mastery over your runs; so yes, you’re working within a design space that depends on randomized elements, but the randomness and the interactions that it allows are pretty tightly controlled.

Also, if we’re trying to dial back our puzzle game and make it more chill, we’ve got a mismatch: “chill” just isn’t an adjective that I’d use to describe most roguelikes.

So we also have to make it a weird roguelike: just like we’re dialing back the intensity of the puzzle game, making puzzles more oblique, and making it totally normal to not be able to solve every puzzle even when we’re doing well, we also want to dial back the intensity of the roguelike, making the systems nature more oblique, and making it totally normal to not be able to meet whatever criteria the roguelike side has for progression on most runs.

In other words: a weird puzzle game combined with a weird roguelike game; but the weirdnesses on both sides are actually very similar, in a way that helps the two sides mesh and work together. And, as I’ve described here, they mesh in a way that solves certain problems that the puzzle game genre has; but, honestly, there are also just as many people who find roguelikes off-putting (I’m sometimes one of them, certainly more often than I am with puzzle games), so this lowering of tension can help from that side of the genre pairing, too.

I think this isn’t completely unrelated to why Hades got relatively broad traction: in that game, you’re not just trying to get better at making it through battles, you’re also trying to piece together what’s going on narratively. And the flow of that side of Hades has something in common with the flow of Blue Prince.

To be clear: I’m certainly not claiming that this is how Blue Prince’s designer thought about these problems. And I’m also not claiming either that this is all that’s going on with Blue Prince or that doing this well is at all easy to do: I continue to be amazed at how well the discovery flow and balance within Blue Prince runs works, getting that right feels extremely difficult to me. But I’m at least starting to understand better why the genre pairing works for me.