By: Jason Snyder (jmcsnyder.delete@this.hotmail.com), January 16, 2021 11:45 am
Room: Moderated Discussions
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.
> 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.
