“Do it right once or you’ll do it again”

Newt’s control scheme and technical debt

Game development rarely progresses as smoothly as you’d like. With deadlines and builds to deliver on, it’s easy to adopt a “good enough” attitude when it comes to building a mechanic or programmed system into your project. A programmer may think “it’s not good, but it works,” and move on just so they can get working on the next part of their prototype. This mindset itself is a trap, however, one that our programming team found ourselves in when it came to out titular character, Newt.

In our initial designs in October of 2021, we decided we wanted to have different camera perspectives for each character. Elena would have a third person, freely controlled camera over her shoulder, and Newt would have his perspective right over his head, playing more into having a small animal’s viewpoint. We did not implement this alternate perspective for Newt until March of 2022. This was largely because the standard third person camera we started with was good enough for our testing of Newt’s mechanics. Time after time we pushed it back, never assigned it, focused on different mechanics, until the camera started behaving badly with Newt’s ability to climb up walls and surfaces. We finally needed to properly implement Newt’s camera and controls. The problem was, we weren’t sure how such a change would disrupt our other systems that relied on that previous movement and camera system.

This is a concept known to programmers as “technical debt”. Simply put, if you do it wrong the first time, you’re going to have to do it again later. Not only that, but the difficulty of rebuilding your solution increases as you add more functions on top of that bad code’s back. The longer you go without fixing a bad foundation, the more you need to pay back in effort when you do. We should have taken time to properly implement our vision of Newt’s control scheme earlier. Because we didn’t, it took a lot more time than it should have to refactor his movement into tank-like controls, and we needed to create an entirely new camera script to achieve our original design, as seen below.

Luckily, the transition between our camera systems was smoother than we anticipated, and at this stage in building the game, the camera is much more robust than our previous iterations. But the pains of stress testing this new control scheme followed us for weeks beyond its initial implementation. We had to rush to finish this core feature with feature complete builds and deadlines on the near horizon. All things considered, we got lucky with only a small amount of extra work as a side effect of the replacement, but this kind of careless building still created a disastrous what-if scenario. The core functionality of one of our two playable characters was riding on this working. It just goes to show that “good enough” is sometimes not enough.

The quote at the top of the article is a bit of parental advice I got growing up, and it continues to ring true as we build this game. Keep in mind that it’s rarely possible to make a perfect character script on the first draft, but that’s not an excuse for leaving in code that you know you’re going to have to rip out and rewrite later. Forward planning and some solid foundational programming save time, effort, and stress on a late night as you try your best to finish off a game build.

Tyler Garcia

Lead Programmer