Addition with Flamethrowers (or, Why Game Devs Don't Unit Test)
Every once in a while, I chat with a software dev who's getting into game development. In terms of "programmer culture", one of the bigger differences between software dev and game dev is that software devs make extensive use of automated unit tests and game devs extensively don't. Why doesn’t this important tool get used, asks the software dev?
Left: A software dev’s view of game devs. Right: A game dev's view of software devs.
(Photo credits: Quinn Dombrowski (left) and Rangga Aditya Armien (right))
The problem with games and unit testing is that games are ultimately about being fun, and 'being fun' is not a well-specified domain.
Here's a story. You are on a team implementing a calculator game. You're in charge of 'Addition', and you create an extensive test suite covering all sort of properties of addition over natural numbers. Commutativity. Associativity. Identity. You've even handled all possible floating point weirdness. Good job.
The next day, the game designer meets with you. You’ll have to add in integers, bringing in subtraction and negative numbers. No sweat. You go back, fix the tests that guard against all that negativity. All tests are green.
The next day, the game designer meets with you again. "We took a look over our analytics, and nobody likes using a 5. Our beta testers hate it and moan about it on our Discord. People rage quit when they have to type in 55. We need to change our addition engine so that all 5s are removed."
"Huh?"
"Yeah, just get rid of 'em. All 5s, everywhere. Don't wanna see them anymore."
"What's the answer be to 2 + 3 then?"
"Hmm, good question. Let's make it 6."
You're a bit perplexed as to why, but you go back and dutifully change the code and then all the tests. 5 are now illegal everywhere, and you implement addition in a base-9 system that successfully avoids using the forbidden digit.
5 - the devil’s number.
The next day, the game designer meets with you again. "We had a great idea last night! What if... math was team-based?! We're now going to have red numbers and blue numbers, and they don't play nice together. If you have add two numbers on the same team, then they work normally. If you add two numbers on opposite teams, then the team with the highest score wins!"
"What does that even mean."
"Oh, there's going to be a combat arena. You know, death match, shotguns, sniper rifles, the works. If one team has more kills, then their number will win at addition and eat the other number, doubling in size."
You swear under your breath, but you are thankful you code in a strongly-typed language. You implement colored numbers, change a whole slew of tests, and call it a day.
The next day, the game designer is smiling from ear to ear. "Check this out - we've added in flamethrowers!"
"That's... great?"
"Yeah, they're really awesome! Everyone loves playing with 'em. Of course, now we got to figure out how to handle addition when some of the numbers are on fire...."
It's an exaggeration, but the nature of games means that the assumptions underpinning a mechanic or system can change drastically and unpredictably. Unit tests slide down the cost / benefit continuum. This doesn’t mean that nobody uses them, or that there aren’t systems where they make sense (such as a physics engine or net code, say). In general, though, it means a smaller proportion of game devs use unit tests as compared to other software disciplines.