4 ms·

"I know my software just works" is really hubris. The fly-by-the-seat-of-our-pants game industry has cranked up programmers egos and made them ignore a wide ran

"I know my software just works" is really hubris. The fly-by-the-seat-of-our-pants game industry has cranked up programmers egos and made them ignore a wide range of tools and practices that have been proven time and time again to improve developer velocity and reduce defects.

everyone 5y ago
I'm a game dev and imo web-devs are the 'seat-of-our-pants' guys. In games we tend to use compiled and statically typed languages. They're pretty strict in what they allow and many errors are picked up by the IDE and/or prevent your code from even compiling. Whereas javascript.. Your code could be doing almost anything yet it will run just fine. Also, cus its not compiled the IDE for javascript is much much less helpful (eg. theres no "find all references") and much more permissive.
- vvanders 5y ago
  I think it depends on a lot on the studio and culture. I don't think I saw a single unit tests before I left gamedev(a few smoketests to make sure the game didn't crash but that was about it). I also rebuilt our audio streaming system over the course of 48 hours to use the texture streaming subsystem when we exceeded the 64 file handle limit on an certain platform. We needed to hit a date for a TGS demo and I can guarantee you that we had things which were even more YOLO for a fairly decently sized team/game.
  - christophilus 5y ago
    To be honest, the game industry is a good counterpoint to TDD zealotry. You can go quite far with adequate results without a single unit test.
    - gravypod 5y ago
      Some of the most buggy software I interface with are games. They crash and break in strange ways. I often wonder what it would be like if someone tested some edge cases or enabled a fuzzer for some functions. Like "what happens if I kill a freed entity", or "what happens if my character is 50% in a wall", etc. Some of these bugs are experience ruining: think Fallout 76.
userbinator 5y ago
"proven" sounds like cargo-culting dogma. The same was said of OOP in the 90s, and look what that caused. Hence my distrust of the snake-oil. Also, my real-world experience with wading through the abstraction insanity often seen in C++ (and justified because it's "safer") to find and fix bugs, and even more so with the sheer baroqueness of Enterprise Java (arguably an "even safer language"), shows that "reduce defects" is more like a dream. Maybe the number is reduced but when one is found, it tends to be harder to fix. Put another way, I'd rather fix relatively simple C (which also tends to be simpler code in general) than the monsters created by "modern C++" because they thought the "added safety" would mean they could go crazy with the complexity without adding bugs. Perhaps there is some sort of risk compensation going on. The saying "C makes it easy to shoot yourself in the foot; C++ makes it easy to blow the whole leg off" comes to mind.
- gravypod 5y ago
  There's a bug difference between extremely complex c++ templates and std::unique_ptr, std::string_view, and constexpr. Also, I've heard many game devs still saying unit tests either take too long to write or they aren't helpful.
- aliswe 5y ago
  its amazing to read such a contrarian viewpoint, i dont agree but its somehow fresh to read
- maccard 5y ago
  > Put another way, I'd rather fix relatively simple C (which also tends to be simpler code in general) than the monsters created by "modern C++" because they thought the "added safety" would mean they could go crazy with the complexity without adding bugs. It's completely possible to write C++ code without it being a mess of a template mostrosity and massively overloaded function names. People who write C++ like that would write C filled with macros, void pointers and all the other footguns that C encourages you to use instead. I've been working with the sentry-native SDK recently [0] which is a C api. It's full of macros, unclear ownership of pointers (in their callback, _you_ must manually free the random pointer, using the right free method for their type, which isn't type checked), custom functions for working with their types (sentry_free, sentry_free_envelope), opaque data types (everythign is a sentry_value_t created by a custom function - to access the data you have to call the right function not just access the member, and this is a runtime check). See [1] (their C api example). With function overloading and class methods it would be much more readable. [0] https://github.com/getsentry/sentry-native https://github.com/getsentry/sentry-native [1] https://github.com/getsentry/sentry-native/blob/master/examples/example.c https://github.com/getsentry/sentry-native/blob/master/examp...
oreally 5y ago
And on the flip side tech gets Leetcode interviews, shoehorned microservices when you dont need it, slow web browsers. The game industry iterates far faster and the result are programs that can handle far more features than the average tech methodology. It's the classic quantity leads to quality pottery grading experiment. Have you ever considered that these 'best practices' pile on so much unneeded crap that an experienced developer doesn't need?
- kaba0 5y ago
  I would not necessarily say that game development has better quality than web browsers. And the latter are anything but slow — they are engineering marvels no matter what you think of them. It’s just that websites like to utilize it shittily.
  - oreally 5y ago
    There's a lot of games out there, way more than there are web browsers. For a start try comparing games with manpower/dev support levels similar to a web browser like chrome. If we take a AAA open world game, the game somehow gets more features done compared to chrome. There's something that can be learnt there. Also last I heard there was a startup aiming to solve slow browsers by running chrome in a server and streaming a video of the window somewhere. If that's not a setback I don't know what is.
    - kaba0 5y ago
      > There's a lot of games out there, way more than there are web browsers. Maybe this should tell you something about the relative complexity of the two problems. And frankly, features in a game are non-comparable to browser features.
      - oreally 5y ago
        You're missing the point. You can't make such a claim about complexity based off the amount of software there is. Games are by far the more popular software to make. This is why I've narrowed it down for you, hopefully you can understand that. > features in a game are non-comparable to browser features You can't hand-wave this away. I'm certain you need a lot more math knowledge if you want to implement something like physical world. Does a web browser need that?

everyone 5y ago

I'm a game dev and imo web-devs are the 'seat-of-our-pants' guys. In games we tend to use compiled and statically typed languages. They're pretty strict in what they allow and many errors are picked up by the IDE and/or prevent your code from even compiling. Whereas javascript.. Your code could be doing almost anything yet it will run just fine. Also, cus its not compiled the IDE for javascript is much much less helpful (eg. theres no "find all references") and much more permissive.

vvanders 5y ago
I think it depends on a lot on the studio and culture. I don't think I saw a single unit tests before I left gamedev(a few smoketests to make sure the game didn't crash but that was about it). I also rebuilt our audio streaming system over the course of 48 hours to use the texture streaming subsystem when we exceeded the 64 file handle limit on an certain platform. We needed to hit a date for a TGS demo and I can guarantee you that we had things which were even more YOLO for a fairly decently sized team/game.
- christophilus 5y ago
  To be honest, the game industry is a good counterpoint to TDD zealotry. You can go quite far with adequate results without a single unit test.
  - gravypod 5y ago
    Some of the most buggy software I interface with are games. They crash and break in strange ways. I often wonder what it would be like if someone tested some edge cases or enabled a fuzzer for some functions. Like "what happens if I kill a freed entity", or "what happens if my character is 50% in a wall", etc. Some of these bugs are experience ruining: think Fallout 76.

userbinator 5y ago

"proven" sounds like cargo-culting dogma. The same was said of OOP in the 90s, and look what that caused. Hence my distrust of the snake-oil. Also, my real-world experience with wading through the abstraction insanity often seen in C++ (and justified because it's "safer") to find and fix bugs, and even more so with the sheer baroqueness of Enterprise Java (arguably an "even safer language"), shows that "reduce defects" is more like a dream. Maybe the number is reduced but when one is found, it tends to be harder to fix. Put another way, I'd rather fix relatively simple C (which also tends to be simpler code in general) than the monsters created by "modern C++" because they thought the "added safety" would mean they could go crazy with the complexity without adding bugs. Perhaps there is some sort of risk compensation going on. The saying "C makes it easy to shoot yourself in the foot; C++ makes it easy to blow the whole leg off" comes to mind.

gravypod 5y ago
There's a bug difference between extremely complex c++ templates and std::unique_ptr, std::string_view, and constexpr. Also, I've heard many game devs still saying unit tests either take too long to write or they aren't helpful.
aliswe 5y ago
its amazing to read such a contrarian viewpoint, i dont agree but its somehow fresh to read
maccard 5y ago
> Put another way, I'd rather fix relatively simple C (which also tends to be simpler code in general) than the monsters created by "modern C++" because they thought the "added safety" would mean they could go crazy with the complexity without adding bugs. It's completely possible to write C++ code without it being a mess of a template mostrosity and massively overloaded function names. People who write C++ like that would write C filled with macros, void pointers and all the other footguns that C encourages you to use instead. I've been working with the sentry-native SDK recently [0] which is a C api. It's full of macros, unclear ownership of pointers (in their callback, _you_ must manually free the random pointer, using the right free method for their type, which isn't type checked), custom functions for working with their types (sentry_free, sentry_free_envelope), opaque data types (everythign is a sentry_value_t created by a custom function - to access the data you have to call the right function not just access the member, and this is a runtime check). See [1] (their C api example). With function overloading and class methods it would be much more readable. [0] https://github.com/getsentry/sentry-native https://github.com/getsentry/sentry-native [1] https://github.com/getsentry/sentry-native/blob/master/examples/example.c https://github.com/getsentry/sentry-native/blob/master/examp...

oreally 5y ago

And on the flip side tech gets Leetcode interviews, shoehorned microservices when you dont need it, slow web browsers. The game industry iterates far faster and the result are programs that can handle far more features than the average tech methodology. It's the classic quantity leads to quality pottery grading experiment. Have you ever considered that these 'best practices' pile on so much unneeded crap that an experienced developer doesn't need?

kaba0 5y ago
I would not necessarily say that game development has better quality than web browsers. And the latter are anything but slow — they are engineering marvels no matter what you think of them. It’s just that websites like to utilize it shittily.
- oreally 5y ago
  There's a lot of games out there, way more than there are web browsers. For a start try comparing games with manpower/dev support levels similar to a web browser like chrome. If we take a AAA open world game, the game somehow gets more features done compared to chrome. There's something that can be learnt there. Also last I heard there was a startup aiming to solve slow browsers by running chrome in a server and streaming a video of the window somewhere. If that's not a setback I don't know what is.
  - kaba0 5y ago
    > There's a lot of games out there, way more than there are web browsers. Maybe this should tell you something about the relative complexity of the two problems. And frankly, features in a game are non-comparable to browser features.
    - oreally 5y ago
      You're missing the point. You can't make such a claim about complexity based off the amount of software there is. Games are by far the more popular software to make. This is why I've narrowed it down for you, hopefully you can understand that. > features in a game are non-comparable to browser features You can't hand-wave this away. I'm certain you need a lot more math knowledge if you want to implement something like physical world. Does a web browser need that?