Game Development Process

The idea for our game Glitch came from the maker’s love for video games, computers, science fiction and a childhood TV show called Cyberchase. Initially the group wanted to create a 3D world in which the player would be transported into a computer. The game would be open world and riddled with puzzles, enemies, and bosses. What we didn’t realize however, that this large scale game would be too much of a feat to create, let alone optimize to fit on a small mobile screen.

Around the end of week 1 of 4, we realized that the work we had done would leave us in a tough spot for the game’s debut- there was just too much work to do, and too little time. We decided that it was in our best interest to fully abandon this implementation and go for something a little more feasible. From this, we created a game that was nearly the same concept, however in two dimensional space. The player could still walk around what appeared to be a three dimensional space so that it would feel different from our Assignment 1: The Platformer. This also made it look better on mobile since 2D platformers are only fun when you have more than just your thumbs to control the player.

Over the course of the weeks, the developers listened to numerous classmates playtest and critique the game which led to a better final version. During the time in between, members of the group created numerous mini games, better enemy artificial intelligences, and more levels. We aimed for about ten levels/rooms and over all 10 minutes of game play. 

Playtesting

The playtesting phase of our development process was absolutely essential for the success of our game. Most of the input came from our professor however, the input from our classmates was just as important. For example, as the player moved from scene to scene, the text font on the buttons would change. Another issue was when the player would pull up the circuits minigame, they couldn’t rotate some of the pieces. To summarize briefly, this was our main feedback:

• Tutorial keybinds don’t work for mobile 
• Aspect ratio off when built on mobile
• Set user interface to scale properly between devices
• Increase the enemies mass so that they can’t be “pushed” by the play
• Add an explosion to the end of the bullets to show enemy damage
• Show the interaction button only when the player should use it
• Any user interface that is not essential to the gameplay, hide it
• Use button to rotate instead of tapping on the puzzle
• If you move out of the puzzle it closes out
• Make the interaction buttons smaller/ create sprites for them 

A lot of the game play related bugs were able to be solved. The issues relating to the interface will likely be implemented later due to a lack of time. Overall, the play testing phase proved to be a necessity.