As I've mentioned before, I find it difficult to make a blanket statement like this because programmers can handle saving and exiting logic any way they want. While you could probably say that it is usually safe because programmers usually try to write well-designed code, there is no way you can say it is always safe.

I'm also a programmer, and am very familiar with how simple it is to screw things up. And the vast number of libraries you can code in that handle everything their own way. There is absolutely no guarantee that this is how any game at all handles saving.

I don't know why so many comments were deleted but two that were vaguely critical without presenting any details were left in, giving the vague idea that "oooo, scary magic code can do anything and break in scary magical ways!" That's exactly what I'm debunking here. Code works by very specific rules. You can't interrupt a linear process by events that won't get processed until later. Guaranteed. You can't build concurrent code with race conditions in it, that gets called all the time, without corruption happening. Guaranteed. From these two principles you can extrapolate the rest.

I think the main point is "you can code bad easily" does not directly translate to "you can easily make code that randomly screws up things for no reason". What Ellesedil and Frank said is technically true, but it doesn't translate to this specific scenario as something that can happen easily. Like what Mason said, you have to make your code in a specific designed way for Alt-F4 to corrupt data, which is just utterly stupid for someone to do, but still entirely possible. However, it won't be done by accident.

Have you seen modern games recently? People walk through floors, games crash all the time, and entire sections of the game render incorrectly even after patches. I seriously doubt that they bothered testing whether or not they appropriately handle kill commands when they can't even get a functioning product out the door.

@Nelson you dont have to intentionally put bugs into your code for them to be there. it is entirely possible that something was not handled the way it should be and was not caught in QA. which is why Frank is right, and Ryan's answer is correct and not this one. Just because someone says "trust me im a programmer" doesnt make him correct. similarly, just because something should be handled correctly, doesnt mean it is.

@ChaseSandmann: ALT-F4 is not a "kill command", and geometry glitches are a completely different class of issue than sequential execution/concurrency problems. This is not the sort of bug you can create by mistake. (Can you point out even a single game where it's happened?)

@Dragonrage Yes, a bug like this, that by its nature goes against not only good programming practices but also the easy way to do things, would need to have been intentionally put there! Most bugs that show up on accident come because someone did something the easy way and missed a detail; this is not that type of bug. That's why I said I know because I'm a programmer; if you don't have experience with concurrency, you won't know the difference, but to someone who does, it's obvious.

Can you prove games to prove your statement? You're makeing giant sweeping statements, and provide zero proof to back it up. I, too, am a programmer. You are wrong. Guaranteed. I will be pushing for this answer's deletion, as it is dangerously wrong.

With the amount of libraries, shared code, hobby coders, you name it out there, I find it incredibly hard to believe that code is going to behave exactly the same way over the last twenty+ years. Now might be a different story, and ideally, it'll all work this way. But unless you can prove every game made for PC ever functions exactly like this, I'm not going to believe you. I have too much familiarization with code and Murphy's Law.

@Frank: You're asking me to prove a negative. Knock it off. Provide a single counterexample--demonstrate that this has actually happened, in any Windows game anywhere, ever--or you got nothing.

This is all great and all, the "programmer" stuff... but the question asked about Saints Row itself, and unless you programmed Saints Row, this is a non-answer. The correct answer is "Yes ALT+F4 can and will corrupt save games if it's in the middle of a save - instead you should press the ESC key, then select the game's provided 'Exit' option".

@SnakeDoc: The question wasn't about Saints Row when I answered it; that was edited in later by someone other than the person who asked the question. A quick Google search for "saints row alt-f4 corrupts save files" turns up nothing but references to this page; what are you basing your assertion that it's a real problem on?

@MasonWheeler: I have definitely corrupted save games in the distant past by closing them while they were saving. I can't think of an example in the recent past, but I'm also careful to avoid situations like alt+F4 halfway through saving. That said, many games clearly do their saves asynchronously. Console games are particularly noticeable since they take so long to save, yet many frames are rendered in the mean time. Hopefully, the main thread refuses to shut down until all child threads report completion, but that doesn't mean it can't happen.

@MasonWheeler You are waaaay to confident that all programmers in the world would code the handler exactly how you would. You have no way of knowing how every game is coded to handle this scenario. What if the auto-save process runs in it's own thread, but depends on state from another, and here comes a poorly coded handler routine that just says "halt now!" and crashes the auto-save thread... and there you go, corrupt save.

@SnakeDoc: What if, what if, what if? As I already said, provide an example or you got nothing.

@MasonWheeler That's a straw man argument. Burden of proof is just as much on you as it's on me. You cannot just claim "this way makes sense to me, and therefore everyone does it exactly like this" unless +you+ have proof (which is impossible, given the sheer number of games). If anything, what I have laid out is more correct until further proof is provided. Leaning towards "it can and might" is far safer than saying "it's impossible" based on no evidence. It's far, far easier to do this wrong than it is to do right, and given the general quality of software...

@MichaelS It's possible to generate save data quickly and then hand it off to be saved asynchronously. It's not possible to generate save data while the game engine is still "in motion", not without corrupting your save state (on a regular basis and not just at shutdown), because of the race condition inherent in doing so. That is my argument, and everyone saying "poor programming can magically make this break somehow" keeps ignoring that.

@SnakeDoc: See my answer to MichaelS immediately above. Burden of proof is squarely on your shoulders now.

@MasonWheeler generate save data quickly and then hand it off to be saved asynchronously You don't know that! You can't know that! You are guessing! For all you know, it's writing to the buffer while receiving state! Hell, it could be calculating moon trajectories for all we know. The point is, you are guessing, and being very optimistic. Majority of code isn't so well done as you seem to think.

@SnakeDoc What part of "if it is generating the save state asynchronously then it would necessarily corrupt ordinary autosave data on a regular basis, and if you do not observe this then the problem cannot exist" do you not understand? This is not a guess. If you understand the nature of multithreaded programming and race conditions, this is obvious. If you don't, then you're not qualified to talk about it. If you think I'm wrong, provide a counterexample or go away. Forgive my bluntness, but this is really getting old, and I will flag any further pointless trolling from you.

@MasonWheeler: Right, the data is copied to a safe buffer somewhere inside one frame of the main loop since memory is fast. Then a secondary thread is spawned to save that memory data to file storage over time. If the main loop received a shutdown command and terminated the secondary thread while it was still writing to the file, it could potentially corrupt a save. It should be set up so it doesn't terminate until the secondary thread returns a safe condition, but interrupts take priority over linear execution, so it could happen. And that doesn't require intent, just bad practice.

@MichaelS: ALT-F4 is not an interrupt. ALT-F4 is not an interrupt. ALT-F4 is not an interrupt. ALT-F4 is not an interrupt. ALT-F4 is not an interrupt. How many times do I have to explain this? Program shutdown on Windows requires all threads to finish before it terminates the process. Code could, theoretically, call KillThread(SaveThread); but that's not a mistake that happens by accident; it obviously falls under the heading of "deliberately sabotaging the code," as I mentioned in my answer, as in "this cannot happen unless the developer deliberately sabotages the code."

@MasonWheeler this cannot happen unless the developer deliberately sabotages the code You have got to come back to reality. It's not "sabotage", it's poorly written code. And there's a lot more poorly written code in the world than there is well written code. It is not impossible to screw this up as you claim. You make an enormous amount of assumptions in this thread, none of which are substantiated by real evidence. All we have is anecdotal evidence about what you would do or think is proper. I have flagged your answer for removal because it's downright wrong, dangerous, and misleading.

@MasonWheeler: The keyboard handler often runs on a different thread than the game loop, in which case Alt-F4 actually can function as an interrupt. But I meant the interrupt that tells the save function to stop processing. It's not the best way to program it, but there are plenty of examples on the web of people doing a thread shutdown on all active threads during the "close application" event instead of either waiting for them to automatically end or asking nicely for them to end as soon as it's safe, depending on whether automatic shutdown is expected of that thread.

@Mason: You're the one making the statement. If you're that certain its not possible, prove it. The onus is on you. If you can't, this answer can and should be deleted.

Alternatively, modify your answer to be specific to the game now mentioned. That's about the only way this answer can stand; either narrow it to the specific case, or prove your claims.