Save game in minesweeper

Started by
6 comments, last by szecs 14 years, 2 months ago
The reason I want to add this feature, is that I have large fields in my minesweeper game (up to 300x300, okay, it's sick). It is obvious, that I can't use the classic save then load whenever I want method. But I can't think of a good way. Ideas so far:
  • Auto-save after every 10th or 20th steps. (the user may exploit that thing, and take his risky decisions just after a save).
  • Auto-save randomly (but I'm not sure about the autosave at all, save file is rewritten or they should be individual files?-how can the user choose a game he wants?) maybe:
  • Auto-save, but the user can rename it (asked at exit)
  • Auto-save the state 10 or 20 steps before user steps on bomb. Seems very complicated to implement, especially with huge fields
  • User-save the state 10 or 20 steps before the save. Same problem as previously The main goal is that the save should occur some steps before an important event, so that the user can only load an earlier state, so he can't take so much advantage of the saving. Any other ideas, or your opinions of the listed methods are appreciated!
  • Advertisement
    Perhaps once you lose, you delete all the saved versions of that game. That way, you can't go back and try again at all.

    That seems to be how minesweeper in Windows 7 works, except it only allows you to have one saved game at a time. When you exit, if the game is still in progress it asks "do you want to save your game?" And when you start it back up again, it loads up your last saved game. If you fail, then the saved game is deleted.
    300x300 is big, but not so big that you're likely to run out of RAM running the thing. I say autosave every turn, and store the last 20 autosaves. When the player chooses to quit and wants to save, you keep the most recent save and delete the older 19. If the player dies and wants to "restore" to an earlier save, bring up the oldest save, from 20 actions ago, and delete the other 19 more recent ones. You can't use it to facilitate trial-and-error gameplay without inconvenience, and if you have to step away from some reason, you don't lose your place.
    You really don't have to save all that much data, provided you use PRNs to generate the level. In that case you only need to save the initial seed and the user actions (click tile or place flag). If you store this sequence of events, you can always recreate the state the game was in when it was saved. And another good thing is that you can just append (rather than replace) data to an exiting file for your potential auto save feature.
    Thanks for your suggestion guys, I didn't want to go into details of the implementation itself, but I'm glad it happened.
    Storing the actions seems a really good idea, because that means in the worst (and impossible) case you will have 300x300 actions. But since there is zero-field-self-revealing stuff and left-rightclick-auto-reveal-whatever stuff, the number of the actions will be much less.

    But I still have a problem, if the user saves the game (one way or an other), he can save the gave before a risky decision, then exit the game, restart it then load the game, repeating this until he dies.

    Maybe in the case of user-save, I only save the 5-steps-before state, if he dies, 20-steps-before state.

    But maybe I could do something at the loading side: store every actions, but load only a limited number of them, depending on I don't know what. Maybe the time of load? So if he loads a file in an hour, a 10-step-earlier state loads. If after longer time: the whole file loads.
    Quote:Original post by szecs
    But I still have a problem, if the user saves the game (one way or an other), he can save the gave before a risky decision, then exit the game, restart it then load the game, repeating this until he dies.

    Well, that's how I play RTS games. :)

    Why would you even bother to prevent people from doing that? I think players deserve the right to ruin their own gaming experience. Otherwise you have to forget about save-on-demand and only implement auto save I suppose.

    How about a Diablo style auto-save? Save automatically and transparently when the user exits and give the user the option of continuing or starting a new game when they run the game again. However, when the user dies, remove the save game and only give the option to start a new game. That way there is no way to use it as a trial-and-error option since there is only ever one save, which the player has no control over, but the player can still leave and come back without loosing progress.

    Oh, and btw. I'm totally with Wan on the whole save game "cheating" issue: If it's a single play game then let the player play the way they want to. If they get more fun out of it by removing the challenge then let them go for it [smile]
    Yes, the feeling is growing inside me (sorry, I don't speak English), that this whole trial-error-prevention stuff is simply meaningless, but I wanted to be so smart.

    Thanks for the feedback!

    This topic is closed to new replies.

    Advertisement