On level design in Blue Bug Bob: Collectibles, Checkpoints and Lifes

28.10.15    gamedev    bbb

This is the follow-up to an article I have written before. This article expands on the ideas and explores the role of collectibles, checkpoints and lifes in platforming games and how this insight was incorporated into Blue Bug Bob.


With collectibles here I mean things like the coins in a Mario game, golden rings from Sonic etc. They are a very important part of a platforming game. Normally they stand up out from the rest of the objects and project a clear path into the level of the game. They lead the player through obstacles to the finish or some other secret and/or interesting place.

Moreover collectibles normally feature a value extrinsic to the collection itself but intrinsic to the game play or at least the game as a whole: "Collect 100 to get an extra life" (game play) or "You need 50 to access this level" (meta-game) or "Find the five keys to unlock the concept drawings" (also meta-game).

When restarting/resetting a level the game play collectibles must reappear to grant the same experience to the player as before. Failure to do so keeps the player from truly replaying the level. The other kind on the other hand must persistently stay collected for the meta-game to make sense. Therefore these two roles stand in conflict and cannot be trivially united in one collectible.

Blue Bug Bob solves this conflict in some sense with its berries. Berries are the only collectible in Blue Bug Bob and they serve the path laying role. They are completely reset whenever one restarts the level. (In fact levels in Blue Bug Bob are always exactly the same when you start them.) But the game keeps track of your best number of collected berries when finishing a level. This is used to unlock other levels.


Now let's talk about checkpoints. These are the places you are allowed to reset to when needed (e.g. death in a platformer). They differ from save points in that you are not allowed to save this progress to disk.

This is simply incoherent and an inconvenience for the player. The game is technically able to reset progress to this place and some designer decided that it is acceptable for the player to start (re-)progressing from here but you cannot save this state to disk. It just does not make sense.

Other problems arise when checkpoints interact with a health system. An illustration:

  • Player starts the game (possibly from some save point)
  • Player surpasses obstacle 1 and reaches checkpoint A
  • Player barely makes it through obstacle 2 and reaches checkpoint B with low health
  • The game just discards the progress to checkpoint A (a problem in itself) and just keeps track of progress at B
  • Player is unable to surpass obstacle 2 with low health. On every retry he restarts from B again with low health.
  • The only resolution is to quit the game and restart from the last save point. Player now needs to overcome obstacle 1 again.

And, yes, I have seen such systems in otherwise well designed games. Therefore Blue Bug Bob just features (relatively short) levels as the single universal quantity of progress.


System of restricted retries are just bad. Always. They disincentivise trying again and put unneeded pressure onto the player. They lead to all kinds immersion breaking behaviours like hard-quitting the game before the loss of a life is autosaved or loosing the game on purpose to regain lifes through the game's backup/emergency system.

Lifes as in restricted retries have no place in a game where the player does not have to insert a real physical coin to retry. Therefore Blue Bug Bob allows the player to retry and reset levels at will.


This two-part article shows that even relatively simple games in a genre which stood the test time show room for thoughtful game design and innovation. Not every design decision of successful games needs to be mindlessly repeated. And even minor decisions (like the exact interaction of checkpoints and health) can heavily damage a game. Be thoughtful.