Episode Updates using Renpy

[CheekyGimp]

Hey Folks,

I could probably find this out with a little trial & error, but I'm under some time pressures, so thought I'd ask here to see if I can get some inputs.
I've been releasing my game in monthly episodes and with each new episode, I package the whole game up as a distributable. So the game size is obviously getting bigger with each new update.
The main differences with each new update would be some changes to some of the script.rpy files, a new script file for the new epsiode (e.g. Ep6.rpy) plus a new image folder with all the new renders (e.g. Ep6Images/).
But with each update people end up downloading a lot of content they already have, such as all the renders from the previous episodes.
So my question is: Instead of packaging the whole game up, could I just package up the new content (the new image folder, the new script folder and any edited .rpy files) and just post that for download (players would just drop the new content into their existing game directory).
I'm assuming it's relatively straight-forward, but just wondering what's the best way to do it and is there any gotchas/potential issues that I'd need to look out for?

Thanks,

 

[UncleVT]

Perhaps @Palanto can help you. He has implemented a good system in

You must be registered to see the links

.

 

[bas]

Hey Folks,

I could probably find this out with a little trial & error, but I'm under some time pressures, so thought I'd ask here to see if I can get some inputs.
I've been releasing my game in monthly episodes and with each new episode, I package the whole game up as a distributable. So the game size is obviously getting bigger with each new update.
The main differences with each new update would be some changes to some of the script.rpy files, a new script file for the new epsiode (e.g. Ep6.rpy) plus a new image folder with all the new renders (e.g. Ep6Images/).
But with each update people end up downloading a lot of content they already have, such as all the renders from the previous episodes.
So my question is: Instead of packaging the whole game up, could I just package up the new content (the new image folder, the new script folder and any edited .rpy files) and just post that for download (players would just drop the new content into their existing game directory).
I'm assuming it's relatively straight-forward, but just wondering what's the best way to do it and is there any gotchas/potential issues that I'd need to look out for?

Thanks,

I'd recommend compressing your game assets to make the download smaller. Not quite so much as I do with my compressed versions, but start with lossless webp and see what that does for you. Sam wrote a nice program for it here:

You must be registered to see the links

I'd caution against releasing updates; if you look at the "Wicked Choices" thread after every update there's at minimum a full page of "how do I update this?" and "where's the full version?" comments, sometimes 2-3 pages. They made a video showing how to do it step-by-step, linked in the OP, and people still don't watch it. This all just distracts the conversation away from the new content in your game on that update & frustrates your less computer-savvy players.

Feel free to ping me on discord if you need a hand with compression.

 

[thecardinal]

To back up boss, compression is the way to go. This way you just upload the entire game instead of picking apart the pieces they need to update.

 

[CheekyGimp]

I'd recommend compressing your game assets to make the download smaller. Not quite so much as I do with my compressed versions, but start with lossless webp and see what that does for you. Sam wrote a nice program for it here:

You must be registered to see the links

I'd caution against releasing updates; if you look at the "Wicked Choices" thread after every update there's at minimum a full page of "how do I update this?" and "where's the full version?" comments, sometimes 2-3 pages. They made a video showing how to do it step-by-step, linked in the OP, and people still don't watch it. This all just distracts the conversation away from the new content in your game on that update & frustrates your less computer-savvy players.

Feel free to ping me on discord if you need a hand with compression.

I knew you'd have some good inputs, but didn't want to ping you directly, bothering you with every question I have. Thanks Boss.

 

[Palanto]

I'd recommend compressing your game assets to make the download smaller. Not quite so much as I do with my compressed versions, but start with lossless webp and see what that does for you. Sam wrote a nice program for it here:

You must be registered to see the links

I'd caution against releasing updates; if you look at the "Wicked Choices" thread after every update there's at minimum a full page of "how do I update this?" and "where's the full version?" comments, sometimes 2-3 pages. They made a video showing how to do it step-by-step, linked in the OP, and people still don't watch it. This all just distracts the conversation away from the new content in your game on that update & frustrates your less computer-savvy players.

Feel free to ping me on discord if you need a hand with compression.

Well compression is a good start, but depending on how big the game gets it would still be better to do it in updates. Though you're right it takes a lot of time and .... nerves... to get the less computer-savvy players to get it to work (although we do a full version each time by now too... but the OP is just badly written and I don't have rights to edit it )
I don't see many players having troubles with it in the Depraved Awakenings thread... Maybe it's because of the age difference.... I don't know One thing I'm certain about is that if more devs would do it, people would learn it more quickly... And like I said, it's not necessary for everyone to "update" the game, most users could just download the full game file. But some people have limited bandwith or slow internet connections, for those players it's fair to say they would rather watch a video tutorial or read a how to then to download a 3.76GB (Uncompressed, for those full HD fanatics) big game like Wicked Choices over and over again.
Well there are, as always, pros and cons.
Pros:

1. smaller download sizes for people with limited bandwith or slow internet connections.
2. smaller upload size for the dev
3. easy patching of script files

​

Cons:

1. Each update the same question... "How do p4tch in g4m3files put where?" Or... well you know what I mean :'(
2. People talking about how to patch instead of how good/bad the new content was..
3. People rating the game negatively because they weren't intelligent enough to read how to update the game...

Hey Folks,

I could probably find this out with a little trial & error, but I'm under some time pressures, so thought I'd ask here to see if I can get some inputs.
I've been releasing my game in monthly episodes and with each new episode, I package the whole game up as a distributable. So the game size is obviously getting bigger with each new update.
The main differences with each new update would be some changes to some of the script.rpy files, a new script file for the new epsiode (e.g. Ep6.rpy) plus a new image folder with all the new renders (e.g. Ep6Images/).
But with each update people end up downloading a lot of content they already have, such as all the renders from the previous episodes.
So my question is: Instead of packaging the whole game up, could I just package up the new content (the new image folder, the new script folder and any edited .rpy files) and just post that for download (players would just drop the new content into their existing game directory).
I'm assuming it's relatively straight-forward, but just wondering what's the best way to do it and is there any gotchas/potential issues that I'd need to look out for?

Thanks,

Potential issues... see above

But if you still want to do it as episodic/chapter updates, I can give you some tips on how to do it.
First you'd want to make sure that your "episodic" images are in a seperate folder each. Like this:
/game/images/episode01
/game/images/episode02

and so on.

Then you have to open your options.rpy and create new archives for the images and one archive for all script files. And you also need to remove the standard 'archive' line which creates the archive.rpa with all files inside.
This could look like this:

    ## Classify files as None to exclude them from the built distributions.

    build.classify('**~', None)
    build.classify('**.bak', None)
    build.classify('**.bk', None)
    build.classify('**/.**', None)
    build.classify('**/#**', None)
    build.classify('**/thumbs.db', None)
    build.classify('**/desktop.ini', None)
    build.classify('game/**.rpy', None)
    build.classify('game/saves/**', None)
    build.classify('game/cache/**', None)
    build.classify('.git/**', None)
    build.classify('.gitattributes', None)
    build.classify('.gitignore', None)
    build.classify('README.md', None)


    ##  Creating the Archives
# build.archive('Archive Name', 'File Types')
    build.archive('scripts', 'all')
    build.archive('gui', 'all')
    build.archive('audio', 'all')
    build.archive('video', 'all')
    build.archive('episode01', 'all')


    # All Script Files
# build.classify('Folder/filename.filetype', 'Archive Name') * = any name of the filetype only in this folder, ** = include subfolders
    build.classify('game/**.rpyc', 'scripts')

    # GUI
    build.classify('game/gui/**', 'gui')

    # Audio
    build.classify('game/audio/**', 'audio')

    # Video
    build.classify('game/video/**', 'video')

    ## Episode specific ##

    # Episode 1 #
    build.classify('game/images/Episode01/**', 'episode01')

See that I exclude .rpy files and only include the .rpyc in the scripts.rpa? That's not necessary but I like to give players some more trouble to extract the files Because some people just "shouldn't" check and mess around with the script files

Now you should have an episode01.rpa which holds all the images of episode 1, a scripts.rpa for alle the script files (pretty small so best to keep it as a seperate single file for all script files if you need to patch something), a gui.rpa for all gui elements (if you want to seperate it), an audio.rpa which holds all audio files in your game/audio/ folder and the same for videos in the video.rpa

Now, if you want to add episode two, just add those two lines:

    build.archive('episode02', 'all')

    build.classify('game/images/Episode02/**', 'episode02')

please watch out for upper / lower cases
Well here's how the options.rpy would look like with episode 02 added:

    ## Classify files as None to exclude them from the built distributions.

    build.classify('**~', None)
    build.classify('**.bak', None)
    build.classify('**.bk', None)
    build.classify('**/.**', None)
    build.classify('**/#**', None)
    build.classify('**/thumbs.db', None)
    build.classify('**/desktop.ini', None)
    build.classify('game/**.rpy', None)
    build.classify('game/saves/**', None)
    build.classify('game/cache/**', None)
    build.classify('.git/**', None)
    build.classify('.gitattributes', None)
    build.classify('.gitignore', None)
    build.classify('README.md', None)


    ##  Creating the Archives
    build.archive('scripts', 'all')
    build.archive('gui', 'all')
    build.archive('audio', 'all')
    build.archive('video', 'all')

    build.archive('episode01', 'all')
    build.archive('episode02', 'all')


    # All Script Files
    build.classify('game/**.rpyc', 'scripts')

    # GUI
    build.classify('game/gui/**', 'gui')

    # Audio
    build.classify('game/audio/**', 'audio')

    # Video
    build.classify('game/video/**', 'video')

    ## Episode specific ##

    # Episode 1 #
    build.classify('game/images/Episode01/**', 'episode01')

    # Episode 2 #
    build.classify('game/images/Episode02/**', 'episode02')

Now all you'd have to do is create the distributables, you'd then get the full game as a .zip file, now copy this file and rename it to let's say... Update_Episode02 or whatever you want to call it.
Then open the zip file and delete all the unnecessary .rpa files in the game folder, so that only the "scripts.rpa", "episode02.rpa" and eventually other rpa's you made changes to are left inside the zip. That's it, now all the players have to do is extract the files and replace the old ones which got changed (i.e. scripts.rpa)
If you didn't update renpy between game updates, all you'd have to upload are the new .rpa files, else you'd also have to upload all the renpy internal files that are inside the distributables (I still do it always just in case, instead of deleting those small files...)

One thing that might help with the patching process would be to name the "created directory" inside the zip files always the same (without adding the version number i.e.)
This can be achieved by using this line of code in the options.rpy:

build.name = "YourGameName"

You must be registered to see the links

build.name = "..."

This is used to automatically generate build.directory_name and build.executable_name, if neither is set. This should not contain spaces, colons, or semicolons.

build.directory_name = "..."

This is used to create the names of directories in the archive files. For example, if this is set to "mygame-1.0", the Linux version of the project will unpack to "mygame-1.0-linux".

This is also used to determine the name of the directory in which the package files are placed. For example, if you set build.directory_name to mygame-1.0, the archive files will be placed in mygame-1.0-dists in the directory above the base directory.

This variable should not contain special characters like spaces, colons, and semicolons. If not set, it defaults to

You must be registered to see the links

a dash, and

You must be registered to see the links

.

build.executable_name = "..."
This variable controls the name of the executables that the user clicks on to start the game.

This variable should not contain special characters like spaces, colons, and semicolons. If not set, it defaults to

You must be registered to see the links

.

For example, if this is set to "mygame", the user will be able to run mygame.exe on Windows, mygame.app on Macintosh, and mygame.sh on Linux.

 

[CheekyGimp]

Well compression is a good start, but depending on how big the game gets it would still be better to do it in updates. Though you're right it takes a lot of time and .... nerves... to get the less computer-savvy players to get it to work (although we do a full version each time by now too... but the OP is just badly written and I don't have rights to edit it )
I don't see many players having troubles with it in the Depraved Awakenings thread... Maybe it's because of the age difference.... I don't know One thing I'm certain about is that if more devs would do it, people would learn it more quickly... And like I said, it's not necessary for everyone to "update" the game, most users could just download the full game file. But some people have limited bandwith or slow internet connections, for those players it's fair to say they would rather watch a video tutorial or read a how to then to download a 3.76GB big game like Wicked Choices over and over again.
Well there are, as always, pros and cons.
Pros:

1. smaller download sizes for people with limited bandwith or slow internet connections.
2. smaller upload size for the dev
3. easy patching of script files

​

Cons:

1. Each update the same question... "How do p4tch in g4m3files put where?" Or... well you know what I mean :'(
2. People talking about how to patch instead of how good/bad the new content was..
3. People rating the game negatively because they weren't intelligent enough to read how to update the game...

Potential issues... see above

But if you still want to do it as episodic/chapter updates, I can give you some tips on how to do it.
First you'd want to make sure that your "episodic" images are in a seperate folder each. Like this:
/game/images/episode01
/game/images/episode02

and so on.

Then you have to open your options.rpy and create new archives for the images and one archive for all script files. And you also need to remove the standard 'archive' line which creates the archive.rpa with all files inside.
This could look like this:

    ## Classify files as None to exclude them from the built distributions.

    build.classify('**~', None)
    build.classify('**.bak', None)
    build.classify('**.bk', None)
    build.classify('**/.**', None)
    build.classify('**/#**', None)
    build.classify('**/thumbs.db', None)
    build.classify('**/desktop.ini', None)
    build.classify('game/**.rpy', None)
    build.classify('game/saves/**', None)
    build.classify('game/cache/**', None)
    build.classify('.git/**', None)
    build.classify('.gitattributes', None)
    build.classify('.gitignore', None)
    build.classify('README.md', None)


    ##  Creating the Archives
# build.archive('Archive Name', 'File Types')
    build.archive('scripts', 'all')
    build.archive('gui', 'all')
    build.archive('audio', 'all')
    build.archive('video', 'all')
    build.archive('episode01', 'all')


    # All Script Files
# build.classify('Folder/filename.filetype', 'Archive Name') * = any name of the filetype only in this folder, ** = include subfolders
    build.classify('game/**.rpyc', 'scripts')

    # GUI
    build.classify('game/gui/**', 'gui')

    # Audio
    build.classify('game/audio/**', 'audio')

    # Video
    build.classify('game/video/**', 'video')

    ## Episode specific ##

    # Episode 1 #
    build.classify('game/images/Episode01/**', 'episode01')

See that I exclude .rpy files and only include the .rpyc in the scripts.rpa? That's not necessary but I like to give players some more trouble to extract the files Because some people just "shouldn't" check and mess around with the script files

Now you should have an episode01.rpa which holds all the images of episode 1, a scripts.rpa for alle the script files (pretty small so best to keep it as a seperate single file for all script files if you need to patch something), a gui.rpa for all gui elements (if you want to seperate it), an auio.rpa which holds all audio files in your game/audio/ folder and the same for videos in the video.rpa

Now, if you want to add episode two, just add those two lines:

    build.archive('episode02', 'all')

    build.classify('game/images/Episode02/**', 'episode02')

please watch out for upper / lower cases
Well here's how the options.rpy would look like with episode 02 added:

    ## Classify files as None to exclude them from the built distributions.

    build.classify('**~', None)
    build.classify('**.bak', None)
    build.classify('**.bk', None)
    build.classify('**/.**', None)
    build.classify('**/#**', None)
    build.classify('**/thumbs.db', None)
    build.classify('**/desktop.ini', None)
    build.classify('game/**.rpy', None)
    build.classify('game/saves/**', None)
    build.classify('game/cache/**', None)
    build.classify('.git/**', None)
    build.classify('.gitattributes', None)
    build.classify('.gitignore', None)
    build.classify('README.md', None)


    ##  Creating the Archives
    build.archive('scripts', 'all')
    build.archive('gui', 'all')
    build.archive('audio', 'all')
    build.archive('video', 'all')

    build.archive('episode01', 'all')
    build.archive('episode02', 'all')


    # All Script Files
    build.classify('game/**.rpyc', 'scripts')

    # GUI
    build.classify('game/gui/**', 'gui')

    # Audio
    build.classify('game/audio/**', 'audio')

    # Video
    build.classify('game/video/**', 'video')

    ## Episode specific ##

    # Episode 1 #
    build.classify('game/images/Episode01/**', 'episode01')

    # Episode 2 #
    build.classify('game/images/Episode02/**', 'episode02')

Now all you'd have to do is create the distributables, you'd then get the full game as a .zip file, now copy this file and rename it to let's say... Update_Episode02 or whatever you want to call it.
Then open the zip file and delete all the unnecessary .rpa files in the game folder, so that only the "scripts.rpa", "episode02.rpa" and eventually other rpa's you made changes to are left inside the zip. That's it, now all the players have to do is extract the files and replace the old ones which got changed (i.e. scripts.rpa)
If you didn't update renpy between game updates, all you'd have to upload are the new .rpa files, else you'd also have to upload all the renpy internal files that are inside the distributables (I still do it always just in case, instead of deleting those small files...)

One thing that might help with the patching process would be to name the "created directory" inside the zip files always the same (without adding the version number i.e.)
This can be achieved by using this line of code in the options.rpy:

build.name = "YourGameName"

You must be registered to see the links

Great detail - Thanks

 

[Palanto]

Great detail - Thanks

You're welcome, if there's anything you don't understand about it, just ask I'll try to clarify it then

 

[OhWee]

I'm a huge fan of either/or when it comes to updates.

Others have already explained this in more detail, but I'll explain my thoughts on the subject.

The script.rpy file (and other .rpy files) is very tiny when compared to the other assets included in a download (pics, etc.). So overwriting script.rpy(rpyc/rpa) when doing a new update is a good way to go if you like everything consolidated, if you are going the 'patch' route.

As a modder, I usually modify other files, because script.rpy (or the files that are story related) regularly gets changed, but since you are the author of the game, yeah that's a different story. When I made story related changes, then I'd still modify script.rpy. or whichever other file was appropriate.

So, when you do a new release, you can easily create a 'patch' for an existing install, adding only the new images along with the new script. This drastically reduces download sizes for newly added chapters for games with lots of updates.

You can just include the new images in the game/images folder in the patch to add the new images (merging the folders when you apply the patch), or if you like to be more organized, create a new images subfolder for the new chapter's images. Dreams Of Desire and Dating My Daughter do this, for example.

As a 'lazy' modder, I don't bother with compiling, or creating a special patch.exe or whatever. I just simply tell people to drag the main mod/patch folder into the game's folder, where it automatically places/merges the new files (located in the appropriate subfolders within that main folder) with the existing install.
I usually ask them to run unren.bat as well, to separate script.rpa into it's subcomponents, since I'm often overwriting screens.rpy, etc., but that may be an unnecessary step if you set up your patch properly (it's been a bit since I messed with this).

People that are more skilled with such things will sometimes create a 'one click' patch file to do this, for people that are more intimidated by the 'drag folder from .zip into 'title of game' folder, now which folder do I drag to again?' thing.

You should still provide a 'full' updated version, though, for people that haven't played your game before, so that they don't have to go through the headache of combining one or more patches with the base game.

Another thing you can do is have the script itself segregated into episodes (i.e. not a single script.rpy). When you finish an episode, at the end of the script for that episode, you put a 'jump' to a placeholder file for the next episode. So if the script/story is ending in episode6.rpy, you'd jump to script in a 'placeholder' episode7.rpy, which simply has the 'to be continued' screen. Then, when you complete episode 7, you simply overwrite episode7.rpy with a new file, and create a new placeholder episode8.rpy for the next chapter.

You get the idea here. As for compiling it, yeah I'll defer to others that regularly compile patches r.e. the best way to compile just the updated script.rpy and/or other script file(s) for the new chapter, along with the newly added images. It's been a few months since I've messed with code, but Renpy is very 'next chapter patch' friendly if you set it up properly.

 

[CheekyGimp]

I'm a huge fan of either/or when it comes to updates.

Others have already explained this in more detail, but I'll explain my thoughts on the subject.

The script.rpy file (and other .rpy files) is very tiny when compared to the other assets included in a download (pics, etc.). So overwriting script.rpy(rpyc/rpa) when doing a new update is a good way to go if you like everything consolidated, if you are going the 'patch' route.

As a modder, I usually modify other files, because script.rpy (or the files that are story related) regularly gets changed, but since you are the author of the game, yeah that's a different story. When I made story related changes, then I'd still modify script.rpy. or whichever other file was appropriate.

So, when you do a new release, you can easily create a 'patch' for an existing install, adding only the new images along with the new script. This drastically reduces download sizes for newly added chapters for games with lots of updates.

You can just include the new images in the game/images folder in the patch to add the new images (merging the folders when you apply the patch), or if you like to be more organized, create a new images subfolder for the new chapter's images. Dreams Of Desire and Dating My Daughter do this, for example.

As a 'lazy' modder, I don't bother with compiling, or creating a special patch.exe or whatever. I just simply tell people to drag the main mod/patch folder into the game's folder, where it automatically places/merges the new files (located in the appropriate subfolders within that main folder) with the existing install.
I usually ask them to run unren.bat as well, to separate script.rpa into it's subcomponents, since I'm often overwriting screens.rpy, etc., but that may be an unnecessary step if you set up your patch properly (it's been a bit since I messed with this).

People that are more skilled with such things will sometimes create a 'one click' patch file to do this, for people that are more intimidated by the 'drag folder from .zip into 'title of game' folder, now which folder do I drag to again?' thing.

You should still provide a 'full' updated version, though, for people that haven't played your game before, so that they don't have to go through the headache of combining one or more patches with the base game.

Another thing you can do is have the script itself segregated into episodes (i.e. not a single script.rpy). When you finish an episode, at the end of the script for that episode, you put a 'jump' to a placeholder file for the next episode. So if the script/story is ending in episode6.rpy, you'd jump to script in a 'placeholder' episode7.rpy, which simply has the 'to be continued' screen. Then, when you complete episode 7, you simply overwrite episode7.rpy with a new file, and create a new placeholder episode8.rpy for the next chapter.

You get the idea here. As for compiling it, yeah I'll defer to others that regularly compile patches r.e. the best way to compile just the updated script.rpy and/or other script file(s) for the new chapter, along with the newly added images. It's been a few months since I've messed with code, but Renpy is very 'next chapter patch' friendly if you set it up properly.

Two episodes ago, I started creating a new script.rpy (e.g. Ep6.rpy with a jump command) and an image folder for each new episode. And I agree with your suggestion... if I do decide to take the option of uploading the new material only, I will still create a "full version" for new players or for those that don't care about download speed and/or don't want to overwrite existing folders. Thanks

 

[xMentat]

I'm a software developer to trade, and these suggestions all hit the mark for me. Have a plan before you do release 0 (or 0.1 or 0.0.1 ...). Software development is relatively easy, sometimes the hard bit is dealing with the distribution (release, whatever!).

 

[anne O'nymous]

As a modder, I usually modify other files, because script.rpy (or the files that are story related) regularly gets changed, but since you are the author of the game, yeah that's a different story. When I made story related changes, then I'd still modify script.rpy. or whichever other file was appropriate.

This make me think... You must also never split your scripts files over multiples archives.
It's tempting when you have one rpy file by day/update, to simply join it to the images and put it in the day/uptade X rpa file. But by doing this, you'll mess with people using mods made the way OhWee said. They'll have part of the game modded, because the files have been directly modified by the mod and not updated by your patch, and part of the game unmodded (all the updated files).
And if the player didn't made a backup of the files before installing the mod, and didn't thought to restore the modded files by using it, you can be sure that he will also blame you, and not the mod, for the "shitty update that don't even works at all".

I'm a software developer to trade, and these suggestions all hit the mark for me. Have a plan before you do release 0 (or 0.1 or 0.0.1 ...). Software development is relatively easy, sometimes the hard bit is dealing with the distribution (release, whatever!).

Er... as senior coder I fail to see where you want to go. Whatever if they precisely planned a release schedule and follow it strictly, or if at the opposite they go like the wind. Anyway they'll face exactly the same problem the day they'll have to release the new update. And they'll face it in exactly the same way, they'll have new images to add and at least one new script file.
There's simply no way to avoid, prevent or change this. The only thing that can be changed is how they'll do it. But in the end it will still stay the same exact problem, which have nothing to do with the existence or not of a planned release schedule.

 

[OhWee]

This make me think... You must also never split your scripts files over multiples archives.
It's tempting when you have one rpy file by day/update, to simply join it to the images and put it in the day/uptade X rpa file. But by doing this, you'll mess with people using mods made the way OhWee said. They'll have part of the game modded, because the files have been directly modified by the mod and not updated by your patch, and part of the game unmodded (all the updated files).
And if the player didn't made a backup of the files before installing the mod, and didn't thought to restore the modded files by using it, you can be sure that he will also blame you, and not the mod, for the "shitty update that don't even works at all".
(snip)

Says who? You say MUST, but in fact multiple Renpy game/vn designers do exactly this - split their scripts by day over multiple days. Or subdivide the script over multiple files for whatever other reason they may have (thinking specifically of Spaced Out here). There is no MUST about anything. How people choose to code their own Renpy games is entirely up to them, and at the end of the day, the only thing that matters is if their particular scripting choices work or not.

Sure, it can be easier for modders to understand if you use a unified script.rpy, but some people actually don't like to see their games/vns modded, and take extra steps to make this more difficult. Or they do it their own way because it makes the most sense to them. If it works at the end of the day, without issues (i.e. without visible error message screens), that's all that really matters.

I've also seen people create separate .rpy's for assigning variables as a 'master variable list' (instead of doing this at the beginning of script.rpy), and similar for image lists. Nothing wrong with that at all, and it works.

The reference to my personal mods comes from the fact that i often modify the interface in some way (to make it more visually appealing, to provide people with additional information, and/or to incorporate additional functionality), which is why I tended to modify say screens.rpy instead for such things. Sometimes, new 'features' added to the interface require a new variable to be created, so adding that interface variable via screens.rpy (which generally doesn't see changes every time a new update comes out) can save a modder time in the future by not requiring an interface update for every story update.

I also include 'back up your files' instructions in the readme's for my mods, so that if people want to revert back they can. They don't HAVE to back up the files, but I do recommend it. People that are skilled with making patch.exe's (or some other format to apply the patch using the app) will often incorporate that into their patch, and sometimes will also include an 'uninstall mod' into said .exe's (etc.).

I've had a couple of interface mods now that I've been able to say 'still works with the latest update' for several new versions of those games, and one was eventually incorporated into the game itself because the game designer liked what I did better, making my mod obsolete.

It all really comes down to individual preference. So be careful with that use of the word MUST, and pontificating how YOU think things should work. Expressing your thoughts on what you think works best is one thing, but there are very few absolutes in coding. It's as much about style and personal preference as it is about using code that works.

 

[anne O'nymous]

So be careful with that use of the word MUST, and pontificating how YOU think things should work.

Can I also give you an advice ? If you could be careful when you read a comment and take the time to ensure that you reply to what is effectively wrote, it would be nice. Because what I wrote is : "You must also never split your scripts files over multiples archives."
Note that the last word is "archives", not "files" ; in fact also note that I also wrote "files" with a final 's' (I even unnecessarily put it at "script"). Therefore, once again you responded completely outside of what I talked about and, once again, it really looks like you took it as a personal attack. This start to be really annoying.
So, don't know, if my English is so bad that you can't understand it, or if it's just that you can't stand me for whatever reason, just ignore me, it will save time to everyone.

 

[OhWee]

Can I also give you an advice ? If you could be careful when you read a comment and take the time to ensure that you reply to what is effectively wrote, it would be nice. Because what I wrote is : "You must also never split your scripts files over multiples archives."
Note that the last word is "archives", not "files" ; in fact also note that I also wrote "files" with a final 's' (I even unnecessarily put it at "script"). Therefore, once again you responded completely outside of what I talked about and, once again, it really looks like you took it as a personal attack. This start to be really annoying.
So, don't know, if my English is so bad that you can't understand it, or if it's just that you can't stand me for whatever reason, just ignore me, it will save time to everyone.

ACTUALLY, Renpy does support using separate .rpa files for patches.

[Tutorial] Making a Separate Content Patch

You must be registered to see the links

Now if your point was to make sure that you don't duplicate essentially the same script file in separate .rpas (hence asking renpy to 'choose' between two script.rpy's), that's a valid point, but patches/updates CAN be compiled into separate .rpas. But don't take my word for it, that's what the Tutorial linked above is for.

There are tricks you can use to supercede a script.rpy (or other file) with a newer one, but that's a different conversation. This entry from the renpy documentation talks about this, but I've personally never messed with this code:

define config.archives = [ ]

A list of archive files that will be searched for images and other data. The entries in this should consist of strings giving the base names of archive files, without the .rpa extension.

The archives are searched in the order they are found in this list. A file is taken from the first archive it is found in.

At startup, Ren'Py will automatically populate this variable with the names of all archives found in the game directory, sorted in reverse ascii order. For example, if Ren'Py finds the files data.rpa, patch01.rpa, and patch02.rpa, this variable will be populated with ['patch02', 'patch01', 'data'].

Another thing you can do is to not archive your 'patch' files, just the base files, so that the patch files are simply overwritten by the newer version without messing with the archive. Put the 'check for a file, if exists do 'b' instead of 'a' as detailed in the link above covers this too.

But the scripts.rpa file is generally relatively tiny to begin with, so simply replacing the scripts.rpa file with an updated one when merging the update with the base folder is not a bad way to go. It's the image, video, and sound files that generally take up by far the most space, and where you can get the most bang for your buck - by not requiring users to download the same images, etc. contained in associated archives over and over.

 

[anne O'nymous]

Now if your point was to make sure that you don't duplicate essentially the same script file in separate .rpas [...]

Absolutely not what I talked about. My point was explicitly :

They'll have part of the game modded, because the files have been directly modified by the mod and not updated by your patch, and part of the game unmodded (all the updated files).

You know, like when you edit the "screens.rpy" file to change the interface, but the update patch do not replace this file because the author didn't changed it. And even for something like an interface change, it can lead to a broken game.

Let's say that you added a "cheat store" button in the map of the game (defined in "screens.rpy"), and put the "cheatStore" label in the well named "location.rpy" file :

• If both "screens.rpy" and "location.rpy" files are replaced by the update patch, all will be fine, the mod will be completely removed.
• If the update patch only replace "screens.rpy", no problems. The mod will stop to works, but the game will be fine.
• If the update patch only replace "location.rpy", the game will become unstable. The "cheat store" button will still be in the modded "screens.rpy", but the "cheatStore" label it will try to call, or jump to, will not exist anymore.

That's what I said, with less details but still explicitly.

But the scripts.rpa file is [...]

How the use of a "scripts.rpa" archive can be seen as splitting your scripts files over multiples archives ? You know, at this level it's not just annoying, it start to be disturbing because you make me doubt of my own sanity.

 

[OhWee]

Just did a test.

I usually run unren.bat on Renpy games as a matter of course (I like to look at the artwork outside of the Renpy framework), but just for fun I extracted a game from the zip file into a fresh folder, without using unren.bat on it.

I then placed a modified script.rpy inside of the game folder, next to scripts.rpa (which contains script.rpy).

The changes I made to script.rpy were the ones that showed up ingame, so Renpy chose the unarchived script.rpy instead of the archived ones when building the game.

I was pretty sure that that I saw this behavior before, but it's been a few months since I've messed with Renpy code, hence the need to test this again for myself.

This loosely ties in to that code snippet and explanation I posted from the Renpy documentation, which talks about telling Renpy which archive takes precedence, say if you are planning to overwrite a 'to be continued' day6.rpy with a 'events of day 6' day6.rpy in a subsequent patch archive.

So short form, for modders anyways, an unarchived script.rpy placed in the /game folder appears to consistently override the archived one in script.rpa. My question is (for Rich, etc.), is this always the case?

 

[Rich]

So short form, for modders anyways, an unarchived script.rpy placed in the /game folder appears to consistently override the archived one in script.rpa. My question is (for Rich, etc.), is this always the case?

My understanding, which may be wrong, is that Renpy pays attention to dates. I know that if you have a .rpy and a .rpyc file (not archived), Renpy will use the newer of the two - that's probably obvious to all of us. When you create an unarchived .rpy file next to an archive that has a corresponding .rpyc in it, the .rpy file is almost invariably going to be newer, so I it could be that's what getting picked up. The interesting question would be to "back date" the unarchived .rpy file to earlier than the .rpa file to see which Ren'py picks up in that situation. That would answer whether Renpy prefers unarchived over archived instead of just working by date. (I don't know if Ren'py includes dates on files inside the .rpa file, or just uses the date of the .rpa file.)

 

[anne O'nymous]

My understanding, which may be wrong, is that Renpy pays attention to dates.

It's more simple than that, Ren'py just don't care... as long as the .rpy files are included in the archive. Whatever there's just the .rpy files or both the .rpy and .rpyc files outside of it, and whatever the date of the .rpy, .rpyc and .rpa files, Ren'py will always use what is outside of the archive.
But if there's just the .rpyc files inside the archive, then you must have the .rpyc files already present outside of the archive. Else, if there's just the .rpy files, Ren'py will loose its mind. It will generate the .rpyc files, and use both the one inside and outside of the archive.
This said, it's half a problem. Close the game, restart, and like now the .rpyc files already exist, it will works.

(I don't know if Ren'py includes dates on files inside the .rpa file, or just uses the date of the .rpa file.)

There's just the full path to the file and the relative one ; plus obviously the file itself.

 

[Rich]

It's more simple than that, Ren'py just don't care...

OK, that makes sense. I've never looked inside Ren'py to see how it went about accumulating .rpyc's at runtime, but "outside first" makes perfect sense. (And, of course, the "if you have an .rpy that's later than the .rpyc, recompile the .rpy" rule)

There's just the full path to the file and the relative one ; plus obviously the file itself.

Pretty simple, then.

We do all know that Ren'py pays attention to the full path to the file (well, relative to the game directory, at least) since it's possible to have the same .rpy/.rpyc file name in two different directories (with different contents, of course) without a problem. And also that if you put a second copy of a .rpyc file in another location, Ren'py will have a conniption, since now it will see anything in that file as being declared twice. Been there, been bitten by that... LOL

Thanks for the expert insight, anne!