
Welcome to my portfolio! I'm a producer and narrative/systems designer with a passion for bringing games and stories to life. I use my production and design skills to develop the other further; design in production to plan further ahead based on what the game needs, and production in design reminding me to creatively problem solve based on the team's limitations and project's scope. With experience in QA to round these skills out, I've used these abilities to great effect on many indie projects and a handful of industry teams.

Akushukai! is an alt-control game I developed with a team of 13 in a little less than three months for the masters program at the University of Utah's game design program. You play as a jpop idol who must appease their fans at a handshake event... even if they have some weird requests.
The game was selected as a finalist for the Alt+Ctrl contest at GDC 2026!

- We used agile project structure, regularly reporting to shareholders and getting their feedback
- We used a virtual kanban board for task tracking and ensuring we were making good time for each sprint
- Ran scrum for sprint planning and estimating task difficulty via the story points method
I handled tech production and QA for this project. I set priorities for our engineering team, acquired supplies for the hardware team, and tracked dependencies with the other departments to ensure we wouldn't be blocked by any bottlenecks. I also playtested the game and organized a public playtest schedule so we always knew what needed to be fixed or improved next.

- Created the kanban with Concept Board
- Tracked our budget and hadware delivery logistics in a Google Sheets document
- Helped keep files organized in a Google Drive folder for most documentation/backup storage, and worked in Unity to ensure project assets were properly organized
- Created progress reports and sprint reviews for shareholders in Google Slides
- Created marketing materials by capturing footage with OBS and editing it with Adobe Premiere Pro
- Created a Discord server for quick communication and collaborative feedback
I joined on this project partway through development, which created an interesting challenge integrating with the team and dividing responsibilities with my co-producer.
Where my co-producer already had a lot of things in hand with managing the team, I focused on examining our processes to see where we could improve. This led to me setting up collaboration tools for the team, tracking our budget expenditure in a proper spreadsheet, and creating a QA schedule for the game.

Echoes of the Nameless was a student project made in the masters program at the University of Utah's game design program. This project was made with a team of 12 over the course of four weeks in Unreal for VR devices.
In it, you play as a test subject who woke up in the abandoned laboratory of a mad alchemist. To escape, you'll need to learn the magic which the alchemist hid, and avoid being caught by the experiments that were left behind.

- We used agile project structure, regularly reporting to shareholders and getting their feedback
- We used Trello's kanban tools for task tracking, and keeping an eye on our team's overall progress
- Ran scrum for sprint planning and estimating task difficulty to determine scope
I handled production tasks for this project alongside my co-producer. I handled tech and design production, and assisted with QA. My co-producer and I worked together to set the scope of the game, keep our respective teams on track, and ensure there was good communication happening between the tech and art halves of the team.


- Used Trello for task tracking, and creating tickets for bugs discovered during QA
- Managed a Miro board for creative collaboration
- Helped keep files organized in a Google Drive folder for most documentation/backup storage
- Created progress reports and sprint reviews for shareholders in Google Slides
- Created a Discord server for communication, collaborative feedback, and to organize fun events to help the team bond
This was my first time co-producing a project since I began my production journey during my undergrad. I was able to put everything I have learned since that project into practice here. We scoped this project really well. We made full use of our time to implement some really cool mechanics and high quality art, while still giving the team time to spend with their family over Thanksgiving. We even had time to polish the project due to finishing ahead of schedule (which is worth mentioning, since the class was about creating prototypes on short schedules, not full polished games).
The only thing I would change from this project would be to do more of our testing on built versions of the game. We did most of our playtesting in-engine to save time for our programmers. This resulted in a net time loss however, compared to just making a build for each playtest, due to us uncovering a load of build issues and technical debt we had to rush and solve towards the end of the project cycle.

Doubloon Dash is an infinite runner mobile game where you play as a treasure hunter on the high seas, collecting booty and avoiding pirates. We made the game over the course of two months as a small rotating team of roughly six members, and released onto the iOS app store in 2024.

- This project was a port/remake of an old school project from undergrad, which served as a good prototype and guidepost for our final product. As a result we utilized a hybrid waterfall-scrum methodology for our project structure instead of agile
- I used ClickUp's kanban tools for task tracking, and burndown charts to ensure we were moving on time with our sprints and overall project goals
- Ran scrum for sprint planning and estimating task difficulty to determine scope
I handled production and publication tasks for the team, QA management and also assisted with game design on the project.
On the production side, I set the scope and timeline for the project, established the development pipelines for our different disciplines, and generally handled management tasks for the project. Unique to this project however was creating an onboarding process for the art team, which gained new members twice over the course of the project. I was able to create a simple system that integrated them into the pipeline and had them creating new assets for us within a week of them joining.

- Used ClickUp for task tracking, design documentation, and creating tickets for bugs discovered during QA
- Managed a Miro board for art style guides, and visual design documentation (such as UI mockups)
- Created a Discord server for communication, collaborative feedback, and to organize fun events to help the team bond
From my bird's eye view of the project as the producer, I was able to learn a lot about the added challenges in each discipline that arise from working on a mobile game. This project also gave me an opportunity to learn the ins and outs of mobile game publishing, and what goes into putting a game onto the app store of different devices.
Next time for a project like this, I would look to see if I could procure a few cheap and old iOS/android devices for my teammates to use as testing platforms, so we wouldn't be so dependent on finding external playtesters who specifically had the device we needed to test.

Subspace Shootout was a game made in three weeks for the Big Mode Game Jam 2023. We made top 15 out of nearly 500 submissions by winning a Judge's Choice Award!

- As with most game jam projects, we used agile and focused on rapid iteration and fast solutions (even if they aren't scalable) in order to playtest our prototypes as quick as possible
- I used ClickUp's kanban tools for task tracking
- Ran scrum for planning the project's timeline and estimating task difficulty to determine scope
I was the Producer and QA manager for the project, and also helped design the game. Using what I learned working on previous projects, I implemented a system for version control that led to us having nearly zero merge conflicts during the entire project between our three programmers.

- Used ClickUp for task tracking, and storing design documentation
- Managed a Miro board for creative collaboration, and visual design documentation (such as UI mockups)
- Organized art and sound assets on Google Drive
- Used Unity for the project itself, and Aseperite for pixel art.
This was a very short project cycle at less than three weeks long, so while I handled production tasks for the team, I had to wear other hats to pull my weight on the project.
I set four dates for external playtesting over the course of the 19 days we had for the game jam. I then assembled a lineup of volunteers for each of those days. Some were new each time, and some returned from previous playtests so we could get a variety of skill levels represented. This allowed us to polish the game and refine our design direction several times during the short project.
I believe this aggressive testing and iteration schedule is what led to our game receiving a judge's choice award, despite the high level of competition on this game jam.

Cursed Crops was my game design capstone project at UCSC. We started as a team of eight, which jumped up to 10 for the last two months of development. The game had a one year development cycle, and by the end of it, we published our game on Itch.io and Steam.

- We used agile project structure, regularly reporting to shareholders and getting their feedback
- We used a virtual kanban board for task tracking and ensuring we were making good time for each sprint
- Ran tri-weekly standups, then assessed what notes or blockers required separate meetings to resolve
I was the producer for the team, although I did also help with writing/editing the game's story, and designing the levels and enemies.
As the producer I managed scrum for the team, planned sprints, and aided in communication between our departments. I also oversaw the QA process for the game, scheduling playtest sessions, and interpreting feedback to make action plans that would help solve the underlying problems identified by our playtesters.

- Used ClickUp for task tracking, and storing design documentation
- Managed a Miro board for creative collaboration, and visual design documentation (such as UI mockups)
- Organized art and sound assets on Google Drive
- Kept files organized in a Google Drive folder for most documentation/backup storage
- Created progress reports and sprint reviews for shareholders in Google Slides
- Created marketing materials by capturing footage with OBS and editing it with Adobe Premiere Pro
- Created a Discord server for communication, collaborative feedback, and to organize fun events to help the team bond
This project was the first major long term project I did production work on. I made a whole lotta mistakes on the project... which made it a very good learning experience! In the end I'm still quite proud of the final product, and the work I did on it though.
I was able to use my background in design to solve several huge bottlenecks that I anticipated for later in production. The solution I'm proudest of came from when I realized our original plans for doing animatic cutscenes were out of scope for our art team. I had to come up with a solution fast, or else we would need to cut the game's story entirely. I knew we would need an in-depth scripted tutorial level due to the relatively complex systems in the game, so I worked closely with my engineer on that project to ensure we could repurpose those scripting tools for our game's cutscenes. By doing this, we were able to choreograph our cutscenes in a way that made them even more fun to read through than our original plan would have been.

From the Pale is a massive solo design project I have been working on for the last several years. It is an expansion for D&D 5e which aims to make the system easier for DMs to run by addressing things like the rest-resource economy which can otherwise break narrative pacing. I made the project into a complete wiki in order to better understand D&D's design language, and to practice designing and iterating on UX for games.
On my portfolio here are two links. The first is a link to the expansion's wiki website. The second is a design showcase for a group of homebrew statblocks I made during the campaign I run. This showcase covers both the design process, and how I iterated on the statblocks after the campaign finished the story arc where they were relevant.
(Project before)

(Project after)

- Used interlinked Google Docs to create the initial source documents for the project
- Created a knowledge base/wiki for the project using Wordpress and the Echo Knowledge base plugin
- Use Roll20 and Foundry for one shots and the campaign respectively
- Cross reference base system style and design language using the D&D 5e Player's Handbook and Dungeon Master's Guide
- Testing specific rules/content balance changes using one shots designed around relevant rules/content (over 25 one shots written so far)
- Longer term balance changes are tested and monitored in a campaign that I've been running for more than five years using these rules
This project has been in the works for years now. I was able to get a lot of experience with playtesting and gathering player feedback for tabletop RPGs when working on this. In both my one shot and campaign testing environments, I've been taking written/verbal feedback on my changes and looking closer to find the core problems I need to address in my work. I have also been tracking KPIs in my notes such as class pickrates/level investment and player resource expenditure/recovery.
Currently, I'm running playtests focusing on the utilization of the new wiki website in order to iterate on the project's UX and sharpen my skills in that field of design. This has been an interesting experience in itself, testing for the usability of a tool rather than the balance/fun of game rules/content, and required I change my approach to asking questions during the playtests, and changed the KPIs I needed to track.

Subspace Shootout was a game made in three weeks for the Big Mode Game Jam 2023. We made top 15 out of nearly 500 submissions by winning a Judge's Choice Award.

I designed the enemies and the power up system for the game, and helped with writing documentation for mechanics my teammates brainstormed.
On this project I also ran our external QA. During this time I took notes on usage rates for the different power ups, and the situations they were being used in. We used this information to quickly iterate on the balance for both enemies and power ups in order to make the game as fun as possible.
Pure design work on game jam projects can often look pretty silly since the short deadline often means you need to get your design documents out the door as fast as possible... even if your visuals on the document were all drawn by mouse in Microsoft Paint. I had to make a lot of these given my role on the project, as both a designer and the producer (leaving me oftentimes as the guy who had to jump in and quickly draft design docs whenever our other designer was busy with art or coding). If nothing else, this project certainly leveled up my skills at Pictionary, since I had to communicate a lot of information quickly, with very subpar drawing skills and drawing tools.

My design philosophy is heavily influenced by my background in production. I look at a project's constraints from the outset (team size/team capabilities, project deadlines, etc), then I think about how I can take advantage of those constraints, rather than simply design around them.
We had the idea to make a game where the player is the pilot of a space ship and must swap between piloting their ship and handling random tasks inside their cockpit in order to keep flying. The initial idea (requiring a 3D flight system, and several minigames to play inside the cockpit at random intervals) was out of scope. I proposed we underscope as much as possible and focus on finding depth through simpler mechanics/systems and the interactions between them.
This turned into the "flight" portion of the game taking on the form of a Galaga-style game. This style of gameplay was much quicker to implement, buying us time to create a handful of enemy variants that could challenge the player in different ways.
The cockpit maintenance minigames were in turn simplified into a unified mechanic of the player being only able to hold/use one item at a time as they interact with stuff inside the ship. We then made it so the two systems in the cockpit (repairing damage and plugging power cores into your upgrade slots) both required the player to bounce between using multiple items to accomplish their tasks. This helped maintain tension for the player even when they were fixing things inside their ship during lulls in the action. Similar to the flight side of the game, this was much quicker to implement than our original plan. This allowed us to put more focus into designing a handful of power ups which all provided different answers to different problems (with some crossover in their use cases, allowing the player to develop their own preferences and style).