Save Scummming and Extra Lives

Discussion and analysis of graphics, story, levels, and so on.
User avatar
Ceilick
Deputy Administrator
Posts: 402
Joined: Wed Sep 03, 2003 2:35 am

Save Scummming and Extra Lives

Post by Ceilick »

The problem: Extra lives are virtually useless in Keen Galaxy due to the ability to save anywhere, any time.

The goal: Create a system in which extra lives are actually utilized and 'fun'. To cut "save scumming" without motivating the average player to cheat. Cheating includes: codes (god mode, jump cheat, free items) or modifying the patch file.

Currently, what motivates a player to restart a level completely rather than load a save?

1. An area that is or has become impossible to pass.
-A. Due to lack of ammo.
-B. An enemy has become impassable.
-C. An impassable dead end.

2. Something in the level was missed and restarting is easier than backtracking, or backtracking is impossible.
-A. Points and trivial items.
-B. Secret areas.

Currently, what motivates a player to save/load rather than restart a level?

1. Ammo conservation (possibly point and lives as well, 'status' conservation).
2. Repeating difficult or time consuming areas.
-A. Repeating an area, or multiple areas, that have one narrow solution and is basically a slog of save/load just to get past.
3. Repeating what has already been seen and experienced.
4. Desire to progress through the game.

It appears to me that there are three ways to maintain a successful lives mechanic:

1. Make the game easy enough to play without saves.
2. Create more impassable situations where saves can lead to doomed scenarios.
3. Modify the save mechanic.
4. Reward the player for restarting rather than loading. (Note: this reward must be a 'potential reward', not a direct reward; the goal is not to encourage players to die).

------------------

1. Make the game easy enough to play without saves.

Option 1 seems pretty dull, minimizing thrill and exploration. Obviously levels shouldn't be insanely hard, but challenges are necessity, otherwise, again, lives and the ability to die become pointless. Moderate difficulty will help reduce save scumming, but has no relevant effect on making extra lives useful.

2. Create more impassable situations where saves can lead to doomed scenarios.

Option 2 leads to frustration, unfairness, and motivates the player to cheat.

3. Modify the save mechanic.

Option 3 seems viable. Possibilities that come to mind include:

A. Saves can only be made on the world map. (Harsh, probably motivates cheating).

B. A limited number of saves per level. (Is this even possible to patch?)

C. A limited number of saves slots for the game. (Consider being unable to overwrite existing saved games)

D. Saved games reset or reduce the player's ammo and/or points upon loading. (Is this possible to patch?)

E. Saving or loading the game uses up lives. When the player has no more lives, they can no longer save the game (Is this possible to patch?)

F. Players can only save when Keen is located on a special save tile or sprite (Is this possible to patch?)

4. Reward the player for restarting rather than loading. (Note: this reward must be a 'potential reward', not a direct reward; the goal is not to encourage players to die).

Option 4 is technically already in use in Keen, although the reward is weak: players get to keep their points from a level when unsuccesful and may recollect them. I consider this a weak reward because points are ultimately meaningless, granting more lives and in turn more opportunities to rack up points. What are our other options here?

A. The level becomes easier on the next try. (Consider if the difficulty settings were scrapped at the beginning of the game, and instead player's start at hard and levels transition to normal, then easy for each time they retry a level. If player's want to keep it hard, they simply reenter the world map and return to the level, which then resets back to hard mode)

B. The level plays different and players can experience something different. (Different enemies appear in different places, or variations of the level exist in an external file and one is randomly selected)

C. The player gains access to areas not availible on the first life.

D. Somehow make levels more 'fun' than just something to progress through and conquer. More interesting enemies? More interactive elements? What makes a player want to stay in a level?

What are your thoughts? Do any of these sound viable, possible, have problems, detriments? Remember the goal, to create a system in which extra lives are actually utilized and 'fun'. To cut "save scumming" without motivating the average player to cheat.
User avatar
Gridlock
Posts: 71
Joined: Sat Feb 05, 2011 7:04 am

Post by Gridlock »

What a tricky issue this is indeed.

I think a good portion of modern games address this issue by establishing checkpoints. If a player dies, the punishment will only set them back a little, giving them the opportunity to reattempt the section and win properly. A problem with this design, though, is that it often assumes more linear level design. While technically checkpoints could be established every time the player enters a certain area, it works best when a game or levels flows in a segmented manner, with checkpoints set before each segment.

I think something along the line of checkpoints in Keen would be the ideal, but implementing it would be very tricky. In-level saving would be disabled, and instead the player's progress would be saved every time that they reached a checkpoint (perhaps a clever sprite patch could accomplish this). If the player died they would have an additional option of restarting from last checkpoint, at the cost of one life. If all lives run out, the player receives a game over and must restart from any saves made on the world map.

I'm not sure how it could be implemented (especially without a bunch of weird bugs), but I really do think this is the best solution.
User avatar
Dr.Colossus
Posts: 33
Joined: Thu Aug 02, 2012 8:41 pm
Location: Germany

Re: Save Scummming and Extra Lives

Post by Dr.Colossus »

Ceilick wrote: F. Players can only save when Keen is located on a special save tile or sprite (Is this possible to patch?)
Like in Biomenace the "saving-poles"
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

I think something along the line of checkpoints in Keen would be the ideal, but implementing it would be very tricky. In-level saving would be disabled, and instead the player's progress would be saved every time that they reached a checkpoint (perhaps a clever sprite patch could accomplish this). If the player died they would have an additional option of restarting from last checkpoint, at the cost of one life. If all lives run out, the player receives a game over and must restart from any saves made on the world map.
A Lemm-level patch, but certainly doable.

Ammo conservation (possibly point and lives as well, 'status' conservation).


I in fact have a patch that resets ammo along with score on death so ammo conservation is less of a problem. It was going to be in Keen 10, but, eh.

1. Make the game easy enough to play without saves.
This is untenable. Nothing is that easy and players will always use the options they have.

2. Create more impassable situations where saves can lead to doomed scenarios.
There are a few options here.

* Disabling the cheats beyond any possible unpatching. This strong-arms the player and many keeners don't like it (I've tried.) but it's not particularly obtrusive.

* Structuring levels so that the entire level can be done, but many things are missed if saving occurs and a wrong choice is made. This tends to not be too effective once the player finds the correct route but is more 'gentle' and generally considered 'fair'

The problem here is a rather small minded view. Most players will be keeners who are used to the saving mechanic and as such will feel aggrieved if it is taken from them. Players of say, Jazz Jackrabbit would not mind as a limited save system was there from the start.


3. Modify the save mechanic.
Interesting but I myself don't like it.

A. Saves can only be made on the world map. (Harsh, probably motivates cheating).
Hard to do.

B. A limited number of saves per level. (Is this even possible to patch?)
If the 'limited' means that exceeding the limit incurs punishments, yes. (See option 5 below.)

C. A limited number of saves slots for the game. (Consider being unable to overwrite existing saved games)
Very easy. Can be circumvented by deleting old files as the game progresses. Eventually will lead to 'save lock'

D. Saved games reset or reduce the player's ammo and/or points upon loading. (Is this possible to patch?)
See section 5 below.

E. Saving or loading the game uses up lives. When the player has no more lives, they can no longer save the game (Is this possible to patch?)
About as simple as the only-save-on-map idea. Good luck.

F. Players can only save when Keen is located on a special save tile or sprite (Is this possible to patch?)
Going to want Lemm for these I think.

4. Reward the player for restarting rather than loading. (Note: this reward must be a 'potential reward', not a direct reward; the goal is not to encourage players to die).
Wait... isn't this modifying the save mechanic?

A. The level becomes easier on the next try.
WIE currently does this, every five deaths drops the difficulty level by 1, successful level completion will restore difficulty. (Difficulty also varies if special 'difficulty points' are obtained.)

This is nifty but not too much of a game changer I think. The entire point of difficulty levels is to be... difficult.

B. The level plays different and players can experience something different.
WIE does this with difficulty levels (The level is different on E vs M vs H) and in Keen 4 especially it should be possible to rearrange large chunks of the level with some clever Mirage-type patching.

Random spawning of enemy types could be easily implemented so that the enemies you get in one play are different from those you get in the next.

The problem is getting the players to realize this; a player's basic instinct is going to be to play and save and they could miss this mechanic entirely. And the cautious type who save are likely to lack the curiosity to
want to see all possible variations of a level.

C. The player gains access to areas not available on the first life.
Fix'd your spelling. This is a variation of point B above, the same rules apply.

D. Somehow make levels more 'fun' than just something to progress through and conquer. More interesting enemies? More interactive elements? What makes a player want to stay in a level?
This is called 'good mod design'


5.) Punishing saving

This is used by a number of older games where things like score or weapons 'reset' when a saved game is loaded. You put this under 'game mechanic' but seriously now, it is a rich vein of possibilities.

* Clearing score on level completion. WIE uses this but I am thinking of scrapping it. It is a variation of the 'reset score on death' patch. If the player loads from a saved game and completes the level then their score is set to a dummy value (Say 1234) The only way to keep your score then is to play the level through without dying or saving (since dying removes the level's points.)

* Losing a 'no save bonus' This is simple enough to do; if the player completes a level without saving then they receive a point\ammo\life bonus. To do this a variable is set on level entry, the pause window (appearing when a loaded game starts) increments it by 1. (A 'save counter') If it is 0 at level end then a bonus is given. This also counts under section 4 'rewarding the player'

* Saving sends the player back to a check point (Can cause bugs)

* Saving changes enemy behavior to make them more annoying\difficult.

With sprite patching and the 'save counter' we can do any number of things on starting from a saved game. Specifically the scorebox needs to spawn (Or fail to spawn or spawn as a demo sign...) whenever a game (or level) is started. At this point we can insert code to check our save counter (Which can be set earlier by modifying Keen's spawn code.) and do things based on that.
User avatar
Ceilick
Deputy Administrator
Posts: 402
Joined: Wed Sep 03, 2003 2:35 am

Post by Ceilick »

I in fact have a patch that resets ammo along with score on death so ammo conservation is less of a problem.
This really isn't a fix. It removes the ONE potential reward players had for restarting a level rather than loading a save game and swaps in a significantly less useful potential reward.
players will always use the options they have.
This just isn't true. If they don't have to then why would they unless they find saving in and of itself fun.
The problem is getting the players to realize this; a player's basic instinct is going to be to play and save and they could miss this mechanic entirely. And the cautious type who save are likely to lack the curiosity to want to see all possible variations of a level.
This one has to work in hand with a patch that modifies how and when the game can be saved; this feature cannot rely on the player's curiosity to see level variations. The entire significance of a feature like this is to make restarting the level "not so bad", no so old hat, not a repeat of playing exactly the same scenario as the previous life, but something different and 'fun again'. Working with a patch that modifies saving, it's a statement to the player that "You're going to have to replay areas, but we're trying to make that interesting."
This is called 'good mod design'
This is called being a smartass.
5.) Punishing saving
Punishing the act of saving seems viable, but no such punishment you've mentioned seems so harsh as to make restarting a level (and engaging the extra lives system) the lesser of two evils. Any punishment for saving MUST engage the extra lives system.

It seems to me that the loss of player lives should only, ever, be initiated by saved games, and that restarting a level or exiting to the world map shouldn't lower the player's lives. Restarting is 'punishment' enough. Saving/Load remains the ideal for making progress but is limited and tempered, and restarting a level takes longer and involves replay but keeps the player's gear in tact or even builds it up.
User avatar
Ceilick
Deputy Administrator
Posts: 402
Joined: Wed Sep 03, 2003 2:35 am

Post by Ceilick »

Discussing things with Lemm over at #KeenModding:

Code: Select all

(6:54:46 PM) lm: If you make save scumming cost lives, then it's like saying you get so many "convenience tokens"
(6:55:34 PM) Ceilick: but that's as opposed to unlimited tokens
(6:55:47 PM) lm: But since you can just (in theory) play the game indefinitely until you win, then it's like "lives" as you would normalyl think about them don't exist any more
(6:56:13 PM) lm: as a game mechanic anyway
(6:57:08 PM) lm: Now the only exception to this would be is if you design the levels in such a way so that the player can get "trapped" UNLESS he reloads.
(6:57:42 PM) Ceilick: well yes, lives, and deaths, are just inhibitions to the inevitable win
(6:58:05 PM) lm: For instance, if there's only one level left, and he doesn't have any shots, and he needs to stun some creature at the beginning  of the last level
(6:58:36 PM) lm: Then the only way to beat the game would be to reload and go back and get more ammo.
(7:00:08 PM) Ceilick: I understand the situation, but I'm not sure I see the relevance
(7:03:05 PM) lm: Well, if you design the levels in such a way, then what has been turned into a convenience mechanic suddenly becomes a game mechanic again
(7:03:06 PM) Ceilick: I guess you're just saying that's a situation where using a life is necessary
(7:03:14 PM) lm: The difference is now that "saving and loading" becomes part of the game.
(7:03:16 PM) lm: yes
(7:03:38 PM) lm: So judiciously positioning your savefiles becomes important.
(7:03:53 PM) lm: heh
(7:05:49 PM) Ceilick: which would add a strategy element, but seems hard to predict for implementation, and to exist just as a meta game
(7:06:54 PM) Ceilick: which I suppose lives management would be anyway if lives were relevant and payed a necessary function anyway
(7:08:44 PM) Ceilick: but much more incidentally so
(7:10:55 PM) lm: If you're trying to prevent save-scumming, i think that the best thing to do would just be to automatically save the game when the player presses "End Game"
(7:11:47 PM) lm: So that you cannot go back and reload.
(7:11:54 PM) Ceilick: save scumming is really a secondary concern to making extra lives actually interesting
(7:12:03 PM) lm: Hmmm
(7:12:24 PM) lm: maybe there can be two endings then.  If you get through the game without losing all your lives, you get the good ending
(7:12:37 PM) lm: if not, you get the bad ending
(7:12:39 PM) Ceilick: they seemed pretty tied together to me, since the one overcomes the other.  That is a good idea
(7:12:48 PM) lm: Or an asterisk on the high score table or something, heh
(7:12:55 PM) Ceilick: HAHhahaha
(7:13:47 PM) lm: YOu could come up with a different concept for "lives" however.
(7:13:52 PM) Ceilick: I like the idea of needing a certain number of lives to change the outcome of the game, although I feel there should be some immediate affects as well
(7:14:34 PM) lm: Maybe the story is such that keen needs to complete something in a week, so he starts off with seven "days."  If he gets killed, he loses a day
(7:15:17 PM) lm: But if he collects a hundred somethings, or does something else, then he delays the horrible event that he is trying to prevent by one day
(7:15:22 PM) lm: so in essence, he "gains" a life
(7:16:16 PM) lm: http://www.youtube.com/watch?v=KhqIfBIl3RI sort of like Armour geddon
(7:16:18 PM) Ceilick: also meta though, unless having a certain number of lives makes a level different
(7:16:32 PM) lm: You had to prevent the enemy faction from building a giant beam cannon.  You could take actions to prevent this from happening.
(7:16:55 PM) lm: But the game ended when the beam cannon charged up ( you could delay this by knocking out power lines, etc)
(7:18:13 PM) Ceilick: but the delay effect is negated with being able to save/load, unless actually dying isn't what causes the player to lose a life.
(7:19:26 PM) Ceilick: for instance, if a player loses a life for completing levels and MUST hunt extra lives to actually progress the game
(7:19:31 PM) Ceilick: 'unlocking' levels, as it were
(7:19:39 PM) lm: Oh right. That's why you would combine this mechanic by only allowing the player to save the game if he ends it as well.
(7:19:59 PM) lm: Hmm, I see what you mean
(7:22:00 PM) Ceilick: and I'm not sure I'd want to inconvenience players TOO much; having to close and reopen the game.  I don't want to pressure cheating either, and I don't want to disable cheats as a cop out
(7:24:49 PM) lm: yeah cheats should always be there
(7:25:23 PM) lm: No, even closing and reopening the game would not matter.
(7:25:30 PM) Ceilick: I like the unlocking levels idea though.  Perhaps an extra life in the BwB level only accessible at 0 lives so players can't get stuck
(7:26:06 PM) lm: If saving is simultaneous with pressing "end game", then the only way back is to start a new game.
(7:26:29 PM) Ceilick: oohh, i understand now
(7:26:48 PM) Ceilick: wait how do you load then
(7:26:54 PM) lm: Just as you normally would
(7:27:08 PM) lm: You start off wherever you pressed end game.
(7:27:36 PM) Ceilick: isn't that functionally the same
(7:27:45 PM) Ceilick: as the current system, that is, just more pressing enter
(7:28:43 PM) lm: If you're already "in a game" then you can't load a game
(7:29:16 PM) lm: Well, I guess actually you could just close the dosbox and load a game.
(7:29:34 PM) lm: Okay never mind
(7:30:16 PM) lm: Hmm, maybe the game could automatically save every time you die
(7:30:17 PM) Ceilick: haha, I like the thought, but yeah, seems to only change loading while still alive, and just restarting dosbox when dead
(7:30:25 PM) lm: So you have to "select a game slot" before you start a new game.
(7:30:51 PM) lm: Of course you could still quit the dosbox right before you die
(7:31:04 PM) Ceilick: oman, so it overwrites a useful save with a dancing death keen
(7:33:13 PM) lm: Yeah, you could do it this way:  You must select an empty game slot when you start. (You can't just press "new game").  Then, the only times you can save are if you press "End game," or if you die.  If you reload after dying, you respawn on the world map outside of the level where you died.
(7:33:42 PM) lm: I think in the end, it just comes down to the player being honorable.
(7:35:17 PM) Ceilick: This is true, and level design should be honorable to the player in turn, but I feel like the balance should be tilted a bit
(7:36:12 PM) Ceilick: I actually like the idea of saving and reloading at any time, but player death overwrites or deletes the save
(7:36:45 PM) Ceilick: as long as death is well balanced and fair
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Another possibility may be limiting the number of lives Keen can get to a predictable pattern. Then we can have certain immediate (and less immediate) effects based on the number of lives Keen has. So if he's in say, level 3 with the max possible number of lives certain enemies run away instead of chasing you or can't fire.

I have a mechanic (it;s rather complex though) where Keen can 'burn' his lives for temporary invincibility. By pressing the 'K' key Keen activates 'Extra Keen mode' which is in essence god mode (To which enemies will react, the dog for example runs away instead of towards you.) which gives him 10 seconds of invincibility to sprites but not tiles. EKM can be used to move past lethal obstacles and thus avoid detours or to save yourself if you're about to be hit OR to make killing a bunch of enemies easier (Since you don't have to dodge AND shoot.)

It wouldn't be that hard to rework it into a save mechanic; saving in a level would either render EKM unavailable or reset Keen's lives.

And as of Keen 10 saving can also change the game ending depending on how often it's used.

It's also possible to have 'IF' lives that only spawn at certain lives values (And IF items too, I have those!)


Finally it's possible to cause Keen to restart the level if he loads a game from the same level he's in (Map level is the exception.) This means that while games can be saved repeatedly in a level (And thus places where you get stuck and can't die are a no-no) they cannot be restored without restarting Dosbox (Ending the game would not work in this particular setup, the LAST level you were in would still be kept track of.) (There is one workaround, load a different saved game then load your game, but the inconvenience should discourage this.) I'd need something from Leem though to stabilize it.

This really isn't a fix. It removes the ONE potential reward players had for restarting a level rather than loading a save game and swaps in a significantly less useful potential reward.
Indeed, so it has to be part of a wider strategy.

This just isn't true. If they don't have to then why would they unless they find saving in and of itself fun.
Because people are curious and lazy. If there's an easy way to do something then you can bet people will find it in short order. Saving isn't exactly fun, I hate the need to have to say 'Yes I want to restore this game and stop my old one' each time I restore, but it's dammably useful. Same goes with cheats and glitches.

This is called being a smartass.
I try.

But seriously, what exactly would you DO that would be different from well... good mod design? The entire point was rather pointless and vague, akin to saying the solution to being poor is making more money. I assume that making levels engaging and interesting is what you just DO saving or no.

It seems to me that the loss of player lives should only, ever, be initiated by saved games, and that restarting a level or exiting to the world map shouldn't lower the player's lives. Restarting is 'punishment' enough. Saving/Load remains the ideal for making progress but is limited and tempered, and restarting a level takes longer and involves replay but keeps the player's gear in tact or even builds it up.
That would be easy enough to implement.
Benvolio
Posts: 228
Joined: Sun Aug 29, 2004 4:44 pm
Location: Ireland
Contact:

Post by Benvolio »

There is one more passive mechanic that occurred to me during the production of my latest mod (I'm talking Vorticons here). In that mod, you have infinite lives, but set up in a way that the 'next keen at' code clocks up by an increment of one every time you die. In effect, that section counts the number of failed level attempts made. For instance, in my video, it took me 116 attempts to complete the game.

So if it were possible to have that number appear on the High Score table, the world would be aware of the reliance of the player on multiple attempts at a level. Which, of course, is approximately analogous to savegames.

Furthermore an algorithm could conceivable be written which would allow this number to influence one's place in the rankings. Or even whether one was entitled to have a place in the high score table. So if PLAYER X scored say 2000 points with 40 attempts, and PLAYER Y scored 2000 points with 200 attempts, then PLAYER X could be given the higher slot on the high scores table, and PLAYER Y might not even be allowed appear on the high score table.

Perhaps it is possible for the game to count up the usages of save-game just as my mod (the code stolen from others I hasten to add) counted deaths. This is just a thought about how to penalise the player at the level of gaining recognition for their playing quality, rather than to alter the course of the game.

@Levellass: that 'burning lives' thing sounds fascinating and could add an unprecedented dimension of strategy to the game. You should inform KeenRush about it!
User avatar
Ceilick
Deputy Administrator
Posts: 402
Joined: Wed Sep 03, 2003 2:35 am

Post by Ceilick »

I feel it's necessary to revise the goal to clarify things:

The goal: Create a system in which extra lives are actually utilized and 'fun'. Because of the default function of extra lives, their purpose is defeated by "save scumming". If extra lives are fixed in such a way that they retain their default purpose, 'save scumming' must be overcome, without motivating the average player to cheat. Cheating includes: codes (god mode, jump cheat, free items) or modifying the patch file.

If extra lives accomplish something fun and interesting for the game other than the ability to retry after death, modifying the save/load features of the game is really of no concern.

However, we also must remember that if extra lives are treated as a gear item, akin to ammo, save scumming can lurk it's ugly head here as well to defeat this new game mechanic. We must create a mechanic that is relatively safe from being destroyed by another game mechanic.
And as of Keen 10 saving can also change the game ending depending on how often it's used.
Is there a visible counter for games saved, and some way the player can know this? Secret mechanics are like this seem less desirable.
But seriously, what exactly would you DO that would be different from well... good mod design? The entire point was rather pointless and vague, akin to saying the solution to being poor is making more money. I assume that making levels engaging and interesting is what you just DO saving or no.
Good mod/level design is a nebulous and unuseful term. And obviously it has nothing to do with saving, I'm not even sure why you're bringing that up except that it's part of the broader discussion.

It has to do with why a player should want to replay a level again. The 'point' was a question in which I proposed answers;
1. Sprites that are more interesting and fun to deal with, "I want to replay the level so I can engage with X again, not to just get past, but because it was fun".
2. More interactive elements. Switches, goplats, sprites that can be ridden, cool jumps to make, other ideas? "I want to replay this level because it's fun to interact with Y".

This is a point because it simply never happens. Players never say the above things, they say "I don't care about shooting and walking past X again, nothing interesting about doing Y, just a thing to do so I can move on."
So if it were possible to have that number appear on the High Score table, the world would be aware of the reliance of the player on multiple attempts at a level. Which, of course, is approximately analogous to savegames.
While this doesn't necessarily solve anything with extra lives, this is FANTASTIC idea for the highscores table. It adds a hard number which is actually useful in comparing scores and certainly reflects play style and skill. Really like this and it's utterly unobtrusive to gameplay.



[/quote]
levellass
Posts: 3001
Joined: Wed Oct 11, 2006 12:03 pm
Location: Ngaruawahia New Zealand

Post by levellass »

Furthermore an algorithm could conceivable be written which would allow this number to influence one's place in the rankings.
This is tricky territory; how many points would 1 life be worth? The simplest method would be to simply not display any player who takes more than x saves to win the game.

Is there a visible counter for games saved, and some way the player can know this? Secret mechanics are like this seem less desirable.
It's simple enough to insert extra counters into say the status window, if a little tedious to rearrange everything.

It has to do with why a player should want to replay a level again. The 'point' was a question in which I proposed answers;
This is very nearly the same as good mod design. The main difference as I see it is that good mod design makes a player want to play a level once whereas what you suggest is perhaps one of the biggest challenges there is; 'replay value'.

If a mod is designed well then the player WILL want to replay the level just because, because the actual gameplay itself will be fun and interesting. If you have a game where the player always just wants to get things done and move on you have half failed. Look at say TTFOS, the bright colors, the large levels, the tilework... all of these makes me at least enjoy playing it just for playing's sake.

But given what Keen is you are never going to b able to defeat the ease of saving; there will come a point where a whole level's worth of work is undone by a single badly timed jump or annoying enemy. At that point it can be tempting to drop the whole game, save or no. The great thing about saving is it allows you to explore, to risk more. You don't have to bet fifteen minutes of work on being able to get that candy over the spikes, you can save and attempt, safe int he knowledge that your effort has been, quite literally, saved.

Interesting sprites and interactive elements only encourage exploration. 'I want to look everywhere in this level to see all the neat stuff' once that stuff has been seen however it is less interesting and the very exploration you encourage naturally encourages saving.


In the end save scumming is a side-effect; an extension of what saving 'should' be for; it is there to make the game easier and safer. It lowers the cost of failure so players are more eager to take the big risks. As such I think the focus shouldn't be on saving at all but rather on extra lives. Most players will build these up either by saving if bad or good playing if good. Saving renders these much less important than they are in say Keen vorticons and as such we need a way to make them relevant again.
User avatar
CommanderSpleen
Posts: 1017
Joined: Sun Aug 31, 2003 12:11 pm
Location: The Land of Sparkly Things
Contact:

Post by CommanderSpleen »

What about patching the save feature to only work on the world map, or maybe so that it is only available in Easy mode? If anyone's particularly bent on using the in-level save feature, they'll probably figure out how to re-enable it, or use the savestates version of DOSBox. But levellass has a point in saying that it comes down to mod design. Crafting the levels fairly is going to make players more willing to play by your rules.

If you disabled in-level saving, you're now dealing with minimising the motivation to edit the patch file or use save states, both of which require more--at least initial--effort than save/loading. Particularly, as I stated a long time ago in a thread far away, by minimising in-level death penalties when combined with several highly taxing obstacles.

I have tried to do this in OrbKeen. If you fall off a ledge, you're often dropped back to a previous section of the level requiring you to simply rerun that area instead of the entire level. The tank bot freezes you instead of killing you and is often employed in vertical climbing sections.

Paramultart would call this "dumbing down", but it's not too different to Monster Bash with its checkpoint system (also its health bar). There are still plenty of deadly obstacles, but they tend to be separate challenges of their own, or placed in optional bonus areas or places that you're only likely to run into them if you're not paying close enough attention.

One-false-move-and-you-die gauntlet levels are still completely suitable to this paradigm, as long as there aren't too many sticking points or a huge placid build-up at the start and then SUDDENLY GARGS! THOUSANDS OF THEM ALSO LAVA AND NOW YOU HAVE TO GO DO ALL THE BORING STUFF AGAIN AND HOPE YOU"RE STILL AWAKE FOR THAT LAST HURDLE BEFORE THE EXIT

I would also take the neo-Vorticons approach of patching out lives and implementing a per-level score counter that is only added to the global score upon level completion. This leaves the lifewater items free to be used as a bonus system that actually means something. This could be extra points, a secondary high score variable, access to a secret level, etc. Or it could even be used as part of the game structure, with a certain amount of lifewater, scattered throughout many levels, giving you a keycard or item that can't be accessed any other way. (Although this could also lead to a dead-end if you don't collect enough.)

A death counter on the high score table seems pointless to me, as you can simply reload the game every 10 tries. Honest players probably wouldn't end up on the list at all. Then you're back to square one trying to prevent the player from save/loading. It is still useful to have a death counter in the status window, but it can't reliably be used to measure a player's performance.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

This has actually developed into a stimulating topic in actual game theory. I'd like to first recapitulate the problem at hand, and then offer some practical suggestions as to how lives can be used to solve this problem. Ceilick has summarized "the problem," in one sentence, but he has not expounded on *why* it is a problem. In an exercise in creative writing, I've constructed a textual fortification rather than smartly breaking my argument up into digestible chunks like Ceilick did, so I'll try to alleviate my roundabout point-getting-to with questionable attempts at humour, and by emboldening and italicizing the important points.




"Of Save-Scumming"
by Lemm

Part I: The Problem

Why do players save-scum? It is an ignoble action, and certainly not one promoted by any respectable modding community. Yet, it persists in gaming society, in our gaming society. Without inquiring into its root causes, we cannot expect ourselves to formulate effective methods to remove it from our DOS platform-game fraternity. Can we blame the gamer? Well, yes, but let's not go down that route. Should we assume that save-scumming is inextricably linked only to "lives," and that the only way to stamp out save-scumming is to do away with lives altogether, or to modify the lives mechanic? No, and as Ceilick has explicated with a list of situations, and explicitly stated, is that save-scumming, as a form of cheating, stems from "desire to progress through the game," or frustration due to "repeating what has already been seen and experienced (1)." (I am, of course, implying that the player is committed to playing a mod properly, and not just using the cheat codes to peruse the levels to experience the artwork and the music). Let us first ruminate on the ultimate goal of producing a mod.

Consider a simple arcade video game, where there is one princess and only one way to save her. The player of this game doesn't care about graphics, or aesthetic appeal, but only on rescuing the princess from her nefarious captors. A win is a win, but the player only has so many quarters, and if he doesn't think that he can rescue her with his remaining bankroll, then he'll quit and go home. It's unfortunate that the damsel in distress must rely on a contracted mercenary rather than a knight in shining armour, but that's how it goes, sometimes. On the other hand, the video game designer who has imprisoned this fair maiden doesn't care how many points the player scores or how ludicrous the manner by which gibs are eviscerated; the job of the designer is simply to keep the player's attention for as long as possible, because this yields him more quarters from the player's pocket. What is interesting about this situation is that, unlike a tug-of-war where two parties are pitted against each other in a contest with a single victor, the successes of the player and the designer of the video game are not entirely incompatible with one another. True, the player would rather put in as few quarters as possible, but this goal is subsidiary to winning the game. On the other hand, the game designer can consider to have "won" if he empties the player's pocket (or from an operational perspective, if his game is occupied by any player for some minimum fraction of time). If the game designer makes his game too easy or too difficult, he does not obtain the maximum profit. The player will prematurely quit either because he's rescued the princess, or because he doesn't think that he'll be able to beat the game with his remaining bankroll. But they can both win if the player beats the game with his last quarter.

Now as mod designers, we are not heartless capitalists concerned solely about financial gain, and we actually would prefer our clientele to enjoy themselves, reach the end of the mod, and publicize their approbations on the PCKF, Youtube, or elsewhere. But, like the arcade game maker, we still want to maximize the time that our player spends on our game, even if it doesn't cost him a single dime, because it vindicates our decision of having spent time to create the mod. If the player spends all of *his* free time on our mod for the rest of his existence, then we have completely achieved our goal by having accumulated the maximal profit in time-spending, (albeit through ruining the player's life). We don't want our player to quit out of boredom or frustration, so we must design our game to beguile him into playing longer. Because mods are more sophisticated than the exemplified arcade game, we can provide aesthetic or other ambient appeal to win the player's attention. To put it simply, *we want to retain the player for as long as we can, and he wants to beat the game.* He will keep playing so long as his mood is positive, and if he does not believe that he can beat the game without becoming frustrated, he will quit.

This is all rather obvious, but what does any of it have to do with save-scumming? If our sole concern is mesmerizing the player with our creation, what business is it of ours to dictate how he should be dazzled? The response, of course, is that we are compassionate game developers. We are concerned with more than just pushing our product; we desire that it should be consumed responsibly as well. We want our creation to be experienced in a certain way, from start to finish without interruption. If a player has save-scummed, then he has been lost. For all intents and purposes, he has stopped playing the mod. He has stopped feeding us his quarters of time-spentedness. To play the mod improperly is not to play it at all. Platitudinous et cetera.

But, then, if the player is save scumming, he is no longer playing our game. So, should we not concern ourselves with save-scumming? The approach should not be to dissuade save-scumming, but to design the game so that the player keeps playing. Referring to Ceilick's tenants that save-scumming is usually due to one of several reasons, we rewrite it to state that "quitting the game is usually due" to one of these reasons. In other words, there is no save-scumming, there is only quitting.


In conclusion:

1. The modder wishes to engage his audience for as long as possible.
2. The player will keep playing as long as he believes he can beat the game without becoming excessively frustrated.
3. Save-scumming is tantamount to quitting.



Part II: It wasn't a problem in the first place

By combining the three conclusive statements from Part I, we establish the basis for Part II:

The modder must design his game so that he can maintain the player in a state of perpetual optimism, otherwise the player will quit.

(This is a very important concept so I've made it slightly larger than normal, even though you're not really allowed to do that in serious writing. And I've turned it into a single-sentence paragraph. Anyway.) Again, we're not thinking about save-scumming anymore, because by assuming it does not exist, and focusing on how we can coerce the player to play properly, we will ultimately lower its rate of incidence. We are now thinking in terms of an optimism balance.

This is all rather counterintuitive, so let's revisit the simple arcade game from Part I, now considering the player's perspective. He will keep playing until he's reached his goal, or until he believes that he cannot continue, and this decision will occur (repeatedly) when he has to decide to put more money in. The player is constantly evaluating whether or not he should keep playing, particularly after he loses all of his lives and is faced with the decision to continue. Remembering that the basis for keeping him feeding metaphorical quarters into our machine is perpetual optimism, what would motivate him to keep playing?

It's no longer advisable to strictly adhere to the economic model presented in Part I of the simple arcade game. This model featured a mechanical gamer who was concerned with a single, well-defined goal and who would quit at a calculable point when his odds for winning turned unfavourable. Before moving away, two key points should resonate:

1. The player is not going to quit as soon as he gets frustrated. This would be like the arcade gamer quitting as soon as he put the first quarter into the machine. No, he will quit when he believes that he will become terminally frustrated (or morally bankrupt) before he can complete the game.

2. The arcade gamer was evaluating if he should continue every time he added a quarter. The mod player can become terminally frustrated, however, at any point. This will usually be after deaths, for they provide the greatest source of frustration, but perpetual annoyance could conceivably occur after missing a bonus, for example.



Part III: Well I don't really want to write anymore at the moment, so I'll just cut to the chase.

The point I am trying to get at, though, is to think of "frustration" holistically, because save-scumming is a manifestation of frustration. And, you might need to accept that the default keen galaxy model lends itself to heavy save-scum abuse, and that you might need to radically rethink the paradigm to discourage such abuse.



Anyway, since you asked for suggestions on how extra lives could be used, I'll provide some so you can't accuse me of highjacking your thread. Ha!


Probabilistic instead of Definite Failure
In contrast to the definite mechanisms that have been discussed in this thread, you could use the number of deaths accrued to probabilistically affect the game's outcome. By always offering the player the chance of attaining his goal, even if the odds are not in his favour, you're more likely to retain his interest. The same principle is observed when a poker player vacillates between calling and folding. Although he might not be favoured to win the hand, he may have already invested so much money in the pot, (or by analogy, time in the game), that folding is an unwise move, and he is compelled to play to the end. Here are two ways in which you could "goad" the player into playing longer.


A. The Pot-of-Gold

Always offer the player the chance to complete the game, with the probability of achieving the best outcome diminishing as deaths increase.

B. The Pursuant Boulder
Always threaten the player with immediate defeat, with the probability of failure increasing as deaths increase past some minimum threshold value.[/i]



Make the game quick
On the other hand, you could just make the game quick. Star Fox (before it went total furry) never had any save capability. Instead, there was a goal (hop from planet-to-planet to defeat the final boss), and there were many routes by which one could arrive at the lair of the boss. You could never play all of the planets in one game, but each game was short (lasting less than an hour). Consequently, there was no NEED to even save the game, because you could just try again if you ran out of lives. By breaking the mod content up in this sort of fashion, where a player can take multiple routes, but never experience the full game at once, you enhance replayability, and you minimize frustration simply because the game doesn't last long enough for it to take root. It's a bit like the cheater's way out, but if the player "quits," he's more likely just to leave the game instead of quitting by my contrived defintion of quitting.


Checkpoints

Yes, these are the best solution in theory, but have fun getting me to patch them. (Note: it probably wouldn't be all that difficult, but keen maps are not designed like mario courses, so it's probably not a very good way of keening.)







References:

1. Ceilick, 2014. Save Scumming and Extra Lives. J. Keen Mod. 1799:19162. (Scroll up, stupid.)
Last edited by lemm on Wed Feb 26, 2014 2:33 pm, edited 2 times in total.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

I thought that this idea was particularly good, so I made a new post for it.

Here's a concrete example of how you could try to perpetuate a positive optimism balance:


The goal of the game is to collect 100 Keencoins. No matter how many levels that you have completed, you always have a chance to get 100 Keencoins. (The easiest way to ensure this would be to make an imposing level containing 100 Keencoins that is accessible very early on, but where every Keencoin, even the 0 degree ones, are difficult to grab. Thus, this is the level of last resort.)

Each Keencoin has a difficulty degree (from 0-9) associated with it. So, if you have collected fewer than 10 Keencoin, all coins will spawn. If you have collected 10-19 Keencoins, then those with a difficulty of 0 will not spawn. If you have accrued 90-99 Keencoins, then only those with a difficulty of 9 will spawn. In this manner, you'll minimize save-scumming because you're always giving the player a hope to win the game right until his dying breath.


Here's why it's really good though:

If your coin balance is low, you will obviously go for the easy coins first. You may also be enticed to get the high-value coins later on, and you will inevitably screw up. But, since you know how to get the easy coins in that level, you can immediately restart it, finish the level with a consolation prize, and then just go on to some other level. Thus, it doesn't feel like you've "done all that work for nothing." So, you are actually enticed to try again to salvage what you have just done.


Of course, it changes the dynamic of the game, but if you want to reduce frustration without telling your audience to "deal with it," then you may have to accept this.
User avatar
Ceilick
Deputy Administrator
Posts: 402
Joined: Wed Sep 03, 2003 2:35 am

Post by Ceilick »

Levellass wrote:This is very nearly the same as good mod design.
Nothing about 'good mod design' as you list it: bright colors, large levels, and tilework, suggests to me wanting to replay a level from the start after dying at some point within it, merely having enjoyed playing an instance of what's there so far and wanting to see the rest. You mention replayability, but there are two kinds of this: wanting to replay it in the future vs wanting to replay it immediately. For extra lives to function as extra lives, and indeed for player death to function 'correctly', players must have some desire to replay immediatly, rather than load the game.

Levellass wrote:But given what Keen is you are never going to b able to defeat the ease of saving; there will come a point where a whole level's worth of work is undone by a single badly timed jump or annoying enemy. At that point it can be tempting to drop the whole game, save or no.
I believe I've said as much; situations where a jump ends up being badly timed 9 out of 10 times, or in which an enemy is passable 1 out of 10, should not happen. When it comes to saving, the player shouldn't have to rely on it to pass a situation. If they are saving every step of the way anyway, but don't have to load because they haven't died, it really doesn't matter.
Levellass wrote:Interesting sprites and interactive elements only encourage exploration. 'I want to look everywhere in this level to see all the neat stuff'

This seems an inherent misunderstanding of what an interactive element is; something more than what is simply 'seen', hence interactive. The bounder replacements in save the quillsheep are an excellent example of this. Mink's puzzle pack and the use of 'Keen drones' is another example of this. Manipulative elements that are 'fun' to interact with.
Levellass wrote:As such I think the focus shouldn't be on saving at all but rather on extra lives.
You're right that saving isn't the issue, but loading is. Unless extra lives function as something other than extra lives, loading renders them, and death, useless.

And if our extra lives function as something other than extra lives, we must question the purpose of death at all in the face of loading.

Commander Spleen wrote:by minimising in-level death penalties when combined with several highly taxing obstacles. I have tried to do this in OrbKeen. If you fall off a ledge, you're often dropped back to a previous section of the level requiring you to simply rerun that area instead of the entire level.
Minimizing death and creating lesser setbacks is effective but players must be willing to accept the setbacks rather then just circumvent them via loading.
Commander Spleen wrote:This leaves the lifewater items free to be used as a bonus system that actually means something. This could be extra points, a secondary high score variable, access to a secret level, etc. Or it could even be used as part of the game structure, with a certain amount of lifewater, scattered throughout many levels, giving you a keycard or item that can't be accessed any other way. (Although this could also lead to a dead-end if you don't collect enough.)
This is similary mentioned above, however, can bring us to the discussion on the point of points and score, a whole other issue possibly best foregone in this thread. Access to bonuses is good, but again, bonuses should be worthwhile; the secret level is a great example, but not every mod can do this, the same goes for an alternate ending. Does every mod wishing to overcome this need to turn it into a unique gimmick?
Lemm wrote:The point I am trying to get at, though, is to think of "frustration" holistically, because save-scumming is a manifestation of frustration. And, you might need to accept that the default keen galaxy model lends itself to heavy save-scum abuse, and that you might need to radically rethink the paradigm to discourage such abuse.
I think you're right, level design, 'good level design' as Levellass will point out, won't 'require' the player to save-scum. However, even IF save-scumming is far from required to pass obstacles and beat a level, we come into territory of why the player should ever die at all or 'accept' any death when they can just load. We can disable immediate loading, but our levels have to be worth plaing again to maintain optomism and keep the player engaged in the game. Mere 'good level design' as a combination of typical elements seems a slim incentive.

If we can't make our levels worth restarting, are we forced to accept that death in Keen Galaxy can only ever be a rare and minor setback in a level? Should Keen even die at all?

Edit:
Disregarding lives altogether, perhaps the best alternative is to offer loading with a penalty (the best immediate penalty that comes to mind is all loaded games reset Keen's ammo. We've mentioned prior grand end game penalties). Players have a choice of restarting the level, taking up time but maintaining their 'gear', or load at a gear penalty.

However, this also penalizes not playing in one sitting, albeit in a friendlier way than life detraction.
lemm
Posts: 554
Joined: Sun Jul 05, 2009 12:32 pm

Post by lemm »

we must question the purpose of death at all
This has certainly taken a turn towards the Nihilistic. Heh.


It was just a carryover from the arcade machines, which is why the early ID games had the mechanic, but it was removed for Doom and beyond. I think that John Carmack mentioned this in the Wolf3d playthrough he did a few years ago on Youtube.

Anyway, I suppose it depends on what type of keen mod you're making. If you want to stick to keen canon, then it would be more appropriate to have keen die in the traditional manner. Certainly BotB would have had this were it not cancelled.



[/quote]
Post Reply