for my FF3ish game Im thinking of allowing the player to save anywhere, only it would be a save and exit kind of thing. When you exit the game it is saved and when you go back to playing you continue from where you left of. For security against crashes i want to have a quicksave running in the background that the player will never see unless their game isnt saved by some crash or poweroutage.
Like in FF1 where you had to cross the forest and get to the other town to save, my game will have that element. Not really to save but to heal, because if you hang around outside you will die. You all know, your marching through the forest at half life, your mana is all out and your down to last few potions, you start running from battles, suddenly every attack counts so for so much,... should your player miss in an attack you may have a problem. When you get the town, you are relieved, your out of danger, you can save. In my case heal or continue without consequence.
In my system when death happens, you will respawn or start again at the last quicksave. THere will be a penalty xp/gold I think.
You can never choose to load. THe only option is "continue".
I think it will work well.
Feedback (flaws) please.
laters.
-Chris
This method will preserve the tactical and mental anguish (entertainment) of trying to get to that next town so you can sav
Save game is the mark of weak game design
A long time ago there was a game called Super Mario World. Saving was only possible after completing certain areas, such as castles and ghost houses. If you died you''d have to play the level over again, from the halfway point if you had crossed the halfway gate, or the beginning of the stage if you hadn''t. Clearly this was a concious decision by the game''s designer.
Would Mario World be a better game if you could save at any given moment? Not in my opinion. Would it be worse? In some ways, yes. For example, such a change would alter the meaning of dying. If you''re able to save whenever you''re about to do something dangerous the game''s overall nature is inevitably altered. Like performing with a safety net, altering the meaning of failure changes the mood by reducing tension.
The ability to save at any time is tempting enough to change the nature of the experience for many players. Some will take advantage of unrestricted saving simply because it''s possible, even if they might enjoy the game better if they played it a little differently.
Restricted saving is a perfectly valid design device. Not all games will benefit from restricted saving, and some will suffer from it, but it all depends on the nature of the game and the kind of experience the game designer wants for his players.
Would Mario World be a better game if you could save at any given moment? Not in my opinion. Would it be worse? In some ways, yes. For example, such a change would alter the meaning of dying. If you''re able to save whenever you''re about to do something dangerous the game''s overall nature is inevitably altered. Like performing with a safety net, altering the meaning of failure changes the mood by reducing tension.
The ability to save at any time is tempting enough to change the nature of the experience for many players. Some will take advantage of unrestricted saving simply because it''s possible, even if they might enjoy the game better if they played it a little differently.
Restricted saving is a perfectly valid design device. Not all games will benefit from restricted saving, and some will suffer from it, but it all depends on the nature of the game and the kind of experience the game designer wants for his players.
After reading these, I have come to the conclusion that save anywhere/anytime is the best solution for most games. It allows for real-life situations, boredom, dying, etc.
This is really a necessity in games. For example, in many games there are traps that can instantly kill you if you do not avoid them or disarm them. Without qsave/qload, you''d be screwed by the one mistake. Also, console saving sucks. In the PC port of Soul Reaver, they kept the console save system. One part was a terribly difficult jumping puzzle that took like 3 minutes to get back to if you messed up. After failing about 3 doxen times, I unistalled the game. It was fun and I''ll play it in the future, but the jumping puzzle was so frustrating I gave up for the time. The conclusion is, the consumer is paying for the product, so do let your "Artistic vision" get in the way of their fun. Games are supposed to be fun, so if one peron''s idea of fun is saving every 5 seconds, let them. I dont in many games, but I did in Half-Life and I had a blast.
This is really a necessity in games. For example, in many games there are traps that can instantly kill you if you do not avoid them or disarm them. Without qsave/qload, you''d be screwed by the one mistake. Also, console saving sucks. In the PC port of Soul Reaver, they kept the console save system. One part was a terribly difficult jumping puzzle that took like 3 minutes to get back to if you messed up. After failing about 3 doxen times, I unistalled the game. It was fun and I''ll play it in the future, but the jumping puzzle was so frustrating I gave up for the time. The conclusion is, the consumer is paying for the product, so do let your "Artistic vision" get in the way of their fun. Games are supposed to be fun, so if one peron''s idea of fun is saving every 5 seconds, let them. I dont in many games, but I did in Half-Life and I had a blast.
Sorry, but this almost totally wrong.
You can say you *prefer* save anywhere all you want, but the idea that it is a necessity is absurd. Reality contradicts you. Explain the popularity of console games, if they lack this "necessity."
Sounds like a problem with the game. Solution: don''t have traps like that.
Anyone who is arguing that games are no fun unless you can save anywhere needs to look around a bit at what we call "real life."
quote:Original post by Anonymous Poster
After reading these, I have come to the conclusion that save anywhere/anytime is the best solution for most games. It allows for real-life situations, boredom, dying, etc.
This is really a necessity in games.
You can say you *prefer* save anywhere all you want, but the idea that it is a necessity is absurd. Reality contradicts you. Explain the popularity of console games, if they lack this "necessity."
quote:
For example, in many games there are traps that can instantly kill you if you do not avoid them or disarm them.
Sounds like a problem with the game. Solution: don''t have traps like that.
Anyone who is arguing that games are no fun unless you can save anywhere needs to look around a bit at what we call "real life."
Hey, the book that I found the link to this site says that you need to include Save Anytime. I like the way Zelda: Majora''s Mask did it where you had to hit the owl statues to save. And I think that some of the Final Fantasy series used a glowing yellow orb with red rings. I think that Majora''s mask chose the most real idea because I don''t think you''d run into yellow orbs out in the middle of nowhere. There''s my opinion. I like the things that come before or after or in the middle and allow you to save only at those points.
The Fantasy Action/Adventure is the Best Genre
The Fantasy Action/Adventure is the Best Genre
Lets prolong this thread a little by adding fuel to the fire.
It has been universally agreed in the thread that at the very least, game state needs to be persistent to some degree for any game that takes longer than 5 minutes to complete. This is "save on exit", or rather the continuous updating of the latest valid game state on disk (to cover the event of a crash). What is saved is up to the designer, but there needs to be solid reasoning behind saving anything but the very latest state of the game, because then you are setting back the player every time he''s out of time to play.
It is the other kind of save which is under discussion: the roll-back save. Instead of focusing on the save, lets focus on the reload. This re-focus is necessary, because it is the reload that makes the actual difference in the game. If you never reload, the save is moot.
So what are the possible conditions for a roll-back reload?
Discussing these possibilities, I think that the reloads under 1 are unavoidable under certain game designs. RPGs with a single linear story line for instance - you''re only going to play them once anyway, why start OVER and OVER and OVER (specially for those with hundreds of hours of playing time before completion). The difficulty lies in determining what the last point before the "point of no return" was. In most games, this is left up to the player (by giving him the choice of when to save), but is it possible to automate?
It''s number 2 that''s really annoying me. You can clamour all you like about "player choice", but perception is the killer - if you WANT the player to perceive he''s losing (when he''s really not) in order to create tension, you''re out of luck. It just won''t happen, it''s a reload situation. A game that allows for reloads at any point will not provide that tension-building experience for any but the most disciplined players. Disciplined in this context means, not reloading until final loss. Perhaps if you limited reloading until final loss, the problem would be solved. However, that could lead to issues with resolving final loss - such as stalemates in chess, or the "everybody is dead but for a single cloaked scout, but when are we going to find him in this huge level" in RTS games. With good final-loss determination, the game will be able to tell you EXACTLY when you''ve lost, and only then will it allow you to load a previously saved game.
Shifting focus somewhat, another issue that has been raised is if there should be limits on when the player is allowed the choice to save (if at all).
Imagine playing competition chess with the option to return to any state on the board. It would SUCK (never mind it would never finish). You lose, but tell your opponent "I want to go back to position X and try again". The competition game works by not allowing you to go back. Now, computer implementations do allow you to go back, even if you are playing against a human component. However, this removes the "competition" aspect of the game completely. I reckon it is the same for most games. Something that was said earlier just struck a chord: "I want to see the story evolve, not replay endless sequences because I can''t get the jump right". It is your right to play like that, but it''s like playing chess with a rollback function. You''re interested in the intricacies of the strategy, but not in playing the game. You are analyzing rather than playing. You want to watch the "movie" and have some sort of feeling that you understand the motivation of the characters, because you have tried to follow in their footsteps, occasionally failing, until you got it right.
That is valid entertainment, but, I think, moving away quite far from a pure "game". For a game to be truly competitive, save games are an obstacle.
People might not remember what you said, or what you did, but they will always remember how you made them feel.
It has been universally agreed in the thread that at the very least, game state needs to be persistent to some degree for any game that takes longer than 5 minutes to complete. This is "save on exit", or rather the continuous updating of the latest valid game state on disk (to cover the event of a crash). What is saved is up to the designer, but there needs to be solid reasoning behind saving anything but the very latest state of the game, because then you are setting back the player every time he''s out of time to play.
It is the other kind of save which is under discussion: the roll-back save. Instead of focusing on the save, lets focus on the reload. This re-focus is necessary, because it is the reload that makes the actual difference in the game. If you never reload, the save is moot.
So what are the possible conditions for a roll-back reload?
- The obvious, failure.
This can mean death, or whatever is the absolute final losing condition of the game (running out of time, stalemate, etc.). The intention is to roll back the game state to a point where victory was still possible, and have another shot at it.
Possible reasons for having saved:- The time necessary to replay the game from it''s initial state to the last known good position is too long to allow for comfortable play.
This infers something VERY important about the type of game you are playing: it is not enjoyable or desirable to replay earlier sections. The player has decided that your game will only be played once. - Replaying the game would most likely not lead to arriving at what you think was the last known good position before your current failure. In plain english: it''s really hard to play the game exactly the same twice, or it might even be impossible with certain random factors.
Here again there is something important to be inferred: your game is not very deterministic(or seems to be), chance seems to play a large part in success. This is through the player''s eyes, he''s the only one that matters when evaluating your game.
Note that both conditions can be true at once, and 2 is in fact a special case of 1 - since it would take a lot of plays before the chance factors worked together to create the same situation as the first time you failed.
2. - The time necessary to replay the game from it''s initial state to the last known good position is too long to allow for comfortable play.
- Player-perceived failure.
There is a very important difference between this and the first type. The first type is indisputable, the game actually says "you have lost". However, in some types of games, it may be that the game allows you to play in a certain-loss situation for a long time before actually acknowledging that you''ve lost (look at chess - there are stalemate conditions that theoretically could have you play forever).
So it may be that the player knows, or THINKS, that he is in a certain-loss (or likely-loss) situation, and wants to roll back to a place in time where he can influence his winning chances. This is the kind of reload that certain game designers dread, because it makes it very hard to push the player through some heroic situations, where the intention is to make it look as if all hope is gone, yet they pull back against all odds.
By using this reload, the player is saying "I think I was losing".
Discussing these possibilities, I think that the reloads under 1 are unavoidable under certain game designs. RPGs with a single linear story line for instance - you''re only going to play them once anyway, why start OVER and OVER and OVER (specially for those with hundreds of hours of playing time before completion). The difficulty lies in determining what the last point before the "point of no return" was. In most games, this is left up to the player (by giving him the choice of when to save), but is it possible to automate?
It''s number 2 that''s really annoying me. You can clamour all you like about "player choice", but perception is the killer - if you WANT the player to perceive he''s losing (when he''s really not) in order to create tension, you''re out of luck. It just won''t happen, it''s a reload situation. A game that allows for reloads at any point will not provide that tension-building experience for any but the most disciplined players. Disciplined in this context means, not reloading until final loss. Perhaps if you limited reloading until final loss, the problem would be solved. However, that could lead to issues with resolving final loss - such as stalemates in chess, or the "everybody is dead but for a single cloaked scout, but when are we going to find him in this huge level" in RTS games. With good final-loss determination, the game will be able to tell you EXACTLY when you''ve lost, and only then will it allow you to load a previously saved game.
Shifting focus somewhat, another issue that has been raised is if there should be limits on when the player is allowed the choice to save (if at all).
Imagine playing competition chess with the option to return to any state on the board. It would SUCK (never mind it would never finish). You lose, but tell your opponent "I want to go back to position X and try again". The competition game works by not allowing you to go back. Now, computer implementations do allow you to go back, even if you are playing against a human component. However, this removes the "competition" aspect of the game completely. I reckon it is the same for most games. Something that was said earlier just struck a chord: "I want to see the story evolve, not replay endless sequences because I can''t get the jump right". It is your right to play like that, but it''s like playing chess with a rollback function. You''re interested in the intricacies of the strategy, but not in playing the game. You are analyzing rather than playing. You want to watch the "movie" and have some sort of feeling that you understand the motivation of the characters, because you have tried to follow in their footsteps, occasionally failing, until you got it right.
That is valid entertainment, but, I think, moving away quite far from a pure "game". For a game to be truly competitive, save games are an obstacle.
People might not remember what you said, or what you did, but they will always remember how you made them feel.
quote:Original post by MadKeithVPlayer-perceived failure.
There is a very important difference between this and the first type. The first type is indisputable, the game actually says "you have lost". However, in some types of games, it may be that the game allows you to play in a certain-loss situation for a long time before actually acknowledging that you''ve lost (look at chess - there are stalemate conditions that theoretically could have you play forever).
So it may be that the player knows, or THINKS, that he is in a certain-loss (or likely-loss) situation, and wants to roll back to a place in time where he can influence his winning chances. This is the kind of reload that certain game designers dread, because it makes it very hard to push the player through some heroic situations, where the intention is to make it look as if all hope is gone, yet they pull back against all odds.
By using this reload, the player is saying "I think I was losing".
...
You can clamour all you like about "player choice", but perception is the killer - if you WANT the player to perceive he''s losing (when he''s really not) in order to create tension, you''re out of luck. It just won''t happen, it''s a reload situation. A game that allows for reloads at any point will not provide that tension-building experience for any but the most disciplined players.
Then, and I repeat myself here - you need to make it obvious in the game design that there are degrees of failure and they are a natural part of playing the game.
Game design should be about carrots, not sticks. If you want someone to do something, make it beneficial for them to do it, don''t just take away the alternatives. Games are about making choices.
quote:Disciplined in this context means, not reloading until final loss. Perhaps if you limited reloading until final loss, the problem would be solved.
And perhaps if you forced me to struggle on through a whole level on 2 health points with 3 bullets, just for me to die anyway two hours of gameplay later, I would break your game cd in two and come on these forums to warn other people off your game...
quote:With good final-loss determination, the game will be able to tell you EXACTLY when you''ve lost, and only then will it allow you to load a previously saved game.
Impossible for many genres. An expert player will be able to survive and play much more effectively than a poor player in the same situation.
quote:Imagine playing competition chess with the option to return to any state on the board. It would SUCK (never mind it would never finish). You lose, but tell your opponent "I want to go back to position X and try again". The competition game works by not allowing you to go back. Now, computer implementations do allow you to go back, even if you are playing against a human component. However, this removes the "competition" aspect of the game completely.
I still think this is trying to dictate to a player what kind of game they can play. If they want to play "competition" games, I believe they will do so. On the other hand, if they want to be guaranteed of winning in the end, they can do that too. How does it help to limit them in this way?
(Besides, some chess players like to set up the game at a given position from a famous match and play through it from there. Something else to consider.)
[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files ]
Taking a cue from MadKeithV's post, let's distinguish between saving games to manage the length of play sessions and saving progress to manage penalties for failure. A game that features restricted saving might incorporate the following:
A. Saving to manage length of play:
- Load from menu: Loading can only be done from the main menu. You must exit a game in progress before you can load another.
- Save on exit: The game state is saved whenever the player exits the game. There is no option to exit without saving.
- Autosave: To protect against crashes, save as often as is possible in as transparent a way as possible. If possible to do so transparently, save whenever significant events in the game are triggered and before they are presented. When an autosave is loaded following a game crash, present a dialog to this effect (to both inform the player and make cheating more obvious).
B. Ways of managing penalties for failure:
- Progress-at-risk/Progress-safe: Progress is divided into manageable chunks. Progress is saved whenever certain conditions are met, such as reaching a particular area or defeating a particular enemy. Progress that hasn't been saved is at risk, and is lost upon certain kinds of failure. Reaching the "progress-safe" condition should produce some kind of feedback.
- Task-at-risk/Task-complete: The player has certain tasks to complete. Failure before completion means that the task is somehow aborted or interrupted. An interrupted task will require some additional action to be undertaken before the task can be completed. An aborted task will require some new task to be completed in its place.
[edited by - chronos on May 17, 2002 8:42:23 PM]
A. Saving to manage length of play:
- Load from menu: Loading can only be done from the main menu. You must exit a game in progress before you can load another.
- Save on exit: The game state is saved whenever the player exits the game. There is no option to exit without saving.
- Autosave: To protect against crashes, save as often as is possible in as transparent a way as possible. If possible to do so transparently, save whenever significant events in the game are triggered and before they are presented. When an autosave is loaded following a game crash, present a dialog to this effect (to both inform the player and make cheating more obvious).
B. Ways of managing penalties for failure:
- Progress-at-risk/Progress-safe: Progress is divided into manageable chunks. Progress is saved whenever certain conditions are met, such as reaching a particular area or defeating a particular enemy. Progress that hasn't been saved is at risk, and is lost upon certain kinds of failure. Reaching the "progress-safe" condition should produce some kind of feedback.
- Task-at-risk/Task-complete: The player has certain tasks to complete. Failure before completion means that the task is somehow aborted or interrupted. An interrupted task will require some additional action to be undertaken before the task can be completed. An aborted task will require some new task to be completed in its place.
[edited by - chronos on May 17, 2002 8:42:23 PM]
You guys are confusing me. I think it would be better to have unlimited saves than save on exit. Save on exit is so explicitely gay that I can''t even describe it. oh well.
The Fantasy Action/Adventure is the Best Genre
The Fantasy Action/Adventure is the Best Genre
MadKeithV this was a great post - that everyone will ignore in favor of simply repeating themselves...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
