How big is too big? (Number of puzzles)

Authoring General Design Discussions
,
1

I’ve been reading on posts regarding puzzle designs, and I don’t think I’ve found any reference regarding size. It seems like either they do it really quickly, as in game jams, or they take really long time, as in months or years.

In my view, it really boils down to Verb+Noun. The number of locations is actually rather irrelevant to me, even as a player. If the game features large featureless maze, then that’s undesirable. However, I have no problem with large, expansive landscapes for atmosphere, assuming that it is consistent with the tone of the game.

What it comes down to, both as a player and author, is the interactivity of the game. That means how natural are the objects implemented? Some games advertise as having so many words, but how many are distinct and how many are synonyms?

Assuming distinct verbs and nouns, a 2 word parser game will take V×N actions to implement, assuming that we’re disregarding Time element. Hence, a 3 word parser will take V×N×N. If you consider Inform with its extremely capable parser with large Verbs, then you can see why a significant game will take years to implement!

Then there is the type of puzzles:

  1. Pattern recognition: moon logic, puns, and the likes. Solving these kind of puzzles elicits “Aha!” moments.
  2. Combinations: logical sequence. 15 puzzle, sudoku, rubic cubes. Solving these puzzles requires “look ahead” minmaxing, type of thinking.
  3. Personality Matching: different people have different reactions to the same things. Dating sims, wargaming, RPG.
  4. Systems: These feature some algorithms and/or mathematical equations that you need to figure out and solve in order to win the game. Card games, simulations, RTS, action strategy games.

I find that the majority of IF puzzles lies in pattern recognition type. Some has personality matching types. As for the rest, very few. About as rare as those walking sims type. I don’t have anything against walking sims type, if they are of the “iyashikei” or “healing” category.

So, back to size. In order to properly implement a game you would either have to do V×N or V×N×N, multiplied by modifiers (adjectives, positional, possessive), multiplied by combinatorial puzzle factor. Once I realized this, I decided that number of locations is not a significant factor in game size. N^2 dwarfs just about everything else.

So, then what should be a good number for games? Counting the number of objects (or locations, assuming their numbers are about the same):

Less than 10: tiny / experimental games.
10-25: What I call Alphabet Design games, listing objects by letters. Small games, like short story (10) or half hour episode (25). Old Scott Adams games.
Up to 64: standard. Most 1980s parser games are of this size. Modern Introductory games are of these size.
Up to 256: large. Large Infocom games. Think z5 games. Level9 games. Professional games.
More than 256: Mega games. Think Sierra On-Line Time Zone, with 1200 locations.

I like small games, that I can play bite size sessions. As far as making them, I can’t imagine doing larger than 64 locations, unless I’m doing it as a professional. The combinatorial explosion does factor a lot in this case, especially if you’re not doing it using 2 word parser.

2 word parser, especially those with limited verbs, can be done relatively quickly, even with large number of nouns. The question is: do you prefer simple parser and rich worlds, or rich parser and simple worlds? Seems to me people here prefer the latter, while general populace prefer the former. There’s nothing right or wrong either way, but if you’re looking for commercial success, maybe you should consider building games with rich worlds, while sacrificing actions. That looks to me as the secret recipe for success both for choice games and visual novel. IMHO.

Note:
With systems puzzles, I find myself spending a lot of time balancing the game. If I find myself getting bored, it means the game needs more balancing, and the process continues for eternity. Obviously, I don’t release too many of those kind of games.

3 Likes
2

Size doesn’t matter so much as how you use it.

Also consider most large puzzles are actually a conglomeration of smaller puzzles.

Most, though not all, games have a “solution” and are themselves a puzzle made up of smaller ones, like an escape room.

3

I don’t understand your answer. Can you please elaborate? How do you “use” puzzles? In a way that is desirable?

4

That’s a nice pragmatic way to categorize things (even if edge cases will always exist) and some good reflections on the pros and cons of complexity in different areas.

I don’t quite follow on the second category. Just out of curiosity, what do you mean by “listing objects by letters”?

1 Like
5

It’s just a technique in design, basically limiting the number of objects to a maximum of 26 objects. So, you write down A-Z, and list each items by the letters, instead of by numbers. This works on paper (literal paper) because I can differentiate letters better than I can with numbers.

In coding, it means
Item(A), item(B), and so on where you do something like
Constant A=1
Constant B=2
And so on…
Computers, of course, works with item(1), item(2).

Just a little cheat technique in designing the game, that’s all. Makes for easier reading.

6

What I mostly mean is asking if a puzzle is “too big” or “not big enough” implies an arbitrary focus on puzzle size as opposed to asking how the puzzle serves the narrative.

That might not be a bad thing - if you’re designing a straight brain-teaser sequence of puzzles (like Sage Sanctum Scramble for example) you do want to pace them.

I would suggest to consider puzzles not as pre-defined obstacles to place in the player’s path, but more as pacing elements to make sure the player experiences the narrative in the order you want.

The simplest puzzle is a locked door. The player must find a key to open it. Why is the door locked? Is it because the author wants the player to explore more? Sure enough, but instead of just hiding the key in an obscure location the player has to dig for, place it with some lore the player needs: The scientist has a secret machine that could be dangerous, locked it in a room, and left a diary full of warnings and helpful instructions that he hid in a box along with the key so nobody would stumble upon it accidentally. That gives a reason for the locked door and that is more satisfying to know than just “the author just wanted me to look under the bed…”

This gives the puzzle a reason to exist instead of just holding the player up arbitrarily. Simplest puzzle ever, but it makes sure that the player understands the reason for the locked door and prevents them from accessing the machine until they understand what it is, and divulges the plot.

Resident Evil does this a lot. Finding three Cerebus dog head pieces to slot into a medallion in a door isn’t a fiendish puzzle - nobody needs to work harder than searching around for these three usually obvious pieces, but it makes sure the player discovers architecture and lore and perhaps a cutscene or two they should know before they get through that door.

That’s not to say you can’t make a puzzle where the player has to do actual “puzzling” but in almost any case everything the player needs to figure it out should exist in game.

And I understand you’re more interested in classifying puzzles by complexity and size, but again, most big puzzles - or “uber” puzzles - are sequences of smaller puzzles layered to create a big puzzle. I venture that puzzles should serve the narrative and plot and guide the player rather than just being a bottleneck to prevent progress until they figure out the specific thing the author wants them to do.

6 Likes
7

That’s great. I agree completely.

I understand you’re more interested in classifying puzzles by complexity and size, but again, most big puzzles - or “uber” puzzles - are sequences of smaller puzzles layered to create a big puzzle.

I’m having trouble coming up with examples of this uber puzzles. A sequence of smaller puzzles means several smaller puzzles, not one big puzzle. About the closest I can think of is Phoenix Wright cases, and I think that illustrate pacing more than puzzle layering technique.

I suppose that’s more of a different POV more than anything. There’s nothing wrong with stringing puzzles together, but you don’t have to. BTW, I’m talking about game size, as opposed to puzzle size. If you mean that a game is composed of several puzzles layered together, then I agree with you.

You can just as well making several small games, instead of one big one. Considering the VNN complexity, several small Ns is more manageable than one big N. Having several games in chapters, means you can beta test and release the game sooner than if you glob everything together.

8

Right, and that just depends on the scope of what you’re doing. A short game may have one simple or complex puzzle, a longer game may have several. An example is The Three Trials in The Secret of Monkey Island, which was sort of a revelation at the time: “You can solve the three trials in any order!” Each of the trials involved several machinations to solve that puzzle, and solving all three meant you could move to the next segment of the game.

That said, you can have long puzzle-less games, or short games that are nothing but puzzles. As long as the machinations serve the story (or not based on intention) there may not be a set preference for “big” or “small” puzzles.

In general, extensive puzzles will slow the pace of the narrative and alter game length, and that may be the core of what you’re asking. I remember in MYST if you know the answer to the final puzzle, you can (I think?) walk directly to it and finish the game within like 5 minutes.

1 Like
9

The problem is that there are a lot of factors in deciding how many puzzles is the right amount:

0: What makes sense for the game you are making. A classic early-Infocom-eque game with 10 puzzles is way too few. A one-room, one-object game with 10 puzzles is way too many, especially if it’s meant to be narrative-focused.

1: Who’s going to play it. People who are attracted to interactive fiction for the puzzles want lots of them, and may not require much linking between them (though they usually want some reason to move between puzzles). People who are attracted to it for the stories want lots of other things, and would prefer a few well-done puzzles that help emphasise the theme, plot and/or characters.

  1. When they’re playing it. Lunch-break games really need the puzzles to be short, and may benefit from the total length being limited (so you’re not playing the same game for six months). Games designed to be played during the weekends or on holiday need lots of length and having lots of lengthy puzzles can help with this. (Both are exaggerated further if for some reason you don’t allow saving in your game).

  2. The puzzle skill level of your players. This is less important for people who are playing because of the puzzles. However, if part of your audience is expected to have come primarily for some other aspect of your game, you will get away with more puzzles if they’re known to be capable players (or if you have really good in-game help) than if you’re aiming at people new to interactive fiction or who routinely need a walkthrough for the puzzling aspects.

  3. Your puzzle choice. The smaller the puzzle, the more of them that can be fit into one game. The more variety of puzzles, the more of them that can be fit into one game.

An example of an uber-puzzle (which would count as a “big” puzzle to me, with smaller puzzles inside), which I haven’t taken from any game in particular:

  • Task: you need to get a bucket of water from your well to the kitchen to make soup.
  • Problem 1: There’s a hole in your bucket.
  • So you go and find wood.
  • Problem 1b: You can’t put a branch on your bucket to plug the hole though.
  • So you cut the wood on your bench.
  • You bend the wood.
  • You nail the wood into the bucket.
  • Problem 2: Something has eaten the chain on your well.
  • You visit the blacksmith and buy a new one.
  • You attach the chain to the well mechanism.
  • Problem 3: Doing so has upset the chain-eating creature in the well.
  • You remove the chain before it gets eaten.
  • You fetch your shepherd’s crook.
  • You get the creature out of the well.
  • You put the creature in the empty well at the other end of the village.
  • You put the chain back on, attach the bucket, get the water and finally solve the puzzle you went to the well to solve in the first place.
4 Likes
10

You could give it a pack of cigarettes so it’s distracted while chain smoking…

(Also: chain-eating creature soup. Mmmhhh… )

3 Likes
11

Coincidentally, the text adventure reviewer in the magazine Electron User used to refer to these sorts of linked puzzles as “chaining puzzles”. The term I like best is “yak shaving”, and years ago I wrote a game that parodied the idea.

4 Likes
12

Which one was that? Oh, I guess this one: Yak Shaving for Kicks and Giggles!