Ling and the Corrupted Hollow

May 2025 — December 2025
Lead Programmer
26 Person Team
Unreal Engine 5, C++, Blueprint, PowerShell, Jira

PLAY FOR FREE ON STEAM

Ling and the Corrupted Hollow is a third-person puzzle-platforming game where players use adorable animal spirits to explore the beautiful Hollow Woods. As lead programmer, I was responsible for 6 programmers and collaborated with them as well as my fellow leads and producers to identify and fulfill the technical requirements for the game as its needs evolved.

Build Automation with PowerShell

During production I developed a PowerShell script to automate the various steps of our build process. This involved synchronizing the project files from Perforce, modifying the project’s DefaultGame.ini file to increment the build version number, building the project using the Unreal Automation Tool, uploading the completed build to Steamworks, and archiving the completed build to the local machine in case the Steam upload failed. The script also supported Slack reporting using the Slack API, reporting on each step of the process, notifying me when a build fails, and uploading log files so that errors could be quickly identified and addressed. This script was also utilized by our sibling game, Kila: Hourbound.

You can read more about this sub-project here.

Post-Mortem

Ling and the Corrupted Hollow had a very turbulent development, from pre-production through nearly launch. I had to learn how to identify which parts of the development process I could control and which parts I could not to maintain my own energy.

What Went Right — UI Development

We started working on our UI systems very early in development: about halfway through Pre-Production. We also collaborated with our sibling game, Kila: Hourbound, to share resources and create a common UI template project. I allocated a single programmer to build this template and our other UI systems throughout development, Caleb Won. This initial research payed strong dividends later in the project. By Beta, Caleb was a subject matter expert and was able to mentor others on his systems to help finish localization and the last rounds of polish. This freed up time for us to focus on bug fixes and finalizing features, resulting a highly functional final product.

What Went Wrong — Pre-Production Buy-In

The leads team attempted to identify our teams preferences in an effort to ensure as many people were invested in the development of the game as possible. We performed a few rounds of prototyping and had several group discussions to try and decide on a game concept. These discussions continually ended up revolving around game genre, particularly between platforming and puzzle games. There was a lot of debate about what would or would not be fun. Ultimately the team grabbed onto an aesthetic—navigating a ancient Asian riverside ghost town—and development continued from there.

In retrospect, this approach was very flawed. Most critically, this approach did not identify a fun core mechanic, making it difficult for our programming and design teams to determine a fun gameplay loop. Several features were attempted—stealth, climbing, collecting, among others—but ultimately had to be cut. Our programming team in particular struggled with buy-in on the game concept, and this had knock-on effects throughout the rest of the project.

If given another opportunity, I would’ve had the programming team develop gameplay prototypes in Unreal Engine on their own, so that would could have started from what excited our team. Having testable prototypes also makes it much easier to determine is fun or not, rather than simply discussing hypothetical designs.

Even Better If — More Team Check-Ins

Throughout the project, I found I was most effective as a lead when I could talk with each programmer in my team one-on-one. It made it easier for me to understand their motivations, frustrations, and progress. Regrettably, I didn’t perform nearly as many of these check-ins as I now realize I should have. This caused certain teammates to feel more isolated, and problematic systems to develop under my notice. In the future, I’ll make sure to slow down more often to check in with my team one-on-one.