Puzzle Game Design: Start Methods

So, Portponky had a long (er, cough) post on Reddit here (don’t worry, all links here will be to another tab/window) about puzzle game design. …That post is in my experience only above average for Reddit standards, and my Great Star Offensive review was just below 6000 words, which is like 10 times the length of his post.

If you don’t have context, he basically replied to someone asking him his engine and puzzle design advice. That someone deleted their comment. But what about his engine?

I have more than a decade industry experience writing C++, and once you’re used to the big guns it’s hard to put them down. Godot looks great, but there is a learning curve with any new tool, so I tend to stick to what I know best. For reference the game took 8 months to develop.

…Honestly, I’m not sure he cares, since it only takes up like two lines. I’m still not sure what his opinions on Godot are or if that’s even the engine he used. Anyway, the real part of this I want to respond to is the puzzle design stuff.

I have SO MANY opinions about puzzle design, so this post might get long. tl;dr: If you want to write books, read a lot. If you want to design puzzles, solve a lot.

First of all. The original post is not long. :/ I’ve solved and made puzzles for fun (as well as made fun of puzzles…) for years, so I think I qualify. I highly suspect there’s a better way to do so though – like playing incredibly bad games to see where they went wrong. I agree here. One of the things I feel like when writing is that I’d at least like one person invested like me so I can really feel encouraged about taking the time to write a long article.

When I design puzzle games, I tend to first think about each mechanic. For Recursed, there were about 8 mechanics that I put into the game and about 15 that never made it past the drawing board. Mechanics should be reasonably simple to understand, distinct from each other and there should be a variety (e.g. items, environment, etc.). Most importantly, mechanics should interact in interesting ways. I don’t add a mechanic if it acts in a way that’s too isolated from other mechanics.

Disclosure: I haven’t played Recursed. It’s interesting, but I no longer spend the time nor money on the risk of dud game purchases since about a year ago. So if a critic contacts me about how Recursed is actually flawed in XYZ, I’m not gonna take any junk from people taking my agreement on a certain topic to be representative of if the game even follows this quality. I’ve already witnessed when someone can say something and then not do it; instead of their opinions braiding, they conflict. In any case…

When I design puzzle games, I tend to first think about each mechanic. For Recursed, there were about 8 mechanics that I put into the game and about 15 that never made it past the drawing board.

Well, wouldn’t be much of a dev if you didn’t, there. I think there’s something missing here though. The definition of a mechanic is always somewhat vague, and if you were to include mechanics already used by the framework, you’d have a lot more; gravity, movement, jumping, in some ways exits. Since it’s almost always possible to split mechanics you can change those to be taken in the view of “just” being split mechanics combined – for example, some games don’t allow for full movement and only allow moving in one direction. Ice-block games only allow you to move the maximum space in one direction at a time. (And whether ice-block games’ “slipperiness” is a result of the ground or the player is for you to decide!)

Mechanics should be reasonably simple to understand, distinct from each other and there should be a variety (e.g. items, environment, etc.). Most importantly, mechanics should interact in interesting ways.

From the ice-block example from before, there are some mechanics that are more like modifiers. For example, one mechanic in Recursed that gives off a green smell will not exist without a respective key or door. However, I am not sure that redundancies are necessarily bad. While if underused it could seem like it was only made to add “+1 feature” on the marketing, it is still good to explore a mechanic just to find any possible interesting side effects to either expand or change.

Most importantly, mechanics should interact in interesting ways. I don’t add a mechanic if it acts in a way that’s too isolated from other mechanics.

I copied the last sentence here because it also applies. I don’t agree with this. In the simplest example, say your game involves oranges. You also have a converter that converts apples to oranges. Your game has no apples. Under this, you would have to remove the converter and never be able to make either the apple or the converter mechanic at all just because they are useless on their own. Basically, you can have interesting loops involving seemingly otherwise isolated mechanics.

(Also, we basically just hit the length of the original post (subtracting quotes, I’m not that dumb), and we’re hardly done. >_>)

Now, as to the ‘interesting ways’ part, that is completely true. Designers have to be worried that they could be making backwards progress each time they add a new mechanic. Note that this is more susceptible in terms of rules, not mechanics – you could make an equally devastating change to a mechanic you already made, and it would be harder to notice. You could completely brick all your levels in a platformer by lowering jump height, but if you alter a tangible that’s even worse – at least in the previous scenario a lot of the levels would be easy (but time consuming) to fix.

Before I go to the next part of the post, I want to quickly mention restrictions. As a beginner puzzle designer, you may have come from anywhere – I did some puzzles in Marble Blast and Super Mario Bros. X (while greatly embarrassing myself), and then made a Talos Principle level. However, you could have used Mario Maker (grumble grumble), PuzzleScript, or Scratch. All these have varying amounts of restrictions; whether ridiculous like The Talos Principle or ‘just’ engine issues which I’m sure happen.

(I’m not a programmer; even though you may see me say I like programming puzzle games, that’s it. I think current programming tools are too terrible and tedious to use, as if they were made by a designer of [insert bad game here]. The only reason I like them is because the best ones, especially LogicBox HTML, actually fixed some of the big issues. So check out any anecdotes from other people who have actually had engine-related issues with mechanic implementation.)

expc1
As you can see, the death zone is very close to the start. What? You don’t believe me? Try taking a box.

With that, you actually have to fight the designer a bit. For example, The Talos Principle has no undo mechanics and an instant death, which is terrible for puzzle design standards. Due to this, I tried to make death and rewind as infrequent as I could, but I didn’t compromise puzzles that needed their use. In those puzzles, I did things like place the death zone very close to the start.

What this is basically leading to is that if you also find one of the mechanics you made are tedious to use, it should be greatly considered – such hiccups can easily be worse than overly harsh loss penalties, but you will have to carefully weigh design space versus wasted time. (There’s a spacetime joke here somewhere, and I’m not getting it! Argh!)

Other elements can also play a part as well – in The Talos Principle’s case, there is already a resetting feature built into the game and it would not impede plot to allow for free undo, and easily other puzzle games without story can add an undo feature, but what about games with stories that shouldn’t allow the player to go back at all, where gameover resetting already takes you out of the action a little bit? It’d be nice if all puzzle games had a rewind feature as an industry standard, but unfortunately this is not the case. (Hell, not even programming has that, but that’s just because it was never meant to be used by human beings anyway.) Funnily enough, the treatment of the lack of an undo pretty much perfectly fits what I mentioned earlier about working around design decisions.

OK, onto the design level methods.

For puzzles, I have three methods of designing levels. They’re pretty much easy/medium/hard.

1) The ‘tutorial’ style level. I think about one facet of a mechanic and come up with a simple situation that is impossible to solve without using that facet. I try to keep misdirection to a minimum, and lead the player on towards the solution.

2) The ‘adventure’ style level. I think of an unusual action the player must take (e.g. copy a chest and take it inside itself). Then I come up with a level for which the player must do that action to solve the level. THEN, I do my best to disguise the possibility of that action. I misdirect away from it. I move all the pieces so the player isn’t likely to randomly bring the right components together.

3) The ‘chaos’ style level. I make a level that’s directly impossible and then try to make the smallest possible tweaks until it’s possible. Create the tiniest crack in its armour. This one’s highly iterative, but it can give great results.

I think this is pretty accurate, but not applicable for all games. I’ll get to that later, but first, analyzing each one.

1) The ‘tutorial’ style level. I think about one facet of a mechanic and come up with a simple situation that is impossible to solve without using that facet. I try to keep misdirection to a minimum, and lead the player on towards the solution.

These end up being generally solid because they are easy to examine. However, I now find I no longer do these kinds of levels. The reason being that there is a high chance it will feel redundant. Several times in The Talos Principle, you could go out of order with levels, solve a harder puzzle before the tutorial one, and then the tutorial would be complete filler. The length of two tutorial levels can usually be very easily combined into one, and the misdirection that offers can even make it into one new puzzle. The only time I would still use the tutorial style level is a massive need for leading (the player), though I often find when the player must learn a mechanic I would rather make it impossible or obviously impossible to do anything else, often with narrow paths.

2) The ‘adventure’ style level. I think of an unusual action the player must take (e.g. copy a chest and take it inside itself). Then I come up with a level for which the player must do that action to solve the level. THEN, I do my best to disguise the possibility of that action. I misdirect away from it. I move all the pieces so the player isn’t likely to randomly bring the right components together.

Honestly, this is a LOT like Tutorial mentioned earlier, and is the from-start way to build a level. In The Talos Principle or even Mario X., making a level’s elements is somewhat tedious to do. This means you basically cannot get anything wrong or you’ll have to demolish what you made. To me, this is only a part of the puzzle of puzzle design, but it is solid.

3) The ‘chaos’ style level. I make a level that’s directly impossible and then try to make the smallest possible tweaks until it’s possible. Create the tiniest crack in its armour. This one’s highly iterative, but it can give great results.

To be fair, this is a bit of an overspecification. Any developing puzzle in any category is going to at some point have a few oscillating parts – some too lenient, some too strict, and you’ll eventually walk a line of impossible and possible while balancing aesthetic things. So, I think doing ‘chaos’ is just as viable if you have an overly possible level and just cut things – it’s just more possible to cut the overly possible level in a way that’s redundant or already explored, versus finding something actually new.

Now, I want to combine what’s being said in 2), 3), and this next section to make a point.

It’s bad form to have an object in a puzzle that has no use. It feels cheap, and players dislike it. Players have a tendency to associate each ‘object’ with one part of the solution.

That whole line is like zigzagging all over 2)! Objects that serve no purpose (or stuff like pathways; you could be more subtle) are just as much a part of misdirection as trying to find the largest possible space between the key objects. I also think once your player solves a puzzle that has a dummy item, they will grow to expect this from the puzzle design. Jelly No Puzzle is guided to the very end with very little red herrings, but The Talos Principle does indulge in red herring puzzles, even if they didn’t make all too much use out of it. Sure, it’s a bit cheap if you plopped Red Herring Puzzle #6 as Puzzle #1, but not if they know. This also makes the rest of the levels slightly less obvious as well.

…but maybe it’s moot, since the quote cycles back to kind of agreement on what I just said? I’m not sure how this was supposed to go.

You can really screw with people by playing with that expectation. E.g. One of the fairly early levels in my game has an object with three distinct uses, which really jams people up for a while. Of course, if you do it all the time, they’ll expect it, so you have to keep your puzzles varied. Some levels are MacGyver, some are Columbo.

Anyway, on the promised 2) 3) Q) combine. Because speaking of combine, where is it? I am more inclined to believe he just left this out by accident because combining puzzles is such a common thing – many ‘chaotic’ answers from 3) can lead into combined puzzles. This is where more than one idea is going into the puzzle, and it can lead to some pretty memorable feeling stuff because you can tweak the level so that the combination is more relevant. For example, any leftovers in Puzzle #1, or switches or positioning you changed, can be used in Puzzle #2 – or surprise the player and they don’t matter at all.

I’m going to return to when I said I’d look at this as an overall. Some puzzle design does not allow for this. Programming optimization games are the biggest example here – solutions are purposely so open ended that there is a bigger rift between possible and impossible. Minute changes can really reduce how succinct a level ends up. For example, it’s possible for any given card in a card game with a number (say 3), that that number is not the perfectly balanced number, but the number it should be is something like 3.6724. Now this perfectly balanced game will require a lot more number crunching and might be less fun overall. Instead, design strategy goes for rapid-fire abstract levels instead (almost like spamming ‘chaos’). You’ll have to think of ways your ideas ABC can fit in a level with as few issues, and you may have to ship flawed many times without knowing it.

Once I have a lot of levels, I do a lot of playtesting and iteration. People generally approach situations in similar ways, and are easily tempted to do certain things, so you can tailor situations to their benefit. That way, they feel like they’re doing the right thing. Playtesting also allows you to get rid of any bad solutions (e.g. alternative solutions that are very laborious and feel bad) and any glitches/shortcuts in the puzzles. There is no such thing as too much playtesting.

I’ve never had a lot of playtesters, so I can’t speak to this. However, I’m glad I don’t hear the design excuse of “Ignore the proposed solution they give” – I mean, wow. That’s so rude. But anyway, even though it’s short, I do wonder about playtesting specifically for first-timers. While an experienced playtester can quickly recreate a level’s solve, I don’t know if they can so quickly recreate their first playthrough. Unfortunately, there will probably be a bound of people and a bound of time on finding what the optimal level order is.

Finally, once I have a full set of levels, I try to order them well. Make sure that levels teach skills in the right order and build upon each other. DO NOT just put them in linear order of difficulty. If the difficulty is too linear, players will reach a certain point and give up, feeling hopeless. Have some relief after a challenge, so the player does not get too fatigued.

Heh, that’s convenient. So, this is generally true – a linear level of difficulty doesn’t work (“but what about quadratic?”). However, there are difficulty scales that are pretty much always often used. For example, a game with mechanics ABCD will not sporadically have perfect difficulty increase. Instead, it’s more likely to see mechanics selectively limited in certain sets of levels for both a sense of consistency and tutorialization.

But really, I don’t think a linear set of levels is a good idea. Some games are now using a system where multiple levels are unlocked at a time, and one more is unlocked if you solve one. I think this is a much better system. Note that the player will still reach a point where all X levels are stuck, but they can vary their progress and not feel like they are out of options. There is obviously the extreme of all-open levels with hidden information on purpose, which is also worth considering, but never done in a traditional level select. This is somewhat strange to say because I thought Recursed already had multiple levels unlocked at once from the trailer…?

It may be interesting to note that side missions can also be done the fully-open sense mentioned earlier, and in a LogicBox-style game, you can have them still be ‘worth’ something – I think it would be the best way forward, as currently LB is extremely linear if you discount side optimization.

(In more detail about LogicBox: Each level is a new tool thanks to the design of the game. For a majority of the time, these tools are not necessary, but they are greatly compact and are therefore convenience. Each time you complete a level, it can be used in future levels. So if the game were to have 10 extra, simple levels, per chapter, the player could have something to do when they hit a roadblock, using the ideas of the simple levels to mull over the level they’re stuck on. Due to levels being tools, doing these side missions won’t just feel like busywork.)

Hopefully that helps.

🙂

 

 


Hey! So, I’m a developer of some sort, as well as other things. Currently, reviews suck, so I’m trying my hand at it, even though I’m not really a writer, so apologies for any issues that might cause. Apparently, this site forces ads, so please use an adblocker when viewing the site. I do not make money off any ads on the site. Useless social media: YouTube (still having issues), Soundcloud, Twitter, Voat, Wordp- hey wait a minute!


 

 

 

“I wasn’t expecting EXTRA long!”

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s