It takes too long to restore a game and I have to know in advance where to situate my save for as rapid a replay as possible. Graphical games solved this problem ages ago; they largely no longer rely on the cumbersome save/load process to close a retry loop. It’s the wrong tool for the job.
To me this is like insisting that every camera angle in a movie be a POV shot from the top of the main character’s shoulders. ‘Aren’t I supposed to be identifying with Tom Cruise? If so, then how come I can see the villains executing their secret plans – Tom Cruise wasn’t even there for that!’ Hyperconcern over maintaining continuity even where it has no emotional import, tends to tie an artist’s hands – and the history of film could have been nipped in the bud, if the literalists had won a very similar debate.
People will accept cognitive dissonance regarding omniscient narrators; so long as the difference is glossed over, instead of belaboured. This is where the Restart, Restore, Quit process fails and why I question its utility – it belabours the dissonance of dying.
Unless you’re talking about the “Try again” button which places the player back at the sticking point. That I like, and a similar alternative in IF might minimise the issue.
“Takes too long” also sounds strange to my ears, maybe because I’ve gotten used to saving a lot - a LOT - and keeping different save files. Restoring a lot is par for the course, and takes me all of, oh, two seconds? Possibly I’m more lenient because I’m used to old-school and have learned to deal with some of its issues.
I only care for speed when I’ve stopped caring about the game. And I only care about the validity of my savegame if I’m worried I may have inadvertently left things behind, or things undone, in sections I can’t revisit. Or, as in Avon, when I’m trying to figure out exactly where a timer started.
I’m not laying out an obligatory formula. I’m saying that if you want to go that way - and if so, it’s perfectly allright to use “Meanwhile…” sequences as long as the player isn’t supposed to be able to act out on that information until the player character has found it - then it’s probably not a good idea to use meta-session information, because you’re no longer telling a coherent story. Unless you WANT the player to be an omniscient character that uses that information to help the PC. Which is - again - another direction.
You’re confusing me. Your previous arguments were against “suspension of disbelief”, and this last one is for it - because if the PC uses information he can’t possibly have access to, it’s a lot more jarring than if the PC dies and the player goes back a few turns, in an established and widespread convention that “we’ll just pretend that never happened”.
Did you edit your original post a lot? 'Cause you say some of the things I wanted to get across in my reply. I either didn’t see them or you added them later… which is a shame, because if that’d been your original post I’d probably never have replied at all.
I’m not sure which post you’re referring to. I’ve made some edits in this thread to improve my examples/arguments with details I thought of after-the-fact but I don’t think I changed the actual meaning of anything significantly. Apologies if the effect was disconcerting – it was not intended. I did not edit anything you replied to after I had already seen your reply.
Thanks for the link. Looks interesting. It’s a little long for me right now – but I have added it to my reading list for later. I’m not talking any specific button – I am talking about the presence vs. the absence of ‘try again’ buttons. I prefer the absence. Obviously I am going to try again, so let’s just go directly there, do not pass GO do not collect $200, do not make me hit buttons, do not make me type RESTORE and navigate to a save file; this stuff all just wastes my time. Either I’m going to try the exact same thing I failed again, or I’m going to quit. Quit doesn’t need a button; a quit can be achieved by the operating system itself. Therefore the only option is ‘try again’. When there is only one option, why ask the player? Just do it.
Well, yes, you’ve explained your own habits here. Simple things sound strange to ears acclimatised to complex things. That doesn’t prove the complexity is necessary. I find it wholly unnecessary. And unlike you, I am not only impatient when I don’t like a game. I am also impatient when the game is very exciting and the storyline very fast-paced, but the puzzle-solving processed is nitpicky and slow. Those two things are not emotionally congruent. Emotional congruency is what I value – not perfect technical or narrative continuity, which are red herrings.
The problems you point out could be true but are not necessarily true. If I use postmortem information to solve the puzzle, it may merely appear as if the protagonist is more intelligent than the player. t only falls your way in the specific case where the postmortem information is absolutely unfigurable otherwise – which doesn’t seem me like the most common instance.
In fact, most games rest upon this dissonance: the player begins as incompetent and only achieves competence slowly; nevertheless, the protagonist is often portrayed as highly skilled the entire way. How do you tell a story about a highly skilled character? You can’t actually, without breaking this rule that you support.
What I am saying is that suspension of disbelief is not nearly as brittle as a lot of people seem to assume, and the way the filmic arts have developed shows massive evidence for this. I’m not saying that suspension of disbelief is unimportant; I’m saying that it can be successfully glossed over, as long as things remain emotionally congruent. The emotional arc of a retry loop is completely derailed and destroyed by too much futzing over the save process or redoing old actions not immediately relevant to the loop. A retry loop requires rotational speed to function emotionally for the player.
Both Inform 7 and TADS 3 support initiating a VM save via game code. So if the game knows it’s headed into a tricky puzzle, it can save a checkpoint file in advance, and roll back automatically on defeat.
I’ve only seen this used in All Hope Abandon, during the chess match, but it seems like a workable solution provided that the player is only faced with one such puzzle at a time, the scope of interaction is restricted to just that puzzle, and a solution to the puzzle can always be found within that scope.
One of the general strands of IF design, which I associate more with games from ten years ago, favors large maps with many puzzles that can be solved in parallel. That tends to work against a checkpoint system that depends on a sequential flow. The current trend seems to be toward shorter, less challenging, more streamlined IF, which to some extent makes checkpoints either unnecessary or functionally equivalent to UNDO.
All Hope Abandon is interesting because it feels so open, and yet it manages to include these very scripted set-piece challenges. I am not sure how much of that is subtle trickery and how much is sheer excess, but I like the effect.
Jon Ingold’s article on challenge in games covers related ground. It’s worth reading if you haven’t seen it.
The Alternative Permadeath extension includes code that can be used for any sort of author-initiated save or restore (of the sort Ben mentions), not just the roguelike-style system Victor used for Kerkerkruip.
I don’t like UNDO either. I mean, not that it should be abolished or anything, but for taking back death? No. Death should be taken back automatically – why do I have to type UNDO one or more to times just to be taken back to the point that both I and the game know was the critical decision point? There are iterative puzzles where the process of typing the UNDOs actually add up to way more typing than the process of the actual ‘doing’. It’s just so obviously crippling any enjoyment factor in the iterative process, to my mind, anyway. So it’s not surprising that IF afficionadoes poo-poo iterative storytelling, but IMO their dislike is misguided and keyed to the way their own medium has classically mishandled that situation.
First, in the interest of fair disclosure, I have to acknowledge that my views may be colored in part by having grown up in the stone age. When I first played Adventure on a printer terminal connected to a mainframe, there was no opportunity to save at all – if you died, you started over and had to run through another forest worth of paper to get back to where you were. (Of course, before we could even play we had to walk barefoot six miles through the snow.) So Neanderthals like me have limited sympathy for a bunch of soft candy-ass Homo Sapiens wusses who complain about having to replay too many moves since the last save.
Seriously, I have no problem with the idea that part of the learning process might entail dying a few times, subject to a few things. First, an insta-kill without any warning is unfair. On the other hand, I have no problem with an insta-kill where there is some warning that danger exists. The warning doesn’t have to be as explicit as a robot saying “Danger, Will Robinson!” – if the circumstances of the game are such that a reasonable player would recognize that things could go wrong, the player ought to be saving frequently, and if he doesn’t there’s no cause for complaint if he dies and has to waste a few extra minutes getting back to the fork in the road.
Second, I think that, in theory, in most games it should be possible to get through the game without dying. Thus, the proverbial example of the code word that you can only learn by dying I would usually consider unfair (unless the experience of death is an intended part of the game, as opposed to the consequence of a mistake). However, that does not mean that a game should be designed so that most players actually get through it without dying or otherwise making a serious mistake. My own view is that if most players are getting through it on the first pass, the puzzles (assuming the game has puzzles) are too easy. In my mind, the really great puzzles are the ones that you struggle with for hours, days, or weeks, cursing the day the author was born, and maybe dying a few times in the process. Then, when you finally do get it (either by figuring it out, by brute force, or by throwing in the towel and looking at the cheatbook) you hit yourself on the side of the head and say "My god, what an idiot I was – it should have been obvious!).
Finally, if a player does die, I have no problem with making him restore (or, if applicable, undo) as opposed to resurrecting him automatically. There may be games where the idea of resurrection works well within the game world itself, and for those games allowing recovery from death “within” the game is fine. However, for a game with a more “realistic” game-world, it seems more appropriate to me to make the player step outside the game-world (by undoing or restoring) rather than allowing him to recover from death within the game itself.
No harm done, I didn’t think you had. It’s just disconcerting for me to see that “post edited” line without knowing what was edited. Bottom line - I should have read your first post better.
Ah, I see. It’s a point of view, of course - it could just as well be argued that if I’ve failed too many times I maybe do want to quit, or restore to an earlier instance of the game, and automatically bringing me to the “Try again” point is a waste of time - and that would be another point of view. I’m therefore pleased to have reached the point where we can agree to disagree.
Then you are much more like me than you think. I’ve even started in this forum, some months back, a thread in which I rant about how puzzles can work against the emotional experience. I’m fully behind everything you say here.
It depends on the information. I can solve the penultimate puzzle in Sorcerer by trial and error (three doors, two lead to dead ends, one to the endgame; there is a way to get a hint about which door is the correct one), and I doubt many players have done it any other way. It’s not about intelligence in that case - the PC was foolish and irresponsible enough to trust completely to his luck. And I will disagree with you again in that I find that the most common instance is, indeed, for the postmortem information to be unfigurable otherwise - which is why we have these discussions at all.
You can. Varicella takes one approach; Spider and Web takes another. Yet another approach would be to gently block, in the PC’s voice, actions that would betray that lack of skill. There are ways - it’s just a question of how the author wants to do it.
(Disclaimer - I’m talking about Varicella way more often than I should, considering I only played it once and am saving it for a rainy day. But I’ve read a lot about it)
Ok, I understand. I think you may be overestimating the importance of those meta-game “breaks” - there are far worse offenders, and the save/restore/quit/retry loops can be (and I thought mostly were) taken as part of the interface, no more worrying than tapping TAB or navigating the mouse to the Inventory button to open the inventory.
Since for me, personally, it would be more disconcerting to have the game immediately go back to the part where I failed than for me to choose to do so (if I do it, I can pretend it never happened; if the game does it for me, it feels different, it wrestles meta-game control from me, and I will have a different emotional response), I am at this point - both of us having explained our views - perfectly happy to, once again, agree to disagree.
EDIT - Wow, I managed to miss out an entire page of replies.
I didn’t know that, and I think it should be documented (I don’t remember reading about it). It’s a great feature. When I was working on my (now abandoned) WIP I wanted the game to automatically save between chapters. I was forced to open a “Save Game” dialog, which I really disliked, especially knowing that in I6 it could be done silently.
For one, because you and the game might disagree on what’s the critical decision point. Also, death (or losing) in IF is already trivial enough when it can be easily UNDOed - automatically going back without player action would banalise it to the point where there is no such thing. In which case we’d be better off designing a game where you can’t die or get stuck. Otherwise failure won’t mean a thing. I’ve seen it happen in console games, another thing I wrote about in a blog post. I’m not sure I’d like to see it happen to IF without a better reason than any I’ve seen here so far.
Well, Inform 7 doesn’t include library code to support it, put the support is present in the underlying libraries nonetheless. I wrote some code to enable it and make it I7-y; Victor included this code in his Alternative Permadeath extension, which is not officially released but is available in the source for Kerkerkruip, as well as at the link I posted above. (If you’ve played Kerkerkruip, you may have noticed that it saved your game silently each turn, and restored it silently if you closed the game and then reopened it. You never see a save dialog box.)
Both of those things (1) can be typed at any time and (2) are possible via the operating system interface, and don’t need to be pushed at me, hogging exclusively to themselves a whole game turn, whenever my character dies. If you are already planning to quit or to restore the game, then the pacing of the current playthrough isn’t important anymore. Speed is of the essence for keeping the player involved ‘in the moment’; in your counter-situation, speed is irrelevant for that purpose, because the player is about to explicitly choose to abandon that moment.
Excellent – I had a feeling there was more agreement here than was apparent. Probably when I read your blog post, there will be even more; I expect that’s why you asked me to have a look. And I will. 8)
Sadly and embarrassingly, I have not yet gotten around to trying Varicella. Spider and Web is a interesting counterexample. Spider and Web was very clever (even brilliant) in the way it contextualised the player/protagonist split to avoid dissonance while supporting a series of very tight retry loops with an old school level of cruelty. That was really good. I don’t think it proves, however, that such a split in perspectives is necessary to have a successful cruel retry loop. (I realise that this wasn’t precisely what you were trying to prove by mentioning it, and it is a good counterexample to my statement which went too far.) Furthermore, Spider and Web is a perfect example of how much better a retry loop works when you dispense with the RESTART/RESTORE/QUIT loop. Ever notice that when you die in Spider & Web, you don’t actually get that menu? Instead you get a little ‘interrogation interlude’ and then are sent automatically back to the nearest convenient checkpoint, as determined by the game itself, which is exactly what I am advocating. But there is no reason that you need to split the player/protagonist perspective in order to skip that menu in the way that Spider & Web did. In fact, if you skip the death event as quickly as possible, that replay dissonance will much minimised, and probably be much more easily overlooked by the majority of players. IMO, of course. You can tell me whether you agree in the final analysis, if and when you try my WIP. 8)
Well, people who are used to the interface do not always perceive how disconcerting it is for a newcomer. And I feel that it is precisely in the case of a tight retry loop, which is typically associated with fast or highly tense and dangerous action, that the conspicuous meta-game break is the worst possible blemish to inflict on the play experience – unless, like in Spider and Web, the meta-game is actually part of the story: and even then the cruft I detest was wisely removed. (I don’t know why this didn’t immediately catch on in a more general way. It’s almost as if the Great Implementors of yesteryear looked down upon the play experience and said to themselves, Impishly, ‘These loopy bits are probably the most tense and time-sensitive bits: lets fill all the cracks in those with extraneous interface cruft.’ And so here we are.)
Much more uncommon than it seems. It is usually quite obvious when the critical decision happened or at least how long ago was the time that the critical decision hadn’t happened. I admit that there are exceptions.
This is a lost cause; death is trivial in a video game. That is an incontrovertible reality. Nothing you can do is really going to render it non-trivial, emotionally, except maybe if you self-destruct the entire copy of the game, never to be played again. So making video game protagonist’s wrong-move death something of great consequence is not an achievable goal. By punishing the players for reaching a fatal ending, forcing them to typing boring irrelevant reset commands repeatedly in the service of that unachievable goal, you are essentially just punishing them for playing the game – because everybody dies, right? I don’t think there is any smart way to actually seriously punish the player for dying; I definitely don’t think it’s a good excuse for subjecting them to meaningless, repetitious gruntwork that isn’t fun.
I realise that this has been a prevailing view for an entire era of game design, but I can’t stand it. I can’t stand this no-dead-ends, safe-world ethic. Plainly stated, this philosophy has directly resulted in a giant truckload of extremely boring games. Mind you, I agree with the goal of this ethos: let’s not punish the player for playing the game (as I mentioned above). But I just detest the now-conventional method of achieving that goal. We should just make death simple, instructive, and as easily recoverable as possible. We should not have abolished fatal endings; that was just a way of avoiding the mental symptoms by lobotomising the patient, IMO.
Agreed on that last bit! 8) We do agree on more than it seems, and our disagreements are kind of magnified by our current focus on a narrow issue. Thanks for explaining all of your views on it.
Heh heh. Well it might surprise you to know that this candy-ass first played Adventure in the late 70s on a PDP terminal via a suction-cup modem. I am old school in many ways – but there are things that have been bothering me ever since the 80s, and one of them is ‘Restart, Restore, Quit’.
Agreed with the above.
Disagree here. I do not wish to catch the player out on forgetting-to-save. That tests nothing, and proves nothing. It is neither a function of the player’s personality, nor does it signify their understanding of the scenario I’ve presented. I understand that from an old school perspective, learning a collection of meta-skills was par for the course, and knowing how to navigate that territory was valuable and proved that you were not a clueless newbie; but I never agreed with that anti-noob perspective, even in the old days. IMO the only ways the player should be tested and found wanting, are in ways that are concomitant with the actual story. And they should never be actively punished for failure with boring interludes. Preventing them from advancing further, until they succeed, is all that is strictly required to make the challenge fun, and any punishment beyond that serves only to make it less fun.
I mostly agree here, although there are several games in which the scenario is contrived such that it makes sense to use the knowledge obtained after making a ‘deadly’ mistake – Peter mentioned Spider and Web. However, I feel the ‘code word after death’ scenario that is often trotted out to support a certain point of view, is not actually a very common scenario. So it’s a misleading example. Kind of like the ‘ticking time bomb’ scenario that is trotted out to support torture, etc: it rarely happens. What usually happens is, your manner of death gives you a clue to something that you could have figured out without the clue if you had thought about it a bit more thoroughly.
So… wait, huh? Making the player step outside the game-world is appropriate when you are after realism? That doesn’t sound right at all. If defending your old standard bits of interface has led you to such a counterintuitive conclusion, I think it kind of makes my point for me. 8)
Not so. He’s just saying that if the world of your game involves things like ghosts, magic, and powerful sorcerous spells, then it can make sense to provide an in-game resurrection when the PC gets killed.
In a more realistic game-world (one that resembles, oh, the world we actually live in, for instance), when you’re dead you’re dead. No do-overs. If an in-game resurrection were provided in such a game, it would break the realistic model world. Therefore, providing an out-of-game-world Undo for an action that kills the PC preserves the realism of the model world. This is a perfectly sensible way to look at it.
If you really want realism, then dying in the game should erase your hard drive. But if you do that, I doubt you’ll find many players who will give your game a positive recommendation.
Actually, I suspect that you won’t need to worry about that – after you’ve erased a player’s hard drive (or, dare I say it, effected an even more realistic “simulation” of death) that player won’t be able to write any reviews at all.
In fact, Jim has correctly stated, far more clearly and eloquently than I did, precisely the point I was trying to make.
I get that. I was being a bit facetious to make a point, which still stands. That being, if the choice is between a ‘realistic’ game with automatic checkpointing and a ‘realistic’ game with a ‘Restore, Restart, Quit’ menu after death, it seems clear that although both are not perfect realism, the latter is plainly the greater transgression against realism, of those two ways to turn around death in an otherwise ‘real’ milieu. Granted, a more fantastical setting can provide a milieu-specific opportunity to do things differently. But that doesn’t really provide any information as to what works best to achieve realism. in any setting, realistic or not, ‘Restore, Restart, Quit’ seems just a pointless out-of-world exercise.
I may agree that there is some sense to arriving at it, but I can’t agree that it is true. Emotional congruency is the issue. Technically the out-of-world actions may, by classifying themselves differently, escape an academic accusation of breaking continuity; but it’s a Pyrrhic victory, for in the emotional reality of the player, they do break that emotional congruity by ‘taking the player out of the game’. As a designer, I just don’t see any rational justification for that break; such breaks are to be done away with in narrative games, wherever possible. And in the case of ‘Restart, Restore, Quit’, the extra cruft is eminently discardable; ergo, it should be discarded. I still haven’t heard a single persuasive reason for keeping it. YMMV.
I sense this conversation will begin to move in circles soon (though it hasn’t quite, yet). I will return later to answer any objections that don’t seem to go over previously argued territory, but if I don’t see any, I think this thread has had enough of my advocacy on this point. Thanks, Jim, Robert, and Peter, for the great debate. 8)
Paul.
EDIT: Changed the mistakenly typed ‘lesser transgression’ to the intended phrase ‘greater transgression’, above.
Nice proof of concept, but I doubt anyone actually plays it.
If I absolutely had to play it, I’d make sure I’d lose before killing any aliens. Because, if I understand right, the more aliens you kill, the more random files you lose.
I can think of two ways to eliminate emotional incongruence. (a) Write a game in which the player never gets stuck, and never dies. (Eric and I did that in “Mrs. Pepper’s Nasty Secret.”) (b) Write conventional fiction rather than IF.
Even in these cases, however, the reader/player can put a bookmark in the book, or save the game, and not pick it up again for weeks, in which case emotional congruency is lost. I agree that a seamless experience is a desirable goal. I’m not sure the goal is achievable, that’s all. Each author has to decide how best to approach that goal, and the best approach may differ from one project to another.
In conventional fiction, an author might write one novel that follows the viewpoint of a single lead character faithfully from start to finish. In another novel, the same author might switch from one viewpoint character to another, jump back and forth in time, or even insert editorial asides in his or her own voice. The first method is not better than the second; it depends on the nature of the material one is working with.
True, but we are not talking about editorial asides here or a narrative voice – what we are talking about is just menu options, that’s all: just menu options. Restart. Restore (plus a file dialog). Quit. Nothing narratively redeeming about it. But you are also correct that utter seamlessness is not achievable in a retry loop; however, it’s not all or nothing. The less time spent out-of-world on pointless action, the better. When one is pulling a rabbit out of a hat, one does not show the audience the secret compartment in the hat (or whatever – I don’t know how they do that trick). You are still pulling a fast one, mind you, because magic isn’t real, but if you are going to do it, do it gracefully and don’t call attention to the secret gears.
