Notes: Puzzles

T. S. Raveling

GMTK: Catch and Revelations

From GMTK's video on puzzle design:

  • Present the problem, the tool, and the "catch" -- why the obvious application of the tool will not work. Then let the player figure out the un-obvious application, resulting in the revelation.
  • This relies on an assumption, i.e., that you already know how the tool should be applied. Often, the game will teach you the "right" way, thus establishing the assumption that you then have to subvert as the player.
  • Luring the player into an easy up-front assumption prevents the player from being overwhelmed -- they think they know the solution, realize they don't, but are already invested, so they keep tweaking it to try to figure it out.
  • The revelation then teaches the player a deeper complexity present within the system, opening up their eyes to the potential it has.

All of this only works with clear communication:

  • Hints: make it hard to figure out, but lead the player in the right direction to avoid frustration.
  • Avoid "false positives" -- circumstances that make it look like if you jumped just a little higher or ran a little faster, you could make it.
  • Build on other puzzles. Lessons you learned in puzzle one should play forward to the next one.

Jonas Tyroller: 5 Steps

  1. Set up some random rules, e.g. in a paper prototype. For instance, "you can only flip cards over in a line." No objectives yet.
  2. Experiment with adding objectives and iterate on the ruleset. Ideally at this point you are familiar with your rules and hopefully know what might be challenging or interesting.
  3. Learn alongside the player -- design incrementally harder puzzles.
  4. Expand the ruleset as you go -- but only if you have fully explored the previous ones!
  5. Reorder and polish (nothing is perfect from jump).
  • In a good puzzle game, actions have predictable consequences.
  • Experimentation pays off -- take your time.
  • The first level should teach the player the basics.
  • A good puzzle includes all the information needed to solve it.
  • Sometimes you can design puzzles backward. Start at the desired end state and then add complications in from there.
  • A good puzzle never fails to teach you something new about the game system.
  • You might be able to toss in some random configurations and see if there is anything interesting or hard about them, then design from there. 
Back to the Systemist
Mastodon