Randomized attack zones indication generator for effective gameplay variation

Hit Area on-click fade functionality for responsiveness

how it works

why my implementation matters

Visually telegraph attack locations, giving players a clear layer of interaction

Random-point generation within UI bounds creates high variability without manually creating attack patterns, enabling rapid iteration w/out addition work

Attack zone generation is independent of enemy implementation, making it re-usable across enemy types keeping combat logic clean by separating where attacks happen from how enemies behave

how it works

why my implementation matters

PlayerCombat - manages what was hit
HitAvaliable - handles how the indicator reacts (visual + state change)
Reduces coupling between player and enemy systems

HitAvaliable Serves as a foundation for any addition of new interactable (weak points, UI targets, body parts or Any object implementing HitAvaliable allowing functionality in the system w/out additional code work

Immediate visual feedback reinforces successful player action
improving game feel and clarity during fast-paced gameplay

Re-usable ScaleChange object scaler for increased gameplay pressure

On-click replace & skinning with art assets for cohesive visualization

how it works

design significance

Applies continuous visual and mechanical pressure during attack phase in place of static click indicators forcing players to stay engaged to do damage. The gradual scaling communicates attack availability very clearly to the player.

Duration-based scaling allows me as the designer to easily tweak pacing and difficulty, and provides a foundation for expanding into more complex behaviors (non linear scaling, curves, hold effects)

Encapsulating logic into a standalone ScaleChange component keeps logic independent and modular, allowing behavior to be reused across different objects and scenarios w/out code duplication

how it works

design significance

Visual sprite change on hit confirms player actions instantly reinforcing interaction success and player confidence with gameplay systems

Event-driven architecture (UnityEvents) separates visual effects from core gameplay logic, enabling me as the designer to hook into interactions w/out having to modify the granular code.Meaning the system can be expanded to support additional effects (animation, sound, vfx) with minimal changes

Type Based Polymorphic Enemy System

Modular Attack System using Data-Driven Command Pattern

how it works

design significance

Using a "has-a" EnemyType relationship allows behaviours to be swapped without rigid inheritence chains, allowing rapid ideation on enemy design without rewriting shared functionality across core systems.

New enemy variations don't require new script classes, only new EnemyType definitions, keeping codebase maintainable as content scales.

EnemyType encapsulates what an enemy does while Enemy controls how and when it happens, separating these responsibilities keeps systems modular and avoids tightly coupled logic

how it works

design significance

Abstract Attack contract allows new attack types w/out modifying existing systems, reducing risk during iteration and increasing scalability and maintainability

Inspector configured parameters enable rapid tuning and iteration without coding granular changes

Enemy logic depends only on the abstraction, not concrete implementations which enforce separation of concerns (SRP).

Modular Enemy Combo Framework

Modular Enemy Combo Framework Implementation

how it works

Heres an example of how a concerete EnemyType would implement the StartCombo()

design significance

Combo defines an attack sequence as data, while EnemyType controls how that data is exeucuted, this prevents tight coupling between the content and behaviour

The same Combo can produce entirely different outcomes depending on the traversal applied by each EnemyType, allowing for simple diversification of combo attacks with with the same data.

New Enemies do not require new combo definitions, only using a traversal strategy, this speeds up iteration

If I were to have a different Enemy Type like a Knight for instance, I could easily diversify how the knight would attack from the dragon by calling a different traversal method

how it works

In the inspector I can easily tweak variables to rapidly create uniquely attacking enemies

design significance

I can customize each and every EnemyType to act differently all with the same or similar assets and behaviour, cutting down on development time

Each EnemyType has a LIST of combos that it pulls from, meaning I can create combo chains without ever touching code

And, because each Combo contains a list of Attacks that is also Inspector-exposed, I can customize each combo down to the level of each attack in that combo, allowing full control of customization still without ever touching code.

Level Select Functionality - Greybox & Skinning

Scriptable Object Dungeon Configuration

how it works

Post Skinning:

design significance

I always greybox out my UX to ensure the functionality is cohesive and responsive. That way skinning goes smoothly and the user can functionaly traverse through the game, even at an early developmental state. This also allows for playtesting at earlier states

I took inspiration from Geometry Dash's UX/UI because it was very simple. I knew from the get-go I could replicate it within a very short time frame because of my confidence with the Unity Editor. This allowed me to quickly create and then move onto completing the game.

how it works

design significance

Because I was going with a level based progression for the game, I needed the levels to be adjustable at a higher level. This allowed me to alter levels without having to go into each individual scene, cutting down on iteration time.

I'm constantly thinking how to program better, and one way of doing this is thinking of immutable design & and data-driven systems. This solution uses both to decrease complexity in runtime scripts and separate my concerns more which increases my script and systems clarity and readability.

JSON Saved Level Progression w/ Locked Final Level

Procedurally Looping Encounter System - Performance Optimized

how it works

Successfully completing a level checks off item in grocery list

design significance

It is very understandable to all ages a list of shopping items, taking this idea I used it for my level progression to increase the player's confidence in the game's functionality

The player has to collect "Grocery Items" from a "Grocery List."
The player will recieve a "Grocery Item" at the end of each level which checks off an item on their list.

how it works

design significance

Encounters are discrete and composable modules that can be altered without changing the core system.
The world is procedurally repeated over and over, cutting down on draw calls if many encounters were loaded at once.

The RepeatWorld listens for the the PlayerCombat to tell it if and when the enemy dies, avoiding polling and increasing perfromance

Led Project Start & Initial Team Directing

Scheduled Team Meetings & Managed Team Sprints

Key production choices

After theme reveal, I saw that our team needed direction, I proactively stepped up and took the responsibility to lead the team from the start.

Key production choices

I setup each person's Sprint and collaborated on achievable goal setting for each person.

Informed them we would stop what we were doing and get together to talk about our progress every 3-4 hours for a meeting.

During meetings I would ask about each team member's progress, being as empathetic as possible, informing them of breaks and asking how they were feeling overall.

Team Composition:

Directed Art Assets & Created Art Approval System for Team Members

Managed Asset Handoffs between Team Members

Key production choices

I came up with an approval system in order to direct the art assets team members created and keep assets cohesive visually and on theme.

This was done for 3D and 2D Art assets alike:

Key production choices

Managed handoff between team members in order to coordinate asset production because some assets required multiple-role work.For Example:

Team members would eventually have a backlog of assets handing off between each other. Thus, I would take a more hands-off approach as our team worked better and better over the course of the jam, we reached a flow-like-state.