Game Musings - Quest logs

I think Quest Logs are really interesting. They’re something I tend to appreciate as a player, and I often see user reviews complaining when an open-ended game doesn’t have one. However… I also am trying to never put one into any game I ever make.

When I talk about “quest logs” I’m talking about a game menu that maintains a clear record of all your current objectives and “quests” - the player’s active to-do list. Often this will keep a record of past finished quests too. On paper, this seems like a straightforwardly good idea. Having a quest log means players always know what they need to do, and they know where to go to find that information if they forget, like for example if they haven’t played the game in a couple weeks. Having info organized like this can be especially indispensible for larger games with many overlapping tasks.

The hidden downside of these logs are that they tokenize every interaction playrs can have with the story. For example, imagine meeting a character in a town who mentions offhandedly that their cat is missing and they’ve been feeling sad about it. Details like that can help enrich the world by giving you the feeling that other character have their own lives and problems going on alongside your own. But a player might naturally wonder whether that information was just for flavor, or whether it’s a problem that they are meant to solve - a quest to find the missing cat. A quest log system makes this completely unambiguous; if you suddenly get a popup saying “New Quest: Find the missing cat,” then you know now that it’s a problem to solve, and if the game has a quest log but doesn’t log this as a quest, then you know that it wasn’t meant to be a task for you.

If something is a task for the player, then they naturally will pay more attention to it. The unfortunate other side to this is, if something is “just flavor” and isn’t actually tied to any task or reward for the player then they’ll tend to ignore it. It’s very easy to get into a mode where you’re simply clicking through all the dialogue and interactions you can have with townspeople to see what actually lands in your Quest log as a to-do item, and then focusing on that in order to progress through the game. (I’ve done this in pretty much every game with a quest log).

Amgiuity is “worse” for the player in the sense that they don’t always clearly know what they’re supposed to be doing, but “better” in that it actually forces them to pay more attention to the story of the game, and make their own inferences about what’s important. If there’s a missing cat the player can find, but they aren’t explicitly told that, then they get to have the thrill of finding that out organically, and the satisfaction of remembering that townsperson who said her cat was missing. But of course, it could be bad if it wasn’t really intended to be a quest, but a player wrongfully assumes that it is, and gets frustrated looking for a cat they’ll never find. Or perhaps worse, they *have* to find a missing cat to beat the game, but they missed the hidden cue about it when they talked to that one townsperson and now they’ll never figure out what they need to do without looking it up…

All games have a hierarchy of what’s important and what isn’t, whether that hierarchy is exposed to the player or not. Athough I love the convenience of always knowing what my tasks are, I value games that allow space for ambiguity. Ultimately it makes for a more believable world, full of potential surprises and depths that you can uncover only through your own judgement and curiosity.

There’s a lot more I could say about this, including how we approached this problem in Chicory (a sprawling, sidequest-filled, open-ended game with no formal quest log…) but I think I’ve already rambled enough in this one.

(This is part of my “Game Musings” newsletter where I write thoughts about game design and development. If you just want news and updates on my projects, you can edit your subscription here.)