Bugs are kind of the fun part of games. If every subroutine worked perfectly, you wouldn't have the chaos of real life. Some of players favorite mechanics are just bugs. (Overwatch example: Mercy's super jump, now a legitimate predictable mechanic that everyone can do, not just people that read the forums and watch YouTube videos about bugs. It started out as a bug, and it was so cool and skill-ceiling increasing that now it's just part of the game.)
Having said that, sometimes you need unit tests. Overwatch had this bug where there is an ultimate ability called "amplification matrix" that is a window that you shoot through and the bullets do twice as much damage. One patch, that stopped working. This kind of issue is pretty easy to miss in play testing; if you're hitting headshots, then the bullets are doing the 2x damage they would if they were body shots that got properly amplified. If is very hard to tell damage numbers while play testing (as evidenced by how many patches are "we made character X do 1 more damage per bullet", and it smooths things out over the scale of millions of matches, but isn't really that noticeable to players unless breakpoints change). So for this reason, write an integration test where you set up this window thingie, put an enemy behind it, fire a bullet at a known point, and require.Equals(damage, 200). Ya just do it, so you don't ship the bug, make real people lose real MMR, and then have to "git stash" that cool thing you're working on today, check out the release branch, and uncomment the code that makes the amp matrix actually work. Games are just software engineering. Fun software engineering. But it's the same shit that your business logic brothers and sisters are working on.
(Overwatch also had a really neat bug, that the community believes was due to a x == 0 check instead of an x < 0 check. If you pressed the right buttons while using Bastion's ultimate, you had infinite ammo. Normally it fires 3 air strikes, but if you got that counter to decrement twice and skip the == 0 check, then you got to do it an infinite number of times. (Well, actually 2^32 or 2^64 times. Eventually you'd integer overflow and have the chance to hit 0 again. Anyway, this was absolutely hilarious whenever it happened in game. The entire map would turn into a bunch of targets for artillery shells, the noise to alert you of incoming missiles would play 100 times more than normal, and it was total chaos as everyone on your team died. And not even that gamebreaking; both teams have the option to run the same characters, so you could just do it back to your opponent. Very fun, but they fixed the bug quickly.
Follow up follow up: all of these silly bugs are in ultimates, which come up the least often of all abilities in the games. That's what happens with playtesting. You don't get test coverage where you need it. A test you write covers the stuff you're most scared about. A careful engineer that likes testing would have never shipped these.)
> Games are just software engineering. Fun software engineering.
I do question the "fun" part. Midnight crunches, unpaid overtime and - as far as I have read - some of the worst working conditions in all of software engineering. I pass.
I've done both gamedev and webdev professionally. I don't miss the long hours or the low pay of gamedev, but I do miss what I worked on. Enough that I'm still working on my own games in my spare time.
I still play the games I used to work on professionally from time to time, and like to show them off to people, even though none were financially successful (a few I worked on solo were at least popular, but we made some 'bad decisions in hindsight' or got really unlucky with release timing for all the games I worked on professionally).
I don't care hardly at all about all the webdev projects I worked on professionally. They each had some intresting problem solving or coding challenges, and some of them were used WAY more than the games I made were played, but I'm still more into the games I made, and those are most likely to still be around after I'm dead, in a Flash game or ROM archive or torrent somewhere.
Also, the worst long hours I ever had was actually in webdev. I once worked in software for a call center, and whenever the phone systems went down, I was expected to be on a call to help fix it (as there was 100+ call center employees that couldn't make calls and we were losing lots of money every minute they were down), sometimes for 16 hours or more sitting on a Zoom call, mostly waiting for people on the server teams to figure things out. And there was a data center migration that had some unexpected problems and required three of us to work for almost three days straight (I literally worked a 24 hour shift, then had 4 hours of sleep, then worked an 18 hour shift right after it).
But that's not the norm in webdev at least. My current webdev job I only worked >40 hours a couple weeks to rework some issues with some junior dev's code for a feature before a big demo.
That is probably true, but you know you suffer for your art and all that. People don't really like software, but they love games. We know that games are just software, but it's so fun, that people forget that. It's pretty cool. Though to me, I kind of like getting 8 hours of sleep a night and playing other people's games. While getting paid more :/
Having said that, sometimes you need unit tests. Overwatch had this bug where there is an ultimate ability called "amplification matrix" that is a window that you shoot through and the bullets do twice as much damage. One patch, that stopped working. This kind of issue is pretty easy to miss in play testing; if you're hitting headshots, then the bullets are doing the 2x damage they would if they were body shots that got properly amplified. If is very hard to tell damage numbers while play testing (as evidenced by how many patches are "we made character X do 1 more damage per bullet", and it smooths things out over the scale of millions of matches, but isn't really that noticeable to players unless breakpoints change). So for this reason, write an integration test where you set up this window thingie, put an enemy behind it, fire a bullet at a known point, and require.Equals(damage, 200). Ya just do it, so you don't ship the bug, make real people lose real MMR, and then have to "git stash" that cool thing you're working on today, check out the release branch, and uncomment the code that makes the amp matrix actually work. Games are just software engineering. Fun software engineering. But it's the same shit that your business logic brothers and sisters are working on.
(Overwatch also had a really neat bug, that the community believes was due to a x == 0 check instead of an x < 0 check. If you pressed the right buttons while using Bastion's ultimate, you had infinite ammo. Normally it fires 3 air strikes, but if you got that counter to decrement twice and skip the == 0 check, then you got to do it an infinite number of times. (Well, actually 2^32 or 2^64 times. Eventually you'd integer overflow and have the chance to hit 0 again. Anyway, this was absolutely hilarious whenever it happened in game. The entire map would turn into a bunch of targets for artillery shells, the noise to alert you of incoming missiles would play 100 times more than normal, and it was total chaos as everyone on your team died. And not even that gamebreaking; both teams have the option to run the same characters, so you could just do it back to your opponent. Very fun, but they fixed the bug quickly.
Follow up follow up: all of these silly bugs are in ultimates, which come up the least often of all abilities in the games. That's what happens with playtesting. You don't get test coverage where you need it. A test you write covers the stuff you're most scared about. A careful engineer that likes testing would have never shipped these.)