[mistercow]

I’ve found that the one thing you can always count on engineers to do is to dismiss sensible tools from adjacent domains using flimsy, post hoc justifications.

All product development involves poorly defined boundaries where the product meets the user, where requirements shift frequently, and where the burdens of test maintenance have to be weighed against the benefits.

You don’t throw out all of unit testing because it doesn’t work well for a subset of your code. You throw out all of unit testing because writing tests is annoying, none of your coworkers have set it up, and the rest of your industry doesn’t do it, so you feel justified in not doing it either.

[stouset]

Right. And because the rest of the industry isn’t doing it, there’s no institutional knowledge of how to do it well. So someone tries it, they do a crap job of it out of understandable ignorance, and rather than taking forward any lessons learned the effort is discarded as a waste of time.

[jayd16]

So wait, who's being dismissive of who's practices here?

[mistercow]

I didn’t say engineers are dismissive of other engineers’ practices. The general pattern is “that makes sense for your field, but we can’t use it because…” followed by silly reasons.

I was guilty of this myself back when I was an indie dev. It took me an embarrassingly long time, for example, to admit that git wasn’t just something teams needed to coordinate, and that I should be using it as the sole developer of a project.

[cableshaft]

Version control I think is worth the effort much more than unit testing in games. If you lose your code it's catastrophic. I also used to not use version control in games, just saved extra folders. It took working in webdev for a while for it to click that I should use it for my games, also (and I didn't even start using Github issues for my personal projects until about a year ago, and I've been kicking myself for not doing that earlier, I just kept track in my head what I wanted to work on next for the game and maybe a simple list of planned major features in a text file somewhere).

If you don't unit test something in a game, pretty much the worst you can do in a game is give players a good time for a little while with an infinite money glitch or maybe temporarily block quest progress and annoy them for a bit.

Although large studios get away with the latter all the time, I played Cyberpunk 2077 a year after it was released and it still had a bug that nearly killed my ability to finish a required story mission. A suitcase that was supposed to be on the room table (we referred to it being there in the scene) teleported into the hotel room's entrance and completely blocked my ability to walk through the doorway to continue the mission.

It even stayed there when I quit and reloaded, and I verified that other quite a few other players online were complaining about it at least six months prior so it was a known bug for that long. I eventually accidentally found a work around by waiting for another character in the scene to leave the hotel room and got in front of him and his collision detection apparently trumped the suitcase's collision detection and he was able to push me past the obstacle.

[eviks]

Interesting, was the impetus for change some big issue you've run into? Or just a gradual accumulation of knowledge about other people experiences made you reconsider? Or something else?

[mistercow]

It was a long time ago, but it was probably having to switch from major feature work to emergency bug fixes that finally became painful enough for me to acknowledge that manual backups weren’t going to cut it.