Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Addition with flamethrowers – why game devs don't unit test

pixelatedplaygrounds.com

Post reply on HN
Print view View original

91–96 of 96 posts

Re: Addition with flamethrowers – why game devs don't unit test

#91

Post by sfn42 »

oefrha wrote: post #36
feoren wrote: post #4

Earlier quoted context omitted.

> Also, remember that games are not very long-lived pieces of software. You build it, release it, maybe patch it, and move on. This was true a couple decades ago. Nowadays many games are cash cows for decades. Path of Exile was released in 2013, Minecraft in 2011, and World of Warcraft in 2004, and all of those continue to receive regular updates (and have over the course of their lives) and still make plenty of mone…

You can add rigor to your decade-plus cash cow later, once it’s clear that you’ve hit the jackpot.

I wonder how many games have been released that could have been jackpots but weren't due to bugs and lack of rigor.

Tests also aren't just about rigor. They don't take years to pay dividends. The time you save just being able to develop and iterate without having to spin up the whole app and manually click through things to test them is huge. Not to mention the time saved hunting down regressions.

Re: Addition with flamethrowers – why game devs don't unit test

#92

Post by sfn42 »

hahn-kev wrote: post #85
Aerroon wrote: post #46

Earlier quoted context omitted.

Perhaps in development, but the stuff that tends to make it into the release of games seems to be gameplay related. Npc behaviors not lining up, the developer literally not implementing certain stats in the game (looking at you, Diablo 4), graphical bugs caused by something not loading or loading too slowly, performance issues from something loading 1000 copies of itself etc.

And where do you think many of those bugs come from? Usually utility code that isn't working in some edge case, those types of things can be easy to pull out and test in their own independent of the game

I don't think I've ever seen someone argue against tests without giving the clear impression that they've never written a test in their life.

Re: Addition with flamethrowers – why game devs don't unit test

#93

Post by neonsunset »

CuriousSkeptic wrote: post #52
mark38848 wrote: post #12

Earlier quoted context omitted.

I think Minecraft was originally written in Java and rewritten in a good programming language (i.e. not Java).

Being written in Java was probably instrumental in enabling the huge modding community around Minecraft. Which in turn was probably in large part responsible for its success.

It should have been written in C#, instead, the developers had to resort to silly optimization tricks that often never transpired.

Re: Addition with flamethrowers – why game devs don't unit test

#94

Post by tmtvl »

cableshaft wrote: post #81
tmtvl wrote: post #69

Earlier quoted context omitted.

Let me guess... Super Metroid? Chrono Trigger? Final Fantasy VI? Ultima Underworld? Symphony of the Night? There were a few decent games released in the '80s and '90s.

The fact that you put Ultima Underworld in the company of those masterpieces makes me think I should probably give that game a shot. I only tried playing one Ultima game a long, long time ago, and I couldn't get into it. I'm guessing that one is a particularly good one, though.

Ultima Underworld is a bit different from the mainline Ultima games. Those are fairly regular RPGs (though I'd say that IV through VII are really good RPGs), but Ultima Underworld is more like an immersive sim. In fact it pretty much created the immersive sim genre. I personally kinda prefer UU2 over UU1, but they're both excellent.

Re: Addition with flamethrowers – why game devs don't unit test

#96

Post by lithos »

shaftway wrote: post #2

I don't buy this argument. Most game developers I know have said that unit tests are a waste of time so they never use them, but they're struggling with making changes to utility code and making sure that it doesn't do the wrong thing. Y'know, what unit tests are for. I think the key here is that the perceived cost / benefit ratio is too high. It's the perception that drives their behavior though. I'm in a company no…

I've set unit tests for functions that are mostly math (base cases of collision, parts of bot predictive logic, and similar).

Though I'm sitting at a hobbyist with electrical and commissioning background.

Post reply on HN