// Game Programmer
ONE HAND CLAPPING
ABOUT
Company
Primary Role(s)
Game Engine
Project Status
Project Type
Languages
Bad Dream Games
Game Engineer
Unity
Released
Indie
C#
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.
Occasionally, a problem would arise in how the game was incorrectly using the CPU cycles on any given platform. It was my job to analyze how the platforms were processing our threads across the different CPU cores. One example where this was an issue is how we handled microphone recording. On the PS4, I saw that the recording thread for mic input was done only on the first core. I managed to multithread that functionality and saw improvements with performance/input quality.
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.
One particular issue that came up was memory size, both in terms of dynamic allocations at runtime and the total size of the game itself. They were exceedingly large. On lower-end platforms, such as mobile and Switch, this was a serious issue. Some portions of the game would produce "Out of Memory" errors, crashing the game outright. Performance also suffered greatly. I scheduled a meeting with the engineering team to discuss the issue. Having researched the topic, I proposed that using the Addressables system would help cut down memory by grouping static/dynamic content of our game. I was tasked with implementing this system to work with our existing codebase. I collaborated with the creative director and principal game designer to help logically group every scene and asset into these Addressable groups. Lastly, I wrote up a new system to dynamically load scenes or assets depending on what was needed during runtime. As a result, this helped cut down the size of the game by 65% on all platforms! No more "Out of Memory" errors also.
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.