Death Petal is a single player puzzle-shooter adventure game, developed for my final-year major project in Game Design at TUDublin.
Players take control of Harmony, a morally ambiguous zombie girl from the 1960s, hellbent on shooting her way out of the underworld!
Inspirations include Resident Evil 2, Lollipop Chainsaw & Killer7.
Team Size: 5
Primary Role: Producer / Game Designer
Tools Used: Unity, GitHub, Visual Studio - C#, Jira, Google Docs, Blender
Timeline: September 2025 - May 2026
Maintained and structured the Game Design documentation
Created diagrams, workflows and design mockups to communicate ideas.
Managed the production pipeline using Jira
(task tracking, sprint planning, milestone definition)
Facilitated sprint planning, task assignment, and team stand-ups
Designed and implemented the Camera System
Designed the core gameplay loop and mechanics
Balanced and iterated core systems through internal testing and feedback
Notable Achievements:
Led production for a 5-person multidisciplinary team for 9 months.
Delivered Vertical Slice, Alpha and Beta milestones on schedule.
Tracked and resolved over 50 bugs through a Jira-based QA workflow.
I was responsible for the design and implementation of the camera system and level block-outs in Death Petal.
Using Final Fantasy X and Resident Evil 2 as my main references, I prototyped and implemented a fixed camera system that occasionally switches to dynamic movement for cinematic effect or practical reasons. The primary focus during prototyping was to ensure that the combination of fixed camera angles, third-person shooting and puzzle elements worked cohesively and felt fun to play.
Once the camera system was functional, I built out the level using first primitive objects and later finished assets, which allowed me to frame the environment in a way that supported both the cinematic and mechanical requirements of the level.
In this way, I was able to curate the players view and direct attention to important landmarks and pathways in the scene.
Completed Camera System in-game
Early Camera System Prototype
As more elements such as enemy encounters and puzzles were introduced, further considerations had to be made when developing the camera system. It was essential that players could successfully navigate the level and engage with the core mechanics without unnecessary frustration.
Some camera angles were found to obstruct enemy visibility or impede player movement, and players initially struggled to orient themselves within the level when passing from room to room.
Through iterative testing, I continuously refined the camera positioning to prioritize readability while maintaining a stylistic cinematic direction. Through practice I grew faster at finding this balance and in the end the fixed camera system became a valuable component of the game's unique visual identity.
The camera system balances cinematic direction and gameplay readability
I wanted to create an overarching story that would keep players engaged but also provide a feeling of working towards a definite goal.
Early in the game, players learn that they need to power up their weapon by defeating enemies which provides a constant short-term objective and aligns with our core gameplay loop.
As players progress through the level, they begin uncovering pieces of the larger mystery which is finally solved at the end of the game.
Rather than interrupting gameplay with long expositional sequences, the narrative was designed to unfold gradually through environmental storytelling, boss encounters and character interactions.
I used:
Jira as our source of truth for tasks and production tracking.
Discord for day-to-day team communication
Google Docs for our Game Design Document
As development progressed, I identified that the GDD was no longer reflecting real-time design changes efficiently.
To resolve this, we shifted toward Jira as the primary implementation reference, and then periodically updated the GDD retrospectively.
I was responsible for making sure that the project remained achievable within our 9-month development cycle.
During pre-production, I encouraged the rest of the team to explore their ideas freely by keeping the brainstorming sessions separate from our sprint-planning meetings. This meant that we could discuss and generate ideas freely without feeling restrained by perceived production costs.
During the sprint-planning meetings, I worked with the team to evaluate these ideas, considering estimated development time, technical complexity and alignment to our planned vision for the game.
I prioritized features that could be made into prototypes quickly so that we could validate them before committing significant resources to their implementation.
This approach enabled us to balance experimentation with the practical needs of production, without sacrificing creative freedom.
I created a simple workflow in Jira for reporting and tracking bugs:
Switch to List View
Create a new work item of type: BUG
Provide a short summary of the issue
Provide a detailed description of the issue
List the steps required to reproduce the bug in engine
Provide either the Build Version number or Date
Select a severity level (Minor to Game Breaking)
Detail the expected behavior
Submit the new work item
Throughout development I regularly assigned the programmers on the team to review the bug tracker and resolve issues, prioritizing bugs based on severity. For each item, a fix was implemented and then tested in-engine before being marked as complete.
50 Bugs were reported and resolved using this workflow during development