Allow saving mid-level?

[Grey Alien]

Hi, here's one for you...

Should you allow players to save mid-level in your "casual" game. What I mean by this is *not* just saving which level they reached and the score at the start of the level, and then next time they load the game just restart the level. But *properly* saving the game state i.e. position of all game objects, current stats etc.

Obviously it would be nice to save mid-level but it can be pretty complex (as I'll outline in a minute). Sure I know that AAA FPS games have a quicksave option and but most casual games don't seem to do this. In fact lots of platform games, shoot em ups, bat n ball games seem to start you at the beginning of the level. However, I just tested Bookworm Adventures and it does properly save mid-level including the letters in the grid!

OK, so why could it be complex? Well apart from storing all the game objects and current stats, what if the player saves *mid-animation*? So say there is some kind of special animation (most games have lots) and the outcome is important because it affects the game objects, then you'd have to save that state and then reinitiate it exactly upon reload. This is possible but is a lot of programming (unless I guess you've properly thought this out beforehand and made a very smart animation list object or something ;-)) and is also bug prone. I've seen major games where the quicksave reloads and the game is bugged.

Another possiblity is to "forward wind" all the anims when the player saves to finish them off so that the result is saved and the game reloads to a point after the anims have occured. But what if the animations cause chain reactions?

Anyway, what are your thoughts on such matters? Thanks.

[ZuluBoy]

Each level in my upcoming game (http://www.playdetective.com) is made of scenes.
At the beginning of each scene, there are scripted animations and dialogs, and then some mini-games.
When a player quits in the middle of a level, only the states of the mini-games are saved.
When the player resumes the level, he sees the same animations and dialogs, but the mini-games are restored to their last state.

[Roman Budzowski]

We save mid-level in Runes of Avalon. It hurts if you don't plan it ahead or don't have experience doing it.

cheers
Roman

[Grey Alien]

Yeah I could do mine by gathering a whole bunch of variables and counters and saving them and call the right procedures to reinitialise the anims at the correct point but yeah ... painful. Perhaps if all the code was in a really neat object-based animation list it would be easier as you could just whiz through the list, save each object, then load them in later an call each animation's initialisation via a polymorphic function call.

[GolfHacker]

That's exactly what I do, Grey Alien.

All of my games can save mid-level. It isn't really that difficult if you're using an object-oriented paradigm. Every C++ class in my game has methods for serializing and deserializing their state (position, size, velocity, acceleration, current animation frame, etc) to/from a stream. When I need to save the game, I just serialize all the game objects. To restore the game, I just deserialize all the objects. The serialize and deserialize methods also allow you to easily implement an undo mechanism for turn-based games, if you want.

[James C. Smith]

Big Kahuna Reef saves mid level because it was easy to do and planned ahead for. Ricochet does not allow this because we didn't plan ahead and there is much more complex scripting going on that has many states that are harder to save. So Ricochet just saves score, lives and level number. In games like this we encouraging Save&Quite at the end of a level but allow it mid level. It just means that when you resume the saved game you will restart at the beginning of the level.

I think it is always nicer when you can support mid-levels saves, but it isn't usually a deal breaker if you don't implement it. It becomes more important if your levels are longer. For example, most Ricochet levels take 2 minutes or less to finish. So the player doesn't lose much if they exit the game mid level and they don't have to play much longer if they decide to finish the level before quitting. In a game with 10 minute levels it would be much more important to support mid level saves.

BTW: As a game designer, I hate allowing players to load and save games at will. I never want a player to reload his last saved game because he died. I especially think that is inappropriate in casual games. A casual player shouldn’t have to manage save games and the game balancing shouldn’t assume that they could load a saved game after death. In casual games, when I talk about saving, I am talking about a suspend game features that saves the state of the game as you exit and restores it the next time you run the game. I am not talking about a system that lets you come back from the dead. But this is a game design question rather than a technology issue. The same programming is needed to allow mid level suspend game and mid-levels load/save. (what I call creep and save)

[Grey Alien]

That's exactly what I do, Grey Alien.Ha, well it looks like I need to improve my OOP in the next game!

So Ricochet just saves score, lives and level numberyeah I found that out when I played it a while back. It's pretty normal for brick busters to to that.

In casual games, when I talk about saving, I am talking about a suspend game features that saves the state of the game as you exit and restores it the next time you run the gameYeah that's exactly what I'm talking about. The game only has short levels actually so it's no big deal if you had to restart. I'm quite far in now to go with the "The serialize and deserialize methods" that GolfHacker suggests, so I may a) disable the menu button during critical anims or b) save the pre-anim state so it reloads just before the anim and the user would need to re-initiate the anim. Mind you that's not even that easy because the game objects are affected by many of the anims...

[tau]

As a busy gamer with a daily job, I quit playing a game (and never touch it again, nor buy it) if it does not allow me to save my progress at any time, because I dont have enough time to start a level again.

[jaguard]

Is it this hard to make this load feature? Just copy your classes to file, and that's it :). They shouldn't use new/delete though, and don't keep pointers to objects, use indexes instead.

[Sybixsus]

Is it this hard to make this load feature? Just copy your classes to file, and that's it :). They shouldn't use new/delete though, and don't keep pointers to objects, use indexes instead.

It's not necessarily that straightforward. Yes, saving your classes saves the game state, but loading them does not automatically restore the game state. Suppose you're mid-way through a sound effect. Even if your class has something to indicate this ( unlikely unless you think about it and plan for it ) then you still have to resume the sound mid-sample, which your audio engine may not support. Or a particle effect is going off and is mid-way through execution. How many engines have particle effects which allow you to start mid way through? Not many, because they usually have some level of randomness and can't predict exactly where things will be at x seconds into the effect. And saving states of particle effects, or even emitters and attractors might be feasible, but it's hardly feasible to save the position of every particle. Most particle engines won't even let you.

Ok, you might call that nitpicking and it doesn't matter, but does it? What if the sound is a spoken tutorial that has only just begun? It needs to be replayed, from the beginning if not from mid-point. What if the particle effect was an important gameplay clue indicating your next move? Again, it needs to be restarted at some point, even if you can't do it to the mid-point. And if you can't get these things resumed at the mid-point are they going to be out of sync with everything else?

It seems to me that the minutiae of this can be very tricky, and important enough to make it worth doing.

[ulfster]

i would not allow the player to save mid game. always keep it simple stupid. that means a level has a start and an end. nothing in between. just take care that the first level are easy to beat so you wont need that option.

but thats just my opinion. for hardcore gamers this might be useful but not for a casual game. greetings

[Infinite Element]

I say have "save stations" throughout harder levels that allow you save, but DON'T RESTORE HEALTH. That would make it too easy.

On second thought, that might not be the best idea. You could just not allow midlevel saving.

[Captain Wingo]

I think saving in mid-level is pretty important to a decent part of the casual game audience. When playing casual games, I take it for granted that if I hit the close button, the game will save itself magically. If I come back and it didn't save, I am surprised and a little sad. It's usually not a deal breaker, but sometimes it is.

However, one thing to keep in mind when implementing mid-game saves is that you have to make this OBVIOUS to the player. This was something I learned from the beta feedback for my upcoming game: many people don't assume that there's an auto-save, so you need to let them know.

This is probably why Luxor 2 has a tiny "Saving..." popup that lasts maybe one second. I doubt it takes a full second to save the game; the pop up is probably just to let players know that a save is occurring.

EDIT: oops, sorry for bumping a dead thread.

[svero]

As a busy gamer with a daily job, I quit playing a game (and never touch it again, nor buy it) if it does not allow me to save my progress at any time, because I dont have enough time to start a level again.

Ditto. This is a must have feature for me unless the levels happen to be pretty short.