Anything can be exploited, though. Having save&quit can allow you to save/quit after every node, copy a backup of the save, and replace that every time. Just because someone can go out of their way to exploit something made for convenience for players who don't want to cheat the system (ie to prevent loss in the case of crash, or what seems much more likely to me, a situation like "shit, my laptop battery just died") doesn't mean it harms the game.Ethaniel wrote:Maybe I used an unfair expression (work with me a bit, my english is kind of rusty), I'm not talking about multiples saves in a traditional way: You said yourself "When you die", not "when you're about to die". Anyone can pause the game when the ship has 2 HP left and close the FTL process in an abnormal way (or just press the reset button in an attack of pure frustration), "simulating" a crash. An autosave must be carefully implemented. If the autosave is based on the beacon you're jumping from (Example: You're at beacon A, and you can jump to beacons B or C, but if I jump to B and things go bad, my autosave is still based on beacon A, so I can kill the process, reload that autosave and jump to C instead), it opens a cheating vector and we don't want that. Now, if the autosave is written when you enter a new beacon it would be kind of "safer", but it will force the player to "replay" that beacon again after reloading (in case if the computer crashes after combat, but before jumping). Another option that could help is to purge the autosave immediately after it's used, just like the "Continue" is purged when your ship explodes and start cursing again.
In short, I still believe it defeats the purpose, but I'm not saying no either. I assume it will require some planning, or it could be exploited.
Anyone can use external means to exploit the system - I don't honestly consider those to be something that the developer needs to spend an excessive amount of time/effort to subverting (same reason DRM seems a bit pointless to me); someone will always find a way around it, and in the case of a single-player game, anti-cheat mechanisms provide no benefit to anyone.
Now, adding in-game means to subvert the underlying goal, is an entirely different situation - if they made save archives where you could unwind every jump and replay any node from every jump, then that'd break what they're going for. But from an in-game perspective, deletion-upon-death autosaves don't affect the gameplay whatsoever. All they do is allow you to continue playing the game as you already would have, without being negatively impacted by external events.
Obviously, I highly support this, and hope that in the next new version or two, they're added. Since it's not been addressed by the devs yet, similar to the connection maps before the most recent update, I remain hopeful that it's under consideration.
You're responding to a different topic. This is not about save and restore. This is about autosaves which otherwise work the same way as the save and quit currently does, except replacing it after each node jump (or possibly sector, but I'd personally prefer nodes, as sectors would allow much more unintentional scummery if the autosaves are needed), solely for use in the case of things such as game crash or system failure (such as power loss).Agent_L wrote:Game can't win with save and restore in any other way than prevent saving. Which is pretty much what's done in FTL.