Idea 0. Do nothing.
The current system isn't overly broken, IMO. So it's not clear to me it's necessary to do anything at all... and I'd rather not do anything until I'm happy with what I'm planning to do. So the null option is certainly on the table.
Code: Select all
init:
$ e = Character("Eileen", color="#cfc")
$ style.default.size = 24
$ renpy.music.play("foo.ogg")
e "Hello World."
$ renpy.music.play("bar.ogg", channel=2, fadeout=1, fadein=1)
Some of the names may be longer then they need to be. Why write renpy.music.play when music.play would suffice? So we could shorten some of the function names... which makes them look a bit nicer.
Code: Select all
init:
$ e = Character("Eileen", color="#cfc")
$ style.default.size = 24
$ music.play("foo.ogg")
e "Hello World."
$ music.play("bar.ogg", channel=2, fadeout=1, fadein=1)
Idea 2. Allow function calls and assignments in Ren'Py.
By allowing function calls and assignments at the top level of Ren'Py, we can eliminate most uses of $.
Code: Select all
init:
e = Character("Eileen", color="#cfc")
style.default.size = 24
music.play("foo.ogg")
e "Hello World."
music.play("bar.ogg", channel=2, fadeout=1, fadein=1)
Somehow allow functions to be called without parenthesis. While properly allocating arguments. We'll ignore the character declaration for a second, as I don't think that'll get any easier then the previous, and focus on these new functions. I have two syntax ideas:
Code: Select all
init:
e = Character("Eileen", color="#cfc")
style.default.size = 24
music.play "foo.ogg"
e "Hello, World."
music.play "bar.ogg", channel=2, fadeout=1, fadein=1
Code: Select all
init:
e = Character("Eileen", color="#cfc")
style.default.size = 24
music.play "foo.ogg"
e "Hello, World."
music.play "bar.ogg" channel 2 fadeout 1 fadein 1
Idea 4. Special Syntax.
We can also add a new statement type for each interesting command. For example, we could add a 'music play' statement, a 'music queue' statement, and so on.
Code: Select all
music play "foo.ogg"
e "Hello, World."
music play "bar.ogg" channel 2 fadeout 1 fadein 1
My Thinking
Right now, I'm leaning towards 2 or 3b. I don't like 4 as it would seem to make user-defined statements impossible, and I don't think that's a good thing. (I could see stuff like "voice" and "voice_sustain" and "nvl_clear" all becoming user-defined statements in the future.)
A problem is that 4 and 2/3 are incompatible, so there's that. And I'm not sure 3 is practical, implementation-wise. Also, it's not clear that I could properly syntax-highlight things for option 3.
Of course, this is a very difficult design decision. So while I'd like people's input, I'm not sure I'll be making these changes anytime soon. I want to be _sure_ before making the changes to the language.
(There's also the problem that I see option 2 as the cleanest of these options, a position I'm sure many disagree with.)