My problem with Rule 1 is I don't really understand the example
Rich is describing a problem some people have, because they copy games that were written a long time ago (or a newer game, which copied someone else, who copied someone else, who... etc. etc.)
The simplest way to think about it is that it is
strongly advised to "create" each variable using a
default statement. It doesn't matter where in the those
default statements exists, as RenPy effectively scans the whole code before the game starts running and processes each of those statements immediately (and ignores them later) as the game starts.
The "old way" of doing it was to have an
init: statement and have lines like
$ my_var1 = 0 for each of your variables. There are some inherent problems doing it that way that means it works 99% of the time for simple games and will come back to bite you in the arse because you didn't use
default. I only mention it, in case you see other people's code that do it that way.
Of course, it could be that your game doesn't use variables at all... and so your confusion is "what's a variable?"... to which my answer would be "don't worry about it".
So far I'm at the point of doing a save at the last frame of version 0.1.
I start version 0.2 the loading menu shows the save but always starts from the beginning.
It's difficult to diagnose without seeing the actual code. You say "last frame", but save points tend to be "last line of dialogue" (or maybe more accurately last true Renpy statement processed).
Your other work is PDF image sets from what I can see (I didn't look very hard)... Could it be that your "game" doesn't actually have any spoken dialogue in it? And is just a series of
scene and
pause statements?
Have you released v0.1 of your game? That is... could I download it to see if I can see anything obvious?
Because usually RenPy would only reset to the beginning if the structure of the game has changed too much since the
*.rpyc files were originally created. It's why Rich's rule #4 exists.
When RenPy loads a save file, it uses a very technical cross reference (stored in the
.rpyc files) of every line of code to try to figure out where it's up to. If you can imagine when you do a "rollback" while you're playing a game to step back through the game to an earlier point - the save system uses the same system. It tries to match things up to the latest line it knows the player saw, if it can't find that... it rolls back one statement and tries to find that... and keeps doing that until it either finds a match or gives up.
It's not quite this simple... but imagine a bit of code like:
Python:
mc "phrase 1" # id = 0001
e "phase 2" # id = 0002
mc "phrase 3" # id = 0003
If you save at "Phrase 2", the save file will record that you saved as "id #0002" (and the previous line was "id #0001").
If you then alter your code to be:
Python:
mc "phrase 1" # id = 0001
m "a new phrase" # id = 0004
e "phase 2" # id = 0002
mc "phrase 3" # id = 0003
The save file still works, even though "phrase 2" is the 3rd line of the code not the 2nd.
(it's nowhere near this simple).
Likewise, if you changed or deleted the line "phrase 2", the save would still work, because it would rollback to "phrase 1" - because that was the line last shown to the player according to the save file's log.
But if you delete the
.rpyc files or change the code so much that most/all of the unique id numbers for each line are unrecognizable between versions, then the "load" system will either get massively confused or revert to the start.
My last thought is that if the only person who's played v0.1 is yourself. Then don't worry about it. Save compatibility only really matters when there are save files out there in the world you have no control over.
