- Jul 2, 2019
- 295
- 324
You're welcome, pleasure mine.
If you need advices, we can start a private conversation about this subject. Software development is my job for 20 years, so I may have a few tricks up my sleeve...
For doing patches myself in my own job - not Ren'Py projects, but patches anyway - I can give you some advices:I'll heavily look into making RPA archives if this is the solution to people getting easier update patches.
- Worst thing you can do, for a patch, is to DELETE A RUNNABLE FILE. Don't do it. You don't need a script anymore? Leave it with only a comment like "Stuff moved to file XXXXX.rpy". Don't need an executable anymore? Replace it with a one displaying a dialog box saying "This executable isn't needed anymore, see XXXX instead".
Otherwise, when the player put the patch in his game folder, both the old AND the new version will be loaded, and it will result in a broken game, with old code loaded at the same time as new code. - Second worst thing is reworking on old parts: it will implies to redistribute "previous" RPA. You rendered a new intro? Fine, but you'll need to redistribute all involved RPA, including some for a minor thing. But it's also why several RPA are better than a gigantic one: you won't need to redistribute the "big one" constantly.
- Don't need an image anymore? Leave it. It takes space on end-user disk, true, but it's harmless. Same for music/sound files. You'll clean that in final, standalone version. Not in patches.
- RPA archives allows you to manage a whole set of files as one single entity. For example, all your scripts weights only 5 MB, compiled ones included. So it will be a very small RPA, and you can replace them fully on each update - it will also handle scripts deletion, since the RPA will be replaced.
- Resources' RPA: 1st method (my prefered)
- For images: do a RPA with all current images, with an explicit name (like "images_ch3_0_1.rpa"). For next update, put all your NEW images in another RPA ("images_ch3_0_2.rpa"), and so on.
Easy way to test that: always add new resources DIRECTLY in the "new sub-RPA". - Music / sounds / other resources: same as images, one RPA per type of resource, with current version.
- For images: do a RPA with all current images, with an explicit name (like "images_ch3_0_1.rpa"). For next update, put all your NEW images in another RPA ("images_ch3_0_2.rpa"), and so on.
- Resources' RPA: 2nd method
- Put all resources in a RPA for this version ("resources_ch3_0_1.rpa").
- Put all NEW resources in a RPA for the update ("resources_ch3_0_2.rpa"), whatever these resources are - but scripts, keep them separated anyway.
- Obviously, an update can lack some elements: you may not need to add any music for an update... You can also number the RPA not with the game version, but with an incremental number.
- Other elements should not be modified between updates (ex: "lib" and "renpy" folders), and anyway, they aren't so heavy - 80 MB maximum, uncompressed - and can be distributed unconditionnally.
If you need advices, we can start a private conversation about this subject. Software development is my job for 20 years, so I may have a few tricks up my sleeve...