By: Jason Snyder (jmcsnyder.delete@this.hotmail.com), January 16, 2021 12:27 pm
Room: Moderated Discussions
Jason Snyder (jmcsnyder.delete@this.hotmail.com) on January 16, 2021 10:45 am wrote:
> Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 15, 2021 5:26 am wrote:
> > Jason Snyder (jmcsnyder.delete@this.hotmail.com) on January 14, 2021 7:32 am wrote:
> > > Considering the above, if my gaming system does mess up,
> > > just replace the failed part (say bad RAM), re-install
> > > any corrupted games, and I am back up and running as all game state is saved on the cloud.
> >
> > Not if you uploaded corrupted game state to the cloud.
>
> The order of frequency I have seen with problems like this with games where it traces back to memory
> corruption is basically never. Usually the instability happens in the middle of game play and the game
> crashes before getting to a save point. The amount of problem corrupt saved game files causes is either
> you message the game maintainers (I have done this with buggy games that lead to corruption and their
> database getting into a wedged state) and either they fix things right away or you see the fix in a
> subsequent update. Often times in a game you realize you could be doing things a lot better or were
> getting bored with the game anyway, so you either switch over to another game or start a new game entry
> / slot / file. Good online game design checks all input for problems as you have to be on the lookout
> for hackers and so should pick up problems that should break things as you should never trust the end
> user. Trusting the end user means your online game will be hacked and cheated on.
>
> The order of frequency of corruption issues I come across with team software development has varied widely.
> Some years and some outfits have really bad years were corruption happens time and time again and sometimes
> it is an every once in a while thing. Usually you can find and correct the problem, but sometimes when a
> bug ticket gets submitted and I look through the version history, I find the corruption happened some time
> ago and is just getting caught now. Other times you compile and the binary executable is doing weird things
> and it is rather annoying if you eventually trace it down to your system corrupted the executable as you
> compiled it as that is not usually the first thing you look for. Especially when you get into really complex
> code bases doing really important stuff, this is not a problem you want to be dealing with.
Something to consider about game state in memory is usually the game engine is reading and modifying that all of the time as it renders each new frame and is making decisions (often decision making is independent of frame rate, but is still cycling through many times per second). So if bit(s) flip in the game state, it is probably going to get noticed within milliseconds as the game engine reads in an invalid value and segfaults. Especially when the system is running at a high load, this is when you are most likely to see the system glitch up, not when you pause the game to save it. Anyways if something does go wrong with a saved game, either you fall back a saved game file where it is not corrupted, decide you want to start over anyway or just start playing a different game, or the game server refuses to sync and so you just exit the game and go back in. It is a rather common thing in gaming to try something again, so adding in an occasional memory corruption to having to try something again is no big deal. Plus these days game updates are being pushed to your computer all of the time, so if at some point your system was unstable and then you went back and fixed it, a new update will come and fix your problem. If push comes to shove, just de-install and re-install the game. The last time a game seemed 'corrupted' to me, it turned out to be an old config file the game generated a long time ago that was incompatible with the latest update, so not due to memory corruption. With Steam being so prominent for getting games, if things get really bad with your system's stability and then you go back and fix it, you could blow away your whole SSD (doing this on mechanical drives is insanely slow) and then re-download all of your games. This is something that can take a few hours, but then you are up and running again on a stable system.
In gaming this memory corruption issue is more background noise than any problem of significance. It is just as a gamer you want quality code to be pushed to your system in the first place and this lack of quality is really the front and center issue in this arena. I mean you go on the online forums with your problem and find everyone is complaining of the same issue(s) and so know it is a software bug, not memory corruption. It is just when nobody else is complaining of your issue is when you try re-installing the game.
> Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 15, 2021 5:26 am wrote:
> > Jason Snyder (jmcsnyder.delete@this.hotmail.com) on January 14, 2021 7:32 am wrote:
> > > Considering the above, if my gaming system does mess up,
> > > just replace the failed part (say bad RAM), re-install
> > > any corrupted games, and I am back up and running as all game state is saved on the cloud.
> >
> > Not if you uploaded corrupted game state to the cloud.
>
> The order of frequency I have seen with problems like this with games where it traces back to memory
> corruption is basically never. Usually the instability happens in the middle of game play and the game
> crashes before getting to a save point. The amount of problem corrupt saved game files causes is either
> you message the game maintainers (I have done this with buggy games that lead to corruption and their
> database getting into a wedged state) and either they fix things right away or you see the fix in a
> subsequent update. Often times in a game you realize you could be doing things a lot better or were
> getting bored with the game anyway, so you either switch over to another game or start a new game entry
> / slot / file. Good online game design checks all input for problems as you have to be on the lookout
> for hackers and so should pick up problems that should break things as you should never trust the end
> user. Trusting the end user means your online game will be hacked and cheated on.
>
> The order of frequency of corruption issues I come across with team software development has varied widely.
> Some years and some outfits have really bad years were corruption happens time and time again and sometimes
> it is an every once in a while thing. Usually you can find and correct the problem, but sometimes when a
> bug ticket gets submitted and I look through the version history, I find the corruption happened some time
> ago and is just getting caught now. Other times you compile and the binary executable is doing weird things
> and it is rather annoying if you eventually trace it down to your system corrupted the executable as you
> compiled it as that is not usually the first thing you look for. Especially when you get into really complex
> code bases doing really important stuff, this is not a problem you want to be dealing with.
Something to consider about game state in memory is usually the game engine is reading and modifying that all of the time as it renders each new frame and is making decisions (often decision making is independent of frame rate, but is still cycling through many times per second). So if bit(s) flip in the game state, it is probably going to get noticed within milliseconds as the game engine reads in an invalid value and segfaults. Especially when the system is running at a high load, this is when you are most likely to see the system glitch up, not when you pause the game to save it. Anyways if something does go wrong with a saved game, either you fall back a saved game file where it is not corrupted, decide you want to start over anyway or just start playing a different game, or the game server refuses to sync and so you just exit the game and go back in. It is a rather common thing in gaming to try something again, so adding in an occasional memory corruption to having to try something again is no big deal. Plus these days game updates are being pushed to your computer all of the time, so if at some point your system was unstable and then you went back and fixed it, a new update will come and fix your problem. If push comes to shove, just de-install and re-install the game. The last time a game seemed 'corrupted' to me, it turned out to be an old config file the game generated a long time ago that was incompatible with the latest update, so not due to memory corruption. With Steam being so prominent for getting games, if things get really bad with your system's stability and then you go back and fix it, you could blow away your whole SSD (doing this on mechanical drives is insanely slow) and then re-download all of your games. This is something that can take a few hours, but then you are up and running again on a stable system.
In gaming this memory corruption issue is more background noise than any problem of significance. It is just as a gamer you want quality code to be pushed to your system in the first place and this lack of quality is really the front and center issue in this arena. I mean you go on the online forums with your problem and find everyone is complaining of the same issue(s) and so know it is a software bug, not memory corruption. It is just when nobody else is complaining of your issue is when you try re-installing the game.