Brainstorm & Planning Phase
Since the task was to create a simple mini game with a couple of interactive features, it was decided that a simple choice-based game would be best to build. The idea was to create a path that forked to have two or three directions for each question.
​
The initial topics suggested were Math comparisons, ELA conventions, or Media Arts composition. Ultimately, identification of geometric shapes became the best option because it required simple true/false identification, where other topic ideas had more subjective possibilities.
​
With the Math topic in mind, the plan was to build that path into a maze, where the player would be presented a prompt and then have to choose one of two doors. After a certain number of doors, the player would reach the end of that maze.
| Planning the Maze |
An original concept for the maze involved a few different iterations. One idea was to use a cavern with forked paths, another was a typical top-down maze, and another using an enclosed room. The next step was to decide on which option would be the simplest to construct in the limited time frame. The final choice was on a modular room concept.
A cavern maze concept with branching paths.
A top-down traditional maze concept.
A maze concept using cube rooms.
| Building the Template Room |
A straightforward approach to the maze design was based on the idea of how dungeon maps worked in the original Legend of Zelda for the NES. Those maps were constructed with rooms with multiple doors against each all to proceed through. For this game concept, a similar approach was taken with the rooms. There would be a door into the room, then two doors, but only one correct in order to continue moving through the maze. The textures chosen were a stone based and resembled a castle-theme, which was simplified using free seamless textures and clipart from the Vecteezy website.
The Legend of Zelda (1986). NES. Eagle Dungeon. Image courtesy Nintendo and ZeldaDungeon.net - All rights reserved.
A map concept using modular rooms.
The modular room concept with initial stone and rock textures
| Connecting the Rooms |
Once the format was established, it was decided that six total rooms would be used as the "level" for this maze. The player would enter each room to see a graphic along the opposite wall, with two doors - Door 1 on the left, and Door 2 on the right. Just as with the maze design being static, the room choices would be predetermined. Further development would consider the maze and the door choices being modular and randomized.
A room concept with question/prompt on opposite wall from the room entrance.
A wireframe of the modular maze design.
An overhead view of the room-based maze.
| Finalizing the Maze |
Once the maze was constructed, the finishing touches were added to the design. This included lighting the rooms, adding the remaining textures, creating a "1" and a "2" objects to be displayed over the doors, adding the prompt/question to the opposite wall, creating the graphics for each individual question, and building a final room with a treasure chest object to signify the end.
Each maze room had three doors, one to enter in, and two exits to choose from.
The final room signifying the player made it to the goal.
| Adding the Player |
It was decided that the game would be played through the player's eyes, so it needed to be coded using the mouse to look around and the WASD (and arrow keys) would move the player throughout the maze. The player would spawn in a tall corridor and fall to the starting door. They would walk through the blue door to see the first room with the geometry prompt.
​
ChatGPT was consulted for building the code snippets to help create the C# functions to allow for player movement. A character design was abandoned after deciding on this gameplay format, but there were some challenges encountered. The player was build as an empty object with a cylinder collider for its RigidBody component.
At first, the gravity and player movements were sporadic, where sometimes the player moved to quickly and would clip through objects, or gravity reactions to object and the RigidBody component caused the player to float up before staying on the ground. Additionally, the player/camera would rotate awkwardly or fall over, so the rotation was disabled. Another challenge was ensuring the code responded correctly, so that whenever the player looked a direction, the "w" or up arrow always went forward. For example, at first the player would alway move "forward" when using the "w" or up arrow, but if you turned to look 180° and pressed "w" you would actually go backwards.
A prototype player design that was abandoned.
The player would fall down a long corridor to see the first door.
ChatGPT consulted for C# code snippets.
| Coding the Basic Events |
With the maze and player built, the next steps involved adding additional coding for events that occurred during gameplay. The plan was to have sound effects for wrong choices, dying, and completing the maze.
A "health" variable was coded (which would eventually be displayed in UI), and each wrong door choice caused the player to lose one health. The blue "doors" would only serve as a covering to hide what was behind the door, and so the player could pass right through them. If they chose the wrong door, they would see the fiery red texture, lose one health, and play an "oof" sound. The only drawback was this was coded to subtract a health each time, meaning the player could keep walking into the same wrong door and end the game. When the player's health reached 0, it would play the "Wilhelm scream."
Each room had a prompt with a geometry question, then listed the answer assigned to each door.
The incorrect door was a fiery texture used as a collider to signify the wrong choice (this was hidden by the blue door).
| Adding UI Elements & Graphics |
Once the health was functioning, the next step was to visually display the players health using a Canvas object in Unity. Since the player was only given five health points, a simple heart icon was used to represent each health point. Coding was added to have the heart icon be replaced with a black, broken heart every time the player lost health. One challenge that was encountered was the positioning of the health bar UI because it was static on the screen and needed to reposition itself in the top-left corner of the screen regardless of the user's screen size, even though the objects were set correctly and sprites were assigned to the UI, the Canvas didn't match the game screen.
​
In addition, the final game graphics were added to the rooms - the frame on the opposing wall and a sprite of the geometry prompt showing the player which door to choose. Using a sprite was the easiest way to incorporate the graphic into the game, since the textures and materials treated the image files differently, especially when it wasn't set to tile.
Consulting ChatGPT to modify the original code snippets to add enhanced interactivity.
Player health was displayed in the top-left corner of the screen and would change as the player lost health points.
| Adding Respawn Mechanics |
ChatGPT assisted with adding in coding for a respawn mechanic. This would reset the player's health variable and reset the player's position and camera angle to how it started at the beginning of the game. A drawback for this was that the respawn was immediate, so sometimes the player would still be pressing forward and they would start moving forward as they respawned in the corridor that dropped them into the maze.
​
Another functionality that was added was the "accuracy" of the players correct choices. For this logic, the health variable was referenced and every incorrect choice dropped the player's accuracy 20%. The only flaw in this logic is that the player can keep choosing the wrong door multiple time is they desire. Improved code would disable the trigger on the wrong door choices after a player chose it, or they proceeded through a correct door.
​
In the end, further improvements on the respawn mechanic were implemented. When the player entered the final door, a congratulatory screen would fade in and display a message (in addition to the final room sound that plays). Depending on the player's accuracy, the message would read differently:
-
80% or higher says, "Congratulations! You escaped the maze and discovered the treasure!"
-
79-41% says, "Good Work. You escaped the maze, but lost the key to the treasure chest. Try again for a higher score!"
-
40% or below says, "Nice Try! But you're still lost in the maze. Don't give up! Try again for a higher score!"
All ending screens would allow the player to restart the maze by pressing any key, which was also displayed in text below the other message. For this prototype, this would simply respawn the player in the same was if they died. Further development would simply proceed to a new level.
The player view with modified health bar and accuracy display.
The ending screen would say different responses depending on the accuracy of the player.
| Bug Testing & Publishing the Game |
With all core elements of the level in place, final bug testing was conducted. Minor tweaks to room geometry and UI elements and graphics were made.
​
With core functionality in tact, the game prototype was ready to upload to an online server. For the sake of ease, Unity Play was used and the game was listed as Escape the Math Maze. Once uploaded, one issue noticed was the Player Controller values operated differently than in the local Unity build (the movement and look functions were faster/more sensitive).
​​
Overall, this was a successful project considering its limited time frame and team size. For further development, other quality of life considerations could include:
-
Preventing the player from losing more than one heart on a wrong choice
-
Adding additional sounds for walking
-
Read aloud the on-screen text and questions
-
Build multiple levels
-
A modular approach to the door choices
-
A modular approach to the maze construction
GAMEPLAY PREVIEW
FULL PLAYTHROUGH
