INSTRUCTIONS
<iframe
src="https://drive.google.com/file/d/1jOlu5LilFKmUNfKnBvXhga8yL5j9j4Dm/preview"
width="640" height="480"
allow="autoplay"></iframe>
Task 1 - Game Design Development
<iframe
src="https://drive.google.com/file/d/1tnnj1PWgzOu0OGFnbQza_ahy3nB94EC9/preview"
width="640" height="480" allow="autoplay"></iframe>
Task 2 - Art Asset Development
<iframe src="https://drive.google.com/file/d/1WjNNwNgvt9Nl78Fw1f0UKSpFGhzhNvK-/preview" width="640" height="480" allow="autoplay"></iframe>
Our development plan was divided into 13 weeks, each focusing
on a crucial aspect of game creation. Weeks 1 - 3 were
dedicated to ideation, research, and drafting the Game Design
Document. In Week 4, we established the game's visual
identity, followed by Week 5, where initial asset production
began, including environment elements and character designs.
Weeks 6 & 7 were spent refining concept art and producing
detailed sprites, animations, and UI assets. Weeks 8 and 9
focused on core mechanic implementation, including movement,
interactions, NPC behaviors, and puzzle integration in Unity.
Week 10 introduced system enhancements like save points,
potion effects, and UI feedback. Week 11 was dedicated to
playtesting and balance adjustments, ensuring smooth stealth
mechanics and NPC behavior. In Week 12, we polished visuals,
refined animations, and added sound effects and ambient music.
Finally, Week 13 wrapped up the project with a playable build,
a gameplay trailer, and showcase preparations. This structured
approach ensured a smooth and efficient development process.
Let me know if you need further refinements
Week 3 Proposal Presentation Day
Lec Mia said that our game needs to focus more on the main theme. Since the story is about delivering secret packages and documents, the emphasis should be placed on the "mission" itself. She suggested changing the original idea of collecting items and storing them in an inventory to a mechanic where the player must push or carry the item/document while moving. Instead of hiding the player, the item can be hidden in corners or other concealable areas. As for the player, the stealth mechanic can be modified so that standing still or facing away from the enemy prevents detection.
Week 4 - 6 Refining Game Ideas
<iframe src="https://drive.google.com/file/d/1tnnj1PWgzOu0OGFnbQza_ahy3nB94EC9/preview" width="640" height="480" allow="autoplay"></iframe>
<iframe src="https://drive.google.com/file/d/1WjNNwNgvt9Nl78Fw1f0UKSpFGhzhNvK-/preview" width="640" height="480" allow="autoplay"></iframe>
Week 3 Proposal Presentation Day
Fig 1.0 2nd game level design - JPEG
After listening to my Mia’s feedback, I redesigned the
game content and levels. This is the second time I’ve
revised the game structure, and I believe that a good
product requires continuous improvement. I spent about
two days reconsidering how to make the game more
complete. I divided it into 3 different difficulty
levels, but the objective for each stage remains the
same: players need to figure out how to secretly
transport the box safely. In this version, based on
Mia’s suggestion, I changed the game rules to “hide the
box” instead of “hide the character.
Fig 1.1 open map layout design - JPEG
Then, I designed the open-world map for the first level.
But turns out, we made a mistake! We were supposed to
design a platform game, yet my design leaned more towards
an open-world map… So, I went back to rethink the game's
direction. My plan now is to shift away from just focusing
on hiding characters or objects. Given the character
setup, I need to consider the story background and logical
consistency. The package that needs to be transported can
actually remain visible to NPCs, since it’s originally a
laboratory item. However, the main character needs to stay
hidden because he is designed as a ninja. Since he is too
conspicuous, he must hide inside a box outside of a
designated ray cast range, or else NPCs will spot him.
When the NPC turns away, the ninja can jump out and
continue pushing the box forward. Throughout the game,
players must use the available map resources to progress
through levels. This includes searching for interactive
buttons, access cards, spells and lasers.
My Task
1. Game Concept & Core
At the start of the project, I helped to develop the
game’s concept and core gameplay loop. Originally, our
team wanted to build an open map stealth escape game,
but after feedback from our lecturer, we decided to
focus on one well-polished 2D platformer level
— the Abandoned Lab.
I contributed to defining the
main theme
of the game: the player (Kuro) must
find a mysterious crate, push it to safety, and avoid
NPC detection. I also helped to refine core mechanics such as:
-
NPC patrol and detection system
-
Player stealth (hide in crates / jump out of
sight)
-
Crate-pushing and obstacle interaction
-
Random potion system to add variety
2. Game Character
I was also responsible for designing the full set of
NPCs in the game. This included:
Fig 2.0 character animation testing - GIF
-
Making cubical-styled security NPCs to match our
art style.
-
created walk cycles and alert animations for
the NPCs so that they look alive when patrolling or
detecting players.
-
I designed the NPCs with clear vision cones, making
it easy for players to understand when they are at
risk.
This was my first time making animated character on
aseprite for a 2D game. Not sure if it can be fit on the
Unity or not.
3. Map Design
Fig 3.0 Discussion Sketch - JPEG
Fig 3.1 map & platform design w/o light and
shadow - JPEG
Fig 3.2 map & platform design w light and shadow
- JPEG
Shawn and I worked together to design three distinct
maps, each contributing to the immersive world of our
game. Through extensive discussions, we explored
different layouts, experimented with level flow, and
refined key elements to ensure a seamless player
experience. Our collaboration involved balancing
aesthetics with gameplay mechanics, considering how
each environment would challenge and engage players
while maintaining visual appeal.
We analyzed every detail from terrain structures to
interactive elements adjusting designs to enhance
navigation and create meaningful obstacles. Iterative
feedback sessions allowed us to refine concepts,
ensuring that each map felt cohesive and purposeful
within the overall game. Throughout the process, Shawn
brought fresh perspectives that pushed our ideas
further, while I focused on integrating those ideas
into a polished final design. Working side by side
strengthened our problem-solving skills and
creativity, making the map design process both
exciting and rewarding. Together, we shaped
environments that not only support the game’s
narrative but also provide an engaging, well-balanced
experience for players.
4. Website & Project Tracking
A clean and engaging project blog introduces the
game, serving as both a promotional tool and a
development diary. Short, catchy descriptions
highlight key features such as Kuro, Escape the Lab,
Push, and Fate Elixir, designed to intrigue
players without revealing too much. The blog presents
the game clearly to potential players while
documenting progress throughout development.
On the project tracking side, a detailed week-by-week
timeline ensures smooth task management. Regular
updates reflect shifts in direction, particularly
after narrowing the game’s scope to a single
platformer level. The plan keeps the team aligned with
deliverables, including art assets, core mechanics,
and testing milestones. Through this process,
adaptability and strong organization emerge as
essential skills in game development.
5. UI Implementation and Flow
To enhance user experience, I created a responsive UI
system that includes the Main Menu, Pause Panel, Game
Over Panel, and Win Panel. I implemented functional
buttons such as Start Game, Resume, Restart, and Quit,
each triggering scene transitions or time control using
Time.timeScale. I also added simple animations to UI
panels for visual appeal, using scale or pop-in effects
via scripts and, in some cases, Unity Animator. A script
handles "pressed" button feedback, and we later made
menu buttons scale up/down in idle state to bring them
to life. Shout out to Shawn, for designing the UI
elements!
Problems Encountered:
Panels did not appear because some object references
were missing or not assigned correctly in the
Inspector. Scene transitions didn’t trigger because
of incorrect scene names or scenes not being added
to the Build Settings.
Solutions:
Carefully re-checked all public UI references in
scripts and made sure to assign the correct
GameObjects. Verified that all necessary scenes
(like "01GameScene", "02NextLevel") were included in
the Build Settings.
6. Game Win Condition and Scene Transition
I scripted the Win Zone
using a collider trigger that detects when the parcel
reaches its destination. When triggered, the game
pauses, and a Win Panel
pops up. After a short delay, it auto-loads the next
scene ("02NextLevel").
Problems Encountered:
Scene did not load due to missing scene index or
unassigned tag/layer.
Win panel didn't show because it was not linked in
the Inspector.
Solutions:
Added all game scenes to Build Settings with correct
indexes.
Tagged and layered the WinZone and Parcel objects
properly.
Used SceneManager.LoadScene()
after confirming collider triggers were
working.
7. Visual Polish and Floating
Animation
To give the UI and game elements a retro,
pixel-art feel, we added a floating script (ElementsFloat.cs) that gently moves objects like icons or buttons
up and down. This gives a lively, nostalgic
aesthetic to static elements.
Application Areas: Title screen logo, Elixir item icons, Menu buttons (combined with scaling on
hover)
Fig 4.0 Game Cover Design - Photoshop
8. Game Cover DesignAfter finishing our game and with just a few days left until the presentation, I have time to create a game cover using our game content. I used Photoshop as the medium, applying grain and noise effects on the poster, then adjusting the overall color tones. For the characters, I used exaggerated photo-bashing to make them eye-catching.
9. Tutorial Video Record, Cut and Editing
Fig 4.1 Game Tutorial - JianYingPro
Fig 1.0 2nd game level design - JPEG
Fig 1.1 open map layout design - JPEG
My Task
1. Game Concept & Core
I contributed to defining the main theme of the game: the player (Kuro) must find a mysterious crate, push it to safety, and avoid NPC detection. I also helped to refine core mechanics such as:
- NPC patrol and detection system
- Player stealth (hide in crates / jump out of sight)
- Crate-pushing and obstacle interaction
-
Random potion system to add variety
2. Game Character
I was also responsible for designing the full set of
NPCs in the game. This included:
Fig 2.0 character animation testing - GIF
- Making cubical-styled security NPCs to match our art style.
-
created walk cycles and alert animations for
the NPCs so that they look alive when patrolling or
detecting players.
- I designed the NPCs with clear vision cones, making it easy for players to understand when they are at risk.
3. Map Design
Fig 3.0 Discussion Sketch - JPEG
Fig 3.1 map & platform design w/o light and shadow - JPEG
Fig 3.2 map & platform design w light and shadow - JPEG
4. Website & Project Tracking
A clean and engaging project blog introduces the
game, serving as both a promotional tool and a
development diary. Short, catchy descriptions
highlight key features such as Kuro, Escape the Lab,
Push, and Fate Elixir, designed to intrigue
players without revealing too much. The blog presents
the game clearly to potential players while
documenting progress throughout development.
On the project tracking side, a detailed week-by-week
timeline ensures smooth task management. Regular
updates reflect shifts in direction, particularly
after narrowing the game’s scope to a single
platformer level. The plan keeps the team aligned with
deliverables, including art assets, core mechanics,
and testing milestones. Through this process,
adaptability and strong organization emerge as
essential skills in game development.
Problems Encountered:
Panels did not appear because some object references
were missing or not assigned correctly in the
Inspector. Scene transitions didn’t trigger because
of incorrect scene names or scenes not being added
to the Build Settings.
Solutions:
Carefully re-checked all public UI references in
scripts and made sure to assign the correct
GameObjects. Verified that all necessary scenes
(like "01GameScene", "02NextLevel") were included in
the Build Settings.
6. Game Win Condition and Scene Transition
I scripted the Win Zone
using a collider trigger that detects when the parcel
reaches its destination. When triggered, the game
pauses, and a Win Panel
pops up. After a short delay, it auto-loads the next
scene ("02NextLevel").
SceneManager.LoadScene()
after confirming collider triggers were
working.To give the UI and game elements a retro, pixel-art feel, we added a floating script (
ElementsFloat.cs) that gently moves objects like icons or buttons
up and down. This gives a lively, nostalgic
aesthetic to static elements.
Fig 4.0 Game Cover Design - Photoshop
Fig 4.1 Game Tutorial - JianYingPro
Feedback and HELP from our lovely
Ms Mia Bong!
Of course, we have met issues when making
the progress. Mistakes lead success... But
no worries we have the "Code Queen"- Mia.
She helped us to fix the push issues on
coding. I just briefly explain here what
I have learned through this:
using UnityEngine;
public class BoxPush : MonoBehaviour
{
public GameObject player; //
Reference to the parcel prefab
public Animator animator;
public float moveDistance = 0.001f;
// move exactly 1 unit
public void start()
{
// Initialize any
necessary components or variables here
if (animator ==
null)
{
animator =
player.GetComponent<Animator>();
}
}
private void
OnCollisionEnter2D(Collision2D collision)
{
if
(collision.gameObject.CompareTag("Player"))
{
Vector2
currentPosition = transform.position;
moveDistance = transform.position.x -
player.transform.position.x > 0 ? 0.1f :
-0.1f;
Debug.Log("Collision with Player detected. Moving
parcel." + (currentPosition.y ));
// Move
the parcel by 1 unit
Vector2
targetPosition = (Vector2)transform.position + new
Vector2(moveDistance, 0);
//
Optional: Check for obstacles at the target
position before moving
transform.position = targetPosition;
//transform.position =
Vector3.MoveTowards(transform.position,
position4.position, moveDistance);
animator.SetTrigger("isPushing"); // Trigger the
push animation
}
}
void ontriggerEnter2D(Collider2D
other)
{
if
(other.CompareTag("Box"))
{
Rigidbody2D rb =
GetComponent<Rigidbody2D>();
rb.constraints =
RigidbodyConstraints2D.FreezeAll;
}
}
void exittriggerEnter2D(Collider2D
other)
{
if
(other.CompareTag("Box"))
{
Rigidbody2D rb =
GetComponent<Rigidbody2D>();
rb.constraints =
RigidbodyConstraints2D.FreezePositionY |
RigidbodyConstraints2D.FreezeRotation;
}
}
// Convert arbitrary vector to
closest cardinal direction
}
This BoxPush
script allows a player to push a parcel
(box) when they collide with it in
Unity. It first checks if an Animator
is assigned; if not, it tries to get the
animator from the player object. When
the player collides with the parcel, the
script determines which direction to
move the parcel (left or right) based on
the player's position relative to the
box. It then moves the box slightly in
that direction (by 0.1 units) and
triggers a "pushing" animation on the
player. Additionally, there are two
trigger methods (ontriggerEnter2D
and
exittriggerEnter2D)
that freeze or unfreeze the box’s
movement when entering or exiting an
area tagged as "Box", to prevent it from
moving incorrectly. However, some parts
of the code, like method naming and
logic checks, need correction to work
properly in Unity.
using UnityEngine;
public class BoxPush : MonoBehaviour
{
public GameObject player; //
Reference to the parcel prefab
public Animator animator;
public float moveDistance = 0.001f;
// move exactly 1 unit
public void start()
{
// Initialize any
necessary components or variables here
if (animator ==
null)
{
animator =
player.GetComponent<Animator>();
}
}
private void
OnCollisionEnter2D(Collision2D collision)
{
if
(collision.gameObject.CompareTag("Player"))
{
Vector2
currentPosition = transform.position;
moveDistance = transform.position.x -
player.transform.position.x > 0 ? 0.1f :
-0.1f;
Debug.Log("Collision with Player detected. Moving
parcel." + (currentPosition.y ));
// Move
the parcel by 1 unit
Vector2
targetPosition = (Vector2)transform.position + new
Vector2(moveDistance, 0);
//
Optional: Check for obstacles at the target
position before moving
transform.position = targetPosition;
//transform.position =
Vector3.MoveTowards(transform.position,
position4.position, moveDistance);
animator.SetTrigger("isPushing"); // Trigger the
push animation
}
}
void ontriggerEnter2D(Collider2D
other)
{
if
(other.CompareTag("Box"))
{
Rigidbody2D rb =
GetComponent<Rigidbody2D>();
rb.constraints =
RigidbodyConstraints2D.FreezeAll;
}
}
void exittriggerEnter2D(Collider2D
other)
{
if
(other.CompareTag("Box"))
{
Rigidbody2D rb =
GetComponent<Rigidbody2D>();
rb.constraints =
RigidbodyConstraints2D.FreezePositionY |
RigidbodyConstraints2D.FreezeRotation;
}
}
// Convert arbitrary vector to
closest cardinal direction
}
BoxPush
script allows a player to push a parcel
(box) when they collide with it in
Unity. It first checks if an Animator
is assigned; if not, it tries to get the
animator from the player object. When
the player collides with the parcel, the
script determines which direction to
move the parcel (left or right) based on
the player's position relative to the
box. It then moves the box slightly in
that direction (by 0.1 units) and
triggers a "pushing" animation on the
player. Additionally, there are two
trigger methods (ontriggerEnter2D
and
exittriggerEnter2D)
that freeze or unfreeze the box’s
movement when entering or exiting an
area tagged as "Box", to prevent it from
moving incorrectly. However, some parts
of the code, like method naming and
logic checks, need correction to work
properly in Unity.
REFLECTION
Experience
Throughout the early stages of developing this
game, I experienced both creative excitement and
unexpected challenges. Initially, our concept was
broader and included multiple levels with stealth
delivery gameplay. However, after feedback from
our lecturer, we had to pivot and focus on a
single 2D platformer level specifically the
Abandoned Lab. This shift forced us to refine our
core gameplay and truly define what makes our game
unique. Learning to adapt under time pressure
while keeping the gameplay fun and mechanically
sound has been a valuable experience. Designing
for mobile and making sure all ideas are
technically feasible in Unity also helped me
understand the limitations and strengths of 2D
game engines.
Observations
Thoughtful level design turns even the simplest
mechanics into engaging experiences. Pushing boxes or
hiding feels meaningful when obstacles and pacing
complement them. In a 2D game, visual layering and
line of sight mechanics enhance stealth, making player
movements more strategic. Playtesting small mechanics
such as potions or crate puzzles early in development
is crucial, as they directly affect balance and
pacing. Meanwhile, player-NPC interactions become more
immersive when enemies follow predictable patterns but
still retain the ability to surprise players. Unity’s
powerful features, like Ray casting and Physics2D,
provide a solid foundation for such gameplay elements,
but they require fine-tuning to ensure smooth
performance, especially on mobile platforms.
Findings
-
Focusing on one level
allows for better quality control and polish.
-
It’s crucial to balance
fun vs. frustration, especially in stealth games.
-
Random elements, like mystery potions, keep the gameplay
fresh, but they must be tested carefully to
avoid unfair situations.
-
Building a
clear core loop
helps guide every other design decision.
-
Properly planning the
development timeline and assets
early saves time and confusion during
implementation.
Experience
Throughout the early stages of developing this game, I experienced both creative excitement and unexpected challenges. Initially, our concept was broader and included multiple levels with stealth delivery gameplay. However, after feedback from our lecturer, we had to pivot and focus on a single 2D platformer level specifically the Abandoned Lab. This shift forced us to refine our core gameplay and truly define what makes our game unique. Learning to adapt under time pressure while keeping the gameplay fun and mechanically sound has been a valuable experience. Designing for mobile and making sure all ideas are technically feasible in Unity also helped me understand the limitations and strengths of 2D game engines.
Observations
Findings
-
Focusing on one level allows for better quality control and polish.
-
It’s crucial to balance fun vs. frustration, especially in stealth games.
-
Random elements, like mystery potions, keep the gameplay fresh, but they must be tested carefully to avoid unfair situations.
-
Building a clear core loop helps guide every other design decision.
-
Properly planning the development timeline and assets early saves time and confusion during implementation.