A NES Era Inspired Top Down Block Puzzle Game

Ben Poland

John With Developer Commentary

Design Process

John is a puzzle game where the player takes on the role of John, a 10 year-old child escaping a dungeon by solving block based puzzles. The player must progress through a series of four levels completing each puzzle in order to progress. In order to solve each puzzle, the player must break all of the green breakable blocks (visible cracks on them) in the level. A block can be broken by pushing the cracked side of a block into another block (but not a wall). This opens up a small door, with a heart above it, into which the player must push the blue companion block to unlock the larger door that leads to the next level. Because of the puzzle aspect of the game, it is possible to get stuck in an unsolvable state, and thus the player is able to restart levels easily by pressing the Esc button. Scoring is based on how quickly the player can complete the game.

John was the first game I ever made, and was structured to allow me to learn the basics of game design and development. The goal of the project was to design and implement a “casual” game in the visual style of the Nintendo Entertainment System. The game had to be an interesting, interactive game with solid gameplay and simple rules. There also had to be some type of score keeping. The game was also an experiment in whether or not the player would develop a bond with the blue companion block, and if the player would feel any remorse for destroying the blue companion block at the end of the game.

I came up with the game’s core puzzle-solving mechanic. I also created all of the art assets for the game, programmed all of the game’s animation and programmed all of the game’s audio. I also ran playtests and fixed bugs.

Through creating John I experienced the game development process from conceptualization to finished product for the first time, and also gave me hands on experience programming a game using DirectX 9.0.

One of the most important things I learned from this project was how critical it is to regularly integrate everyone’s code. This makes things much easier as the process goes on because instead of trying to get two large projects to merge together all at once, which can be a nightmare, you are integrating smaller chunks that are easier to debug which helps keep the project on track.

This project taught me about how focusing on one mechanic and keeping it simple can allow the player to learn your game quickly without feeling overwhelmed.  This also allows for more interesting and difficult level design because the player already understands the rules of the game.

While creating the art I learned how important it is to provide visual clues to the player. For example, drawing large cracks on the breakable blocks allows the player to piece together how to break the blocks just by looking at them.

Last I learned about how providing good audio and visual feedback to the player allows them to understand how they are interacting with the game world. For example, our game fails in the end to elicit a reaction from the player on the last level. Part of the reason for this is because the player does not understand what is happening when they push the blue companion block into the red spike blocks. They don’t understand because the audio cue does not sound like the block is being damaged.

In the end I am proud of John, because it was the game that showed me that I could make games.