GAMES DEVELOPMENT / FINAL ASMT

Naura / 0356798 / Interactive Spatial Design
DST61104 / Games Development
Final Assignment 03: Playable game

JUMP LINKS:

• Link to my Game
• Link to Drive
• Game Documentation

__________________________________________________________

Instructions:

• Integrate your art assets into your game.
• Produce a fully functional and playable game.
• Submission Requirements:
• Unity Project Files and Folders: Submit the complete Unity project.
• Video Capture and Presentation: Record and present a gameplay walkthrough.
• Game WebGL Build: Export and include a WebGL build of your game.

__________________________________________________________

Although following YouTube tutorials sped up parts of the coding process, the true test came when I had to debug and customize the game’s structure to match my own vision. Starting with Level 3, unexpected obstacles really ramped up the difficulty of development, forcing me to make significant design changes that set this version apart from my earlier prototype (Assignment 3).

A quick beta test with my friends—who essentially served as my playtesters—led to a number of adjustments, especially to Level 3, which was far too difficult and lengthy. Their input was crucial in striking a balance between challenge and fun. I didn’t specifically get their impressions on the mini-boss and final boss fights, but I’m confident they’d agree that the overall level progression feels much better now.

One notable feature I added during this phase is a cutscene to clarify the game’s lore. This helps set the stage for players, giving them a clearer sense of the game’s overarching goal and deepening the narrative experience.

Implementing the scripts for the Colossi, the mini-boss, and the final boss was another challenging aspect of development. Unfortunately, I couldn’t find extensive, step-by-step tutorials for these specific elements, so I was navigating uncharted territory for a while. Although the final implementations aren’t exactly what I had envisioned due to time constraints, I’m proud of how the mini-boss and final boss turned out—they genuinely feel like formidable opponents, offering players a proper challenge.

At one point, I lost all my progress—a heartbreaking moment that showed me just how important it is to keep backups. Fortunately, it happened early enough that I was still able to recover and continue building the game.

Finally, I changed the background music for Levels 4 and the boss battle to a darker, more foreboding score, amplifying the sense of urgency and danger—almost as though Aeron’s heartbeat is racing in sync with the action.

I also made some tweaks to art assets originally created by penusbmic and zneeke, and I’m incredibly grateful for their work. It allowed me, as a designer, to focus more on the coding side and create deeper, more nuanced encounters in the final two levels.

Here, I’ll break down the structure and flow of my 5 levels, detailing their hierarchy and key elements.

Fig 1.0 | Level 1 Hierarchy Elements

Fig 1.1 | Level 2 Hierarchy Elements

Fig 1.2 | Level 3 Hierarchy Elements

Fig 1.3 | Level 4 Hierarchy Elements

Fig 1.4 | Level 5 Hierarchy Elements

Debugging Challenges:

In my previous assignment (the prototype), I identified several errors throughout the gameplay that impacted the player's immersion in the game. One of the most frustrating yet easily recognizable issues was the flipping mechanic. The primary problem I faced was that the player couldn’t flip properly when interacting with the tilemap and ground tilemap collider. Upon investigation, I discovered that the issue was caused by the 'Is Trigger' setting being enabled on the Platform Composite Collider 2D. This caused the player to pass through the tilemap. Fortunately, the fix was straightforward: disable the 'Is Trigger' setting on the tilemap (AAAAA)

However, turning off 'Is Trigger' introduced another problem. If the player somehow ended up inside a wall, they couldn’t escape. This caused further complications during the flipping process. In my original code, when the player flipped, they sometimes got stuck in the tilemap. To resolve this, I updated my code to ensure the player flips at a specific point, adjusting their Y position to move them slightly higher. This adjustment prevents them from getting stuck in the tilemap.

Here’s a code snippet to demonstrate the fix:

Vector3 playerNewPos = transform.position;
playerNewPos.y += (rb.gravityScale < 0 ? capsuleCollider.size.y : -capsuleCollider.size.y);

transform.position = playerNewPos;

I've used the player's Capsule Collider 2D, to determine their height, ensuring the correct height is applied when flipping the player.

Another issue I noticed was with the camera functionality. While Cinemachine was a lifesaver, it had a tendency to focus too much on the ground, especially when the player flipped toward the ceiling. This issue occurred because the Cinemachine Virtual Camera was primarily tracking the player’s position on the ground. As a result, when the player flipped, the camera's focus shifted downward, leaving the upper part of the scene overly covered.

To resolve this, I added offsets to the Y-axis of the tracked object and adjusted the X, Y, and Z damping values to 0.5, 0.5, and 0, respectively. Additionally, I created a Camera Animator script to maintain a steady offset during the flip. This script needs to be attached to the virtual camera, and the virtual camera must be assigned to the CameraAnim field in the Switch Gravity script via the Inspector.

Fig 2.0 | Camera Adjustment Script

This code smoothly adjusts the camera's vertical offset based on the player's gravity scale:

1. Check if cameraAnim is not null: Ensures that the camera animation object exists before attempting to interact with it, preventing potential null reference errors.

2. Determine targetY: Sets the target vertical offset for the camera. If the player's rb.gravityScale (the rigidbody's gravity scale) is negative—indicating flipped gravity—the target offset is set to -2.2f. Otherwise, it is set to 2.2f.

3. Animate the camera offset: Uses cameraAnim.AnimateOffsetY(targetY, 1f) to smoothly transition the camera's vertical position to the targetY value over the duration of 1 second.

Scenes:

Start / Main Menu

• Start Button
• Quit Button

Fig 3.1 | Start Menu

IntroScene

• Cutscene (non-skippable)
• Game Title

Fig 3.1 | Intro Scene / Cut Scene

Level 1 + Tutorial

• Gameplay instructions
• Enemy Mob 01: Wraith
• Traps:
• Spikes
• Saws
• Bandage Collectibles
• Checkpoints
• Guildmate
• Portal

Fig 3.2 | Level 1 Platform Design

Level 2

• Gameplay instructions
• Enemy Mob 01: Wraith
• Enemy Mob 02: Abyssals
• Traps:
• Spikes
• Saws
• Falling Platforms
• Bandage Collectibles
• Checkpoints
• Guildmate
• Portal

Fig 3.3 | Level 2 Platform Design

Level 3

• Enemy Mob 01: Wraith
• Enemy Mob 02: Abyssals
• Enemy Mob 03: Colossi
• Traps:
• Spikes
• Saws
• Falling Platforms
• Bandage Collectibles
• Checkpoints
• Guildmate
• Portal

Fig 3.4 | Level 3 Platform Design

Level 4

• Enemy Mob 01: Wraith
• Enemy Mob 02: Abyssals
• Enemy Mob 03: Colossi
• Traps:
• Spikes
• Saws
• Bandage Collectibles
• Checkpoints
• Mini-Boss: Keiran
• Gate Key [ hidden ] 
• Gate
• Guildmate
• Portal

Fig 3.5 | Level 4 Platform Design

Level 5

• Final Boss: Caesar
• Bandage Collectibles

Fig 3.6 | Level 5 Platform Design

Pause Screen

• Resume Button
• Back to Menu Button
• Quit Button

Fig 3.7 | Pause Menu

Death Screen (only occurs if the player doesn't reach a checkpoint)

• Restart Button
• Back to Menu Button
• Quite Button

Fig 3.8 | You Died Menu

End Screen

• Restart Button
• Quit Button

Fig 3.9 | End Game Scene

Uploading:

Due to the tight deadline, I couldn’t fully verify whether my game uploaded correctly, so I’ve included the Unity project in my drive as a backup. Hopefully, everything runs smoothly without any glitches or unusual issues.

Final Submission:

Fig 4.0 | Presentation and Walkthrough

Fig 4.1 | Game Document

Reflection:

This assignment has been a steep learning experience (for me at least, because why do I have to be so ambitious for?) and I spent the most time and effort in this module. It was satisfying to see my game come to life—in a way, my efforts paid off, but I don’t think I would like to see Unity ever again in my life.

One of the biggest challenges was balancing difficulty in level design. I think, in a way, I never properly learned how to design a good level. I was too hasty in making the game, so initially, players found certain stages too complex. Analyzing their feedback was an eye-opener, as it made me realize how differently players experience the game compared to developers. I implemented a tiered progression system that gradually introduces new mechanics, and it was rewarding to see players engage better with the adjusted levels.

I think when I saw the huge progress in the middle of my development, I got overly excited and tried to dive into state machines without fully understanding them. This set me back by about two weeks as I struggled to grasp the concept. If you asked me now, I’d say I understand about 40% of it. That struggle taught me the importance of patience and persistence when tackling complex topics.

There were numerous features I couldn’t implement simply due to time constraints. But in a way, it’s a good thing I was ambitious at the start because it allowed me to prioritize the core elements of the game and discard ideas that weren’t essential. For instance, I wanted to add a second gun for the player, which would deal more damage, and enemy AI that follows the player. If I had managed my time more wisely or had more of it, I could have incorporated those ideas.

This project taught me a lot about time management and the need to plan a development timeline more carefully. In future projects, I’d focus on understanding core mechanics earlier and allocate time for unexpected delays or debugging. I also learned the importance of taking breaks and stepping back when I felt stuck, as this often led to breakthroughs.

Although my ambition created challenges, it also pushed me to achieve more than I initially thought possible. Striking a balance between ambition and realism is something I’ll continue to refine. Overall, while I may never want to open Unity again (I think I have to though... see you again in experiential design, sir), I’m proud of the growth this project represents—not just as a developer but as a learner.