top of page
Stephen Lee - Gameplay Programmer
The first concept of Maze Game was a series of doodles that I drew when I was ten years old, which were inspired by the game Doom. While these doodles have since been lost to time, they generally looked something like this.
Legend:
1: Start
2: Blue key, required to open blue door.
3: Blue door.
4: Finish.
​
From here, the blue key was replaced by a blast pellet gun, (Which was later renamed to the Blast Pellet Launcher) and the blue door was replaced by a cracked wall that required the gun to break. Aside from that, the general concept was the same, and it was then used to make the microgame, Adventure Demo.
This was one of my very first projects, and it was an LWTech school project, so the challenge was to simply create a platforming FPS within {roughly) a two week timeline that fits within the theme, "Point and click interaction". The main issue encounter was trying to get the weapon switching system to work, and the only way to do that was to have each specific key call its own weapon switching event.
​
The game had a fair share of issues, such as the player's speed. I decided I'd be better off fixing these things in another game, and thus Maze Game was born.
Pictured: The very first level of Maze Game, which didn't make it into the current release.
The original idea was to make an unfolding game like Candy Box or Frog Fractions, and the main challenge was that I wanted the game to switch between a top-down perspective and first-person perspective. This required having two separate movement systems, where the initially, the Player could only look left and right by dragging the mouse left and right. This was because I had a lot trouble figuring out how to get the character to look at the mouse. Eventually, with a bit of trial and error, I was finally able to get the player character to look at the mouse.
​
Another challenge was figuring out how to make an enemy that would chase the player character, Spryte, and attempt to attack her at close range. Since the game was still using bolt, the first attempt involved having the aptly named Bit Mite look for Spryte to see if she is within range. If she was, it would begin to chase her, and then when it got close enough to attack her, it would use a raycast to check if she was still within the attack range when the attack would damage her. This method caused a problem where bit mites would sometimes become unable to find the player. The solution was simple: Store the player in a variable, and use that to store the player's position so that it wouldn't have to find it again every time it finished an attack. This not only solved the issue, but also greatly improved performance.
​
Lastly, one thing that was starting to become apparent was that the first level felt too much like padding. I was hesitant to remove it, as it contained valuable tutorial information. After someone pointed out that the game wasn't a very effective vertical slice with how long the level was, I ultimately condensed it to the much quicker two-room tutorial that is now seen in the current release.
bottom of page