Ren'Py Roadmap

[jack_norton]

Well, I really like python indenting for example when you do menus, is much more readable than brackets, if you have very long branches.
I programmed a lot in C and I find much better the indent than the brackets. I guess is just personal preferences.

[Jake]

Well, I really like python indenting for example when you do menus, is much more readable than brackets

I've got nothing against it for my own code, I tend to lay everything out neatly anyway. But seriously, there's nothing that stops you from indenting your blocks in C as well, it looks just like Python with extra brackets. I do it all the time, because it helps readability... I'm just saying that normal people who aren't already programmers and don't understand programming concepts typically consider meaningful whitespace insane.

[PyTom]

But seriously, there's nothing that stops you from indenting your blocks in C as well, it looks just like Python with extra brackets.

The argument (which I'm not sure I totally buy) is that in C you can get the indentation wrong, which can confuse someone reading your code.

Anyway, back to the roadmap: I'm strongly considering introducing a new format for rpy files. Files in the second rpy format will have the following changes:

- It will use the python 2.6/3.0 string formatting. This will allow us to write:

Code: Select all

e "You are {player.age} years old."

instead of:

Code: Select all

$ age = player.age
e "You are %(age)d years old."

Frankly, I'm not 100% sure how to manage this transition, as we currently use { and} for text tags. Perhaps it makes sense for substitutions to be written with {{ and }} instead, or some other delimiter.

- Monologue mode: When the text of a say statement contains one or more blank line in it, that say statement will be broken into lines at the blank lines. For example:

Code: Select all

    e "This is the first screen that will be shown to the user.

        This is the second screen.

        And this is the third and final screen."

- Perhaps some changes to how we handle whitespace, like not automatically merging whitespace? I'm not sure about this one.

I'd appreciate suggestions, as once I change the syntax, it will be years before I'll change it again. I'm not looking for radical changes, but little ones that should make Ren'Py easier.

Right now, the idea is that there will be two new statements introduced to manage the format transition.

Code: Select all

rpy version 2

controls the version of the current file.

Code: Select all

rpy default version 2

will control the version of all files parsed after this one. (I'll be changing Ren'Py so options.rpy is parsed before other files, and this will go there.)

[Jake]

The argument (which I'm not sure I totally buy) is that in C you can get the indentation wrong, which can confuse someone reading your code.

Equally, though, if I want to read C-style code in a particular format - indented for each block, with open-block brackets on the line following the command which takes the block, for me - then I can run someone else's code through a pretty-printer which formats it whichever way I'm most comfortable reading it.

Code: Select all

e "You are {player.age} years old."

This looks nice...

- Monologue mode:

This, though, I'm not sure what the benefit of it is?

I'd appreciate suggestions, as once I change the syntax, it will be years before I'll change it again. I'm not looking for radical changes, but little ones that should make Ren'Py easier.

Well, I'd still have suggested what I said a few posts back - a narrow interface to Python, disallowing $-prefixed lines, and Ren'Py commands to do everything you'd need to do in the course of a 'normal' VN - including simple arithmetic, setting up Characters, etc. And if you're going to make options.rpy special, I'd seriously consider making it a non-rpy config file, for that matter - come up with some syntax for defining characters, sprites, images and so on that also doesn't require Python nor an understanding of init blocks. I'm not sure how it would fit with your new string-interpolation, let alone whether anyone would consider it 'not radical', though. But it seems to me that if one is going to create a new script file format, one should take the opportunity to get the best changes one can think of into it, since breaking changes can't be effected every day.

[Counter Arts]

I like the indentation blocks because I don't have to go around looking for and counting brackets. Of course, I can easily solve this by using more calls.

For those who are new to programing... having brackets there seems easily abusable and daunting to look at for anyone new if it is abused.

Then again, on the mini-project I am hacking together... I do funny control-flow stuff in the ren'py blocks that tom would probably kill me for showing to someone else on this board. (Because he might be asked to figure out how it works)

[delta]

- Monologue mode:

This, though, I'm not sure what the benefit of it is?

The main benefit is that you can save a lot of overhead that is very error-prone if you don't make a generic ADV game. Though it still doesn't go far enough for me - I'd rather have a "speaker" statement that starts a block spoken by said character and ends the previous one - and require no quotes at all instead.

[Jake]

I'd rather have a "speaker" statement that starts a block spoken by said character and ends the previous one - and require no quotes at all instead.

This would make a lot more sense - having the quotes there seems to me to be just as much a potential source of problems, if you're going to do it for more than a couple of lines. And for a couple of lines, it seems like an unnecessary solution.


(The solution PyTom gave also seems pretty counter-intuitive, to me - I would expect, if Ren'Py allowed me to insert linebreaks into string literals, for those linebreaks to be treated the same way as "\n" in the same literal... I'm pretty sure I've seen someone try and add linebreaks to their dialogue like that before, in fact.)

[EwanG]

On another matter, it would be "helpful" if part of the character definition also allowed you to specify a text style. For myself, if I have a character speaking their "internal" dialogue, I indicate that using italics. Which gets to be a pain after a while. It would be nice if I could have a "pov" character definition that uses the default style, and a "povi" character that uses italics. Then instead of all the {i} {/i} tags I would just use the "other" character.

Just a thought...

[Vatina]

As a non-programmer, I'd like to say that I don't have much problems with the white-space indentations. I think the brackets would have confused me a lot more when I started out with my "I can't program"-attitude
It doesn't take long to catch on to, really, especially since the editor makes them for you when you are about to create menus and such. (at least in Scite? Not sure about all the others.)

But maybe that's just me. I don't know if it becomes an increasing problem if you use more advanced code either.

[Jake]

I think the brackets would have confused me a lot more when I started out with my "I can't program"-attitude

How so? It looks exactly the same, only with brackets. So you end up with things like:

Code: Select all

if (someCondition)
{
    doStuff
    doOtherStuff
}

Despite the apparent belief of some people in this thread, you don't lose the ability to indent your code if you use brackets... it's still a very good idea. A very large number of editors will automatically add indentation for you, and even better several will reformat other people's code on-the-fly so you can read it the way you prefer regardless of how they wrote it in the first place, which just isn't possible with whitespace.

I don't know if it becomes an increasing problem if you use more advanced code either.

It's kind of a moot point, since beginner programmers are pretty unlikely to be writing advanced code; anyone doing so more than likely understands blocks as a concept already.

[Cironian]

On another matter, it would be "helpful" if part of the character definition also allowed you to specify a text style. For myself, if I have a character speaking their "internal" dialogue, I indicate that using italics. Which gets to be a pain after a while. It would be nice if I could have a "pov" character definition that uses the default style, and a "povi" character that uses italics. Then instead of all the {i} {/i} tags I would just use the "other" character.

I don't know if it's the same for ADV mode, but for NVL, using what_prefix and _suffix works fine for me:

$ i = NVLCharacter("Mr. Italic", what_prefix='{i}"', what_suffix='"{/i}')

I use that one all the time to give my characters individual styles where appropriate.

[PyTom]

The reason for having quotes (as opposed to a statement and indented block) is for better editor support. Something like:

Code: Select all

e "This is the first screen.

    This is the second screen."

"This is a different say statement."

Is very easy to highlight. By comparison, something like:

Code: Select all

speaker e:
    This is the first say statement.

    This is the second say statement.


speaker narrator:
    This is a different say statement.

Would be more difficult to get a regexp-based text editor to highlight correctly.

In general, I like the current division of Ren'Py definitions into Python and Ren'Py statements, where the only special statement is the image statement, which is necessary because the multi-part image names don't really have an equivalent in python. I don't want to have to come up with new syntaxes for this sort of thing, because I'm pretty sure within a few years they'll grow into Python invented poorly.

Having given it some thought, it's tough to come up with an alternative syntax for character declaration that's much clearer while still retaining the functionality of the Python version.

One thing that's new in 6.9 is that init (as opposed to init python) blocks are basically obsolete. While I still have to update the examples in the documentation to reflect this, it's now possible to do things like:

Code: Select all

init python:
    e = Character("Eileen")

image eileen happy = "eileen_happy.png"

And have that work. (Come to think of it, it might make sense to rename 'Character' to 'Speaker' at some point, since that better reflects what the class is used for.)

Adding braces or begin/end is unlikely. In fact, feedback from teachers show that indentation-based blocks are easier to understand that brace-based blocked. (See this, and also note that Python grew out of experiments with an educational language that showed that indentation-based blocks were successful.)

I don't think that begin/end or {/} will win us enough to be worth changing to them, especially when Python code will remain in the mix.

On another matter, it would be "helpful" if part of the character definition also allowed you to specify a text style. For myself, if I have a character speaking their "internal" dialogue, I indicate that using italics. Which gets to be a pain after a while. It would be nice if I could have a "pov" character definition that uses the default style, and a "povi" character that uses italics. Then instead of all the {i} {/i} tags I would just use the "other" character.

We've supported this forever:

Code: Select all

init python:
    pov = Character(None)
    povi = Character(None, what_italic=True)

[EwanG]

We've supported this forever:

Code: Select all

init python:
    pov = Character(None)
    povi = Character(None, what_italic=True)

Glad I asked then. My fingers thank you.

[delta]

The reason for having quotes (as opposed to a statement and indented block) is for better editor support. Something like:

Code: Select all

e "This is the first screen.

    This is the second screen."

"This is a different say statement."

Is very easy to highlight. By comparison, something like:

Code: Select all

speaker e:
    This is the first say statement.

    This is the second say statement.


speaker narrator:
    This is a different say statement.

Would be more difficult to get a regexp-based text editor to highlight correctly.

This is why KiriKiri is far superior in this regard in my opinion; it just treats EVERY line as say text by default and marks those that aren't any with a special reserved starting character (it uses several ones for different purposes, but no need to get into detail here; choose any you like). That means no forced indentation, no quotes, and no problems with highlighting either because it's just a string literal unless the line is special (which is easy to detect). And in even that most code-heavy scripts, the majority of your script WILL be say text.

Code: Select all

@speaker e
This is the first say statement.
This is the second say statement.

@speaker narrator
This is a different say statement.

@show eileen happy #etc.

Sure, it isn't Pythonic anymore but then again I thought Ren'Py script wasn't supposed to require understanding of Python. Also note that I'd take a cleaner scripting system over editor highlighting any day in any case; editor highlighting needs to be coded only once, but everyone benefits from an even marginally streamlined scripting system.

As a side note, I view a large part of the Ren'Py script philosophy as an attempt to utilize Python's OOP philosophy as much as possible; that's all fine and dandy if you're coding, but does not lend itself to narrative texts, which are by their very nature highly linear, well at all.

[Counter Arts]

The only problem with what you propose is when you have speakers changing too much. I may not use as many quotes but I'll be writing "@speaker" waaaaayy too much. I'd rather type two quotes than type that every time.

The problem you describe can be solved just using a python say block.

Ah... that's why tom wants monologue blocks. If one person talks too long use a monologue block.

EDIT: I recommend the following

Code: Select all

darkPerson says:
   Haha...
   I will hurt you all.
   Eat candy evildoer!
bystander says:
   I'll be going now.
   After I heavily comment on mindless details about the actual lost art of throwing candies
   Blah Blah
   Blah blah blah

hero "Can we get started already?"
talkingPet "We need to burn about 2 more minutes."
hero "NOO!!!"
talkingPet says:
   Here is our elaborate strategy.