Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What I’m failing to articulate is that it seems like if you can reliably look ahead to detect a “weird” but technically valid result of the physics engine, you’ve also detected the flaw in the physics engine that led to that result. At that point you should just... fix the bug.

“Let’s monitor in real time for whether any possible combination of inputs could produce a technically valid but undesirable state” doesn’t sound any less complicated or more effective than finding bugs and fixing them.



And yet you still see that approach in the wild. In the game destiny 2, there are a slew of bugs which seem to result in failed assertions, at which point your character suddenly dies. The message which describes what killed you will read "Killed by the architects" as a catch-all. The game has been under development for years and years but somehow the players (and bungie) have come to accept random dying due to physics and netcode bugs. I'll say it's better than an outright crash, but not by a lot.


Huh. It still seems there’s a meaningful difference between “if we’re in a bad state, kill the character instead of trying to recover” and “see a bad state coming in advance and avoid it”, which is what parent proposed.

The Destiny version doesn’t require understanding the bug, only recognizing after the fact that the player has, say, clipped out of bounds. Doesn’t matter how you got there. That sounds like a decent compromise for a pvp game where preventing exploits is very important.

But being able to extrapolate that the current state will lead to a bad state implies that you already understand the bug and could, you know, fix it.


Yes, you're right. My example was not quite the same. Detection of errant state is sort of the starting point, knowing preconditions is a step further in debugging.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: