I always see a signal to not turn of the system while the game is saving. I think I've heard, this is to prevent the game save from becoming corrupted.
Why is this an issue? I'm not entirely sure how this works but shouldn't you make sure the save file is completely written before you overwrite the old one? I don't think I see this problem on cartridge based games.
Of course there's also the possibility that the game is telling you not to turn it off because the game hasn't been saved yet, and if that's the case, eh forget what I've just said.

It is the latter I imagine. I certainly hope they do not overwrite the current save directly, which risks not only the progress made in this session but all previous sessions.

From my experience (with consoles - PS1, PS2 etc.) saving to memory card is REALLY slow. If you power off during the save or pull out the memory card during the save there is a good chance that the save will be corrupted.

It's a right pain to have to support the memory card being pulled out during a save....but it is (or was) a Sony requirement. This is probably true for other hardware manufacturers, Microsoft, Nintendo etc.

The warning text is a platform holder (Nintendo, Sony, Microsoft) requirement.

Why is this question in Game Design...? Is there a design question in this?

Why is this question in Game Design...? Is there a design question in this?[/quote]

But of course! The whole issue deals with design.
- How serious should the text I use be when saving? How much does it need to be enforced?
- Should I use autosave knowing the player could accidentally turn the game off during an autosave? How bad could that it get?
- Should I make clear cut save points so the game doesn't unexpectedly start saving while turning the game off?

Yes, your system should be redundant and fault tolerant. You can't "enforce" anything because your code doesn't bleed into the real world to paralyze player arms or give the power grid stability

-me

Why is this question in Game Design...? Is there a design question in this?

But of course! The whole issue deals with design.
1- How serious should the text I use be when saving? How much does it need to be enforced?
2a- Should I use autosave knowing the player could accidentally turn the game off during an autosave?
2b- How bad could that it get?
3- Should I make clear cut save points so the game doesn't unexpectedly start saving while turning the game off?
[/quote]
1. What text does the platform holder require? (What platform are you designing your game for?)
2a. You should let the player know when you are autosaving. And you should inform the player beforehand that powering down during an autosave is a no-no.
2b. I don't know, what media are you autosaving to? Talk to your lead programmer and ask HIM (or her) this question.
3. That's up to you. Why are you even worrying about this stuff, if you don't have a lead programmer to ask these questions of? Isn't this all a bit more anal than necessary?

I always see a signal to not turn of the system while the game is saving. I think I've heard, this is to prevent the game save from becoming corrupted.
Why is this an issue? I'm not entirely sure how this works but shouldn't you make sure the save file is completely written before you overwrite the old one?

As already mentioned, for console or hand-held games it is usually a requirement for publishing on the platform in question that a specific message be displayed. In cases where this doesn't apply the developer has either chosen to be cautious of their own accord -- either without good cause, or because the target platform is particularly prone to problems -- or may simply have copied this behaviour after seeing it in professionally developed titles.

For your own games:

• You must follow any requirements dictated by your target platforms and/or publisher.
• In the absence of any such requirements or guidelines you may do as you wish -- assess the risk of the player losing progress because of this, as well as how serious such a loss would be, and word any message you choose to display accordingly.
  
  Warning messages aside, the answer to your other question is yes; if it is technically possible to do so on your target platform you should ensure you have written your new save-file to disk successfully before you erase any existing data. Where it is not technically possible to do so you should make your best effort to ensure saves are performed as quickly as possible and that chances of data being lost or corrupted are kept to a minimum.
  
  

  
  - How serious should the text I use be when saving? How much does it need to be enforced?

  
  I assume since you're asking the question that you're not targeting a platform or dealing with a publisher where any such text is a requirement, or you would have been informed of what was needed. You are therefore free to make your own decision. You should consider
  
  • How likely is it that a save file will be lost or damaged?
  • How much progress is likely to be lost if a save file gets messed up?
  • How much will it matter to your average player if they lose some progress?
    
    

    - Should I use autosave knowing the player could accidentally turn the game off during an autosave? How bad could that it get?[/quote]
    Again, this depends on your particular platform -- you can't control everything, and most of the time you can expect a player won't knowingly turn off the game whilst playing. If they do, they might exit the game before doing so (note that on mobile devices they might not do this), allowing you to ensure your saving is completed then. If you're technically able to do so you should take precautions to avoid problems being caused -- don't erase an old save file until a new one is completely written to disk for example.

It's all about the way flash memory works.

Flash memory is subdivided into blocks - on Sony consoles, these blocks are 8KB in size - and can only be accessed on a block-by-block basis (strictly speaking, they can be read on a page-by-page basis, with pages being smaller than blocks). When writing to flash, random data cannot be written; the write signal can change "1" bits to "0", but not the other way around. So in order to write properly, you first need to erase the block, which sets all the bits in it to "1". However, erasing a block puts some wear and tear on it - after enough erases, a block will become unusable.

Because of the slow write speed and physical degradation from erasure, it's therefore important to avoid unnecessary writes. So when overwriting a file, it's overwritten in-place to avoid unneeded writes to the file-allocation table. Some systems, like the PS2, back up blocks to a specific area of the memory card before erasing them, but this only really protects against the card being removed during writing - it's totally useless for preventing save data corruption from powering down during writing. If the card is removed while saving, the game can resume saving after the card is reinserted; but if the system is turned off, that's not possible.

[s]The situation is worse on the original PlayStation, which used a far simpler file system. The 128KB memory card was divided into 16 8KB blocks - 15 of these blocks are usable for game saves, while the remaining block is a table-of-contents block that contains file metadata for every file on the card, including file name, file size, icon, and block allocations. Since most games update the filename with additional identifying information (useful for more clearly identifying save files in the BIOS memory card browser, and possible because PS1 memory card filenames are 32 characters long) and many also change the file's icon each save, these saves also require overwriting the ToC - and since the PS1 has no backup provision, if the card is removed or the system powered down while saving, it's possible to end up with a corrupted ToC, which effectively destroys all data on the card (since the data blocks themselves do not contain the data needed to reconstruct the ToC). At least on other flash-using consoles, interrupting the write process can only corrupt the file being written...[/s] EDIT: Double-checked and actually, the ToC block only stores allocation chain data, so unless a file is being created or resized it generally doesn't get written to.

It's not a major issue with the cartridge-based systems, because they don't generally use flash - normally they use battery-backed SRAM. In most such systems, the SRAM used is accessed as fast as main system RAM is, so saving takes no noticeable time, and turning the system off mid-write is for all intents and purposes impossible. The main exceptions are the Nintendo DS and the Nintendo 64 (though there were a small handful of Genesis/Mega Drive games that used EEPROM), where EEPROM and flash memory are the most common form of non-volatile storage, although some N64 games used battery-backed SRAM. Even then, however, most cartridges that save data, regardless of console, maintain multiple redundant copies of save data to reduce corruption, and in the case of flash memory, they can use smaller quantities of flash with smaller block sizes more suited to a specific game's needs.

It's not a major issue with the cartridge-based systems, because they don't generally use flash - normally they use battery-backed SRAM. In most such systems, the SRAM used is accessed as fast as main system RAM is, so saving takes no noticeable time, and turning the system off mid-write is for all intents and purposes impossible. The main exceptions are the Nintendo DS and the Nintendo 64 (though there were a small handful of Genesis/Mega Drive games that used EEPROM), where EEPROM and flash memory are the most common form of non-volatile storage, although some N64 games used battery-backed SRAM. Even then, however, most cartridges that save data, regardless of console, maintain multiple redundant copies of save data to reduce corruption, and in the case of flash memory, they can use smaller quantities of flash with smaller block sizes more suited to a specific game's needs.

I assume you are referring to recent consoles here, because it was definitely a problem on the Gameboy Color. You can easily duplicate Pokemon in Gold/Silver by deliberately powering off in the middle of a save. Presumably, there was no redundancy due to cost issues back then.