Exactly, while Vren spends more time adding new features and other core changes that aren't compatible with saves and therefore require new playthroughs. If Vren were to focus on story for a while, which has been out of focus for quite some time, there would be a period of save compatibility.
This isn't an issue with the game engine or it wouldn't matter what he focuses on, even story would cause this issue. The actual problem, and I use the word problem loosely here, is Vren's focus on adding features that include elements the saves from older versions cannot track. He's changing the way the game works on a constant basis and that messes with the saves. If he instead changed what the game told us instead of working under the hood, this would not be happening. For the record, I do understand he does need to make these changes at some point, that's why I used the word problem loosely, because what he is doing is a necessary step. He's just choosing to do it all at once whereas other Renpy developers tend to space out that kind of work, sometimes specifically to allow players some time in between having to restart because they know that some won't be happy with that even if it is unavoidable. Even with this type of game, it doesn't need to be the way it is, the way to change it is to shift focus to something that won't mess with saves like story development.
So far, everything in the story can be tracked with existing variables, so this is why I say that shifting focus to story development will stop the need to restart at least until something needs a new variable or something along those lines to continue the story, thus giving players some time between restarts. You don't even need to resort to default variables as long as nothing is getting added or removed as far as existing variables. As long as the variable already exists, it won't mess with saves this badly and it would even help main mod development.
Most games are like that and Renpy is largely a VN engine. It can do things outside of VNs, but it is best used as a VN engine, which is part of why most developers use it for VNs and not other types like this. This is part of why the original Lab Rats did so well on this engine, because it was essentially a VN with some management elements and not a full blown management game. Most developers would use something else entirely, Unity for example, for this kind of game, but that relies entirely on whether a developer has knowledge of the engine being chosen and Vren doesn't have knowledge of any other engine that I am aware of.
I agree on this last part, most probably don't understand it fully, potentially even experienced developers. I get some of it, likely due to my own background in programming with the old Visual Basic and the general knowledge that came with that background, though some of it is a bit more complicated than what I had to deal with. It does seem fairly limited if I'm understanding the save portions of the linked page correctly, being only able to save what can be returned to plus the current statement plus a couple other things. That can be a lot depending on the number that can be returned to, of which I am sure Renpy has a hard limit, which could be many or only a few.
Adding story content wouldn't usually cause any form of change in the save. The reason is that is essentially fixed data that doesn't change during the game. The dialog lines and so to that effect aren't adjusted and then saved back to a variable or built on the fly. Which is why none of that stuff causes an issue.
I get were you are coming from you are putting the blame on Vren for making the types of changes he is doing.
My point is if the engine was written differently he could still make changes like this and it not require new starting new games.
I know that for a fact because I develop game engines. That's where I spend most of my time these days building game engines.
Vren could have also done a few things differently at the start of the development for this project. If say the character attributes were saved in an array rather than as individual variables you could write the code then so it doesn't require a new start easily.
But like I said above most people don't fully get the implications of the way Renpy saves stuff.
Just because I say the engine is at fault for something doesn't mean I am saying the engine is bad. I'd say more the issue is this game is using an engine that isn't suited for the purpose he is wanting to use it for.
But if you want to fair assessment of the engine. It's excessively slow for what it does. If we simply look at the graphic performance and not bring python into the factor. Renpy is built on Pygame. Pygame can move about 1000 objects on screen at 60fps on a 3.0ghz system. Pygame is built on SDL2. But they don't fully use its capabilities instead for some reason they nerf the fuck out of it. You can move to pysdl2 and get 3400 objects moving on screen at 60fps. Use ModernGL with python and you can make use of several features that SDL2 doesn't and bump it up even more. Use Vulkan and you can get a bit more. Really depends on what you are doing and your skill at coding.
So there is a crap load of performance thrown the hell away this game engine could make use of.
If they made a glyph system with SDL2 textures rather than what they are doing now and moved to SDL2 textures and not just the surfaces they would get more than 3x performance.
You can still have the ability to change stuff while using texture. What you do is store a surface and then keep bool for if it is modified. If it is modified you copy it again to the texture. When it isn't modified you just keep using the texture as is. That way you get the ability to modify surfaces and the performance of textures.
The save and rollback system in Renpy:
He created a script system and the rollback system which was a good bit of work. However, they save a massive amount of information they don't need to. In most game engines we don't save the state of something like python. Renpy does. It also saves the state of its own functions right down to what function you are in and what iteration you are on in a for loop in renpy script. In C and C++ or even other python games we simply save the information to recreate the state of the game at that time.
You might think that won't work for rollback. You would be wrong.
You can create systems that are reversible. In fact there is an entire programming language that is reversible. You don't need to go that far though. What you are primarily in need of is the functions that effect variables and things like arrays and so on.
That would be things like add,sub,mul,div and anything that adds to an object,array, tuple,dic... It should be vastly a good bit easier under python than C and C++ for this. You primarily need to create a standard way at each scene to call a reverse on what was done. The simplest way is creating two functions one called forward and one called reverse. The character selection is provided to it for that event type or screen and it makes the change according to it. Yes, it means creating a forward and reverse for each scene but it doesn't mean doubling the code or anything like that. In truth variable manipulation in stuff like visual novels is rather low. Even in lab rats 2 it isn't that high.
Then you effectively need an vector or array in this case that stores a tuple with location and the change that happened so you can go back through it and just undo stuff. In the last system I used this on it amount to 2 variables one that was the game state and the other was the choice selection. The game state variable indicated location and screen and so on. This was made rather easy because we treated locations like screens the same.
The resulting difference in that method vs Renpy's is you can undo many more events for the amount of space renpy uses. Also because you aren't saving such a large amount of data each time with the auto update it will give back a lot of performance.
If you think its a lot of work we used a modified version on a proof of concept for a 2D rpg where all the characters actions that caused changes in their stats were saved. This was built into each character. That way we could look at the progress of the characters. We wanted the ability to rollback through it based on time so we did have to add a time stamp to the tuple in the array. You could then scroll through the time line allowing you to see each characters progression over time.
That said Renpy's method takes next to nothing for story developers to implement other than adhere to some guidelines.
With the system above you have two options. The first is build the reverse system into the script and that would be hidden as this is from the developers. Given he wrote a script and a more complex rollback system. I think the time would have been better doing that instead. But that's just an opinion based on stuff I built. The second alternative is the forward and reverse function method you can have game developers create for each scene and screen method. That would require the game / story developer to be actively involved in building the rollback methods. It also would require developers to learn a different design approach for building games from what they are currently using. So while this is a lot more efficient and would work for seasoned developers it wouldn't work for most of the developers who have little to no programming experience.
So Renpy's Save and Rollback system in my book is good. It isn't great and it isn't bad either.
If I looked at it based on target users I would rate it a good bit higher than I would for general users.
Lets say it was designed with people new to programming in mind. Then its a 8 or so.
If you look at it with the general user in mind including those with medium to advanced programming skills it drops to a 6.
If I was looking at it from an advance programmer perspective it drops to a 5. (Primarily because we don't have to spend time building it thus raising it up a point)
