Wk 13 – EXTRA CREDIT – Kyle Wadsworth’s Puzzle Game

Well, I didn’t see anything limiting the extra credit opportunity to non-developers, so I thought I’d give some insight in the development process for some sweet sweet EC points!

The game itself is a One Dimensional Puzzle game that started off to prove to my friend that it could be done. I originally made a text based Javascript experiment to prove it, and I thought about leaving it there.

But then I got bored.

I started twiddling around with this engine called “Game Maker” made by YoYo games, and here I am now with a pretty decent demo for the game!

Now, the main puzzle mechanic in this game involves “mirroring” your position in the world. For instance, if you are at the end of the array of tiles in the level, you travel to the other far end, whereas if you are in the center, you travel to a position near the center.

Now, this is never ever explicitly told to the player, since I left it the instructions for Mirroring at “Press “. I wanted to make the player have to “feel” the mechanics, rather than turning the puzzle game into an equation. So, I forced them to experiment with the mechanics in the second level, a 2 part level with a very simple puzzle, but one that forces you to “feel” the Mirroring both ways.

In my game, the elements are introduced gradually. Movement, Mirroring, Crates, Switches, Doors, etc. This is because any good game designer will tell you to NEVER front load your tutorial. If you gradually introduce new concepts as you train your player, they will enjoy the game more. Also, it has been proven that “learning through play” is a better way to teach players your mechanics instead of a wall of text. Unfortunately, many designers often coming from different fields, such as movies and board games. In these fields, you are FORCED to front load your “tutorial” either by making a script all at once or making a rule book for your board game. This often leads to instances of sloppy design, and will make your player less likely to enjoy your game.

Now, because this is merely a tile based game, the mechanics were not hard to implement in the game maker engine. For instance, for the “Mirroring”, the game merely keeps track of a number of steps it has to teleport forward or backward based on its position. Near the center? Teleport very few steps forward. Near the end? Teleport the entire stage length. However, one of the harder things to implement were doors that “felt” good. In this game, a switch moves ALL doors. I quickly found out during early play testing that if the doors moving in different directions (some up, some down) confused a lot of players, so to make it feel natural, I changed the position of the doors based on whether it was open or closed. For instance, a doors that starts open starts off with a open/close range of Below and In stage, whereas a door that starts off closed has a open/close range of In and Above. This means that doors feel like they are all “shifting” together vs “Jumbling Incoherently” and confusing players.

Overall, this game has been a fun experience to design. So far, one of the hugest criticisms is that “The game is too short!”, and if that is my biggest problem, I at least know I am doing something right!