Checkpoints are a contentious subject when it comes to gameplay design. Especially in a retro style games, there are many schools of thought. First off, let’s define a checkpoint: for our purposes, it’s any mechanic that saves the player’s progress, allowing them to return to it in that position after dying or losing.
Some people think that repeating content is never good and copious checkpoints or even quicksaving should be implemented; think the quicksave ability in a game like Half Life, where you can save the game at any time. Other players are purists, and think progress shouldn’t be saved until you beat a stage! The Yacht Club thinks there is no hard and fast rule: it depends on the game you are trying to create, the emotions you’re trying to evoke, and the experience you want your players to have.
For Shovel Knight, we knew from the beginning that losing, lives, and checkpoints would be important to get right. Lack of checkpoints and hard limits can typically cause a lot of frustration in classic games. We wanted to retain the mechanic, but do away with the inherent frustration of having to repeat large swaths of content.
Iterating on checkpoint design was a slow and painful progression, but the result was worth it. There were 3 main versions of the checkpoint mechanic, so let’s go through them!