17
\$\begingroup\$

I'm currently working on a turn-by-turn puzzle stealth game (as a student group project), inspired by Tiny Heist. The basic mechanic is that every time the player moves a square / does a thing, every NPC moves as well.


My objective is to make an experience similar to Portal: the player goes from room to room, each room has an entrance and an exit, with obstacles between them. The player can see where the exit is, as well as the obstacles, and must leverage the game mechanics to bypass the obstacles and reach the exit.

An example room would be:

  • There is a corridor, with a guard going back and forth. The exit is at the end of the corridor.

  • There is a closet in the middle of the corridor.

  • The player must exploit the guard's patrol to hide in the closet, let the guard pass him by, get out of the closet and reach the exit.

I want the player to feel perplexed when they're trying to solve the puzzle; ideally, I want them to feel there is a solution just within their grasp, but they can't find it; and I want them to feel smart once they do solve the puzzle.

The problem is, I don't know how to design puzzles to give that experience. I have a few ideas, some of which feel like they'd make fun "early game" levels, but after a while all the levels I'm sketching feel same-y and boring, or too complicated with too many moving parts (I had the same problem back when I tried to design Portal 2 levels).

I want to create dependencies, levels where the mechanics overlap with one another to make the player think "I need to do X, but I can't do X before I've got Y, but how do I do Y without having done X?". I could add additional mechanics like dogs, or security cameras, but I don't know how to exploit them.

When I try to design a level, the kind of ideas I come up with follow a pattern of "you need to turn off the cameras to progress, but you need to give a bone to the dog to reach the camera, but you need to distract the guard to acquire the dog". These ideas are convoluted, but shallow; they don't feel like they'd make for intellectually stimulating (or even difficult) levels.

What methodology or design pattern can I apply to create richer problem-solving opportunities for the player in this stealth game context, or in any kind of puzzle game?

\$\endgroup\$
  • 4
    \$\begingroup\$ I notice some close votes on this question, but I think there's a specific question here we can fruitfully contribute to our Q&A structure. Following the game-design tag's guidance, this question 1. clearly defines the game context, 2. describes the feature being designed, 3. identifies a specific target experience that the design should support, and 4. asks for a strategy to deliver that experience. I think this gives us enough to identify potential correct answers to the problem - I've attempted one below, and I'd welcome more! \$\endgroup\$ – DMGregory Oct 24 '17 at 12:49
  • \$\begingroup\$ @DMGregory Nicely explained. \$\endgroup\$ – S. Tarık Çetin Oct 24 '17 at 14:54
  • \$\begingroup\$ A relevant extra credits on how stealth games can go beyond waiting, and leverage playing as the underdog. \$\endgroup\$ – Will Oct 26 '17 at 17:12
  • 1
    \$\begingroup\$ While the Extra Credits episode is relevant to the title (puzzles for stealth game), it doesn't really help with my specific project (turn by turn puzzles, with more reflexion than waiting or suspense). Thank you anyway! \$\endgroup\$ – Narrateur du chaos Nov 2 '17 at 4:25
  • \$\begingroup\$ For a few limited ideas you might check out the original, 2D Castle Wolfenstein game. Guards could be snuck past, shot, knifed, tricked with fake identification, and probably a few other things I'm forgetting, each with different benefits and drawbacks. \$\endgroup\$ – Perkins Feb 13 '18 at 0:24
11
\$\begingroup\$

What it sounds like you're currently missing is a way for the player to influence the state of the level and its patrols.

If all the player can do is identify a sequence of hiding places and wait for their opportunity to cross between them, then I think you're right, the level design space becomes somewhat limited (though you could embrace this dodging detection as a core play experience, like the Frogger or Bullet Hell of stealth)

Check out other stealth games and you'll find they often contain ways to make new opportunities. A few examples....

  • throwing a rock or noise-making device to divert a guard from their course, or a piece of meat to distract a dog
  • donning a disguise to slip through a checkpoint undisturbed
  • stealing a key or information needed to open a secure door
  • deactivating a security system or moving its detection area

Once the player can influence the state of the level, it becomes a problem of how to defuse the threat at each juncture, and there might be more than one solution depending on how the player changes the situation.

To get the kind of staged logical reasoning you're talking about, you should consider the dependency graph of the steps the player needs to take. Zelda dungeons do this all the time in their level design, forcing the player to do one series of actions to get a key for a locked door, or to access a switch that changes the dungeon's state in such a way that a new area is reachable.

The last thing to consider is that stealth games are often playgrounds of consequences. I open the gas line which makes a hiss which lures the guard who falls unconscious from the gas who's then seen by another guard on the next patrol who diverts from his path which lets me slip through but gives me only a short window before he sounds the alarm - the level can be a Rube Goldberg machine of chains of events. :)

To maximize the possibilities you get from this, think of each object and verb you add to the game, and how it could possibly interact with every other.

Guards can detect the player. What else can guards detect? How do they react when they detect that thing? If the player can throw a rock on the ground to make noise, what else can the player throw? What else can a thrown rock trigger? (eg. activating a switch from a distance, or disabling a camera... if a camera can be disabled, how does a guard react to detecting a disabled camera?)

Thinking about all the potential intersections of your features is what helps you build a rich world for problem solving, and identify game verbs or elements that might be very one-note and don't offer the kind of gameplay variety bang-for-your-buck that you're seeking.

One of my favourite descriptions of this style of game design was from Jonathan Blow, who described the role of the designer as "curating the mechanics to achieve the maximum combinatorial goodness" - and I think this style benefits stealth games especially.

To close, I'd also recommend watching this talk on the design of Mark of the Ninja for some more inspirations - it's one of my favourites. :)

\$\endgroup\$
  • \$\begingroup\$ Mhh, that is helpful. The problem I run into when I think along those lines is how do I design the abilites / puzzles so that the player doesn't solve every single problem the way, or that the solution isn't obvious? For instance, I don't want the player to think "Oh, a guard. Well, there's a [distraction] next to him, I'll just use it to get past the guard. I think I'll start by thinking about ways to Rube Goldberg it (the distraction is protected by another guard, to distract him I need another item, etc), but I don't know if that interesting enough. \$\endgroup\$ – Narrateur du chaos Nov 2 '17 at 4:26
  • \$\begingroup\$ @Narrateurduchaos another way to make your puzzles more interesting is to occasionally subvert the default strategies. Ex: usually you don't want guards to notice you, but if they can open locked doors, deliberately letting them peruse you may be necessary in some cases. Having long chains of consequences can be difficult to figure out, but having different "flavours" improves variety with less increase in complexity. Making sure that the player is aware of the individual interactions is crucial. (If they have never seen a guard open a door, the puzzle above would be unfair) \$\endgroup\$ – Will Nov 2 '17 at 5:58
  • \$\begingroup\$ Quick head's up: while I really like your answer and the effort you put into it, the answer I wrote based on Mark Brown's video is the one that directly addresses the core of my question, and the one that I feel would satisfy people looking at this question with the mindset I had, so I'm validating it. \$\endgroup\$ – Narrateur du chaos Jun 5 '18 at 11:44
2
\$\begingroup\$

If you have ever played LittleBigPlanet 3, there are some bonus side levels which are side-scrolling puzzles where the controller controls 2 characters with the same analog stick. I can't find a clip at the moment.

Anyways, you hold the stick right and both characters go right; EXCEPT, if there is a wall to the right of character B, only character A will move to the right, while B walks in place.

You could add this to complexity to your game in later levels (or as bonus levels). Two characters start in different areas of the level, and the player controls both with the same buttons.

Here's how this could work with the scenario you described: character A is hiding in the closet, with the closet door to the left and the rest are walls. The player can input patterns of up, right, or down to move character B (while keeping A in the closet) to advance the guard's patrol, and navigate character B to his or her destination. Once the guard moves past the closet, the player can move character A out of the closet.

Obviously having the player control 2 characters simultaneously would require really thought out level design, but it could add that extra layer you are looking for. Hope that helps.

\$\endgroup\$
  • \$\begingroup\$ Another game like this is The Last Ninja Twins. It's a very cool mechanic! \$\endgroup\$ – user1118321 Oct 25 '17 at 4:50
  • \$\begingroup\$ HITMAN Go would also be a good frame of reference \$\endgroup\$ – cpimhoff Oct 28 '17 at 15:15
1
\$\begingroup\$

The Game Maker's Toolkit episode on puzzle-making, which was released a few months after I posted this question, describes game design principles for puzzle games with many examples from existing games.

While the video covers a lot of ground, there are two highlights pertinent to this question:

1. Provide clear information

The focus of a puzzle should be finding the solution, and everything else should be immediately clear:

  • The final objective: for instance, the exit door in Portal rooms. The player should never be wondering what's their goal.

  • What are the player's tools. The situation you want to avoid is the one where the player finds the solution in a walkthrough and thinks "I didn't even know I could do that". Having simple, broad mechanics helps.

  • The consequences of an action. The player should always know what triggering any level in a room does.

  • What is possible and what isn't. If you want a gap to be too wide for the player's 10m jump, don't make the gap 12m wide, make it 20m wide.

These principles are helpful, but I already knew them when I asked the question; giving clear information isn't enough if the puzzles aren't challenging. They need to provide an intellectual challenge that the player can feel good about overcoming, which means the game designer needs to create that challenge somehow.

2. Build puzzles around mastering the mechanics

The key insight: the player should solve puzzles by achieving a deeper understanding of the game's mechanics.

Puzzles shouldn't be a matter of brute-forcing every combination of moves until you find the one where making move A doesn't stop you from making move B. Solving a mechanic-driven puzzle should be an act of realization, of understanding an emergent property of the game's mechanics, like a combination of two properties, or some way a rule previously introduced can have new implications.

  • Dark Matter is immune to gravity, the Planetary Crown reverses gravity.

  • Your robots stop moving when they're broken, so in this puzzle you have to break a robot to keep it from moving away from a pressure plate.

Notice that the second example doesn't introduce a new mechanic; it introduces the fact that a previous mechanic (robots breaking) which usually had negative consequences, can now be necessary to progress.

Achieving this without breaking rule n°1 (provide clear information) can be hard. You want the player to discover emergent property of the rules, not discover the rules themselves.

  • If a puzzle is based on breaking a robot with a laser, you need to introduce lasers and their robot-breaking properties in a previous level.

The way you present your level is also important. You need to build puzzles with a catch. Something where, if the player follows their first intuition, they're faced with an insurmountable obstacle.

To achieve that, you may want to put the player in a situation where they make a wrong assumption. What you want to avoid is a level design where the player's first intuition leads them directly to the exit. You want the player to see the locked door before they find the key.

To summarize

  • Provide clear information.

  • The player should solve puzzles by understanding the game better and deeper.

  • Lead the player to false assumptions.

  • Do lots and lots of playtesting.

\$\endgroup\$
0
\$\begingroup\$

You could also design the primary challenge of your game around observing and understanding enemy behaviors.

Create more different enemy behavior patterns, and represent them with clearly visually distinct sprites. Make the puzzles about figuring out these behavior patterns and ways to navigate around them.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.