It is after all python, i think it is doable.
I agree that the game has changed very much and that the code has not been restructured as you want it to be to build on it. We have seens duplicate code, code that works against other code, code that works around other code and so on. But this is not a problem of python or renpy it is a problem of modularity in code and cleaning the code if you change something.
I have seens strange things programmed in python that were really experiences where i would say, why?
I have seen python who had inbeded pearl scripts or other scripts in other languages. But over the last years nearly everyone changed it to python only or python based.
To stop this advertising of python lets come back to the game.
I' am not a betatester, but for me the changes sound like a nightmare to implement. In my opinion to implement this, without running in problems with code that works around or stand in opposition to other code a great amount of files must have been changed. If he had done this correctly it should have removed some of the older problems.
So i see two possible outcomes.
1) Everything works fine and he has cleaned his code and i will be deeply impressed after what he has done the last times.
2) Great parts are not working as intended and we see more code that is conflicting and questionable.
I will wait for now with judgement and hope for Option 1.
I was more looking at the performance of Renpy.
Renpy is built on pygame which is built using SDL2 however it nerfs the fuck out of SDL2 and what it does use it uses fairly poorly.
I built base copy of my C++ game engine to see how bad it was. in C++ with SDL2 I get 40,000 objects moving at 60fps.
Using python and pygame it is reduced to 1000 on the same system. Using python and SDL2 without pygame it s 3500 at 60fps.
Pypy unfortunately is not 3.10 compliant yet. So using it isn't a good choice either without rewriting a lot of code. While it is several times faster than cpython it isn't near C or C++. Why that is is an entire different discussion.
Then looking through Renpy's code there are a lot of things in it that also aren't exactly efficient.
Then you have the code written for the game stacked on top of that inefficient mess. Which is a mess in its own.
But lets pretend for a second Vrens code was written as good as it could be. You would still have a limited number of character and stuff that could be done and tracked because of the update system would eventually come to a crawl it would take a lot more time to load a page.
You have all the character schedules to update.
Effects on all the serums to track and keep track of.
Production
Sales
Events
Then updating any characters that have gone through a change or are affected by a serum or the player is interacting with.
Just that alone is going to run you into a limit.
But lets look at what else is poorly done. The way images are displayed. SDL2 has texture system which is much faster than simply using surface. Textures in SDL2 are hardware based buffered objects. Using SDL2 by itself would make it easier to display images. That said using python with opengl they good display the characters themselves it would make moding anding outfits and so on a million times easier give the render quality currently in use Opengl would be an improvement even with medium detail models.
Then you have stuff like displaying text. There are several ways to do it. You could use texture system to do it which uses the freetype library and create the textures as you need it. That's slow as hell. You could do the same thing directly with freetype again slow. You could pre-generate the textures store them and render the fonts as you need it. You could create an opengl context overlay it on top of the SDL2 window and render shaders and stuff through it. Again wastes performance.
Or you could create a glyph and font library system that can use the SDL2 texture system and render the font insanely fast.
I can go into details how that works but its for another discussion on a different forum.