Scroll Down for Portfolio
My Design Process
Select to expand.
Games I’ve Worked On as a Designer
Unannounced Projects and Prototypes
Select to jump to portfolio section.
XDefiant - AAA (Shipped)
Associate Game Designer
Red Storm Entertainment, 2024
F2P FPS | Snowdrop Engine | Live Service Team of 300
AAA Skills Summary
Design Expertise
System Design: creating a new gameplay experience by designing and implementing a set of interacting player mechanics that evoke the desired player skill expression with high satisfaction. I’ve owned systems from paper design to prototype to polish, and have jumped on existing systems to quickly leverage completed work into positive results.
3C’s: Creating bespoke character controllers that use every aspect of the medium to make the player “feel” like they are their character. My film school experience (fueled by a lifelong love of cameras and animation) has helped me wonders with this.
Documentation: Using words, spreadsheets, slideshows, videos, graphs, and drawings to present all necessary information for a system (Game Design Documents, Technical Documentation, and Feature Roadmaps) from one source of truth. This has been game-changing for QA for every project I’ve been on.
Playtesting: Writing User Research test cases (“when [A] is [B], the player [C]”), writing playtest questions for measurable results, and encouraging consistent playtesting and feedback loops within the dev team.
Languages and Software
C#, Blueprints, Visual Scripting, C++, Unreal Engine 4/5, Unity, Snowdrop Engine, Proprietary Software, Swarm, Perforce, Confluence, Miro, Excel, PowerPoint, Blender, Photoshop, Premiere, Audition
Production and Teamwork
Feature Ownership, Agile Methodologies, Collaboration, Cross-Disciplinary Teams, Leadership, Onboarding Team Members, Teaching Software and Skills, Public Speaking
-
Paper design is a necessary first step. I believe this so strongly that I chose to speak about it to the UNICEF Global Game Jam participants last year. The kids needed to hear this: we should know who we’re making the system for, what skills we want them to express, why the system we’re making fits in the context of our game, and how we’ll know if we’ve been successful, before ever touching a game engine.
And the system, of course, is a gameplay experience comprised by a set of mechanics that the player uses to express themselves in our game. Each mechanic is made up of the “levers “ we pull as designers to define how it works, things that can’t be broken down further like “speed” or “resource cost”.
The answers to these questions, and a 2d bubble map of the system broken down into mechanics and levers, should be documented before proceeding. My favorite device is Confluence.
-
Once we have a GDD that explains how our system and mechanics work, then it’s time for prototyping: using the bare minimum to learn the most. I’ve grown my technical toolkit in Unreal, Unity, and Ubisoft’s Snowdrop Engine enough to scope out and prototype new systems largely on my own, and I also have years of experience driving cross-disciplinary implementation as a designer. I break down the work that needs to be done by discipline (UI, audio, animation, art, programming, level design, etc), as if we were tasking things out for all of those disciplines
Then, I determine what I can take on myself given my abilities and current workload, and participate in team tasking to ensure all aspects of the system’s design are accounted for and headed for the same level of quality. At this stage, I’m always reminding myself and others that increasing scope and polish isn’t the point right now. Prototyping systems is for validating the rules that content design will follow. We make it fun before we make it pretty, or make tools for it.
-
Another non-negotiable for me is consistent, constant playtesting. We shouId be playing the game ourselves throughtout the day and giving clear, constructive design feedback amongst the team, both in regular 1-1 communication and as a group. I love leading these discussions, as well as regular design postmortems.
I also have experience from all of my projects with onboarding new players and delivering playtest questions/surveys that I’ve written to gain trackable metrics (data). I’ve also helped many other designers create playtest questions for their game features. These questions should gain the player’s holistic perspective of the system, as well as their experience with the individual mechanics. We want to use data to prove that our design is successful, and can only be improved upon by “lever” pulls. If the data doesn’t, it should be clear from our results where changes should be made.
-
We parse our feedback and design data in the context of our paper design’s assumptions and definitions of success, then decide how to move forward from this version of the prototype towards our goal. No one has any personal attachment to this work, especially because we kept the scope down, so we can go as far as completely scrapping the system and leaving feeling grateful for what we learned from it.
But if our playtest feedback and data proves that our prototype accomplishes the goals we set out to, then it’s on to full iterative cross-disciplinary development and tools development to support the system.
Tom Clancy’s The Division Heartland - AAA (Unreleased)
Associate Game Designer
Red Storm Entertainment, 2024
Survival TPS | Snowdrop Engine | Team of 130
Cecelia - Indie (Shipped)
Technical Designer and Design Lead
Aifir Interactive, 2023
Action Adventure RPG | UE5 | Team of 16
XDefiant - AAA (Shipped)
Ubisoft: Red Storm Entertainment
Snowdrop Engine | Live Service Team of 300
Associate Game Designer, May 2024 - Dec. 2024
Red Storm joined the co-dev team for XDefiant in May 2024. In addition to designing and implementing the VS Bots game mode and owning live updates for the Cleaners faction, I gave playtest feedback on weapons, unreleased factions, and game modes, and shared Snowdrop knowledge with our Red Storm team and co-dev partners.
Top Skills Used
System Design, Combat Design, UX Design, Visual Scripting, Snowdrop, Swarm, Perforce, Jira, Confluence, Agile Methodologies, Cross-Disciplinary Collaboration, Leadership, Debugging and Optimization
Designed and Implemented VS Bots Game Mode, Adding AI Player Bots to XDefiant for The First Time
Designed User Experience for bot team backfill (replacing empty slots on a player’s team with bots after [X] seconds) and collaborated with engineers to make supporting changes to code.
Designed core principles for PvE combat in XDefiant: expected player and NPC behaviors, definitions of success. These included:
Bots should flank players whenever possible
Bot combat targeting should be based on active threat, whoever is dealing the most damage to the bot and its teammates while spreading out targets between allies
Bots use their hero abilities in appropriate ways (direct damage towards enemies, healing and buffs towards allies) as often as possible
We used these principles as guideline when testing the bots’ interactions with the level design, gamemode objectives, human players, and other bots (enemy and ally). I coordinated AI behavior code changes with engineers, while handling data changes in Snowdrop.
Set logic for enemy and ally team bot filling (how many of each faction, skill, difficulty setting,) allowing multiple AI playstyles to balance each other out and create emergent combat scenarios.
Created 72 individual player bot “profiles” with configurations for behavior/combat difficulty, faction, skills, and cosmetic. This achieved XDefiant directors’ aesthetic visions while also achieving our designed combat principles (note: narrative names were due to be provided by narrative team prior to XDefiant cancellation. RSE (I) was not allowed to use our fun robot pun names.)
Orchestrated VS Bots game mode playtests with entire XDefiant Live Service team, wrote playtest questions and parsed feedback.
Coordinated bug tracking with Quality Assurance, determining if anything bot-related was a bug or a feature.
Documented VS Bots design and technical implementation in Confluence.
I represented design on team with 3 programmers reporting to the XDefiant Creative Director and Executive Producer.
We met with XDefiant leads biweekly to give updates, receive feedback, and establish new goals. I documented meetings, goals, and tracked current status of all aspects of the feature in Confluence and Jira. Created design tasks for VS Bots in Jira, gave design updates in Daily Scrum meetings, and feature updates in larger team meetings.
I set and enforced the scope for the new VS Bots mode to 6 game maps and 2 game modes (Domination and Escort) for its a bug-free season 3 initial release (achieved.)
I created the 6 map VS Bots playlist in Snowdrop, and limited player voting to supported maps and modes while in VS Bots lobby.
I created new VS Bots gamemode class in Snowdrop. I added to development-only builds until reaching final LOQ, then added to shipped retail build.
I coordinated the new XDefiant Front “Play” Menu and inclusion of VS Bots mode to First Time User Experience with our co-dev UI and UX teams (mostly Ubisoft Osaka.) I wrote the new game mode description.
I identified area for code changes to allow for per-gamemode player XP gain rates. I collaborated with the player progression team (Ubisoft San Francisco) to implement those code changes, and then I tuned the values with data changes in Snowdrop.
Owned Live Updates for Cleaners Faction on Factions Live Service Design Team
Operated as Feature Owner for live service updates to the Cleaners faction in XDefiant. Collaborated on a team with three other faction Feature Owners (also technical designers.) Parsed player bug reports and prioritized bugs in Jira. Pushed bug fixes to 1.5 million monthly active users. Decreased bug reports for Cleaners by 90% prior to leaving project.
Fixed high priority bug that existed for years: allowed Incendiary Drone to be Hijacked by DedSec faction hero skill. The intended behavior was for a DedSec player to be able to activate their ability near an active Incendiary Drone, taking ownership of the drone. This would send the drone on a straight path back to its deployment origin, spawning a fire trail beneath it that did damage to the to original drone owner’s team. I achieved this by:
Using Snowdrop debugging feature to determine that, when hijacked, the drone’s collision detection line trace was sweeping in a 180 degree half circle as it turned around, causing it to often explode
Editing the visual script for the Incendiary Drone to deactivate the line trace while rotating in place, then reactivate once on the correct flight path
Implementing the logic for the fire trail to be spawned for the hacking player’s team, using same logic for initial implementation but parameterizing to pass in an “owner” and calling when Hijacked
One of my favorite memories on XDefiant was testing this feature with the Red Storm team. By having two teams of DedSec players and one Cleaner deploying the drone, we were able to successfully ping-pong the drone back and forth as many times as we had the ability to use Hijack.
Optimized visual scripts for Firebomb hero skill in Snowdrop. Made it so only server values were used for game art (fire AoE) instead of calculating and spawning from each client, and performed these calculations during skill deployment time. This significantly improved the UX by removing confusion of where in the game world was actually on fire.
Updated UI text for Cleaners faction description page, reducing confusion (and bug reports) about Incendiary Rounds.
Handled complicated manual merge of visual scripts in Snowdrop for Incendiary Drone between two branches of the game, which included many conversations with high-level producers and product managers over several weeks to get approval for my necessary change. I later taught what I learned to the Lead Gameplay Engineer on the Red Storm team, significantly reducing downtime and confusion for his change.
Playtested and gave design feedback for all Live Service XDefiant factions multiple times a week.
Assisted other Red Storm technical designers with debugging their faction’s implementation in Snowdrop.
Old Incendiary Rounds Description
New Incendiary Rounds Description
Tom Clancy’s The Division Heartland - AAA (Unreleased)
Ubisoft: Red Storm Entertainment
Snowdrop Engine | Team of 120
Associate Game Designer, Jan. 2024 - May 2024
Game Design Intern, Aug. 2023 - Jan. 2024
I joined the Heartland project in August 2023 as it was going through its third and final genre pivot from a PvEvP F2P TPS to a boxed product survival shooter.
Top Skills
System Design, 3C’s Design, Combat Design, Balance Design, Visual Scripting, Coding (Proprietary Language), Perforce, Excel, Jira, Confluence, Miro, Powerpoint, Agile Methodologies, Public Speaking
Tuned Combat and Survival Systems to Change Game Genre
Learned implementation of Heartland systems in Snowdrop inside and out: where everything lived, what was a data change, a code change, visual scripting, or UI graph.
Researched real-life wilderness survival and performed competitive analysis of survival games. Researched all weapons (guns) present in Heartland.
Set and iteratively tuned most data values in the game:
weapon damage at tiered ranges
player and NPC health
player stamina and encumbrance
player and NPC armor
item weights
in Snowdrop to achieve “every bullet counts” survival game feel. This involved establishing design assumptions for TTK and survival 3Cs, documenting the above values and where to change them (Snowdrop files) in Excel, and creating one source of truth by creating new design documents and marking deprecated ones.
When I joined Red Storm, I immediately formed tight relationship with Quality Assurance, providing updated values and expected outcomes to reduce false bug reports and confusion. I became their go-to for design questions for the remainder of the project.
Designed and Prototyped New Survival System
Worked on feature team as technical designer with 2 programmers and 1 technical UI artist, reporting to Lead Game Designer.
Began work on feature with competitive analysis and design ideation, aiming to reuse as much of the existing Water/Satiation/Fatigue system as possible.
Worked with Lead Game Designer to approve final design and set actionable goals for team.
Coordinated code changes for 3C’s, setting up ways to tune feature in the future with data-only changes.
Collaborated with UI artist to completely redesign player inventory interface.
Set, tuned, and documented data values for system.
Set all values for player stamina system and new status effect, owning until project end.
Created 3 panel system in-game description for new survival system.
Wrote and maintained design documentation for feature in Confluence.
Wrote test cases for User Research lab.
Raised player perception (User Research playtests with hardcore The Division fans) of new survival system from “Dissatisfactory” with previous version to “Indifferent” with first iteration of system to “Highly Satisfactory” with final version.
Remained SME for new survival system for remainder of the project.
Designed and Prototyped New Melee Combat System, Creating Emphasis on Stealth
With the mandate “every bullet counts”, melee needed to be a reliable and strong choice. The work started with me brainstorming new Melee Combat with Associate Game Director. Then a development team was formed with myself and two other technical designers, the two game directors, two gameplay programmers, an animator, a UI technical artist, and a producer.
We collaborated in brainstorming meetings, talking on Teams while I mapped out the new system in Miro. I’d provide design feedback and a TD’s perspective on scope and engine constraints.
We designed 3 melee attacks: A “buttstroke”, the player using their gun as a melee weapon; a “normal”, where the player uses an equipped melee weapon to attack an aware NPC; and “stealth”, a “normal” melee attack performed on an unaware NPC, which was always lethal unless the NPC was wearing a helmet.
Paper Design for New Melee Combat I Created in Miro
Once the paper design was complete, we split the work. My focus was on the player’s experience.
My time in-engine was spent creating the logic and tuning the 3C’s, stamina, stealth, and damage values to be different for the three melee attacks. I’d modify data and visual scripts to make iterative changes to how the three different versions of melee felt. This meant a lot of close collaboration with animators as they made changes to the animation graphs, programmers who I’d work with to add new variables/design levers for me to pull and remove existing melee assumptions from our Division branch of the engine, and our Lead NPC Designer who owned everything “melee reaction.”
I also acted as SME for Melee Combat for the remainder of the project.
Implemented and Tuned Game Difficulty Settings
Implemented difficulty settings for the game within Snowdrop.
Set debug commands for difficulty settings; Coordinated new Difficulty Settings menu with UI team.
Set and iterated on the following values for three difficulty settings.
what % of damage NPCs do compared to players with same weapon
how many NPCs spawn in an encounter
how much health NPCs have
how accurate and intelligent NPCs are
Wrote User Research test cases and playtest survey questions, parsing feedback against the players’ determined skill levels.
Public-Facing Systems SME
Acted as SME for Combat, new Survival Systems, and Game Difficulty settings, to other developers, User Research, and Quality Assurance.
Was a go-to for impromptu questions about these systems or pretty much anything in the game. When someone was onboarded to the project post-January, I’d give an intro to our game’s systems, a Snowdrop learning session and show them where to find documentation.
Presented at 5 multi-studio project updates (delivered a PowerPoint presentation I created to 300+ people on a recorded Teams call.) I used humor to sell our teams’ designs and encourage participants to playtest the game. One moment ended up making the sizzle reel for entire 5+ year Heartland project, which was a huge honor.
Redefined Game Design Documentation at Red Storm
My first month at Red Storm, I created a Game Design Document for a new survival feature in Confluence. This included a brief summary of the feature and sections for each of the system’s mechanics. The mechanics section went very in-depth, line by line through the player’s experience.
For each step, all aspects of that feature were accounted for (from UI to 3C’s to audio), and gameplay values that needed to be quickly iterated were identified (for example: vaulting costs the player [30] stamina).
We also had tags for each of these aspects that corresponded to their current Jira status. We knew what should be done and playtested as such, and what wouldn’t be present in that day’s build.
This documentation also contained a technical documentation section at the bottom that was linked to throughout the design documentation. If someone reading the design documentation wanted to know where to tune values they were reading about, they just had to click on them. If they didn’t want the technical documentation, they didn’t have to see it.
This documentation was helpful for many reasons: it made the design’s intentions and definitions of “success'“ for tasking incredibly clear to the feature’s developers; it communicated the design beyond the team to other developers, User Research, and Quality Assurance, ending “is it a bug or a feature?” for the system; and it drastically improved the efficiency of onboarding a new dev onto the team. The documentation handled what I’d need two weeks of Teams call to figure out.
The positive impact was noticed by our production leads, who made the new survival system’s page into a Confluence template and initiated an overhaul for all of our system design documentation to follow it. This template was still used past the end of the Heartland project, on other projects.
Cecelia - Indie (Shipped)
Aifir Interactive, UCF FIEA M.S. Capstone Project, 2023
Unreal Engine 5 | Team of 16
Technical Designer and Design Lead, November 2022 - August 2023
Worked as Technical Designer to own narrative design, audio design, and contribute to playtesting and bug fixing efforts on team of gerogereiger to create first-person action adventure RPG where the player escorts a giant baby npc across a dauntingly beautfigul island.
The UCF FIEA Capstone project is the defining experience of the program. 70 grad students are drafted into 4 different teams of artists, designers, programmers, and producers. Together, they must produce a game experience. That’s the extent of the constraints.
A handful of projects are shining achievements of student excellence. Ours represents the reality of 16 graduating students needing an example of [Game Dev Skill or Art Style] and “1 shipped title” on their resumes to get into [Dream Games Studio]. The game was designed around ensuring each person got to flex the #1 skill they wanted to show on their resume, in the style of their Dream Studio. And it had to ship on Steam no matter what.
It’s not a very fun or good game. But it clearly has heart, a lot of it is very pretty, and most of us got jobs in the games industry after graduation by showing their work from this game, which was our goal for the project.
I learned SO much from this experience, by making key mistakes every developer has to but in a controlled, safe setting. I was not a good Lead Designer, but I was humble, honest, and a supportive peer, and always the last one to leave the building when design work was being done. Thankfully my design leadership skills have been tested many more times since then, with higher consequences, and those experiences let me prove I can do this.
The lessons I learned, more that the game I showed, is what got me into the AAA industry with my design internship at Ubisoft following this project. Here’s the biggest ones:
How to constructively say no to keep a design space pure without shutting down people or ideas
Daily Scrums and team building activities are necessary for morale and unity
Every game is specifically A Thing for A Person, you need to truly know what you’re making/selling and how the minute-by-minute gameplay experience will satisfy your consumer
Don’t touch the engine until you have a paper design for your game’s systems
Don’t scope out a full game before achieving a fun barebones prototype
The importance of level metrics and iterative whiteboxing before level art
Document the process of making everything, including time spent in order to make better estimates
Keep design documentation in a single location (one source of truth), update it constantly
Delete irrelevant JIRA issues, don’t plan for a future that’s not certain
Top Skills
Visual Scripting, Audio Design, Narrative Design, Level Design, Premiere, Audition, Perforce, Jira, Confluence, Miro, Agile Methodologies
Lessons Learned
Led Student Design Team
Participated in Sprint Planning with Project Lead, Development Director, Lead Programmer, and Lead Artist.
Led Design Team Scrum meetings 3x a week.
Represented designers’ needs at regular Leads update meetings.
Had 1-1’s with designers to discuss project experience, portfolios, and needs from me.
Directed Mocap Shoots for Character Controllers
Coordinated with designers, animator, technical artist, and programmers to determine and documents needs for player and NPC character animation graphs in Excel.
Attended mocap recording sessions, directing what animations needed to be recorded and how (often physically demonstrating) alongside our Lead Animator, updating documentation upon completion.
Wrote Narrative and Voiceover Script, Cast Actors
I attended an open casting call with our Project Lead for UCF actors with all of the capstone teams, auditioning each of them over Teams.
The plans for our game’s narrative varied drastically as we continually cut scope and Frankensteined together the pieces of a game we had. At the last moment, I wrote a new game narrative and script that I proposed to the team, which utilized our actor’s strengths.
They were impressed with how the whole thing was woven together. If players ignored the absence of systemic gameplay, they could be delighted by a story with a beginning, middle, and end that fit our game’s setting and mechanics.
Worked Where Needed as General Technical Designer and Bugfixer, Constantly Playtesting
My unofficial role on the project was the final Technical Design line of defense, someone to slot in and do what no one else wanted/had bandwidth to do. This meant a lot of late nights before milestone presentations. In addition to the work detailed above, I:
Playtested Bird and Spider NPC combat, giving feedback to NPC programmers
Playtested and updated floor collisions for all game levels to allow player and companion NPC to fully navigate them, giving feedback to Level Designers and cementing level metrics to decrease navigation bugs
Created playtesting “gym” level for our game mechanics
Created playtest questions for internal and external playtesters
Sourced and Implemented Most Audio in Game, Created Dialogue Subtitle Tool
Sourced audio from our V.O. recording sessions, freesound.org or other free sources provided by FIEA, often editing files to fit our specific needs in Adobe Audition.
Implemented audio where it made sense to: audio volumes for environment ambience, sound emitters in Blueprints for environment interactions, animation notifies for footsteps, 2D sounds for V.O.
For in-game dialogue, I created a Blueprint class that was physically placed in the game world as a trigger. When it was triggered, it played the V.O., and if subtitles were enabled, it played subtitles. This allowed us to completely control the narrative pacing of the game.
The only sounds I didn’t implement were player exertion (jumping, mantling) and bird NPCs.
Created Cinematics
I created this bird cinematic for our game’s trailer by setting up the scene in Unreal, using a UE Cinematic camera to capture multiple shots, and creating the blinking eye effect/editing the video in Adobe Premiere Pro.
I also created the opening “cinematic” of our game, a voiceover conversation between a mother and daughter set on a rowboat, using Adobe Audition and Premiere Pro.
Unannounced Co-Op Game Prototype
Ubisoft: Red Storm Entertainment, 2025-2026
Unreal Engine 5 | Team of 9
Technical Game Designer, Aug. 2025 - March 2026
I contributed as a Technical Designer on a prototype team with 2 other TD’s, 2 gameplay programmers, the Creative Director, Associate Game Director, and 2 producers to create a new PvE Online Co-Op game in the setting of a Ubisoft Fantasy IP.
In addition to prototyping replicated melee and ranged player hero abilities using Blueprints, the Gameplay Ability System, and C++, and implementing the logic for a total player team limit and created a Spectator Cam game mode, I contributed to our Combat and Mission systems design.
Top Skills
Blueprints, Gameplay Ability System, C++, Animation, Blender, Perforce, Miro, Agile Methodologies
Created Hero Ability Building Blocks and Prototyped Magic Hero Abilities
As a team, we started by brainstorming a list of magic abilities that our characters could use in our horde combat encounters.
I identified that a lot of our ideas for spells required a “Cone Spray” component, hit detection in the shape of a cone extending away from the player out of their wizard’s staff.
Following this observation came the decision to make hero ability “building blocks”, essentially the base mechanics in a hero skills system that would be iterated on with different attributes to make the final versions of bespoke magic abilities.
To create the Cone Spray building block, I first created the G.A.S. Ability Blueprint and Gameplay Tag to activate it. I added the Ability to a development skills loadout, then started building out the mechanic using Blueprints. I added a “Multi-Cone Trace By Channel” node in C++ to our Blueprint Function Library and activated it in in my ability in the direction of the player’s control rotation. I created an obviously debug hot pink Niagara System of Splatoon-like spraying particles in a cone shape, which I activated using the same information as the cone trace. The cone spray ability applied a DoT Gameplay Effect to any character it hit.
Another building block I made was creating a “Receive Gravity” base character ability. To apply a replicated magnetic force to characters, a hero ability just needed to activate this ability (which was granted in the base character class) on its hit target and pass in the direction it wanted them to be pulled towards. I used this to make a prototype a new version of Zarya’s black hole ultimate attack from Overwatch.
I also created two new Gameplay Ability Target Data classes and Blueprint node in C++ for our BFL for use in our games player abilities: one for In-Game Items, which would tell the player’s inventory system what item it was picking up and what equip animation to use; and one to directly pass in the Vector2D value of the player’s Controller Input when activating a Combat Ability.
Set Multiplayer Team Size Limit and Created Spectator Game Mode
For a long time, when playtesting the game, we’d have four people join the game, and one of them would stream their gameplay on Teams.
Using Blueprints, I edited the logic where players join a server session to determine if 4 players already existed in the game, and if they did, the 5th+ player would possess a Spectator Pawn class I created. Spectators could fly freely around the game world, or press buttons to teleport back and forth between the active players.
In the next iteration, I would have moved this logic from where players join a session to activate from an updated “Active Players” variable in the game’s state, so Spectators would instantly spawn and possess a character when a 4th active player left.
Unannounced Cozy Game Prototype
Ubisoft: Red Storm Entertainment
Unity Game Engine | Team of 22
Associate Game Designer, Dec. 2024 - April 2025
I contributed as a Technical Designer on a prototype team of 22: 5 UI/UX Designers; 2 gameplay programmers (for the first month, then all coding was done by me and 2 other technical designers); a narrative designer; 4 audio designers; 4 artists; and 2 producers. We were tasked with making a gameplay demo for a new cozy game.
Top Skills
C#, 3C’s Design, System Design, Confluence, Miro, Powerpoint
Feature Owner for Animal Crossing-Like 3C’s
Designed and implemented camera system that had dynamic cinematics for NPC conversations, smooth UX for constructing buildings and designing inside homes.
Created third-person 3D character controller using C# and Animation State Machine
Designed and Implemented Core Gameplay Systems in C#
Implemented collectible resources, scripting gameplay economy system, creating UI, placing level art, programming player interact, adding animation and VFX
Built player inventory system and in-game item class, defining pipeline for 3D asset integration and item data assignment
Collaborated with gameplay programmers to implement player construction flow, me contributing with 3C’s and UI changes
Set up initial UI system with “one canvas to rule them all” in Unity.
Little Shopping Buddy
Indie Dev Project, April 2025
Unreal Engine 5 | Solo Dev
I wanted to make a game where you’re a little kid helping your parent run errands.
For this game’s audience, I felt that having a 3C’s experience that was fun enough on its own was the most important thing.
So I created a cute first-person and third-person character controller with the ablity to control arm movements with joysticks and grasp hands with triggers. I also created shopping cart with simulated physics using Blender and Unreal’s Physics System.
Top Skills
Blueprints, 3C’s, Animation, Blender
Design and Implemented Adorable First and Third Person 3C’s
Edited animation graph to
Edited animations from Mixamo and added to Animation Graph
Created Shopping Cart with Simulated Physics Using Blender and Unreal
First, I downloaded a free shopping cart static mesh from the Interwebs.
Then, I imported the FBX file to Blender. I used modeling tools to separate the wheels from the rest of the mesh. Then, I imported the segmented shopping cart static mesh into Blenders.
After creating a blueprint for the shopping cart actor, I used physics constraints on each of the cart’s wheels to allow them to roll and swivel like shopping cart wheels.
Proprietary Mission Design Tool Port to UE5
Ubisoft: Red Storm Entertainment
Unreal Engine 5 | Solo Tool Creation Assignment
Associate Game Designer, May 2025
To assist in the remaster of a previous Red Storm Entertainment Game, I ported the mission design tool from a proprietary game engine to Unreal Engine 5. This included setting up the attributes of our enemy NPC’s.
Top Skills
Blueprints, Porting, Tool Creation, Perforce
Ported Mission Design Tool and NPC Settings
Created mission blueprint with Spawn Enemies function, which took in a Mission Data Asset I created.
I duplicated the Mission data asset’s settings from the mission tool in the proprietary engine. In a data table, designers set:
How many enemy teams were in a mission
How many platoons were in each team
How many NPCs were in each platoon
The NPC settings of each NPC in a platoon
Spawn Enemies Function
I created the base NPC class by:
Adding variable for spawn transform
Added armor type enum and logic to effect character shield HP values.
Added character class enum.
Added variables to set character behavior and damage values
Added game difficulty enum and applied difficulty settings mission blueprint, controlling whether or not this NPC would spawn
So, instead of hand-placing NPCs in the game world or setting up spawners, a designer could set and change the enemy settings and a mission’s difficulty in data only.