Without thinking about those using 3D renders, it's more difficult to turn into puppets graphics like those in
Summertime Saga or
Lust and Power. Not impossible, but not as easy if you want a smooth and good looking result. And the question is to know if the time you'll need for that worth what it will add to the game. As for games using 3D renders, it's clear, the result will be horrible most of the time.
Yes - that was what the Pusooy games involved. He'd clearly done 3D renders, but then mastered the art of cutting them into pieces (the hard part being the joints, of course) and then animating them like puppets. His games had a lot of "you have to move the mouse back and forth, which moves the characters back and forth, and you have to do it N times before I'll let you move to the next frame" mechanics. Some of which were effective, some of which were.... tedious.
As for the rest, animate part of the decors by example, Ren'py is already able to do it, and do it smoothly.
Yes - absolutely. For that kind of thing, Ren'py's
I agree. Ren'py is actually maturing into its future state, with PyTom using the fact that he have to rewrite part of the code, and will be forced to drop a part of the backward compatibility, to add many things. The most impressive one being probably that he just opened the gate for realtime 3D. It's still something to do, and it will be limited in regard of what more professional engines can do, but it's a big step ahead.
Ya, that's kind of what I was talking about in terms of "things hardcore programmers can use." Providing a more "front and center" OpenGL implementation that can be accessed from Python may make very interesting changes in Ren'py-based games (not just adult ones) going forward.
If I remember correctly, PyTom once tweeted that there were more commit for the 7.4.0 than there were for the whole project during the X (it's the part I don't remember at all) last years.
Quite. For the past few years, it's been mostly small editions and bug fixes with each release. (Well, "small" in the grand scheme of things - not discounting the value and power of things like LayeredImages, etc.) This, on the other hand, was a massive rewrite, both because of the additional features, but also because of the beginning of the Python 3 migration. The latter required non-trivial changes on a LOT of "foundation code" that's been in Ren'py (more or less untouched) for years and years.
Just for the benefit of the people that may not be aware of this, one of the big reasons Python 2 and Python 3 split in 2008 was because Python 2 was created well before Unicode support was a "thing." (Not that Unicode didn't exist, but most people just didn't worry about international support back when Guido first invented Python - it was an "ASCII world.") (There were other reasons as well, but that's one of the big ones.) So, Python 2 treated strings as sequences of 8-bit characters, which obviously won't cut it in the modern "all those languages" days. Later on, "unicode" objects (i.e. "strings" made of unicode characters) were added, but the big issue was that lots and LOTS of Python 2 code also used strings as arbitrary containers of 8-bit bytes, not just sequences of text characters. So, if you read a binary file, you got back a string object, and you had to do a lot of mental bookkeeping to deal with "is this a text string or is this a binary buffer" throughout your code. This mixing of "strings as binary" and "strings as text" made for all kinds of problems when the migration toward "proper" Unicode support happened, and greatly complicated a lot of issues with I/O. Eventually, it was decided that this, along with a lot of other odds and ends, had to be fixed. Basically, "let's clean up our language and our core packages." Rather than breaking huge amounts of existing Python 2 code, they essentially forked Python 3 out of Python 2, and then made the wholescale underlying changes to "get it right" (or "more right") just in Python 3. In Python 3, a string is always text - it always contains Unicode characters, not raw binary, and a new "bytes" object type was introduced to handle arbitrary binary data. The two aren't interchangeable, although one can be converted to the other and vice versa. So now reading a binary file returns a "bytes" object unless you explicitly ask for the raw bytes in the file to be converted to text, which is done by different methods. There were lots of other cleanups as well, of course. (One of them being the behavior of division, which is the one most likely to bite people in the butt.) But, in many respects, you have to think of them as two very similar but not-quite-compatible languages.
Python 2 and Python 3 essentially evolved in parallel for many years - lots of new "3" features were back-ported into "2", and "cross-compatibility" techniques were introduced so that people could write libraries that would work with both Python 2 and Python 3. (This is where Python's lack of "strong typing" was a great benefit - you could write code that would say, "well if this is running inside a Python 2, I can use create "unicode" object, but if it's Python 3, I can create a "str" object, then go use them.)
Eventually, however, it was decided that no new features would be added to Python 2, so Python 2.7 was the last major release of it. In 2014, "they" announced that Python 2 would stop being supported as of 2020. That doesn't mean that Python 2 "blew up" at that point, just that no more updates would be done to it. Which, in turn, means that many of the packages "out there" would drop support for Python 2, or that packages specifically written for Python 2 would stop getting updates. So, somewhere in 2019 (I think) PyTom bit the bullet and started work toward migrating Ren'py toward Python 3.
Since he's as committed to backward compatibility as the Python people were, when full Python 3 support does come out, it's going to come out in parallel with continued support for Ren'py using Python 2. So, for a while, there are going to be two parallel Ren'py's as well. But, eventually, developers are likely to wean themselves off Ren'py-Python-2 and over onto Ren'py-Python-3. Version 7.4 is the first step in that direction - it still uses Python 2 under the hood, but it has a new compatibility mode that allows you to begin writing code in "compatible with both 2 and 3" manners so that people that do serious Python in their Ren'py can prepare for Ren'py 8.0 and Python 3.
I mentioned division earlier. In Python 2, if you divided two integers, you got an integer, with fractions thrown away. So, in Python 2, "5/2" gave you "2" - the result truncated to an integer. If you wanted 2.5, you had to convert one or both to floating point numbers first. ("float(5)/2"). On the other hand, if you divided floats, you got a float with the fraction. So 5.0/2.0 didn't give you the same result as 5/2. Not a big deal when you're using explicit numbers, but when you start using variables, what does "a/b" give you? It depended on the exact types of "a" and "b".
In Python 3, all uses of "/" give you a floating point result. If you want the old behavior (i.e. "throw away the fraction") you can either do "int(a/b)" or "a//b". The new "//" operator has the semantics of the old "/", but behaves consistently with either integers or floats. So "5.0//2.0" gives you "2.0" - the fraction is discarded, even though both are floats. So, an inconsistency that had plagued programmers for years was cleaned up. (This is one of those "other things" that they fixed when going to 3.)
So, ya - no surprise that this was one of the biggest Ren'py releases ever. The amount of "framework code" that had to be updated was probably huge. (Think about all the code involved in parsing .rpy, .rpyc and image files - all that probably required tweaks to deal with the "str vs bytes" issue. Even with "works on 2 and 3" compatibility libraries, it HAD to be a ton of work. PyTom credits 35 developers in addition to himself as having helped bring out 7.4.)
