When warning screens tell you not to shut down the game while saving, it refers to turning off the power or other more drastic ways of terminating gameplay.ĪLT+F4 is generally ok to shut down a game.
TL DR: If your game already performs autosaves without corrupting itself, it's safe to assume that there is no risk of corruption in politely asking the game to shut down, (which is what Alt+ F4 does,) even if you do so in the middle of a save.
So one developer checking in code that performs a save on a separate thread would most likely be looked upon with horror by the rest of the dev team! Any competent developer is going to go out of their way to avoid scenarios in which a race condition would pop up. Failing to follow this principle creates race conditions where data gets corrupted and things fail in bizarre ways. This is actually one of the first things anyone learns about multi-threading: never let two threads touch the same data at the same time if one (or both) of them is going to be changing it. If you do this without interrupting the game, it's possible that something can change in between when you start to save and when you finish, and then the save file ends up with some data that refers to the old state of the game and some that refers to the new state, which don't make any sense together, and you now have a corrupted save file. This is because saving means writing out to disc a copy of the state of the game at the moment. So someone might ask, "what if it's saving in a different thread while the WM_CLOSE message comes in and gets processed?" The answer to that question is that any developers who do this, their code is likely to corrupt savefiles left, right and center even without the user requesting a quit at an inopportune moment. This is known as multithreading, running two or more linear "threads" of code execution at the same time. It's always possible to have a computer program doing two things at once. Assuming that the save is taking place in the main thread-which I'll cover a bit further on-the code can't even check the event queue to see that it's been sent a WM_CLOSE message until after saving is complete. So what happens if the user presses Alt+ F4 while the game is in the middle of saving? Keep in mind the first point: processing is linear. (This is a very rude thing to do, but developers occasionally do it.) One of the most common responses is to ask the user "Do you want to save before quitting?" and/or provide a way to cancel the close request.
The program is free to respond to this in whatever way its code says to, including ignoring it entirely.
It tells the program that the user has requested that the program close down the current window. It's a special type of input, nothing more. The first is that the event loop is a linear thing: you don't process event #2 until you're finished processing event #1.Īnd the second is that a WM_CLOSE message does not "quit the program". There are two things to keep in mind here.
At the heart of the code for essentially every program driven by external input, including games, is what's known as an event loop, which checks for input on the event queue, processes it, then repeats the last two steps in a loop forever until it's time to shut down. The event queue, as the name indicates, is a queue of events for the program to process this mostly consists of input from the user.
While it's possible to come up with a hypothetical situation in which pressing Alt+ F4 would corrupt a save in progress, actually doing so would require the developers to quite deliberately go out of their way to screw up the saving system.įrom a coding perspective, the user pressing Alt+ F4 does not "close the active window," nor does it "interrupt the program." What it does is cause Windows to place a WM_CLOSE message onto the program's event queue. As a programmer, both answers posted so far are incorrect.