4
\$\begingroup\$

Players can achieve the expected results through continuous saving and loading in rogue-like games.

I am try to reduce this method as much as possible, but don't want to keep players from trial and error at all, which makes the game more difficult.

Anybody could give me some advice in this respect?

\$\endgroup\$
  • \$\begingroup\$ Thank you for answering my question. In the future, I will pay attention not to ask such simple questions of seeking advice. In my designing game, players can try to battle with the enemies, if they feel bad about the situation, they will re-load the game. That is not what I want to see. \$\endgroup\$ – ToT Nov 25 '19 at 12:48
  • \$\begingroup\$ Hi again ToT, your question seems to be on topic, I judged it wrong, so I went ahead and posted my comment as an answer. Feel free to keep the question open for alternative answers :) \$\endgroup\$ – TomTsagk Nov 25 '19 at 15:08
  • \$\begingroup\$ Can you give a concrete example of the kind of save-load behaviour you're concerned about? There are many forms of "save scumming" that players might be tempted to try, depending on how your game works and what they can gain by reloading, so knowing exactly which motivations/behaviours are most problematic for your game can help us tailor answers to addressing those cases. \$\endgroup\$ – DMGregory Nov 25 '19 at 15:38
  • \$\begingroup\$ Thank you. For my game details, at present, players will automatically save after passing each level, and exit in the level battle is unable to save the progress. When a player passes a certain level, he will face different levels, and the more difficult the level, the more rewards he will receive. But if he fails in the battle, he won't get any reward and the mission fails.So players can use a method of SL to challenge the harder levels, if they feel bad they will quit or exit the game.Then they will choose the easier ones to challenge. \$\endgroup\$ – ToT Nov 26 '19 at 2:45
5
\$\begingroup\$

Traditional roguelikes solve the save-scumming problem by making the saving system completely automatic. The game auto-saves the player's progress whenever feasible. Especially after something went wrong (including a game over, which deletes the savegame). But the player can not create manual savegames. That means the player can quit the game whenever they want in order to progress it at a later time, but they can not restore it to an older state when they make a mistake.

This system has the advantage that you encourage the player to think carefully about their actions and experience a greater variety of gameplay situations by forcing them to accept setbacks. If done well, this can greatly increase the player's emotional investment in the gameplay.

But on the other hand, it can also be very frustrating for the player to lose a lot of progress due to a stupid mistake.

One way to avoid frustration is to make sure that starting over again doesn't feel too bad:

  • Have great replay value, especially in the early game. (most roguelike achieve that with a combination of procedural level generation and a large variety of character options)
  • Make sure the player feels like the game is fair. Design your procedural generation in a way that it doesn't create difficulty spikes and avoid random number rolls or hidden information which can instantly kill the player.
  • Death should not feel like a complete loss. A common method is to have a progression system where achievements from one run affect subsequent runs.

Another strategy can be to avoid frustration by avoiding player setback altogether:

  • Design your game in a way that the player can't die or put the game in an unwinnable state.
  • Design your game so the player can easily recover from any setbacks in the game.

Regarding trial-and-error gameplay: You can have that in a roguelike, but you need to be careful with it to keep it fair. First of all, make sure that the punishment for errors is very light compared to the possible reward. Punishing the player for a mistake when they can not know what's the right thing to do can be very frustrating. Then make sure that it is possible for the player to learn something useful from experimentation. For example, let's say you have different colored potions in your game and the player is supposed to find out which color does what through experimentation. Either make sure there are lots of identical potions in each run or make the colors mean the same thing in every run. That way players have the opportunity to make use of the knowledge they acquired.

\$\endgroup\$
  • \$\begingroup\$ I agree. I think that one should simply allow players to save any time they want. If that is what they end up doing to enjoy the game, then let them do it. Because the alternative is they simply don't play your game. You can have ideas about how you think people will play your game, but you can't force them to play it how you want them to. The only place where hard enforcement of (some) rules is important is when there is some inherent competition between players, so there can't be any unfair advantages. This might be a typical multiplayer game, but this also applies to gambling. \$\endgroup\$ – Tim Holt Nov 25 '19 at 17:39
  • \$\begingroup\$ Thank you for your answer. I'm looking for a balance between allowing players to trial and error and trying to avoid SL as much as possible. \$\endgroup\$ – ToT Nov 26 '19 at 2:52
2
\$\begingroup\$

To prevent players abusing saveing/loading before progressing, there are a few things you can do on your end. Which one you pick, depends on the game.

  • Make saving expensive. Allow the players to save, but only if they have an item. This will make them think twice before saving. Example of a game doing this technique is Resident Evil 2 (2019).
  • Limit the functionality of saving. You can for example allow the user to save only when exiting the game, and when they resume the save is "destroyed" or otherwise inaccessible. One example of a game doing this is Ziggurat

Keep in mind that if this for a platform where users have access to the game's files (like a computer) then no matter what you do, there will be a way for a user to "copy-paste" save files. In which case you can't really entirely prevent users from abusing that, but you can only make it harder.

\$\endgroup\$
  • \$\begingroup\$ Thank you for giving me these game example. Do you have played any another lightweight games which solve the problem well? My designing game may be not that hardcore. \$\endgroup\$ – ToT Nov 26 '19 at 2:55
  • 1
    \$\begingroup\$ @ToT One other example I can think of, is Pokemon Mystery Dungeon, at least the first version of it that I've played, had a similar saving system where you can save in the middle of a dungeon and exit the game, but if you resumed that save was deleted. On top of that you can always save in the city, which is never deleted. \$\endgroup\$ – TomTsagk Nov 26 '19 at 12:26
  • \$\begingroup\$ "and when they resume the save is "destroyed" or otherwise inaccessible" - but be careful when choosing this option - a naïve implementation will leave the save unrecoverable if the device loses power while playing the game. Moria took this to the extreme and deleted the save file while the game was running. Risk of total loss of the save file to a power failure will make players take the reasonable step of making a back-up of the save file, and having already made the back-up, the temptation to save-scum will be greater. \$\endgroup\$ – TheBeardyMan Dec 9 '19 at 16:17
  • \$\begingroup\$ @TheBeardyMan This is all true, but it depends on the game. In my example, the game Ziggurat is a small-scale game, that every time you play you unlock new assets. So losing the progress of one dungeon is not serious (since you can complete multiple of them in a session), but the rest of the saved assets remain intact. In Pokemon Mystery Dungeon mentioned above, this is tackled by having the dungeon as a separate save from the main one. \$\endgroup\$ – TomTsagk Dec 9 '19 at 16:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.