Add option to prevent save scum on death

[CodeBandit]

Summary

SUMMARY: Content "New configurable option added under general to disable save scumming on death"

Purpose of change

For players wanting to embrace a more concrete permadeath experience fr their character. If the setting is enabled, there is no turning back the character's death. Though there are ways (such as having a save copy), it's better off to just leave the setting off at that point. It is off by default, and do not affect any existing players unless they choose to turn it on.

Describe the solution

Add a configurable setting (default of false) that deletes your character immediately on death before the memorial displays. This will cause Alt+F4's to be ineffective for save scumming when you die. The setting is added so the permadeath solution isn't forcibly imposed on players that do wish to save scum. It is a single-player game after all, and the players may enjoy the game as they wish.

Describe alternatives you've considered

No setting at all, therefore forcing everyone into this permadeath situation (as was intended).

Testing

Suicide character with the option disabled then alt + F4. Re-open the game, and the character is still there.
Suicide character with the option enabled then alt + F4. Re-open the game, and the character no longer exists.

Additional Notes

Changed from default off to default on as suggested by Night-Pryanik
Changed back from default on to off as pointed out by KorGenT
changed option text and description as pointed out by Arcangelus

[reed501]

I'm not sure we should be making a feature out of force-quitting the game. It's a single player game, maybe there should just be a dialog that lets you either reload your previous save or continue on with your death.

[CodeBandit]

I'm not sure we should be making a feature out of force-quitting the game.

I'm not adding the ability to save scum. In fact, I'm removing the ability to do so with this PR. Players have been save scumming since time immemorial. They can choose to keep doing so by not bothering with the setting, or turn on permadeath as it was intended

It's a single player game, maybe there should just be a dialog that lets you either reload your previous save or continue on with your death.

Permadeath is an intended core feature of the game. Save states and reloading wouldn't pass

[Night-Pryanik]

It is off by default, so players may save scum/reset at their leisure.

The intended game experience is permadeath. We allow people to savescum, but do not encourage it, and allowing savescum by default is going against this position. So I think it's better for your option to be enabled by default.

[AlexanderBodnya]

So let me get the logic straight here. Forceful game process termination is now considered proper game feature? Maybe you also consider starting game process from elevated user, such as TrustedInstaller so player would not be able to terminate game process at all? Also don't forget to add EULA which explains how to play the game 'the right way'.

Adding this feature does not make any sense. People who want to play with permadeath already don't savescum. People who want to savescum - shockingly will savescum anyway. Another checkbox to fill is just more code and interface clutter.

[Night-Pryanik]

Forceful game process termination is now considered proper game feature?

Well, yes. And it was always so, at least from times when "permadeath" term was invented. You die - game over, these are the rules, like it or not.

[AlexanderBodnya]

@Night-Pryanik you seem to not understand my point in this quote. PR author assumes that forceful game process termination, e. g. killing game process with alt f4 combination or via task manager/other means by player is game feature and it should be prohibited.

Second point, about all 'it is the rules' schtick. Every game has manual and ruleset, but no game (except for competitive ones) does not force you to follow the rules. Is CDDA competitive game? We have some tournaments here which I don't know about? This game is for playing or for competing?

Third point again - what is the meaningful change is going to happen? People who don't savescum will not savescum anyway. People who savescum will continue to savescum no matter what.

Fourth point - we had multiple occasions of game breaking bugs which killed characters, look for 0 hitpoint limbs on start, death from one bottle of beer due to 1-seclnd turn etc. Is this seems fair to you, to lose character not because of your actions but because of a bug? You might say, that one should play stable, but stable also has bugs.

[Tamiore]

I'm still not sure what problem is this PR supposed to "fix".
Has any player ever actually had a problem with the fact that you can, if you so desire, savescum?
Also keep in mind that "accidental" deaths happen regularly due to UI-related reasons. (Misclicks, commands buffering without player noticing, etc.)
P. S. Bug-related deaths are also a thing, btw.
P. P. S. One more thing: "legit" deaths rarely happen out of the blue within a single turn. So whoever wants to savescum will just savescum before dying. While majority of effected characters would be those that died "out of the blue": a subset heavily enriched with bug/UI/unintended interaction -related deaths.

[CodeBandit]

@AlexanderBodnya

you seem to not understand my point in this quote. PR author assumes that forceful game process termination, e. g. killing game process with alt f4 combination or via task manager/other means by player is game feature and it should be prohibited.

I assume that it's a game feature? That could be interpreted a few ways, but to summarize, it is NOT intended for the player to alt+F4. You are able to do so anyways, hence this pushes players specifically wanting to follow the intended game design (permadeath).

For your second, third, and fourth points -i'll lump my response in this one. This option is NOT mandatory and NOT forcibly enforced. That's why it's a configurable option. I could have just fixed permadeath and prevented save-scumming altogether. The players who do find save scumming on death a fun way to play could still do so, there are no repercussions to enjoying the game as they wish.

@Tamiore

I'm still not sure what problem is this PR supposed to "fix".
Has any player ever actually had a problem with the fact that you can, if you so desire, savescum?
Also keep in mind that "accidental" deaths happen regularly due to UI-related reasons. (Misclicks, commands buffering without player noticing, etc.)
P. S. Bug-related deaths are also a thing, btw.
P. P. S. One more thing: "legit" deaths rarely happen out of the blue within a single turn. So whoever wants to savescum will just savescum before dying. While majority of effected characters would be those that died "out of the blue": a subset heavily enriched with bug/UI/unintended interaction -related deaths.

The summary of the problem is that you are capable of "reviving" your character when the intended mechanic is permadeath. This option is optional, not mandatory, and not enforced. It is up to the player whether they wish to turn this on or not.

Bug related deaths are a thing, yes. They seldom happen to begin with. I'm not sure what your point is saying characters don't die on a single turn. If people want to save scum, let them. I'm not forcing anyone not to. You mention most characters affected by this would be those that die in a single turn due to "a subset heavily enriched with bug/UI/unintended interaction -related deaths." Would you mind naming a few? As an aside, I could look into fixing those.

[AlexanderBodnya]

Then again, what is the point of adding an option, when the option is already there? To enforce the right way to play? To make save scumming more difficult, because... Reasons? It is like requiring people to jump thrice to buy a bottle of liquor - annoying, but it will not prevent anyone from buying it.

[CodeBandit]

Then again, what is the point of adding an option, when the option is already there? To enforce the right way to play? To make save scumming more difficult, because... Reasons? It is like requiring people to jump thrice to buy a bottle of liquor - annoying, but it will not prevent anyone from buying it.

"To enforce the right way to play", "to make save scumming more difficult" -there is nothing mandatory about this, and nothing is made more difficult? The point is to enforce permadeath for players wanting permadeath enforced; it is an option.

[Tamiore]

You mention most characters affected by this would be those that die in a single turn due to "a subset heavily enriched with bug/UI/unintended interaction -related deaths." Would you mind naming a few? As an aside, I could look into fixing those.

Ca-a-an do. Just to name a few:

1. Commands buffering up (if you press a button again before previous turn has finished processing).
2. Freezing to death without waking up: Fatal tempretures do not interrupt sleep. #39593
3. Holes appearing in vehicles when you turn.

The point is to enforce permadeath for players wanting permadeath enforced; it is an option.

And this is where you lose me.
Because as of right now players who want permadeath enforced already have an option of simply NOT savescumming. It's not like savescum on death happens "naturally" — you have to manually terminate the program to make it happen.

[Arcangelus]

Let me see if I understand this. Currently:

• Permadeath is the intended way of play.
• There are players that like this form of play, and others that don't.
• It's possible to use out-of-game commands (OFGC form now on) to avoid permadeath.
• Nothing in-game informs the player about OFGC "save-scumming"

This PR

• Considers OFGC fair game.
• Makes some forms of OFGC ineffective.
• Said change is optional. (Op out)

Under these conditions:

• Option OFF:

  • People that want to "cheat death" will continue to do so.
  • People that want the "permadeath experience" will accept death and carry on.

• Option ON:

  • People that want to "cheat death" will either NOT choose this or find another way of doing so.
  • People that want the "permadeath experience" will accept death and carry on.
  • Deaths caused by "unaccounted circumstances" such as bugs will be more difficult to track down and reproduce. On principle anyway, as it also depends on the habits of said player and nature of said circumstance.

• By existing:

  • More code
  • More interface options

The only people that MAY benefit from this are those that want to experience permadeath and are too weak willed to actually do so. Is that the intent? Otherwise, I really see no point.

[mrkybe]

The only people that MAY benefit from this are those that want to experience permadeath and are too weak willed to actually do so. Is that the intent? Otherwise, I really see no point.

I feel attacked. But honestly, the will is weakest when staring at the death screen. I think this is a reasonable change.

[CodeBandit]

@Tamiore
In that list you gave, only 1 of them is a valid issue, and that's an issue you personally raised not too long ago (and still not "on a single turn" as you specified). Input buffering therefore you'll die in a single turn? Also, cars having holes wouldn't cause immediate death for no reason either unless the player made some fatal error (drive diagonally next to a zombie hulk which let him magically hop on the vehicle).

@Arcangelus

Let me see if I understand this. Currently:

• Permadeath is the intended way of play.
• There are players that like this form of play, and others that don't.
• It's possible to use out-of-game commands (OFGC form now on) to avoid permadeath.
• Nothing in-game informs the player about OFGC "save-scumming"

This PR

• Considers OFGC fair game.
• Makes some forms of OFGC ineffective.
• Said change is optional. (Op out)

I will humor summarizing "force closing" as "OFGC". That has and always been fair game in games with permadeath mechanics, which this game intentionally has. Nothing in-game informs players about save-scumming, but that doesn't stop players from doing so -this piece of information is irrelevant.

Under these conditions:

• Option OFF:

  • People that want to "cheat death" will continue to do so.
  • People that want the "permadeath experience" will accept death and carry on.

• Option ON:

  • People that want to "cheat death" will either NOT choose this or find another way of doing so.
  • People that want the "permadeath experience" will accept death and carry on.
  • Deaths caused by "unaccounted circumstances" such as bugs will be more difficult to track down and reproduce. On principle anyway, as it also depends on the habits of said player and nature of said circumstance.

Taking this implications approach reads a lot but says too little:
Option OFF:
Absolutely nothing changes for the player.

Option ON:
Fix bug since game's introduction that allows you to cheat permadeath. Re-creating bugs becoming more difficult is a valid concern. However, the files aren't deleted, only relocated to the graveyard so if bug testing really needed to be done it's more than possible.

• By existing:

  • More code
  • More interface options

By existing, more code that will only ever be hit once (on character death) and for insignificant time. More code is irrelevant. For more interface options, you can simply choose to ignore it or configure it for the few seconds it takes to configure.

The only people that MAY benefit from this are those that want to experience permadeath and are too weak willed to actually do so. Is that the intent? Otherwise, I really see no point.

In lieu of becoming to argumentative on this controversial topic, yes that is one of the core intents. Hence, it becoming optional. As Mrkybe put it, "the will is weakest when staring at the death screen".

I feel all that needs to be said constructively has been said (though more constructive discussion is highly encouraged). An option was added instead of a total fix as an in-between for pro and anti perma-death. Whether this PR survives the dice roll that is Closing or merging is up to whoever decides to do so.

[Tamiore]

In that list you gave, only 1 of them is a valid issue, and that's an issue you personally raised not too long ago (and still not "on a single turn" as you specified).

"Single turn" here means "without initiative comings back to the player after the previous action". It may on may not be one in-game second, but if you die after taking a single action — that's effectively death in one turn.

Input buffering therefore you'll die in a single turn?

Yes, easily. For example, you get hit with heavy buffering near a bridge — vehicle flies off that bridge. DED.

Also, cars having holes wouldn't cause immediate death for no reason either unless the player made some fatal error (drive diagonally next to a zombie hulk which let him magically hop on the vehicle.

So you don't see the fact that driving diagonally magically allows zombies to ignore vehicle walls as a bug?

Anyway, at this point this is devolving into pointless semantics.
I gave you three examples of dying after taking (or attempting to take) a single action.
If you want to just hand wave them away as "player not being careful enough to know a proper workaround" — be my guest.

[enaantd]

This PR doesn't bring anything to a player that does not use out-of-game commands.
And I do not see any reason to add code whose only purpose is to control what the player does outside of the game.
If the players want to savescum, they will. If they don't, they won't. There's no need to force them to, and therefore no need for this option.

If I may quote Richard Stallman: "With software there are just two possibilities. Either the users control the program or the program controls the users. The first case is free software."

[CodeBandit]

As I've re-iterated time and time again, and one final time -only the player force themselves to abide by the permadeath rule. If the players want to save scum, they can. Hence, why this is an option (toggle-able, on or off) and not simply globally enforced as the nature of the game would dictate.

Please read the top post fully.

[enaantd]

I've read the top post (and the entire conversation) carefully. Please don't assume what I have read and what I have not. My disagreement does not mean I am poorly or lazily informed.
What I am saying is that, within the boundaries of the game, permadeath is already the rule.
An option (especially one that's on by default) that prevents the user from using out-of-game commands is way out of scope, and this option has no added value to the players that already play "by the rules" anyway.

[CodeBandit]

Originally, default was false so I would be inclined to agree. It was changed to true due to Night-Pryanik's recommendation as he's a member of CleverRaven and I personally view their recommendations with weight.

[Arcangelus]

@mrkybe

I feel attacked. But honestly, the will is weakest when staring at the death screen. I think this is a reasonable change.

You made me laugh. Regardless, point taken.

@CodeBandit

I will humor summarizing "force closing" as "OFGC". That has and always been fair game in games with permadeath mechanics, which this game intentionally has. Nothing in-game informs players about save-scumming, but that doesn't stop players from doing so -this piece of information is irrelevant.

Besides force quitting, I was also including save-file backups, custom scripts, world manipulation, save editing, external programs and a few others. But that's a mouthful, and only 2 of those are "easy" to do. That why I said that only some were rendered ineffective.
Regardless, my point was that you need to go out of your way to do so.

Taking this implications approach reads a lot but says too little:

It seemed a more fair way of expressing my understanding of the consequences rather than just sticking to the differences, in case I was missing something. The act itself qualifies more as a exploit rather than a bug, in my opinion at least, but that may as well be semantics. I'm unfamiliar with how the graveyard works, so I'll take your word for it.

In lieu of becoming to argumentative on this controversial topic, yes that is one of the core intents. Hence, it becoming optional. As Mrkybe put it, "the will is weakest when staring at the death screen".

Fair enough. I apologize if my statement came as dismissive, that was not my intention.

It should be noted that the option itself gives a nod at the possibility of save scumming while the current state does not. This can be considered acknowledgement of save scumming as a supported way of play. You may want to do something about it.

[enaantd]

Indeed, I have seen their comment. If the option is merged, then it would maybe make sense (although arguable) to have it on by default. But my point is that this option should not be merged in the first place, for the reasons mentioned above.

[enaantd]

I understand that this is the core intent, but then I still think it should be off by default. As in, a player will see the option (with a description like "Turn this on if you want to force permadeath") and have the choice to challenge themselves when they feel ready.

[KorGgenT]

1. This option should default to off. The comments on bugs killing the player is 100% valid, and closing the game should not be enforced as deleting your save file if you so choose, unless you toggle some option somewhere.
2. I'm really unsure of the actual utility of having this as an option in the first place. The game has garnered quite a bit of option bloat, and too many options hurt the player experience, rather than helps it.

Fix bug since game's introduction that allows you to cheat permadeath.

I disagree with the premise that this is a bug.

[CodeBandit]

It should be noted that the option itself gives a nod at the possibility of save scumming while the current state does not. This can be considered acknowledgement of save scumming as a supported way of play. You may want to do something about it.

That's a valid point, and should perhaps be changed. I'll look into an alternative to naming and wording conventions on this option

Indeed, I have seen their comment. If the option is merged, then it would maybe make sense (although arguable) to have it on by default. But my point is that this option should not be merged in the first place, for the reasons mentioned above.

I understand there's a dichotomy in this controversial conversation. Both sides have a valid point, and we are not inclined to agree with each other. I believe in some post above, I mentioned this should be left up to the dice roll of closed or merged.

[enaantd]

I believe in some post above, I mentioned this should be left up to the dice roll of closed or merged.

I don't know if I'm missing something (I'm not a native english speaker) but I don't think this decision should be left to chance.

[CodeBandit]

I believe in some post above, I mentioned this should be left up to the dice roll of closed or merged.

I don't know if I'm missing something (I'm not a native english speaker) but I don't think this decision should be left to chance.

It was more of a metaphor to say, "leave it up to the person who actually decides to close or merge this"

[enaantd]

It was more of a metaphor to say, "leave it up to the person who actually decides to close or merge this"

I understand now. However I think that there is more than one person deciding, and they may not all agree which each other, hence the conversation where everybody explains their arguments.

[kevingranade]

A few things.

1. I'm not sure this works, if you skip "move_to_graveyard()" you also skip deleting the file. I'm not 100% there because I haven't had time to either review it in detail or test it, but it looks like it will just leave the player save in the main save directory.
2. I don't like a new option for this, I'm pretty anti-option in general and this one is pretty problematic on top of that. You could mitigate this by folding it into the "WORLD_END" option, which is a superset of this.
3. The default should be "stash the player save in a graveyard". My position on this has been "we neither support nor work to prevent savescumming" for a very long time now, and defaulting to deleting the player save crosses that line.
   3a. I don't want to carry around optional code around cleanup, that crosses the line in the other direction by explicitly changing game functionality based on not enabling the "anti-savescum" option. Stashing the player save is one thing, but not doing cleanup on the basis of "maybe they're going to restore their save" is something else.
4. I don't like the name. One, sticking it in WORLD_END should address this, but it should say what it does, which is "post-death player save handling" or something, not what it's for, which is "try to prevent savescumming".

[reed501]

I don't agree with this PR at all, in my opinion it should be closed and save scumming should be embraced as a valid way to play. But still, if this were going to be included I don't think there should be an option or toggle at all and it should just be on. It's tedious and clutter, and an in-game toggle that allows the use of force-quitting is very unprofessional. Besides, if you want to save scum this isn't really going to change anything, except accidents and bugs will literally kill you now.

[enaantd]

I think a solution would be to have two game "modes".
It already exists in other games (for instance, we can look at Paradox Interactive grand strategy games), where there is a normal mode where you can savescum as much as you want (with save and load buttons in game, namable save files), and also an ironman mode where you're supposed to not savescum, and in which you can get achievements. (Note that in that case people still savescum and achievements can still be obtained this way, in order mainly to not frustrate the player if their save crashes after 30 hours of gameplay.)

It would require some work (I'm not sure how much), but it could be the solution to this situation: have a "fun easy" mode for beginners, debug, or just people who want to kill some easy zombies, and have a "permadeath" mode where people can challenge themselves. This way it gives the players a choice while still promoting the original intent. This could be chosen right before or after selecting which points pool we want to use for instance. It would also make debug easier by having in-game access to namable save files.

[CodeBandit]

@kevingranade

1. from testing, there is no way to skip move_to_graveyard() in this case as it occurs immediately after death and just before the gravestone and text input. If you see it, the save has been moved to the graveyard already.

2. I took a look at folding it into WORLD_END, though it specifies "when last character dies". I can just update that description instead. Defaulting it to off has been committed just before your post.

3. Yes, it just stashes the player's character in the graveyard. No actual deletion is being done here. Before and after functionality in terms of file clean up is preserved.

4. The name and description has been changed just before your post. I will be looking to fold it in WORLD_END and see if that's preferable with the above information

[esotericist]

1. this kind of setting quickly becomes a 'tribalism' pivot, where people start lining up based on whether the option "should" or "should not" be on. i don't want to see that, and i especially don't want to have to deal with it (and the comments on this PR are already edging that way)
2. this is not a comprehensive solution. there are still going to be ways to savescumm (and I'm not actually convinced this works as stated as-is), it just might make it slightly harder/more annoying, without actually preventing it.
3. because of 1. and 2., a partial solution pretending to be a full solution invites more code complexity down the road as people try to "finish" or "fix" it. all the methods i know of for successfully preventing savescumming with any kind of reliability are substantially out of scope of this project, and trying to chase 'as good as we can get' will only translate to more technical and development burden for little to no gain.
4. our development team is predominantly focused on making the game we want to make, which also means being able to approach it as developers, with developers (contributors getting the benefit of being included here). this also means that we spend a lot of time making it easy to get debug information if something goes wrong. if the game ever willfully deletes data, that can result in the loss of potentially vital debug information.

i firmly believe even attempting this is bad for both the game and the community, and there are substantive reasons kevin landed on the 'relocate the save to the graveyard folder' solution years ago. i'm not seeing any compelling arguments to change that stance now.

[esotericist]

as a further note, it was pointed out to me that this is already documented as a space we don't want to pursue.

between that, and my other concerns above, i'm going to close this.

[CodeBandit]

Though I'm unhappy (and biased) to the closing of this issue, since it is well documented that fixing save scumming is not to be done, I will not pursue this issue further. Thank you for linking the documentation @esotericist