Episode Updates using Renpy

[anne O'nymous]

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

It come from the inside mechanism.
Basically speaking, in addition of its AST, Ren'py have a name map of the whole code. It's a dictionary indexed by the labels, when it's a label statement, or a tuple containing the full path, an integer and the line number where the statement was, for all the other lines. And it have the statement object (perhaps the whole Node with the later optimization change) as value.
You can have a quick look from the console with this :

renpy.game.script.namemap.keys()

But WARNING it's not something to do with a big project ; the empty project that Ren'py create for you already have more than 1600 entries.
And for an example of the value :

renpy.game.script.namemap["start"]

Then come a question, if it's a .rpyc file, so kind of a binary file, how Ren'py know about the line number ?
And the answer is simple, both the full path and line number are part of a node, and so included in all the .rpyc files. It's wonderful for a modder and it's also why un.rpyc sometimes generate files with so many blank lines ; it place each statement at the exact line number where they are supposed to be.

That's the reason why you had this problem. The .rpyc aren't in the same place and don't necessarily have the same content ; you can even rename one afterwards. But for Ren'py you'll still have two "myComputer/myGameDirectory/myGame/game/someFile.rpy, line 12" and... well, it's not supposed to happen.

Thanks for the expert insight, anne!

You're welcome.

 

[79flavors]

For all the technical considerations and possibilities, I think you're overlooking the main factor here...

... users are stupid.

Not all of them. There are, of course, exceptions to any rule. But for the most part, if you try to implement a clever solution... you'll encounter some very un-clever people who'll make you want to tear your hair out.
Do you want to spend 10 hours per week programming or 10 hours per week replying to stupid people on the forums?

If RenPy games included a launcher that could apply incremental patches... you'd be fine. But it doesn't.
So what you are left with is detailed installation notes (which people will ignore) and luck (most of it bad).

Whilst I agree that bundling all chapters together in a single (ZIP/RAR) archive is wasteful of bandwidth, it's also the simplest solution. For me personally, that trumps all other considerations.
Build the game you want to build and let others worry about their bandwidth.

If you're content to compress your images... do that.
I believe the RenPy suggestion is that "bg" (background) images be .jpeg's and overlay sprites be whatever you want.
But that presumes that the game's "actors" will never be rendered into the background... which a lot are.

There are tools which will batch convert .PNG to .WEBP (both lossless and lossy)... Google search is your friend.

And of course, there's stuff here on the forums: [

You must be registered to see the links

], [

You must be registered to see the links

] and of course @bossapplesauce 's own [

You must be registered to see the links

]

Whilst I've barely dabbled with RenPy, I think my workflow would be something like... (Create 24bit .PNG) -> (write/test game) -> (Backup .\images\ folder) -> (Batch convert .PNG to lossless .WEBP) -> (Build Distribution) -> Rinse and repeat.
I might do a .PNG -> lossy .WEBP convertion to address my personal curiosity, but I've seen lossy images in other games and whilst most are just fine, occasionally you'll get images that just scream "crap" at me. Personal preference of course.

I think you've fallen into the standard programmer trap of "this is interesting". It is, but it's also a distraction. Because at the end of the day... users are stupid. So stick with single (ever bigger) release files.

Though one thing to consider is to use lossy images for your monthly/periodic released. Then use lossless for your "final" release. Bearing in mind obviously that as soon as you release that final version... you'll find a bug in it.

 

[anne O'nymous]

If RenPy games included a launcher that could apply incremental patches... you'd be fine. But it doesn't.

Really, it can't ? How do you think that the SDK do to update itself ? Nobody talked about it because it's not really a suitable solution ; at least it's why I didn't talked about it before. But it doesn't mean that it's not possible, just that it's not the right answer here.
Using

You must be registered to see the links

by default need to have a static point where your game will found the update, and one that will really stay over the time. Alas, having its own reliable web site is a luxury that all the authors aren't able to pay for. Anyway in top of this they'll need the trust of their players, and it's obvious that it's not the pirates we all are here, who'll accept without reluctance a game that will check online for new files. Even regular users will probably be reluctant to trust an indie author for this ; that's why smartphones, whatever they works over Android, Windows or IOs, have a store, it provide the trust you can't have in the author himself.
But I'm sure that you can also tweak the said feature, making it works with local files instead of web hosted ones. This remove the need for trust, but alas, it's not basic Ren'py writing we are talking about here. So, once again it's not suitable for the average game's author.

 

[79flavors]

If RenPy games included a launcher that could apply incremental patches... you'd be fine. But it doesn't.

Really, it can't ? How do you think that the SDK do to update itself ?

Fair point and thanks for the link. I gave that statement way too much certainty and I'm clearly wrong.
I suppose I assumed that since the vast majority of games I've seen only include a single .exe file, that any sort of patching/sync type operation would be problematic. I guess I also assumed that if that sort of patching were in common use, I'd have seen it at least once by now (which I haven't).

tbh, I wasn't even aware the SDK was capable of updating itself - since I've just downloaded and installed three separate versions independently of each other and never once had it offer to update to a newer version. But clearly, the SDK must include that functionality and I've just never seen it.

As an ex-programmer myself (nothing vaguely current tech), I know how tempting these rabbit holes can be. And useful too, in specific circumstances. But my gut feel here remains that whilst a clever technical solution might exist, it would still be preferable to deliver a 2.5GB update monthly and waste some bandwidth than deliver a 105MB update that leads to a disproportionate increase in time spent dealing with "support" issues.

 

[anne O'nymous]

But my gut feel here remains that whilst a clever technical solution might exist, it would still be preferable to deliver a 2.5GB update monthly and waste some bandwidth than deliver a 105MB update that leads to a disproportionate increase in time spent dealing with "support" issues.

If you manage to tweak the updater feature, you can link the "update" button to a long text explaining that the player must :

1. Wait for an update to exist (including current version as reminder, just in case) ;
2. Download the said update wherever he want as long as the rights are compatibles ;
3. (optionally, depend of how you tweaked it) decompress the archive wherever he want as long as the rights are compatibles ;
4. Do all the above before clicking on the "go" button bellow.

Then you prompt the player for the full path to the update archive/files (see optional part above), and name of the archive (if not decompressed). It's even possible to do it visually like with any 'load' button of an average program.
Then you use a file to validate that the update is really new and really apply to this version. A simple text file looking like this can be enough :

patch:VERSION_AFTER_PATCH
apply:MINIMAL_VERSION_NEEDED

It should drastically reduce the need for support. But well, you still need to tweak the updater first.

 

[OhWee]

Calling users stupid is pretty insulting to about 90% of your user base.

Sure, the first time someone applies a patch to a game, it can be somewhat intimidating, but this isn't a Renpy only issue. But once a user gets the hang of how it works (clear instructions are quite useful here), and they've done it once or twice, it becomes almost second nature.

And users of most Renpy games already need to understand things a bit more than simply clicking on an icon to install. They need to pick a place to extract that .zip file to, which already gives them a general idea of where to look for their game. Sure, some Renpy game designers understand how to make an installer, but most Renpy games don't have installers.

RPG Maker usually requires even more knowledge, but somehow people manage to figure out how to get it working eventually. Renpy's relative simplicity is part of it's appeal.

So 'dumbing down' your install options to appease a small minority of your users is silly, Besides, I already covered the solution for those people, as well as for new users. Provide a 'full install' version with each update along with the patch. People that despise large downloads (when games start cracking say 1GB) can use your patches, and those that just want the full install, or that are downloading your game for the first time, can download the full install instead.

As for compression that comes at a bit of a cost. For example, Bossapplesauce's compression efforts require additional steps (i.e. installing special software extensions in order to read the image format). Not to mention that there IS a loss of quality, minor as it may seem, and a handful of people do notice such things.

I personally support 'finding a a balance here' on the designer end r.e. image file sizes, and regularly convert to .jpg in Photoshop to help reduce images sizes a bit from the default Daz .png sizes. I'm doing postwork anyways, so it's part of my workflow.

And it doesn't have to be either/or. You CAN appease both crowds, and it'll only take you a few minutes to set up a patch as well as a 'full' version. Heck, you can even appease all three crowds if you provide a 'HQ' version as well as an 'Optimized' version.

Users love additional options, and some may even give you a bit of extra love for your efforts...

 

[random.person]

I agree with OhWee, giving the users options is the best choice.
In my case, patches would be ideal since my connection is pretty slow, so updating long-running games takes a lot of time, especially if they pack a lot of 3D renders. But most devs don't bother with them and just release the full game every time, which is pretty wasteful for everyone in my opinion. Sure, it saves them the hassle of dealing with users support, but it still is a waste of time since they have to reupload everything when they could have just rolled out a patch.
To be honest, I think that the reason most adult games aren't updated with patches is that they are made on Ren'Py or RPGM which lend themselves to use by non-programmers. The result is that a lot of adult games devs probably don't even know how they could roll out a patch. They probably don't use git for version control too.
If more devs started using a patch approach for this kind of games and maybe released some tools to automate the process I'm sure it'd become the standard quickly.

 

[UncleVT]

I think a solution implemented by @Palanto is good. Yes, there will be a certain number of post asking how to do it, but how many silent users download the patch without any issues? I'm sure they are majority. And like random.guy says, most use the system, more standar becomes.

 

[TearStar]

Going to save this thread for later if my game (games) become bigger than a 1GB. But I think of many problems about this system. Developers still needs to upload a full game because of new players possible. That is important to have new players.

What I think about: I use GitLab. Using different branches for updates, like this: have master, update1, update2...
Full game is always at 'master'. You need to only clone and compile update 1 and put in a ZIP. Sure you would have a lot of branches but I wouldn't care. Still better than nothing.

 

[Palanto]

Going to save this thread for later if my game (games) become bigger than a 1GB. But I think of many problems about this system. Developers still needs to upload a full game because of new players possible. That is important to have new players.

What I think about: I use GitLab. Using different branches for updates, like this: have master, update1, update2...
Full game is always at 'master'. You need to only clone and compile update 1 and put in a ZIP. Sure you would have a lot of branches but I wouldn't care. Still better than nothing.

True, or you could buy some webspace with huge amounts of bandwidth then you could just use the build in renpy auto updater But the same thing works with a mega folder... sadly many players don't like reading much (Hmmm crazy if you think about it, since the game we're doing is a VN rofl) so they don't read what to do and just download the latest update instead of the first full game version and then all the updates to the latest version Same will happen with the github stuff.. I like github and use it frequently but it's the same there as on mega.nz or anywhere else, if the players don't read they just download whatever and nothing works

 

[TearStar]

True, or you could buy some webspace with huge amounts of bandwidth then you could just use the build in renpy auto updater But the same thing works with a mega folder... sadly many players don't like reading much (Hmmm crazy if you think about it, since the game we're doing is a VN rofl) so they don't read what to do and just download the latest update instead of the first full game version and then all the updates to the latest version Same will happen with the github stuff.. I like github and use it frequently but it's the same there as on mega.nz or anywhere else, if the players don't read they just download whatever and nothing works

I have a webserver already paid for another work of mine but not everybody has that. I could even create an auto-updater and launcher too it won't be an issue for me. GitLab is just like GitHub but GitLab has free private repos. Also you can move projects from GitHub to GitLab. I only think this 'partial' update thing only needs for 1,5< GB games.

Though I never thought downloading the full game was much painful even with my 10 Mbit connection. The problem starts at when you have limited bandwith. I'm still thinking about the best alternative.

 

[Palanto]

Well we're still talking about ren'py right? Cause if we are, then try the solution I showed you, even with a repo and multiple branches most players can't just download an update like that, they usually mess up the step where all the stuff from the update has to be put inside the old previously installed game on their own computer. So to make it a little easier for them, provide them a zip file which they can just extract in their game folder or even better in the folder above the base folder itself so i.e. C:\Games\YourGame\game\ <-- not here but --> C:\Games\ <-- here

 

[TearStar]

You can not predict how any player would react to your actions. The safest play is always remains 'full update'. I'm still a long way on this path maybe I'll get an idea which maybe helps anybody (or develop something generic).

 

[random.person]

If we want to go full theorycrafting, an optimal solution would be to release an installing script instead of the game, like most stuff does nowadays. A .bat or .sh script checking for current game version on the system and using the likes of curl, FTP stuff or straight up git to download from a public repository would be relatively easy to make.
The real problem would be how to manage the repository. Git would be very useful, but making users install such software to update porn games is not really friendly on the dev's part so I'd rule it out - as well as any approach that requires non-standardly shipped software.
The problem with FTP would of course be having a secure server with the necessary storage and bandwidth.

All things considered, on a *n?x machine I can see implementation of this model as being quite straightforward, whilst for Windows systems I am not acquainted enough with its command-prompt to assess whether it'd require too much hassle and additional installations for the user.

Edit:
So, when will F95Zone start giving devs centralized public repos for updating purposes =P?