Why is it a separate language?
Yeah, exactly, why the language that describe screen isn't the same than the one used to build scripts ?
After all, it's something never seen before, and clearly not the most used couple on the networks... It would be known if we needed one language to describe web pages, and another language to turn them interactive ; this with a weird API in between.
Why can I override with dissolve with with Dissolve() but I can't override frame: with Frame():?
Are you seriously comparing the behavior of a parameter (
with dissolve) with the behavior of a command (
frame:) ?
But what is really surprising is that you ask this, while already knowing the answer.
If you use
with Dissolve(), Ren'Py will throw an exception, because the class expect at least one parameter. A parameter that is absent when you write
with dissolve. Isn't this a strong hint that they aren't exactly the same thing ?
Therefore, while you can use both, there's on, and only one, case when the two will lead to the same result ; when you use
with Dissolve( 0.5 ). This because
dissolve is nothing more than a short cut (a
macro if you prefer) for
Dissolve( 0.5 ). Use any other value with
Dissolve(), and you'll get a transition that will last more, or less, than 0.5 second.
In the end, your question is nothing more than asking why you can replace
print CONSTANT by
print "some constant text", but not
exit by
exit(). Programmatically speaking it's a pure none sense.
Why is the syntax for Ren'py, ATL, and screen language totally different?
Well, they are three different languages, that each have its own needs. And like any languages, they have their particularities and differences.
But contrarily to what you think, only the Animation and Transformation Language effectively have a syntax different from the two others. The syntax for both the script language and the screen language is one single line.
It happen that, for a reason of convenience, you can split all screen statements into blocks. But it's a question of convenience and readability, not their base syntax.
Code:
textbutton "whatever":
style "myButton"
action NullAction()
alternate NullAction()
selected not flag
can perfectly be wrote
textbutton "whatever" style "myButton" action NullAction() alternate NullAction() selected not flag, and it would do exactly the same thing. In fact, most of the default screens rely on this syntax for any statement that isn't natively a block.
Of course, you can claim that putting the parameters and the content on the same level is weird. But here again it's nothing more than a question of convenience.
While something like this would be clear
Code:
frame xpadding 10 ypadding 10 xalign 0.5 yalign 0.5:
vbox:
[...]
Something like this would be really confusing
Code:
frame
xpadding 10
ypadding 10
xalign 0.5
yalign 0.5:
vbox:
[...]
And, on a technical note, it would also uselessly over complicate the parser.
All this being said, the SL1 syntax is still available. You can perfectly design screens in pure Python, by only calling function, if really it's your thing. And the same apply for almost all statement of the script language. In the end, you can perfectly write a full Ren'Py game by only using functions calls ; except for the labels, that you'll have to declare using the script language.
I doubt that the auto-completion file, for Visual Studio or Atom, pick the one you prefer, include all those functions, but you can extend it yourself after all.
In Godot (or Java's Swing or C# for that matter), GUI construction follows the same object-oriented syntax as the rest of the program.
An unique language that follow an unique structure... What a surprise.
Whereas with Ren'py you need to juggle the screen language page and the screen properties page to find out which GUI elements take margin, which take padding, and which don't take either.
Well, if you can't figure by yourself that
text is a text, and therefore will not take window/box style properties, while
frame being a window/box, it will not take button properties, I doubt that it's the fault of Ren'Py. But I'm can be wrong...
