Can the Ren'py engine be upgraded after release?

[Aurelius Ambrosius]

I was wondering whether it was possible to upgrade older games which are no longer in development with newer versions of the Ren'py engine.
Would that help with bugs and features compared to older engines? Or is the Ren'py version closely tied to the game code?

 

[rayminator]

it depend on how old the game is that you are talking about...

 

[papel]

With the source code, the game can be upgraded to use a newer version of the engine.
Whether that would fix bugs is a case by case thing. Ever seen programs or apps that break after being updated? Same can happen to games. Depending on the game, upgrading the RenPy might make it completely unplayable or add new bugs. It all depends on the game and how the code's written.

 

[Aurelius Ambrosius]

The reason I ask this is because there are bugfixes and new features in more recent Ren'py versions. For instance, being able to change the font when pressing the 'A' key. Also, deleting save games with the 'D' key when hovering over them.

I'm not sure whether these features would then also be available to older games if we replaced the Ren'py folder with something newer.

For instance, I copied the Renpy and Lib folders from 'Lewd Island 2' to 'Lewd Island 1'. There were MANY differences in the files I copied, so maybe some things now work better and/of faster(?).
And... the game ran perfectly fine.

What I'm trying to get at is this:
I would really like it if we simply had one Renpy folder for all our games. Such, that games and Renpy can be upgraded independently. Does anyone here know whether this is possible or is even talked about?

 

[anne O'nymous]

For instance, being able to change the font when pressing the 'A' key. Also, deleting save games with the 'D' key when hovering over them.

For most games, the font should be able to be changed by naming whatever font you want "DejaVuSans.ttf" and "DejaVuSans-Bold.ttf", then dropping the files in the "[path to game]/game" directory. For games using their own font, the principle is the same, it's the name of the files that change. It's less easy, but the accessibility option just offer you a change between two fonts by default.
As for save deletion, it's possible since years by pressing the "delete" key.

I'm not sure whether these features would then also be available to older games if we replaced the Ren'py folder with something newer.

None. The accessibility menu, and some changes in the key assignations, are the only things that can benefit to all games. Everything else would need the game to be designed to use them.
And at the opposite side of the spectrum, many games would break while doing this because the said accessibility menu appeared at a time where Ren'Py ceased to be effectively and fully backward compatible.

so maybe some things now work better and/of faster(?).

Unless the game was made with a particularly bugged version (there's really few in Ren'Py history), it wouldn't works better, nor faster.

 

[Aurelius Ambrosius]

Thanks Anne O'nymous.

Do you know whether one universal Renpy directory for all games is in the roadmap?

PS
Thanks for your (help with) mods!

 

[anne O'nymous]

Do you know whether one universal Renpy directory for all games is in the roadmap?

It's far to be in the roadmap one day.

I know well how it can be annoying. But in the same time its constant evolution is what make Ren'Py interesting.

Thanks for your (help with) mods!

You're welcome.

 

[Rich]

I would really like it if we simply had one Renpy folder for all our games. Such, that games and Renpy can be upgraded independently. Does anyone here know whether this is possible or is even talked about?

First, what anne O'nymous said.

Second, part of what you have to remember is that the .rpyc files that are built by Ren'py version X.Y are intended to be executed by that version of the Ren'py runtime. So, it's pretty easy for a dev to update to a newer version of Ren'py, because when they make a new release, things get compiled with the updated engine. And, for the most part, there are few breaking changes in the Ren'py engine from a source code point of view. (There are some, but they're really rather few and far between.)

But Ren'py provides no promises whatsoever that if you compile .rpyc files with Version X that they can be executed with Version Y. That's not something that PyTom & Co have as one of their goals, and I wouldn't expect it to EVER be a major goal. I strongly suspect that ensuring save file compatibility across versions is hard enough for them.

 

[Aurelius Ambrosius]

But, rpyc files can be decompiled and recompiled right?

 

[anne O'nymous]

But, rpyc files can be decompiled and recompiled right?

Yes, it's deleting it that would cause problems.

Be noted that rpyc files that are still in the rpa archives are seen as deleted by Ren'Py. Or, more precisely, they'll not be used as base to "recompile" the rpy files.

 

[Aurelius Ambrosius]

Rich
Thanks for the info. It's really ridiculous that EVERY game comes with 1000 files consisting of Ren'py and Python2.7. I literally have DOZENS of identical Python2.7 folders. That, while on Windows, Python2.7 can be installed once so that it can be used by ALL scripts/programs.

Maybe I could create a softlink or junction to the Python directory on my computer(?)

Edit:
I can confirm it works. You can remove all the duplicate python folders from all the games and replace it with 1 directory.
On Windows:

1. Open a command prompt in the Lib directory of the game.
2. Type the following command (replace the <path_of_python2.7> with your actual install)
   mklink /j python2.7 <path_of_python2.7>

Example:
Python2.7 installed in "C:\Users\Bouwhuis\AppData\Local\Programs\Python\Python27"
Game = Midnight Paradise
Open a command prompt in the "Midnight Paradise/Lib" directory
mklink /j python2.7 "C:\Users\Bouwhuis\AppData\Local\Programs\Python\Python27\"

 

[Rich]

It's really ridiculous that EVERY game comes with 1000 files consisting of Ren'py and Python2.7.

Well, not when you consider that the games were intended to be stand-alone and self-contained, so that it wouldn't require people to pre-install software onto their computer in order to play the game. Telling people, "first go install this, then go install that, THEN you can play the game" would be a huge clotting factor.

 

[cooperdk]

Python 2.7 is not really known for its compatibility.
Doing a fully compatible game engine in a tool like Renpy was until 2016 (when 2.7 ended long term support) is pretty fucking unintelligent. Even more so when each game needs the same fucking 80-140 MB of libraries.
Py3 would be a help but seems that the dev doesn't really want to carry on. I understand him.

There are better tools available for both Unity and Unreal, as well as standalone dev programs which actually build true executables.

For some reason, lots of people love renpy.

Maybe they're the same people who are totally ignorant to the fact that Renpy 2.7 is unsafe to run because it is full of safety related flaws, bugs etc, and this will never be fixed. The last update was 9 years ago (not counting three small patches).

That's true: Python 2.7 was developed in 2010(!!!) - and was finally deemed "extinct" in 2020, after three minor patches since 2013.
Story about renpy is about the same. Slow development, limited support for anything really.
Use one of the established tools that will run on a modern computer. Py2 is too slow (about half to one third the speed of Py3, which is still MUCH slower than an actually compiled program.

 

[anne O'nymous]

Doing a fully compatible game engine in a tool like Renpy was until 2016 (when 2.7 ended long term support)

Except that the support for Python 2.7 ended the

You must be registered to see the links

, what didn't prevent them to release a last version of Python 2.7 in

You must be registered to see the links

.

Py3 would be a help but seems that the dev doesn't really want to carry on.

A full Python 3.9 working 8.0.0 version is available for everyone in beta state since the

You must be registered to see the links

...

Maybe they're the same people who are totally ignorant to the fact that Renpy 2.7 is unsafe to run because it is full of safety related flaws, bugs etc, and this will never be fixed. The last update was 9 years ago (not counting three small patches).

Not counting the tenths patches

You must be registered to see the links

, and

You must be registered to see the links

, including the Python team.
And obviously I pass on the fact that ~75% of the advisories regard third parts modules and not Python itself ; what mean, among other things, that there's no need to patch Python, updating the module is enough to solve the issue.

That's true: Python 2.7 was developed in 2010(!!!) - and was finally deemed "extinct" in 2020, after three minor patches since 2013.

Without counting the 2.7.18 I talked about above, here's your supposed "three minor patches since 2013":

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

.

Story about renpy is about the same. Slow development,

63 versions of Ren'Py (see link for the 8.0.0 above) released since the 6.13.9, 10 years ago, (May 2012), what mean an average of 6.3 updates by years. Doesn't really looks like a "slow development" for me.

limited support for anything really.

It works on Linux, Mac OS X, Windows, iOS, Android, and through WebAssembly. It had *BSD ports, and even a Wii version. It support Live2D and now start to introduce a basic 3D models system.

Use one of the established tools that will run on a modern computer. Py2 is too slow (about half to one third the speed of Py3, which is still MUCH slower than an actually compiled program.

It's not what

You must be registered to see the links

say. Globally speaking the last 3.10 is just 1.2 time faster than the 2.7 version. Yet there's still some points where the 3.x branch is still slower than the 2.x.


TL;DR:
You don't even have the start of a single clue regarding what you talk about, and haven't said a single thing that happened to be true.

 

[Aurelius Ambrosius]

anne O'nymous
I MUCH prefer RenPy over Unreal or Unity.
RenPy guarantees a certain style and certain capabilities (like rollback and saving and skipping text etc). I don't even download anything from F95zone that isn't RenPy.

I certainly hope developers will switch to a more current Python v3.x branch instead of staying of v2.7.
What would the reason be to not switch? Compatibility? Did the license to use Python change? Isn't if free to use like v2.7? Doesn't it support certain systems/OSses?

 

[anne O'nymous]

What would the reason be to not switch?

There's none except the fact that Python 2.x and Python 3.x aren't compatible.
This mean that it need time to port the more than 300 000 lines of code of Ren'py. Especially since this code is supposed to works on many OSes. I guess that in the same time there's a bit of refactoring that is done. Ren'Py being more than 15 years old, there's parts that are wrote "that way" only because they were slowly extended over time. So, this port is the occasion to look at them and see if you can't write them better.

You also can't release it "as it". Ren'Py have some issues, but globally speaking it's a strong engine that have been tuned through the time. It's not what the version 8.0.0 is.
The code is based on the actual 7.4.x branch, but due to the incompatibility between Python 2.x and 3.x, there's possibly some bugs that appeared. I assume that it's why the 8.0.0 is available in beta, to let some people use it, not for their game, but for test, in order to find those possible bugs.

PyTom always said that the 7.x branch and the 8.x will be parallels. So we will surely have few more release in the 7.x, and perhaps few unofficial 8.x, before the 8.x become the official release branch.