The best would be unlimited UNDOs. That not being feasible, I feel like ten (Quixe when I last asked) is pretty good – if they’re guaranteed.
Eight is, to me, merely decent. This was a fixed number it was suggested some gave.
I also feel like doubling what is ‘pretty good’ to take it into the realms of healthy overcompensating would be, uh, really good. Like if Quixe could go to 20. It’s not a case of (me, anyway) wanting to eternally increase the limit, but lifting it out of the sort of querulous-in-my-practical-experience sub-10 area where it mostly seems to be. To go from ‘what will usually fix an immediate problem, without a safety margin’ to ‘what will comfortably fix an immediate problem’. At 20 moves, it’s probably no longer an immediate problem, but a broader desire to rewind the game which fits more with the unlimited undos paradigm.
Quixe has the limit hardcoded to ten, yes. Looks like I added that limit in the original Quixe undo implementation (2010!) and I’m pretty sure nobody’s raised the question since then.
It is in theory possible for the browser to run out of memory saving the undo stack. (It’s regular Javascript memory, not browser local storage.) There’s no check for this error and I imagine it’s not plausible, even playing Counterfeit Monkey on your phone. But nobody’s investigated that question either.
The Glulxe interpreter defaults to 8 but it now supports a command-line option to increase this. (Added 2022, so it’s new for this thread.)
As I recall, Git has a limit in kilobytes rather than a fixed number.
This idea came from a long time ago when I was trying to make a client/server version of FyreVM. The back-end server code would store every turn’s actions and auto-saves. It could then go back to any save point and replay any commands the user had already entered or start a branch.
I got it working to a point and then abandoned the project.
I had crazy game ideas where of you went backward and forked, you could change the story, like an alternate timeline story.
Is there anything non-programmy I can do to encourage a move to 10? I understand there are to-do’s, priorities, and it’s work for not-me someone or someones, and I don’t know how easy or hard it is.
Maybe more a bugbear is that I’m interested in seeing this go up to a respectable amount like 20 on most interpreters, and they’re using different approaches (e.g. the Git kb thing you @zarf mentioned).
@mathbrush … have you noted anything with NGUHD? Can you still UNDO your 8 steps or whatever right near the end of the game?
10 as what? Players of Inform games will never be guaranteed 10 for all interpreters. (Git will have a smaller default limit for playing huge games; there’s old interpreters out there; etc.)
The difference between “usually 8 or more” and “usually 10” does not seem like a strong case for trying to make a sweeping policy change. I think most players wouldn’t even notice the difference.
You could argue for increasing the limit on Quixe, in particular. Or Glulxe. Or for making the limit a user-settable preference in Lectrote. Or some combination of these?
Actually I’ve already forgotten why I said 10 at that point. Probably 10 guaranteed. Timidity? I had already said 20 would be a good idea, and is significantly different to 10.
I don’t care about old interpreters not doing this, or if they have tech that cannot guarantee a particular number. I’m not interested in this as a right-to-UNDO issue or a policy. I’m interested in what’s practically helpful and possible. I’m pushing for interpreters that are still being maintained to bump up a guaranteed amount if they can and be able to declare what that number is. 20 would make a helpful difference for any game, big or small, as 8-10 is the querulous zone as far as I’m concerned.
Right, well I’d argue for increasing it in Quixe and Glulxe to 20 guaranteed. I can’t see a benefit to making it a preference when one can give people a bigger reliable number.
Maybe this is too much worrying about indirect consequences, but I do not want people to get the idea that every interpreter has the same undo stack limit. That will cause problems. (In fact, it did cause problems in the Cragne Manor project.)
I am fine with the idea of increasing the default limit in Quixe and Glulxe to 20. But I am not okay with the message that 20 is some kind of interpreter standard. In fact I’m sort of tempted to make the Quixe limit 18 just to underline this fact!
(I’d also like to at least glance at how much memory a Counterfeit Monkey undo slot takes in Quixe, and compare that to the actual browser memory limit of, say, a five-year-old iPhone.)
This is how strand works right now. The world is changed by a series of deltas. but to replay, you don’t actually reprocess the commands, that’s rather crude. Instead you reapply deltas.
you can go back to any fork and continue down other branches. Except I don’t have the ui for it! that’s been the biggest problem of all. Visualizing the situation and options. Did you ever come up with a widget for this. It’s like trying to show people git branches in a simple way. But whatvis that simple way?
I’d be inclined to say that most terps should use at least 10MB of RAM for undos (unless they’re on such a limited platform that there isn’t enough RAM.)
I don’t know exactly how much space an undo state takes in memory, because it is stored differently than a regular Quetzal save file (usually without compressed memory), but a Counterfeit Monkey save file is about 200kb. Old Quixe versions that don’t use typed arrays would use a lot more space than that. Newer Quixe versions use typed arrays for the main RAM, but Arrays for the stack, so still not as optimal as could be.
Yeah, I just want ones that can, to have a bigger limit than they have now. It doesn’t have to be the same bigger. 20, 37, 40, 128, 200, whatever one can go with, it’s a meaningful help over the 8-10 give or take that seems to be the case for a range of interpreters at the moment, and the inifinite that’s not on the table. The give or take sounds like it can never go away with some terps and that’s always bad for writing docs for a game, or doing a commercial game (You have an UNDO command. How many will you get? Depends.)
You could do what Inform used to do, and forbid undoing twice in a row on the game side, because you can never guarantee the interpreter will supply more than one.
This might not be entirely on topic, but if you’re worried that your game might become unwinnable because an interpreter offers too few undos, an alternative might be to implement a checkpoint mechanism: save the game state to an external file at crucial moments and give the player a way to return to the most recent one.
Counterfeit Monkey secretly does this in one particular place.
That was a terrible approach; it should have been considered a library bug and fixed right away. Even on the Z-machine, the game can keep trying UNDO until the interpreter reports a failure. The game does not have to enforce anything.
