Ren'Py Roadmap

[PyTom]

A bunch of responses:

Running a poll is not something I'll ever do when designing Ren'Py. Reasoned debate is one thing, but we're not going to get anywhere designing a language by committee. This is Ren'Py, not Ren'C++.

When it comes to the dialogue syntax, my general instinct is to be relatively conservative. We've had a dialogue syntax that's worked well for 4 years of actual use, so I'm not really that inclined to change it, unless the change is likely to be a huge win. I think adding monologue mode is likely to be a big win, but some of the more radical suggestions proposed here seem to be larger changes that I'd be comfortable with.

I'll also point out that radical changes have other problems. We have hundreds of examples of dialogue on renpy.org, and more on other web sites that I can't easily control, and I'm kinda loathe to pick a new dialogue syntax that makes all of them invalid.

The integration of Python with Ren'Py is a philosophical issue, more than anything. I strongly believe that any reasonable VN engine will grow to include a scripting language, and hence we might as well start with a good one. I do think it might make sense to add a feature to Ren'Py that lets it dump out the names of interesting things: characters, tags, positions, transitions, and so on.

A Ren'Py-aware text editor is an interesting problem. Personally, I don't think we're limited by the language syntax very much--- the only sane way of doing this would be to use Ren'Py to parse Ren'Py. I think the big problem is that writing a text editor is a huge undertaking, and so few are willing to do that.

(That being said, I did just find out about a jEdit plugin that will make adding some Ren'Py support easier. Another thing to do when I get around to it.)

[delta]

Renpy has lots of useful additions to pygame (mostly GUI and dialogue system), that's why I use it instead of pygame.

Eh, so in short... you use it as a GUI toolkit for pygame, and it's good at that (lack of alternatives certainly does not hurt). Fine, nobody is saying that you can't do that, and nobody wants to cut features. But as someone who uses the engine extensively in the field it was actually designed to be primarily used in, I can say that it's far from perfect at that, so it should be improved.

BTW, thinking about it, you can probably just fake the "speaker" command by making a shortcut command to overwrite the narrator character with another one repeatedly. But that still doesn't get rid of the quotes.

I think adding monologue mode is likely to be a big win, but some of the more radical suggestions proposed here seem to be larger changes that I'd be comfortable with.

If you do it in the way you proposed, the change is pretty inconsequential. Also, if you're the only game in town, it's not really clever to say "it worked for 4 years, so it's perfect". PHP has "worked" for 10+ years, that does not make it not a badly designed language. Not to mention that we are discussing this on the Ren'Py fanboi forum, where people who don't think the syntax is the best thing ever hardly show up (FYI, I've talked to people who highly dislike the syntax, but consequently they don't use it and don't register here).

[DaFool]

Er, one of my projects required the use of a custom text system PyTom programmed for us. It's not ADV, it's not NVL either, it's something which we have a name for but don't want any other people to know what it is so that ours will be the first game to use that custom text system. Now how would such 'special cases' fit into the discussion regarding optimal scripting systems?

[delta]

I don't know, because I can't discuss things you basically didn't say anything about. I can go in and say that every change I dislike breaks some mysterious thing I happen to be working on but won't say anything about, but I wouldn't expect anyone to take me seriously.

[Jake]

Now how would such 'special cases' fit into the discussion regarding optimal scripting systems?

To put it more bluntly than delta did - in a public discussion regarding scripting, you have two choices: get ignored or explain how your supa-sekrit text mode works so it can be taken into consideration.

Of course, if you have PyTom coding for you and bearing your method in mind when he makes decisions about the direction of Ren'Py, then all the better for you - but it does make the public discussion pretty pointless if your special-case system is considered in PyTom's choice.


Of course, there's also the argument that execution is invariably more important than inspiration, and that if your game is well put together it doesn't matter at all whether it's first-to-market, but that's largely beside the point.

[PyTom]

Frankly, the project DaFool mentioned would work with any of the text descriptions mentioned here. So that didn't really factor into it much. I do consider the ui functions to be an important part of Ren'Py, as they allow for hybrid games (Magical Boutique, Summer Session, and others) which I do think are important in the Ren'Py ecosystem.

I don't think Ren'Py is a badly designed language, at least to the point where it requires a radical overhaul as opposed to incremental simplification, especially if such an overhaul will invalidate much of the documentation that has already been written, and the experience people have.

I'm actually reasonably proud of Ren'Py's script language. While there are certain flaws that I need to address (moves are way too difficult), in general I think it accomplishes the job, being both readable and reasonably minimal. While some might dislike Ren'Py, I suspect that the disagreements are more philosophical (optimized for ADV vs NVL, textual vs graphical, definitions versus declarations) than with the actual syntax that was developed as a result of that philosophy.

(The discussion on significant whitespace is probably the major syntax disagreement, but I think it makes sense, especially if Python is the embedded scripting language.)

Delta, it would be interesting if you could find out what people actually dislike about the syntax, if anything. I suspect it will be the ADV over NVL bias that Ren'Py has, which predates the release of Tsukihime and Fate.

[delta]

That's quite simple. There are people who like significant whitespace (Let's just call them "Python programmers" for short) and people who dislike it (let's just call them "everyone else"). And the point is not that those people are right, the point is that this forum is a very tiny amount of people that constantly tell each other how great they are. Not a recipe for change, in any way.

[Preludian]

I'll try to keep it short:

1.

I'm actually reasonably proud of Ren'Py's script language.

Hell yes! This is a wonderful piece of software, I love it, Thank you very much for it.

2. I thought I had to keep the indentation slavishly, even in non-python parts, and if somehow some whitespacing would be broken by another editor than good-bye. But it's good to know that I am free how to use it within Renpy-Code.

3. I made a chm from the documentations, because I like to be able to search through the docs. IMHO although there is much text it is sometimes difficult to understand all the syntax. Especially the reference is complex, more complex than it should be, because many commands are simply not explained enough or are missing examples or only show the easiest examples.

So I have to search around, examine your great demo to understand more. My wish would be to have a -at least- small example for every command with all flags etc. with a understandable comment.
This is what has been done for Blitz3D, a nice sort of Basic language for 3D and everybody is so happy. On the other hand, the new product called BlitzMax has a dreadful documentation and everybody complaints and so much time is lost.

So as my naive conclusion, maybe all the hassle is less about the Syntax or Python itself, but the difficulty to step further, from pure standard easy Renpy script like in the quickstart to the more advanced subjects. I think that's the point where many stumble. At least that's what happened to me. So often I didn't understand a function from your reference but then managed to find an example or another explanation somewhere and than suddenly I understood and then asked myself, why is the reference missing the essential link to understanding.

I hope this makes sense somehow

[Spiky Caterpillar]

I think you're missing my point - just because Ren'Py is written in Python doesn't mean that it has to follow Python conventions or syntax. It does so for convenience, and specifically for the convenience of PyTom and of people wanting to do advanced things with it.

But most users won't be doing advanced things with it, and most people doing advanced things won't actually typically be spending more than 10% or so of their script doing those advanced things, so from a usability point of view it's silly to make that the primary driver for the way the scripting language is put together.

Well, most of Science Girls' source is in init python blocks... *grin*

Using two different syntax models in Ren'Py depending on whether you were writing VN script or using advanced features would let users experience all the flaws in curly-based and whitespace-based indentation together (plus, I suspect, special errors caused by attempts to mix and match). Not really an improvement, and for someone writing a vanilla VN who just wants to do one or two fancy things (... say, those pseudo-imagemaps with different sounds for different buttons), a royal pain in the arse.

[Spiky Caterpillar]

Code: Select all

e "You are {player.age} 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.

Being able to directly interpolate object members will be nice. From a backwards compatibility standpoint, I think {{ }} or %( ) are the best options, since they save us from having to reassign text tags to a new delimiter and don't require reserving any new characters. %( ) would make Ren'Py just Do What I Expected From The Beginning, which is arguably a Good Thing(tm).

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

I forget whether I commented on this already or not, but I'd love to see auto-merged whitespace go away. (In large part because I'm picky about grammar and like to doublespace after periods.)

[PyTom]

I forget whether I commented on this already or not, but I'd love to see auto-merged whitespace go away. (In large part because I'm picky about grammar and like to doublespace after periods.)

This is incorrect, though. Most sources seem to agree that it's correct to leave one space after a period:

MLA: http://www.mla.org/style_faq3
Chicago Manual of Style: http://www.chicagomanualofstyle.org/CMS ... Two02.html
US GPO Style Manual: "A single justified word space will be used between sentences. This applies to all types of composition."
Microsoft Manual of Style for Technical Publications: "Use only one space after a period in both printed and online content."

Common English Errors: http://www.wsu.edu/~brians/errors/spaces.html

http://howmanyspacesafteraperiod.com/

[Spiky Caterpillar]

I forget whether I commented on this already or not, but I'd love to see auto-merged whitespace go away. (In large part because I'm picky about grammar and like to doublespace after periods.)

This is incorrect, though. Most sources seem to agree that it's correct to leave one space after a period:

MLA: http://www.mla.org/style_faq3
Chicago Manual of Style: http://www.chicagomanualofstyle.org/CMS ... Two02.html
US GPO Style Manual: "A single justified word space will be used between sentences. This applies to all types of composition."
Microsoft Manual of Style for Technical Publications: "Use only one space after a period in both printed and online content."

Common English Errors: http://www.wsu.edu/~brians/errors/spaces.html

http://howmanyspacesafteraperiod.com/

Waa, they changed the language rules when I wasn't paying attention.

The MLA one at least says both modes are correct, even if singlespaced is more popular now.

[Jake]

Using two different syntax models in Ren'Py depending on whether you were writing VN script or using advanced features would let users experience all the flaws in curly-based and whitespace-based indentation together

I'm not necessarily suggesting it has to be radically different. Just that I think Ren'Py script should be a small, streamlined language specifically for writing VNs, which Python definitely isn't. Presently, Ren'Py is more like an extra set of sugars for Python than a language of its own, and it shows. I strongly suspect that 95% of users couldn't really care less about the Python side of things so long as sufficient functionality to write a VN with a few relatively-normal bells and whistles was built into the language. I also strongly suspect that there are a significant number of potential Ren'Py-users out there who are presently put off by the necessity to script by hand without any friendly tools (which auto-completion doesn't qualify as). Unfortunately it seems like inertia is going to kill any chance of getting any meaningful changes to the scripting language, though.

(Personally, I don't really like significant whitespace, but personally, I indent all my C-style code anyway so it's hardly a big problem for me, with a competent editor. However, my experience suggests that teaching people that whitespace has meaning and that it doesn't matter how far you indent so long as it matches the rest of the block and that they have to return to the previous level of indentation and not just go back one or two spaces and that it doesn't matter whether it lines up in the editor, there is a difference between tabs and spaces and Python will punish you for forgetting it and all that is harder than teaching people to match brackets wherever they damn well please, which is why I suggested begin/end or some other way of denoting blocks. But PyTom seems pretty resolute on that one so it's not really worth discussing it further anyway.)

Not really an improvement, and for someone writing a vanilla VN who just wants to do one or two fancy things (... say, those pseudo-imagemaps with different sounds for different buttons), a royal pain in the arse.

I see no reason why imagemaps couldn't have their own syntax in a hypothetical VN-specific scripting language? They're already getting one in Ren'Py in this most-recent release, aren't they? You'd only really need to add an optional sound parameter to the end of each hotspot line and you'd be there, you could play the 'clicked' sound at the beginning of each hotspot's block if you really needed to.

[EwanG]

Unfortunately it seems like inertia is going to kill any chance of getting any meaningful changes to the scripting language, though.

Suppose someone could take Python and some of the alternate ideas around here and make just what you'd like to see if they wanted to. However, I can't say I've seen any evidence of anyone wanting to take on that challenge.

[PyTom]

there is a difference between tabs and spaces and Python will punish you for forgetting it

I'll note that this is less of a problem in Ren'Py, where tabs are banned entirely.