7 ms·

I don't buy this at all. This is the antithesis of defensive programming. It's a game-breaking bug that's allowed to happen because of two things: 1. They all

I don't buy this at all. This is the antithesis of defensive programming. It's a game-breaking bug that's allowed to happen because of two things: 1. They allowed companions to take damage because they marked them with the wrong property 2. They never checked if the companions went somewhere silly to warp them back to where they should be That's not defensive, that's like calling an API without a defensive try/catch if something goes unexpectedly wrong. If they'd have done either of these things (and sent back error reports when it happened), they'd have caught it way sooner. I don't write games and appreciate the interactions can be very complex. While I can understand your delight in them finding the root cause, I can't understand your support for failing to put in some defensive measures when they couldn't recreate a frequently reported bug.

gdxhyrd 7y ago
Those defensive measures you describe are the kind of hacks that introduce more and more complexity. Defensive programming is not fixing bugs with more features, quite the opposite: it is failing hard when a condition does not hold.
- johnmaguire2013 7y ago
  Yeah... The whole try/except "in case it throws" without an understanding of IF it should and WHY it might is a huge anti-pattern that creates more bugs down the line than it may potentially solve in the short-term. If it shouldn't throw, don't try to catch... That is an unexpected failure that needs to be understood.
  - Joe-Z 7y ago
    I get so irritated whenever this is brought up as an "additional security measure". Like, guys, we just found the source of the bug and put in some code to fix it. If it fails again it shows we haven't understood it completely and should take another look. Not just throw in a random try-catch where the outcome is that if it fails again it's just that some string won't be rendered in the application anymore or whatever. Could take months before anyone notices and we learn that something basic has been broken all along. Thank you for standing up for confident programming! (We could make this a new term if we wanted to :D) EDIT: Wait, maybe there's a better term than confident programming already... I would appreciate some input if someone sees this.
    - johnmaguire2013 7y ago
      Wikipedia seems to call it "offensive programming": https://en.m.wikipedia.org/wiki/Defensive_programming https://en.m.wikipedia.org/wiki/Defensive_programming
    - shkkmo 7y ago
      There is a third route. You can add a try catch and then throw a more detailed exception (or otherwise automatically surface the issue while not degrading the user experience) showing the context of what failed, then fo attempt to fix a poorly understood bug for which you may have an incomplete set of reproduction circumstances for. The best solution is, as always, context and resource dependant.
  - organsnyder 7y ago
    When I was interning at IBM (~15 years ago now), I saw a bug report closed with "added catch for NullPointerException" as the solution. Something tells me that developer didn't really dig to the bottom of the issue...
  - ufmace 7y ago
    Well it depends on where. For ex: If a request handler in your web server is throwing an exception, it's not a good design for the whole server to go down because you thought it was a bad pattern to catch any exception that handling one request might throw. The whole request should fail, return a 500 to the client, and log exception details for later examination, but shouldn't be allowed to disrupt the rest of the server.
    - rocqua 7y ago
      Thing is, request handlers cross a boundary. Thus, you really should expect them to get malformed input. This means wrapping it in a try catch because 'input might be bad' is a pretty sane thing to do. At the same time, you really should try to validate inputs. The idea being that most exceptions caught should be of the form 'Input was invalid'. Rather than 'function crashed'.
      - ufmace 7y ago
        Well the parent seems to argue for at least only a very specific and limited catch. Perhaps the most common error is, say, invalid JSON. You wouldn't want to catch only the exception for that though. Maybe that's the most common, but who knows what other kind of subtle bugs might be in there. And the rule of thumb is that the web server process should never go down, no matter what kind of weird data you throw at it. That makes that indeed a case of catch everything, log it, and then move on to handle the next request.
        johnmaguire2013 7y ago
        Sorry, I probably wasn't very clear - I'm not arguing that a try/except MUST be very targeted. > without an understanding of IF it should and WHY it might rocqua explains it best - the API handler is an "input" to the overall system. That input may be "invalid" in that it fails to handle its own errors. In that case, you should catch a general exception rather than crashing. In this case, you know that it might raise an error, why it might raise an error, and that it's OK to ignore (well, log/alert/whatever.) The situation I was responding to is very different - it's basically suggesting rather understand what the API you're invoking may be trying to tell you, just try/catch anything it throws and ignore it if you didn't expect it.
- Dylan16807 7y ago
  > Those defensive measures you describe are the kind of hacks that introduce more and more complexity. On the other hand, a system where damage is prevented in some ways and assumed not to happen in others is already an overly complex construction of interacting systems. Switching to an invulnerability flag could simplify the system.
shawnz 7y ago
I think you're right that it would have been a better design if it weren't possible for the companion to die in the first place. But I also agree with the parent that they were right to find the actual cause of their assumptions being violated before deciding how to implement the fix.
AaronFriel 7y ago
> 2. They never checked if the companions went somewhere silly to warp them back to where they should be In a modern open-worldish game, this is pretty nontrivial.
- eropple 7y ago
  This can't be understated. Like, for this particular thing? Yeah, you could say "oh, they're out of range of the ship and that should never happen, warp them back." But you have to have them escape the zone first to know you should do that. And what's the most likely way to do that? Falling out of the world. Not climbing. So there's a good chance you'll miss it even if you thought about it! This is exactly the sort of bug that anybody under the kind of bone-crunching compression you see in game development is gonna fix after they see it. "Don't start bandaging until you bleed."
dvt 7y ago
Not sure why this is getting so aggressively downvoted. A coordinate sanity check on entities is trivial to do, and at the very least should be logged.
- Arwill 7y ago
  Its not just that, but why test quest failure for if the companion is dead, if in principle companions can't die? This is a typical case of game design where lower level engine systems like physics dictate behavior/cause bugs in higher level functionality like the quest system. Game engines do everything every frame by default, and the game has to disable/enable stuff from happening, which leads to bugs like this. With a more functional approach instead of tweaking the engine state these bugs can be avoided.
  - michaelt 7y ago
    > why test quest failure for if the companion is dead, if in principle companions can't die? The game's hardest difficulty setting - "Supernova" - allows companions to die [1] (as well as a bunch of other changes that make the game tougher, not just stronger enemies) [1] https://www.pcgamer.com/uk/which-the-outer-worlds-difficulty-supernova-hard/ https://www.pcgamer.com/uk/which-the-outer-worlds-difficulty...
- meheleventyone 7y ago
  That entirely depends on how complex the set of valid and invalid coordinates is.
  - dvt 7y ago
    A very basic implementation would use a bounding box. This is done quite often in MMO type games to make sure players don't end up outside the map geometry somehow.
    - meheleventyone 7y ago
      As I said it can be easy or hard depending on the complexity of deciding what is valid or invalid. Just because you can think of something very basic doesn’t actually make it applicable to the task at hand.
ergothus 7y ago
> I can't understand your support for failing to put in some defensive measures when they couldn't recreate a frequently reported bug From the tweet series: "There were one or two cases before launch where this issue seemed to happen, but no one in QA ever managed to reproduce it and despite our best efforts we couldn't learn anything concrete about it" Assuming this is true, before launch, it was NOT a frequently reported bug. After launch, they dove in and figured out what was happening AND what triggered it. Your complaint appears to be that they (1) had a bug, and (2) didn't resolve boundary checking in the production code. Given the number of "fall through the map" bugs in countless games, I assume #2 is, in fact, hard. Writing non-trivial code without bugs (to avoid #1) is also hard, based on...all the smart coders I've read. Regardless of the source of the bugs, I'm cheering that they didn't just put in defensive measures and called it a day. To the point that defensive measures can be a source of bugs, consider how many "violent vibration" bugs we've seen in, say, Skyrim, Fallout, and GTA. (While I don't play, based on clips I've seen from GTA and Red Dead, those engine(s) spam duplicate entities when the boundary overlap is detected, where Skyrim/Fallout just vibrate and rattle). I find it very plausible that attempts to "warp" characters having positional bugs without understanding the source of those bugs will end up a source of new bugs.
- Bekwnn 7y ago
  Re: (2), see https://caseymuratori.com/blog_0005 https://caseymuratori.com/blog_0005 to see exactly how difficult it may be
- wruza 7y ago
  >Given the number of "fall through the map" bugs in countless games, I assume #2 is, in fact, hard. Can’t gamedevs reinvent solidness and make underground/walls solid? Viscosity/density/archimedes?
  - natpat 7y ago
    There's lot of great ways to ensure your collision detection is perfect. Sadly none of them run at 60fps.
  - 7y ago
LifeLiverTransp 7y ago
You are wrong, but not downvote worthy wrong. Lets put a artificial cube around the ship, that teleports npcs back to a safe start location (lets call it there bunk). Now you created a whole zoo of new troubles, including a whole set of troubles you cant even predict, because you didnt know about them when you made this giant default behaviour case. if (specific case){ } else (everything else that could ever happen, inlcuding all future edgcases){ // here be dragons } Examples? Leveldesigner adds elevator, that transports player and npc ocassionally outside of the teleport box. Skybox entitys are npcs that live outside of the box- so space battle npcs, get telported to bunks.. etc. etc. Handling the unknown - with any other paradigm then the fail early, fail loud - is the root of evil.
tasubotadas 7y ago
Judging how defensive programming worked out for PHP, I consider it an antipattern.

gdxhyrd 7y ago

Those defensive measures you describe are the kind of hacks that introduce more and more complexity. Defensive programming is not fixing bugs with more features, quite the opposite: it is failing hard when a condition does not hold.

johnmaguire2013 7y ago
Yeah... The whole try/except "in case it throws" without an understanding of IF it should and WHY it might is a huge anti-pattern that creates more bugs down the line than it may potentially solve in the short-term. If it shouldn't throw, don't try to catch... That is an unexpected failure that needs to be understood.
- Joe-Z 7y ago
  I get so irritated whenever this is brought up as an "additional security measure". Like, guys, we just found the source of the bug and put in some code to fix it. If it fails again it shows we haven't understood it completely and should take another look. Not just throw in a random try-catch where the outcome is that if it fails again it's just that some string won't be rendered in the application anymore or whatever. Could take months before anyone notices and we learn that something basic has been broken all along. Thank you for standing up for confident programming! (We could make this a new term if we wanted to :D) EDIT: Wait, maybe there's a better term than confident programming already... I would appreciate some input if someone sees this.
  - johnmaguire2013 7y ago
    Wikipedia seems to call it "offensive programming": https://en.m.wikipedia.org/wiki/Defensive_programming https://en.m.wikipedia.org/wiki/Defensive_programming
  - shkkmo 7y ago
    There is a third route. You can add a try catch and then throw a more detailed exception (or otherwise automatically surface the issue while not degrading the user experience) showing the context of what failed, then fo attempt to fix a poorly understood bug for which you may have an incomplete set of reproduction circumstances for. The best solution is, as always, context and resource dependant.
- organsnyder 7y ago
  When I was interning at IBM (~15 years ago now), I saw a bug report closed with "added catch for NullPointerException" as the solution. Something tells me that developer didn't really dig to the bottom of the issue...
- ufmace 7y ago
  Well it depends on where. For ex: If a request handler in your web server is throwing an exception, it's not a good design for the whole server to go down because you thought it was a bad pattern to catch any exception that handling one request might throw. The whole request should fail, return a 500 to the client, and log exception details for later examination, but shouldn't be allowed to disrupt the rest of the server.
  - rocqua 7y ago
    Thing is, request handlers cross a boundary. Thus, you really should expect them to get malformed input. This means wrapping it in a try catch because 'input might be bad' is a pretty sane thing to do. At the same time, you really should try to validate inputs. The idea being that most exceptions caught should be of the form 'Input was invalid'. Rather than 'function crashed'.
    - ufmace 7y ago
      Well the parent seems to argue for at least only a very specific and limited catch. Perhaps the most common error is, say, invalid JSON. You wouldn't want to catch only the exception for that though. Maybe that's the most common, but who knows what other kind of subtle bugs might be in there. And the rule of thumb is that the web server process should never go down, no matter what kind of weird data you throw at it. That makes that indeed a case of catch everything, log it, and then move on to handle the next request.
      - johnmaguire2013 7y ago
        Sorry, I probably wasn't very clear - I'm not arguing that a try/except MUST be very targeted. > without an understanding of IF it should and WHY it might rocqua explains it best - the API handler is an "input" to the overall system. That input may be "invalid" in that it fails to handle its own errors. In that case, you should catch a general exception rather than crashing. In this case, you know that it might raise an error, why it might raise an error, and that it's OK to ignore (well, log/alert/whatever.) The situation I was responding to is very different - it's basically suggesting rather understand what the API you're invoking may be trying to tell you, just try/catch anything it throws and ignore it if you didn't expect it.
Dylan16807 7y ago
> Those defensive measures you describe are the kind of hacks that introduce more and more complexity. On the other hand, a system where damage is prevented in some ways and assumed not to happen in others is already an overly complex construction of interacting systems. Switching to an invulnerability flag could simplify the system.

shawnz 7y ago

I think you're right that it would have been a better design if it weren't possible for the companion to die in the first place. But I also agree with the parent that they were right to find the actual cause of their assumptions being violated before deciding how to implement the fix.

AaronFriel 7y ago

> 2. They never checked if the companions went somewhere silly to warp them back to where they should be In a modern open-worldish game, this is pretty nontrivial.

eropple 7y ago
This can't be understated. Like, for this particular thing? Yeah, you could say "oh, they're out of range of the ship and that should never happen, warp them back." But you have to have them escape the zone first to know you should do that. And what's the most likely way to do that? Falling out of the world. Not climbing. So there's a good chance you'll miss it even if you thought about it! This is exactly the sort of bug that anybody under the kind of bone-crunching compression you see in game development is gonna fix after they see it. "Don't start bandaging until you bleed."

dvt 7y ago

Not sure why this is getting so aggressively downvoted. A coordinate sanity check on entities is trivial to do, and at the very least should be logged.

Arwill 7y ago
Its not just that, but why test quest failure for if the companion is dead, if in principle companions can't die? This is a typical case of game design where lower level engine systems like physics dictate behavior/cause bugs in higher level functionality like the quest system. Game engines do everything every frame by default, and the game has to disable/enable stuff from happening, which leads to bugs like this. With a more functional approach instead of tweaking the engine state these bugs can be avoided.
- michaelt 7y ago
  > why test quest failure for if the companion is dead, if in principle companions can't die? The game's hardest difficulty setting - "Supernova" - allows companions to die [1] (as well as a bunch of other changes that make the game tougher, not just stronger enemies) [1] https://www.pcgamer.com/uk/which-the-outer-worlds-difficulty-supernova-hard/ https://www.pcgamer.com/uk/which-the-outer-worlds-difficulty...
meheleventyone 7y ago
That entirely depends on how complex the set of valid and invalid coordinates is.
- dvt 7y ago
  A very basic implementation would use a bounding box. This is done quite often in MMO type games to make sure players don't end up outside the map geometry somehow.
  - meheleventyone 7y ago
    As I said it can be easy or hard depending on the complexity of deciding what is valid or invalid. Just because you can think of something very basic doesn’t actually make it applicable to the task at hand.

ergothus 7y ago

> I can't understand your support for failing to put in some defensive measures when they couldn't recreate a frequently reported bug From the tweet series: "There were one or two cases before launch where this issue seemed to happen, but no one in QA ever managed to reproduce it and despite our best efforts we couldn't learn anything concrete about it" Assuming this is true, before launch, it was NOT a frequently reported bug. After launch, they dove in and figured out what was happening AND what triggered it. Your complaint appears to be that they (1) had a bug, and (2) didn't resolve boundary checking in the production code. Given the number of "fall through the map" bugs in countless games, I assume #2 is, in fact, hard. Writing non-trivial code without bugs (to avoid #1) is also hard, based on...all the smart coders I've read. Regardless of the source of the bugs, I'm cheering that they didn't just put in defensive measures and called it a day. To the point that defensive measures can be a source of bugs, consider how many "violent vibration" bugs we've seen in, say, Skyrim, Fallout, and GTA. (While I don't play, based on clips I've seen from GTA and Red Dead, those engine(s) spam duplicate entities when the boundary overlap is detected, where Skyrim/Fallout just vibrate and rattle). I find it very plausible that attempts to "warp" characters having positional bugs without understanding the source of those bugs will end up a source of new bugs.

Bekwnn 7y ago
Re: (2), see https://caseymuratori.com/blog_0005 https://caseymuratori.com/blog_0005 to see exactly how difficult it may be
wruza 7y ago
>Given the number of "fall through the map" bugs in countless games, I assume #2 is, in fact, hard. Can’t gamedevs reinvent solidness and make underground/walls solid? Viscosity/density/archimedes?
- natpat 7y ago
  There's lot of great ways to ensure your collision detection is perfect. Sadly none of them run at 60fps.
- 7y ago

LifeLiverTransp 7y ago

You are wrong, but not downvote worthy wrong. Lets put a artificial cube around the ship, that teleports npcs back to a safe start location (lets call it there bunk). Now you created a whole zoo of new troubles, including a whole set of troubles you cant even predict, because you didnt know about them when you made this giant default behaviour case. if (specific case){ } else (everything else that could ever happen, inlcuding all future edgcases){ // here be dragons } Examples? Leveldesigner adds elevator, that transports player and npc ocassionally outside of the teleport box. Skybox entitys are npcs that live outside of the box- so space battle npcs, get telported to bunks.. etc. etc. Handling the unknown - with any other paradigm then the fail early, fail loud - is the root of evil.

tasubotadas 7y ago

Judging how defensive programming worked out for PHP, I consider it an antipattern.