Lemma Soft Forums

Is it possible to limit the rollback so that it doesn't go past the last multi-way selection? You know, when you make your choice, there's no turning back and undoing it?

http://renpy.org/wiki/renpy/doc/referen ... ollback%29 ^^

I have another question regarding rollback, specifically in NVL-mode.

I noticed that what it does is simply erase the newly written line. Is it possible to make a style to differ the rollback screen from the standard nvl screen? For example, my nvl screen has a border which is 100% transparent (background can be seen). I would like that the rollback screen has no such border, make the text bold to differ it from nvl screen, and show it in pages rather than rows of text (meaning - it goes backwards one nvl page at a time, and not one nvl row at a time), and I would like to add a scrollbar too.

Is this all possible?

You are talking about 'Readback' mode.
Which is actually broken, I think.
And maybe no one's really too keen to fix a feature which is considered less useable than rollback.

Dunno, but the VNs I played ALL had readback functioning with no glitches. Then again, those were Kirikiri and Nscripter based. But I think it would be nice if readback was supported in Ren'py as well, simply as a GMs choice.

Question to PyTom: can you explain a bit more about why readback crashes the game when saving? Is it possible to make it in a way that doesn't affect saving the game? I would really appreciate a workaround on this subject, because, frankly, rollback in nvl mode looks a bit ridiculous to me ^^' (sorry for being honest ) Thanks as always!

The problem was that readback created a huge linked-list data structure. This was fine for small games, but larger games (and synthetic game-examples I use for testing Ren'Py) would crash due to the large amount of recursion required to pickle it.

Now, this is quite fixable, as one just needs to implement some sort of tree. But I don't like readback, so I haven't bothered. IMO, rollback is the superior option in almost every case, and one of the big advantages Ren'Py has over other game engines.

What makes you say "rollback in nvl mode looks a bit ridiculous to me"? At least for me, it seems fine... but if you have some sort of concrete objection, I can entertain adjusting it.

Well, let me explain myself. It doesn't look the way I had imagined it. I mean, it looks OK for adv mode, but in nvl mode it looks like reading the book in reverse! Meaning - where are my lines going? XD

OK; I know I'm ridiculous, but I can't help it. Regarding nvl-mode IMHO readback looks more plausible. You know I wouldn't bother to ask you if it's possible to fix the glitches, if I were that deep into python. But I'm not, although I'm getting my way around of it (studied C++ on college, though to a limited degree).

I'm just saying, if it's possible to implement fully functional readback feature in ren'py for GMs to choose, it would be nice. Even though I may be the only one in favor of that XD

I know I am not a coder, but, as far as I understand, only thing readback should do is to keep seen says (double-linked list for me)? So, if size of list is an issue, why not simply hard-limit it?

How big is this readback issue, time-wise needed to debug it? Because I would really, really, really love to employ readback in the VN my friend and I are currently working on. I hate myself because I can't code it myself, since I don't know what you mean when saying that some sort of tree should be implemented (and I'm not at all inclined towards Python, although I notice similarities with C++). Could you please, please, please (with sugar on top) really look into the readback and make it bug-free, because I honestly think it's a nice function to have when making a VN (hell, all the other VN engines have it).

Is anyone else in favor of doing this?

PS: Prologue is almost done now ^^

I have no plans to re-implement readback, since I think it's a lousy imitation of rollback. I worry that if I waste my time implementing readback, people will use it, and their games will be worse because of it.

What I am considering is modifying nvl-mode rollback to work in a page-at-a-time manner.

I fully support Py'Tom in this decision. It sounds like all you really want is to let you rollback NVL-mode a page at a time, which is a reasonable feature request.

If you really think you want readback rather than rollback - characterised by being able to see previous text but not change decisions - you have to ask yourself, "Why?"

Do you want to make the game harder for the user? Do you want to make the user stick to a single path at a time? All these kinds of reasons can be answered with, "But what are you going to do if they save the game at your decision points?" Or, for that matter, "But they can always start the game again."

Some players will play according to the rules of your game: they won't rollback from a silly death, or getting a question wrong, like in Reconstruction 101 or in EVEning Class. Other users won't. If you prohibit rollback, then they'll just save the game, or start again. You're needlessly frustrating both groups without achieving anything.

chronoluminaire wrote:If you really think you want readback rather than rollback - characterised by being able to see previous text but not change decisions - you have to ask yourself, "Why?"

I can reply to that but should I?
You blocked rollback in your combat system for ER, didn't you? I'm quite sure you had a good reason for that.
And I had been considering for a while to block rollback on my combat system as well, but with a solid reason: I had nothing against the player rolling back to retry a combat that has gone ill or even to switch tactics, a la Sands of Time... the problem is that, due to the way the combat functions were written, rolling back after an attack is granting the player its action points back, but is not restoring the monster's health... so the player could use this glitch to impunely massacre my beloved monsters without them having their legitimate chance to retaliate ... and this would even happen if the player has no "cheaty" intentions and just wants, for example, to switch tactics.
While I've looked at some approaches to fix this, I'm keeping this behaviour by now because it helps testing the combats' balance; and I plan to entirely rebuild the combat system anyway
But the point is that there are some situations where rollback cannot be kept, and you know that well enough. On such cases, having readback could make a fair alternative that works these glitches around.
OTOH, I understand PyTom's viewpoint, and I also think that adding readback to the engine would only lead to many games becoming worse, while very few cases would improve thanks to it. In other words, I think there are some reasons in favor or readback, but are not enough to justify the issues it would arise.

As a last point, I'd like to mention that anyone messing so much with the natural Ren'py gameflow to need blocking rollback should be able to either find a workaround, implement readback from zero, or simply not mess so much with the engine (yes, this applies to me as well , but I can't help it: I have to mess things up continuously, I can't sleep if I don't )

chronoluminaire wrote:"But what are you going to do if they save the game at your decision points?"

I have to reply to that one I will be blocking save/load on my next project, and I've good reasons.

herenvardo wrote:

chronoluminaire wrote:If you really think you want readback rather than rollback - characterised by being able to see previous text but not change decisions - you have to ask yourself, "Why?"

I can reply to that but should I?
You blocked rollback in your combat system for ER, didn't you? I'm quite sure you had a good reason for that.

Heh. OK, fair comment. Yes, for minigames or sections where the primary gameplay isn't VN-style but something else, I agree, rollback shouldn't necessarily apply. I may well have blocked it in the Elven Relations combats, and I'm expecting to in the TileEngine & UnitEngine.
(Actually, thinking back, I don't think rollback was disabled in the ER combats. I think it worked fully. I'm faintly surprised that I managed that, but ISTR that it worked. But I certainly wouldn't expect minigames to allow rollback in the general case.)

herenvardo wrote:But the point is that there are some situations where rollback cannot be kept, and you know that well enough. On such cases, having readback could make a fair alternative that works these glitches around.

Hmm. From what I understand of the technical reasons why rollback doesn't work with your and my combat engines, I think the same would apply with readback.
What I'd quite like to do is the following:
* Disable rollback during the TileEngine / UnitEngine sessions themselves
* But once the user's finished a combat, allow them to rollback and rollforward past it, to review the VN segments before and after it without replaying the combat itself.
I think this'll be possible, from what I've seen of the intimidating and arcane rollback hooks that are scattered throughout Ren'Py, but I'm pretty sure I'll need some help to achieve it. But that's a topic for a different discussion

herenvardo wrote:

chronoluminaire wrote:"But what are you going to do if they save the game at your decision points?"

I have to reply to that one I will be blocking save/load on my next project, and I've good reasons.

That game is going to be a RPG as well, it will feature five difficulty levels (easy, normal, hard, hardcore, and nightmare), and on the last two saving and rolling back will be disabled: the game will auto-save at certain points; and this will obviously be done to increase difficulty.

Whoo! Controversial. I can see why you'd do it, but...

Philosophically, the same points apply, though. Saving the game at a given point is just a neat technological shorthand for making the user replay every action they've taken in the game up to that point. If there are real-time or dexterity elements (or randomness ), then the user might not be able to perfectly replicate their actions, but the same principle basically applies. There's an interesting philosophical debate to be had over allowing saving games in non-VN gameplay - for example, a number of people playing SNES RPGs like Chrono Trigger in a SNES emulator will be very glad of the emulator-provided ability to save the game at any point, rather than just at the save-points the game provides. But then again, difficulty settings meet a lot of this need.

I'm rambling again. I'd better stop.

Never ever forget about Saving Because Something Is Burning At The Door, or in other words, saving because real life is calling. Games not allowing you to save at anytime are a kick to the groin in those cases. Maybe you were *about* to finish a segment, but just because you have real life friends ringing at the door, or because you suddenly have to go somewhere, you're done for. That's not very nice .
I'm more understanding of the scheme used in roguelikes which kills a savegame when you die, as you can still save whenever you like... but dying means dying, just as it meant dying in old arcade games when you lost your three lives.

monele wrote:Never ever forget about Saving Because Something Is Burning At The Door, or in other words, saving because real life is calling. Games not allowing you to save at anytime are a kick to the groin in those cases. Maybe you were *about* to finish a segment, but just because you have real life friends ringing at the door, or because you suddenly have to go somewhere, you're done for. That's not very nice .

Although nothing about that project is definitive (I've more imminent worries in mind right now), my original idea was to implement something like Diablo II's Save & Quit (the game gets saved when, and only when, you quit to the menu or to the desktop); plus some auto-save points in those places you're quite likely to die (ie: when entering dungeons) for hardcore; then only Save & Quit for Nightmare. The idea is that whenever you quit and come back, you can continue from where you left; and on Hardcore you're still allowed some "retries" in the toughest parts of the game. (Note: unlike in Diablo, monsters you kill will be gone and won't "repop" when you come back). And keep in mind that the main point of these über difficulty setups is to provide a real challenge for those players who complete the many endings required in "hard" mode