• White LinkedIn Icon
  • White Twitter Icon
  • White Facebook Icon
  • White YouTube Icon
  • Patreon
// Game  Programmer




Primary Role(s)

Game Engine

Project Status

Project Type


Bad Dream Games

Game Engineer





 One Hand Clapping is a 2D platformer that invites you to sing into your microphone to solve musical puzzles and discover the power of your voice as it changes the world.

This exceptionally unique game provides you the freedom to express yourself through its mechanics, helping you build confidence in both your singing voice and the voice within you. Don’t worry about hitting the wrong notes, One Hand Clapping is all about taking risks and learning from your mistakes. Find out just how far your voice can take you!
This was my first full-time position in the gaming industry! Working on One Hand Clapping certainly challenged me in a number of ways, but I proved to myself I could excel in my work at a professional level. This, out of any previous job, required me to put in a substantial amount of time into research and development. As a Game Engineer, my responsibilities were to add support and maintenance for modern platforms (PS4, Xbox One, Nintendo Switch, Android, and IOS). That involved absorbing a gargantuan amount of documentation for each platform, working with platforms-specific plugins, and developing various APIs to assist designers.

Click the buttons below to learn more about my contributions to One Hand Clapping!

The platform-specific features I developed were achievements, touch controls, mic support, haptic feedback, saving/loading, and cloud storage. For each of these features, my goal was to create a easy-to-use API for designers. For instance, to support achievements for each platform, I created a singular abstract class. Derived classes would correspond to each platform, overriding uncommon functions. Using this architecture, Bad Dream Games could then reuse this generic logic in other projects.

One Hand Clapping also released on mobile. I was tasked with creating the basis for functional mobile UI and touch controls. Designing the UI was a very iterative process that had me working closely along side our art director and game designer. Because of the size variability of mobile, I had to accommodate my design to work on all appropriate resolutions and sizes.

Lastly, I organized most of my design ideas through spreadsheets, pseudocode, and class diagrams. This ensured that my code and class structures were clean, comprehensive, modular, easy to read, and allowed for the other engineers on the team to easily review and offer insights into these important systems early on in development.

Testing the game on various platforms allowed me to work hands on with dev kits, which proved very invigorating. Specifically, I worked with the PS4, Switch, and Xbox One dev kits. I also tested on a few different Android and IOS phones/tablets. I created a solid work flow regarding building to the devices, using the appropriate debugging software corresponding to each platform, and testing the game.

Performance optimization on all of these platforms was among my responsibilities. Our target FPS was 60 on all consoles and mid-tier mobile devices, and at least 30 FPS for low-tier mobile devices. With that in mind, I developed a process to help improve frames in expensive areas of the game. My first step was to run a frame counter and play through the game normally. I notated any areas which dipped below our target frame rate. After my playtest, I went into Unity's standard profiler and/or the CPU/GPU software package each platform provides. This was able to tell me whether this particular area was CPU or GPU and the offending code or shader. If it was a code issue, I first discussed the issue with the engineering staff, then proceeded to optimize the logic. If it was a shader issue, I pinged our graphics programmer with a description of the problem.

Regarding memory management, I utilized Unity's memory profiler and each platform's memory analyzer software package. My job here was to ensure no memory leaks or out of memory issues. I also wanted to keep the size of the total memory as small as possible, as we were porting the game to mobile. Most of the optimizations here revolved around texture and asset compression. I setup Unity's Addressables system to systematically label static/dynamic content. This allowed us to compress different assets by group, loading them in at runtime only as needed. As a result of my optimizations, we reduced the total game size by around 70% since I began work on the project.

Because of the COVID-19 pandemic, I was forced to work remotely from home. This allowed me to familiarize myself with various software and tools effective in remote work. For version control, we used Perforce. We followed basic practices to organize and describe different revisions. As development of the project progressed into later stages, we utilized branches to separate different types of project releases.

For issue tracking, we used a combination of ClickUp and Mantis Bug Tracker. ClickUp is very similiar to Jira in terms of adding and distributing tasks. I used it to organize my weekly tasks and determine how long a particular task should take to complete. Mantis Bug Tracker was used by our publisher, Handy Games, to report bugs. I would assign bug reports to me, fix them, and respond in the report. Often, I would write up replication steps and post videos for tricky bugs.

Team communication was handled via Slack and Discord. We used Slack for instant text communication. Discord was used for its more robust video conferencing. Every workday (Mon-Fri), the team hosted standup meetings in the morning. Each member of the team would state what they worked on since the previous meeting and if they had any blocking issues. If needed, additional meetings would be held to discuss more pressing issues with the engineering staff. 1-on-1 meetings occasionally happened between myself and the creative director to discuss my work output and habits.