Flavors for preventing save & reload

Started by
63 comments, last by makeshiftwings 17 years, 6 months ago
Well, you know, I'm really with you on most sentiments. You'll note I caveat'ed my idea to not encompass games where the lack of save/reload is an obvious and integral machination of the game. In other words, this game, and the gameplay which I would like it to have, as I have designed it here and now would be harmed by saving/loading, after having weighed the pros and cons.

I do, however, see a distinction between measured discretion between convenience and challenge, and stating, as a core tenet of game design, that "saving and reloading is dragging game design into the ground." One, I believe, is founded on conscienscious design concerns, the other on creation ego. So what if the player gets to use the game in -slightly- different ways than which you would prefer to play the game? Surely the goal is fun for as many people as would be interested in your game, unless you are only interested in catering to a specific demographic, or the "hardcore".


Surely, if there are situations where it is demonstrably NOT a good idea, there must be areas(and in my opinion, far more numerous areas than the alternate point of view) where it is not only justified, but simply courteous toward your customer. Give my tired hands and sense a break. To quote George C Scott as general Patton, "I don't like to pay for the same real estate twice."


Advertisement
Quote:Original post by krikkit
Well, you know, I'm really with you on most sentiments. You'll note I caveat'ed my idea to not encompass games where the lack of save/reload is an obvious and integral machination of the game. In other words, this game, and the gameplay which I would like it to have, as I have designed it here and now would be harmed by saving/loading, after having weighed the pros and cons.

Yes, I noticed that (although the impression you gave was that you'd still be ticked off, just slight less so [sime]). I did write that last response a little bit strong though, but I'm fairly opinionated on this subject [smile].

Quote:I do, however, see a distinction between measured discretion between convenience and challenge, and stating, as a core tenet of game design, that "saving and reloading is dragging game design into the ground." One, I believe, is founded on conscienscious design concerns, the other on creation ego. So what if the player gets to use the game in -slightly- different ways than which you would prefer to play the game? Surely the goal is fun for as many people as would be interested in your game, unless you are only interested in catering to a specific demographic, or the "hardcore".

Actually, I do think saving and reloading is to an extent, dragging game design into the ground, at least on the PC. One of the problems is that this dynamic is so entrenched in PC game design that it's become close to blasphemy to even consider alternatives - hence the accusations that the designer is a bit of a prima donna or masochist for suggested it (although the argument isn't helped that quite a few of such designers do really fall into that label [headshake]).

The main issue I have is that I consider the penalty for losing to be a prime design decision, and one that should be firmly designed for. However having a quicksave system is often used as a method to lazily pass the problem off to the player. If the player then suffer a "game over", it's now their fault they forgot to save in the last two hours. The rise of autosaving has helped alleviate that problem, but it's still an issue with many games. It also leads to an overuse of "WHAM - you're dead!" gameplay.

Quote:Surely, if there are situations where it is demonstrably NOT a good idea, there must be areas(and in my opinion, far more numerous areas than the alternate point of view) where it is not only justified, but simply courteous toward your customer. Give my tired hands and sense a break. To quote George C Scott as general Patton, "I don't like to pay for the same real estate twice."

Actually, I tend to think it does more harm than good to be able to save the game at any moment in time. It's fine if your game really is an "interactive experience" as Way Walker described it. However if you are making a game one of the most important gameplay dynamics is the risk/reward structure you offer the player: do you take the easy path and play it safe or risk it all and go for the big prize?

The problem is with a quicksave/load system the risk for any (short period resolved) decisions is now virtually zero; if you fail, just reload and try again. This makes a lot of gameplay mechanics totally meaningless as the best strategy is always to save, try the risky choice, and reload until you succeed.

Thus you can't have gambling in a quicksave/load system without it seeming stupid ("Dealer gets blackjack!" "Oh no, he doesn't! Quickload!"). This extends to anything with a random component - random success of a pickpocket attempt working? Just save and try it anyway. "Danger runs" in platformers where you can take an optional highly dangerous route to get the big point scoring bonuses are now pointless; just save and do 'em. Also as I wrote before it also makes it very hard to balance a combat sequence if you don't know how often your player will save.

All in all I think it would be better if the game itself managed the failure cases and the player could just concentrate on enjoying the game rather than whether they need to save a backup in case the game decides to smack them upside the head for no particular reason [smile].
Quote:Original post by Trapper Zoid
Quote:Original post by krikkit
Well, you know, I'm really with you on most sentiments. You'll note I caveat'ed my idea to not encompass games where the lack of save/reload is an obvious and integral machination of the game. In other words, this game, and the gameplay which I would like it to have, as I have designed it here and now would be harmed by saving/loading, after having weighed the pros and cons.

Yes, I noticed that (although the impression you gave was that you'd still be ticked off, just slight less so [sime]). I did write that last response a little bit strong though, but I'm fairly opinionated on this subject [smile].

Quote:I do, however, see a distinction between measured discretion between convenience and challenge, and stating, as a core tenet of game design, that "saving and reloading is dragging game design into the ground." One, I believe, is founded on conscienscious design concerns, the other on creation ego. So what if the player gets to use the game in -slightly- different ways than which you would prefer to play the game? Surely the goal is fun for as many people as would be interested in your game, unless you are only interested in catering to a specific demographic, or the "hardcore".

Actually, I do think saving and reloading is to an extent, dragging game design into the ground, at least on the PC. One of the problems is that this dynamic is so entrenched in PC game design that it's become close to blasphemy to even consider alternatives - hence the accusations that the designer is a bit of a prima donna or masochist for suggested it (although the argument isn't helped that quite a few of such designers do really fall into that label [headshake]).

The main issue I have is that I consider the penalty for losing to be a prime design decision, and one that should be firmly designed for. However having a quicksave system is often used as a method to lazily pass the problem off to the player. If the player then suffer a "game over", it's now their fault they forgot to save in the last two hours. The rise of autosaving has helped alleviate that problem, but it's still an issue with many games. It also leads to an overuse of "WHAM - you're dead!" gameplay.

Quote:Surely, if there are situations where it is demonstrably NOT a good idea, there must be areas(and in my opinion, far more numerous areas than the alternate point of view) where it is not only justified, but simply courteous toward your customer. Give my tired hands and sense a break. To quote George C Scott as general Patton, "I don't like to pay for the same real estate twice."

Actually, I tend to think it does more harm than good to be able to save the game at any moment in time. It's fine if your game really is an "interactive experience" as Way Walker described it. However if you are making a game one of the most important gameplay dynamics is the risk/reward structure you offer the player: do you take the easy path and play it safe or risk it all and go for the big prize?

The problem is with a quicksave/load system the risk for any (short period resolved) decisions is now virtually zero; if you fail, just reload and try again. This makes a lot of gameplay mechanics totally meaningless as the best strategy is always to save, try the risky choice, and reload until you succeed.

Thus you can't have gambling in a quicksave/load system without it seeming stupid ("Dealer gets blackjack!" "Oh no, he doesn't! Quickload!"). This extends to anything with a random component - random success of a pickpocket attempt working? Just save and try it anyway. "Danger runs" in platformers where you can take an optional highly dangerous route to get the big point scoring bonuses are now pointless; just save and do 'em. Also as I wrote before it also makes it very hard to balance a combat sequence if you don't know how often your player will save.

All in all I think it would be better if the game itself managed the failure cases and the player could just concentrate on enjoying the game rather than whether they need to save a backup in case the game decides to smack them upside the head for no particular reason [smile].


I basically agree with everything you've said here. The save system is as much a game mechanic as anything, it's not a separate concept that is solely used for the player to stop playing the game and return later (regardless of its original purpose). Good game players generally take advantage of any/all resources available to them, and the ability to save/reload anywhere, in itself, is an amazing resource which is hard not to abuse for some players... especially when game designers themselves consider save/reload a game mechanic and expect players to use it. When this happens, the player is at a disadvantage when he wants to just focus on playing the game and forget about having to save his ass every 2 seconds.

Kest's approach is good in that he makes it clear to the player that the game is not designed with save/reload in mind. Players who like it can still use it, but players who don't like it can play without it and have an easier time disregarding it as an actual game mechanic. It's like saying from the start "You can play through this game with the mega powerful sword of death if you wish, but the game was designed for you to play without it and using the sword may make it too easy for you." This is different from just giving the player the sword to begin with and forcing players to figure out for themselves that the game is only good when you challenge yourself to not use it... and then the game challenge feels weak because you have to "go easy" on it, and it's hard to feel suspense in any difficult situation knowing you have a cure-all in your pocket. The difference is basically about explicitly stating whether save/reload is the expected norm or not.

My game solves this problem with frequent check points. The check points save and fully heal your players, and are placed between short, intensely challenging gameplay segments. You won't be faced with a number of easy challenges in a row followed by a difficult one right before a save point. Wasting your time is what truly makes death frustrating in these cases, and this is what would make players want to save right before the difficult challenge so that they can reload and not have to waste their time with things they can trivially complete. With this save system, I can build individual challenges and not worry about them being broken up by anytime-saving.
Quote:Original post by makeshiftwings
First, those of you posting to say you can't imagine playing your favorite game without reload-anywhere need to stop ignoring the fifty times Kest has said that yes, of course, a game needs to be designed with reloadless gameplay in mind from the beginning, not "Oblivion but you're not allowed to save."

Just as a side note (and not very meaningful to the thread's purpose), there are a few games that allow reloading that I personally would have loved to try without it, but was never able to fully keep myself from doing so.

The Civilization series is a great example. I've tried numerous times to play a full game of Civ IV with hard settings without reloading. But I spent so much time tinkering with my cities and balancing my economy that I would go into rage-against-the-machine mode when the AI pulled out one or more unlikely combat wins to eventually raze one of them. The game relies on random combat chances, but also gives players the ability to reload every turn. If I was unable to reload, then I would have accepted combat defeat in many of those situations. Instead of them being unfair, they would have been unfortunate. I would have to accept that my units can make dumb mistakes, and plan in advance for those unlikely situations.

For a game like Civ, a play mode would have worked for me. Just the ability to start a new game that didn't allow saving & reloading, but still allowed me to exit.
Quote:Original post by krikkit
I do, however, see a distinction between measured discretion between convenience and challenge, and stating, as a core tenet of game design, that "saving and reloading is dragging game design into the ground." One, I believe, is founded on conscienscious design concerns, the other on creation ego. So what if the player gets to use the game in -slightly- different ways than which you would prefer to play the game? Surely the goal is fun for as many people as would be interested in your game, unless you are only interested in catering to a specific demographic, or the "hardcore".


It may not seem like it in some of my posts, but I really don't think this is a case of mere difference in opinions and my ego saying that I'm right and the player is wrong. You can break it down logically and see that unlimited quicksave/quickload turns ANY game design into a non-game. It is logically impossible to have things like "difficulty" and "challenge" when the primary mechanism of the game is basically "step, step, step, mistake, reload, step, mistake, reload, mistake, reload, step, win". As you can see, there is no way to NOT win. There is no longer the option of actually "losing" in a reload-based game. The only option that mimics failure is the player getting frustrated and losing patience with repetition if he gets stuck in a reloading loop for too long, and thus uninstalling your game. But it's impossible to have a classic game-like structure if you give the player the unlimited ability to turn back time and retry every mistake.

The usual answer to this is that the player should control himself, and that "if the player wants to ruin the game, then the designer should let him", but that's not a good answer. Tennis would be a worse game if each player were allowed to win by saying "I win" whenever he wanted, and they were just supposed to "not ruin it for themselves" by not saying it. Chess would be a worse game if a player were legally allowed to win by kicking the board over whenever he felt like it but they were not supposed to because it's considered poor sportsmanship. Tennis and chess are games because of their rulesets, rules are what make games, and as much as I like the concept of anarchy, it doesn't have a place in a competitive or challenge-based game.

I can see an argument to "let the player optionally do what he wants if it's easy to implement". I don't have a problem with putting a god mode or infinite lives cheat into a game. So I wouldn't have a problem with an option that allowed infinite reloading, as long as the main game was designed around it NOT being there. I think games should at the very least include a death system beyond popping up the reload UI. The primary game mechanic should not be assumed to be infinite-reloading, because it spreads out and consumes the entire game design. It would be the same as if you tried to design a game assuming God Mode was the default, and then later tacked on a not-god-mode option. It wouldn't work.

This topic is closed to new replies.

Advertisement