Matt is very open about being self taught, so of course his path to a goal is not going to follow the "standard".
It's not a question of standard, just a question of common sense.
Python equivalents exist for the case where you need a feature
from inside Python code, not to be used from a label. And because of this, not only it's more limited (by example you can't have transition when displaying the screen), but also less easy to use. Without counting the fact that the screen can't be predicted if shown through the Python equivalent, and will not be included in the lint process.
It's precisely the reason why they are
always presented after the statements, when not on a different page. They are an alternative to use for really specific cases, not the main approach.
What he's doing is like teaching how to use a unicycle to people who own a 750 motorbike, while telling them that it's the best way to travel to the other side of the country.
So, yeah, with him you'll know how to master the use of unicycle, but you'll still have 1,000 km (if you're lucky to live in Europe were countries are small) in front of you, and will need tiring days before you reach your destination.
And yet, in Ren'py... even with as little knowledge as I have taught myself so far ... it is obvious that there are usually several ways to achieve a result.
There's several way, of course, and I'm among the ones who remind it regularly. But when you decide to teach something, the least one can do is to do it correctly. Not by teaching "the right way", but by teaching the easiest way, that generally double as the most efficient one.
Because whatever how good you can be at teaching, in the end viewers will be alone face to their code, and alone face to its issues.
There's lots of technicians I work with who are better pure mechanics (what we call "wrenches") but I have honestly never met a person that can understand how systems interact as well as I do.
Well, isn't it a reason more to teach the easiest and most efficient way ? That way 99% of the time they'll not need to know how they interact together.
Isn't it better to just have a statement, that will automatically fill a variable for you, that having to remember that you need to assign the value to a variable ?
Python:
label whatever:
call screen whateverScreenName
if _return == "whatever value":
[do something]
Versus:
Python:
label whatever:
$ returnValue = renpy.call_screen( "whateverScreenName" )
if returnValue == "whatever value":
[do something]
How many will not remember the leading "$", and pass minutes, when not hours, before figuring it ?
85% of what they'll find regarding the content of Ren'Py labels, including their working code, will show them that you don't need a leading "$". And to find it in the doc you need to look somewhere else that the parts talking about labels.
How many will not remember to assign the returned value, and wonder why it doesn't work ?
If they search for something like "get the value return by a Ren'Py screen", most of what they'll find will talk about
call screen, and therefore not have that assignation. If they are beginners, they'll not understand that it's different with
renpy.call_screen(), believing that they behavior are the same.
How many will want to pass a parameter, and not understand why Ren'Py complain ?
If you've a screen declared with
screen myScreen( first=None ):,
call screen myScreen( "Something" ) will works, but depending on what version of Ren'Py they'll use,
renpy.call_screen( "myScreen", "Something" ) will not necessarily works.
From memory it was definitively fixed around the version 7.4.0, before this you had to explicitly use a keyword argument. Even me, who know about the issue and faced it often, still forget about it once in a while when I works on my variable viewer or any code that need to be compatible with older versions.
If that means my code is done differently than yours... so what? If it works, it works.
The key point is the last sentence...
I don't question your code, this is a generic question, but does it really works ?
Take a game like
Corruption, that is finished since two years now. There's a never fixed bug that prevent you to see two third of the content in the casino. It's just an error in few conditions, so there's no crash. And like players don't know what is supposed to happen here, only those who looked at the code know that there's a bug.
It looks like it works, feel like it works, but it doesn't.
Another classical is the wrongly declared variables like:
Python:
label whatever:
menu:
"Do you spy at the marvelous naked girl ?"
"Yes":
$ spied = True
"No":
pass
Then later the "spied" variable will be tested, and anyone who decided to not spy will have a crash, because for them the variable do not exist. But who's dumb enough to not spy at the marvelous naked girl while playing an adult game ? So, near to no one will ever know that the game is broken.
I don't remember their names, but there's a dozen games currently in development that have this in almost all updates. And when it's really a choice as basic as this one, the bug is still present after many updates, because no one encountered it.
Of course, using
call screen in place of
renpy.call_screen() will not magically prevent bugs to happen. But it will generate warnings when you lint your code, while limiting the risk for them to happen, because the syntax is more intuitive.
And like it's the natural way to process, the one promoted by the documentation, you'll easily find what you are looking for if you face a bug at that level.
So I am slowly developing my own styles and naming conventions and what not. I'm sure it would probably make you curse and throw up your arms, [...]
You should read me more often if you think it's the way I would react.
