Games

Background

Golden Gloves VR is a boxing game created for the Meta Quest series of headsets, made with the goal of bringing a realistic boxing experience “to your living room.” It features multiplayer bouts, physics-enabled bags, and the well-received Fists of Fury minigame. I reached out to the company through a connection of Full Sail and joined the team in summer 2023. I stayed on the team for quite a while until unfortunately being let go due to budget cuts and industry uncertainty in April 2026.

My role

I programmed several features of the game, the most notable being the Fists of Fury minigame, the calorie tracker, and the AI boxer damage textures.

Challenges and solutions

For some months after its initial release, subsequent updates to the Fists of Fury minigame would end up breaking the minigame, because of some hardcoded values I used for object/player positions and rotations. This was especially apparent in the XR version - every position had to have an XR equivalent. Thus, over a period of days when I had some downtime, I updated the Fists of Fury code to use points existing in the scene for object spawning/player teleporting instead of hardcoded values. That way, if adjustments did need to be made, the point in the scene could just be moved around - and if new instances of Fists of Fury had to be put in a new level (as did happen several times), placing was all the designers needed to do.

What went right

• I had to learn VR in a very short amount of time to keep pace with the job and I adapted quickly!
• Fists of Fury, on its release, tripled the game’s active users.
• I learned what it was like to collaborate in a production environment, as well as how to work with artists and musicians up and down the pipeline.
• I learned a lot more about edge cases and anticipating every possible scenario.

What went wrong

Every developer has a “I broke the repository” story, and this is mine: early on, we wished to update the Unity version of the game, and the task fell to me to process the update and make sure nothing broke. I was overzealous and committed the update to the main branch of the repository before opening the project and ensuring everything still worked. Unfortunately, several scripts were broken in the update and our project lead had to spend a day restoring the repository. I’m thankful for his understanding, and I’ve learned to be very careful with Git - to keep my work in separate branches, and to NOT commit anything breaking.

Background

Elemental Defense is my capstone project for my Game Development program at Full Sail University. Created in Unity, it is a tower defense game in which players deploy towers with different elements (fire, water, grass) that attack elemental enemies. To play the game effectively, one must make use of elemental reactions (e.g. fire + grass = burning damage over time) to clear out enemies before they reach the end of the path.

My role

I worked on implementing the elemental effects, the protective totems, and the level hazards.

Challenges and solutions

The game has protective totems that you can buy to protect your turrets from level hazards in a radius around the totem. This was an odd little challenge, as it was entirely possible for a tower to be half-outside the totem’s range and I initially programmed the totems to only protect the towers fully enclosed in its radius. After discussion/playtesting with my teammates and our professor, we realized that such design would feel unfair, so I changed the totem’s programming to protect all the towers in its radius.

What went right

• As mentioned, one of my tasks was implementing the level hazards (exploding volcano in stage 1, storms in stage 2, and tornadoes in stage 3). To make them visually attractive and attention-grabbing, I had to spent a lot of time with Unity’s particle system to fine-tune the appearance of the hazards. I’m pleased with how they turned out, especially the storms and the strobe-light effect of the lightning.
• Integrating the elemental effects with the towers a teammate made went very smoothly because of his approach to assigning towers an elemental type.

What went wrong

There was little playtesting done for balancing; my teammates and I only tested to make sure the game worked. As a result, certain tower setups became extremely powerful, to the point where there was little need to use any other towers. For future games, I will make sure to test with balancing in mind and encourage others to do the same.

Background

Tales of the Tunneler was a game my husband and I made together back when we dreamed of running an indie game studio. We took the mining section of Stardew Valley and expanded it into a full game, complete with ten different biomes, multitudes of enemies, and dozens of collectibles.

My role

I handled all of the programming (including inventory system, enemy AI, and level generation) and some of the static pixel art assets.

Challenges and solutions

One of the hardest things for me to implement was the inventory screen in the hub area. There were two separate inventories: the hub storage, and the player’s inventory which they took with them on each run, and the player could swap items between inventories in the hub. It was a hassle for me to figure out, because I had to keep track of values across two dictionaries, make sure values added/subtracted correctly, and take into account edge cases. The solution to this was perseverance; after much hard work, I had a working inventory system!

What went right

• This was approximately a two year project, and I’m proud of the both of us for sticking with it for the whole duration.
• As development on the game progressed, I noticed an increase in my pixel art skill, and I redid some older sprites. The progress is clear, and I’m very proud of it!

What went wrong

I did not fully understand the concept of class inheritance, so - though all the enemies in the game shared many variables and methods - they still all had their own scripts. This resulted in a lot of unnecessary code and space bloat. Now that I know how inheritance works, if I ever remade this game, the enemies would be handled totally differently.

Background

This game was made with my husband and myself for Game Maker’s Toolkit 2021 game jam. The theme was “join together”; our concept was a spirit warrior that could detach his spirit from his body and fight with either separately or both at once. Each form gives you different strengths and weaknesses (e.g. spirit being able to go through walls; body having more health).

My role

I handled all of the programming for the game, as well as the environment art.

What went right

I’m not super happy with much about this project (see “What went wrong”) but one thing I am proud of is the environment tileset.

What went wrong

I was so focused on making the game look pretty that gameplay fell far to the wayside and as a result, the game turned out not fun at all (and buggy!).

Background

To Appoint a Lord was a self-imposed game jam done by myself and my husband in seven days. “Appoint” was the word we were given for our theme, so we decided to make a game similar to Sort the Court, where you play as someone that is looking to climb ranks by doing favors for the people around you.

My role

I did all of the programming for the game, most notably the petitioning system, and I wrote the different petitions for each rank.

What went right

I like that we implemented a time limit on the game (10 in-game days). It challenges the players to climb the ranks as quickly as possible to reach the top rank before the end of the game (which is actually quite difficult on a first playthrough!)

What went wrong

• Something that happened early on in development was that someone would make a petition right before the day ended, which would result in the game fading to black as the person was still speaking. I was not very familiar with the ins and outs of coroutines so my “solution” was to disallow new petitions an in-game hour before the end of the game day, which could result in the player just sitting there with nothing to do for a few seconds too many. I understand coroutines much better now, and I know that you can stop a coroutine (if you’ve saved a reference to it) and that you can yield return coroutines with boolean conditions using WaitUntil or WaitWhile.
• There are some petitions that you can’t know what the right answer is ahead of time and can get penalized for it (e.g. giving money to someone who is actually a runaway thief). Some could argue it’s about taking chances, but looking at it nowadays, it feels unfair to penalize players for something they can’t know how to respond to.
• There are very few petitions overall so the game gets repetitive really fast, even for a game jam game.