Ren'Py Roadmap

[delta]

It's a bad habit of some programmers to presume that complex syntax, keywords etc. are OK just because they understand them.

Another bad habit of programmers is that they think what they think is simpler to understand actually IS simpler to understand. Ren'Py's neither fish-nor fowl (where fish = Python and fowl = pseudo-English) approach is a very good example of this. IMO, it's a bad idea to make programming languages "friendly" if you can't pull it all the way through, because at the end of the day you are still programming and the interpreter will choke on deviations from a supposedly "simple" system as much as as from deviations from a "complex" model, so it's a folly to pretend you're making anything actually easier - you still have to learn the language, and it looking all nice and friendly only leads you to think that the supposedly friendly interpreter will somehow magically understand anything you tell it if you are nice to it.

Now, using some sort of abstraction system is still very beneficial, but not for the goal of making it simpler but to keep the overhead low. For this reason, I've been advocating to have all init code be pure Python, and use the simple statement language only where it really saves work, namely the scripts themselves (and remove forced indentation and quotes there).

[EwanG]

That said, I think if I were to pick a single thing which would make Ren'Py easier for most people to understand how to write games for, it would be to get rid of the reliance on indentation for block control and use begin/end or something similar for blocks in Ren'Py script. Not that I expect that's going to happen any time soon.

Yes, that would make me an incredibly happy camper also. Though I've often wondered if it wouldn't be possible to write a macro that would replace some character with X number of spaces so I could write it one way, then run the macro and have it formatted the way needed...

[JQuartz]

so it's a folly to pretend you're making anything actually easier

Really? I felt Renpy's easier to understand language(compared to C++ or Python) was crucial for me to understand it (I'm not a programmer). I definitely wouldn't have learned as much as I had now (which is still not much) if Renpy was any tougher. So personally I don't feel it's really a folly.

For this reason, I've been advocating to have all init code be pure Python

Psst...use init python.

[PyTom]

Preludian >>> My hope is that by the time I'm ready to do a Silverlight port, its prevalence will be such that it's useful for many of the online demos and things. It won't work for the DS or Wii, but for now a Silverlight port will be technically much easier than a Flash one.

Part of what I have to do is to balance usefulness with complexity. I'd much rather have a flash port than a Silverlight port. But the flash port (as of today) would be very very difficult to pull off, while the Silverlight one will be technically much easier.

That said, I think if I were to pick a single thing which would make Ren'Py easier for most people to understand how to write games for, it would be to get rid of the reliance on indentation for block control and use begin/end or something similar for blocks in Ren'Py script. Not that I expect that's going to happen any time soon.

Yes, in retrospect this is probably one of the things that makes Ren'Py more difficult to learn, especially because you have to teach it to people very early, before they are comfortable with the language.

[Jake]

For this reason, I've been advocating to have all init code be pure Python

Psst...use init python.

I think you're missing his point - he's not complaining that he can't just write Python code in the init blocks, he's suggesting that it would be better if there wasn't any option to write Ren'Py-script init code. Presumably on the basis that most of the things you want to do in an init block require Python, there isn't much Ren'Py-script which is specific to the init block and what there is isn't much different what you might do in Python. And there's some inconsistencies between setting Characters (Python only) and images (Ren'Py-Script or Python) up, and having Ren'Py-Script options for init stuff invites people to put init stuff in their main script by accident.



It seems to me it would be better to make it possible to write Ren'Py games without a shred of Python, purely in a more-friendly Ren'Py script. Allow Python integration only through a set of well-defined interfaces, maybe have a separate 'config' file for setting up all the things we presently do in init: blocks. Ren'Py-script being a simpler, smaller and more usage-specific language, it could more-easily be parsed for things like GUI IDEs, which a lot of people would benefit from. It would also mean people who don't go out of their way to use Python wouldn't ever encounter impenetrable Python errors, and Ren'Py-Script could have its own set of easy-to-understand error messages.

One of the nice things about Ren'Py is how easy it is to customise for those of us who understand programming... but it doesn't help much for the novices who don't and don't want to.

(And seriously - yes, people are still programming however friendly the language, and they still have to stick to some basic rules of syntax, but in my experience most non-programmers find it a hell of a lot easier to pick up new concepts when they're presented using English-language verbs rather than symbols - or worse, whitespace. A big part of it, as best as I can tell, is to do with getting over the initial "programming is hard" mental barrier.)

[JQuartz]

I think you're missing his point - he's not complaining that he can't just write Python code in the init blocks, he's suggesting that it would be better if there wasn't any option to write Ren'Py-script init code.

Oh, okay. I thought he was complaining it was troublesome to put $ before every python code.

[Preludian]

@Jake: Exactly and right on the point. This would free the User of having to learn RenPy AND Python.

Me personally I wanted to learn Python for another project, so RenPy is a great motivation to do it.

But how it is now, the difficulty at first is to know when it's RenPy and when it's Python. (And the one thing I really never liked about Python is the way of having to structure through indentation, brrrr )
Besides Python I am learning PHP too right now and it's really so much easier, more logical and more intuitive than Python IMO, maybe, because it behaves more like a 'normal' language??

So, forcing the process of making the difference between RenPy and Python more noticeable is the correct way IMO.

@PyTom (Flash): I understand (nah, no problem , btw. did you have a look at the OpenLaszlo-Project?

[DaFool]

Something that just popped in my head regarding Python-syntax-less Ren'Py scripting:

This would require a lot of Frameworks to be developed already, which can be called like C++ libraries. e.g.

renpy.include(jquartz_menu)

Of course it would be much easier if mix and matchable features come as plain rpy script files, but when a python-illiterate opens them up using the text editor and he sees tons of ZOMG HARDCORE programming, it may be a turn-off.

I dunno, maybe designate that all python from now on be in .py and ban them from being used in .rpy? (And include an automatic script parser that splits them and isolates them). Also probably have an option to open up renpy script only (default) or python script only (for more advanced users).

[jack_norton]

I agree about having all init only python, doesn't make much sense to use the $ simbol before variables
But I don't understand why you want to cut out python from .rpy !? if you don't want to use python, don't use it. Non programmers can make a game fine using normal renpy commands, but if I want to add lots of ui and custom stuff I don't see why I shouldn't be able to use it as it is now.
For me now renpy is a very good language honestly and I don't think it would need a total revolution unless there are obvious benefits.

[Spiky Caterpillar]

That said, I think if I were to pick a single thing which would make Ren'Py easier for most people to understand how to write games for, it would be to get rid of the reliance on indentation for block control and use begin/end or something similar for blocks in Ren'Py script. Not that I expect that's going to happen any time soon.

Yes, in retrospect this is probably one of the things that makes Ren'Py more difficult to learn, especially because you have to teach it to people very early, before they are comfortable with the language.

NOOOOO!

Anyone new to programming is going to be confused by whatever form of block control is used - be it begin/end/{} or whitespace. I think the whitespace method makes it a fair bit easier to *read* the code when you're trying to figure out what went wrong. And I suspect that the regular "Why isn't my code working it said indent error" "This is how to fix your indentation error" threads probably waste less overall time than threads about misnested curly/begin/end errors will.

[delta]

Python's whitespace grouping is fine for code that uses grouping heavily, but for Ren'Py scripts, where literally 99.9% of everything is on the same level, it's nothing but an annoyance to always have four spaces at the beginning of each line.

[PyTom]

But that's just style. There's no requirement for a block to follow a label, so something like:

Code: Select all

label start:

scene bg wall street
show eileen happy

e "The stock market went down today."

show eileen vhappy

e "But there's good news!"

show eileen concerned

e "If it goes down this much for another 22 days, it won't go down anymore!"

I think this is less readable, even with syntax highlighting, but it's been supported since Ren'Py 4, at least.

[delta]

WHAT

[Jake]

NOOOOO!

Anyone new to programming is going to be confused by whatever form of block control is used - be it begin/end/{} or whitespace. I think the whitespace method makes it a fair bit easier to *read* the code when you're trying to figure out what went wrong.

Brackets of any kind are easier to explain to people than whitespace. Seriously. You can see them and everything! They're also more deterministic - if you've opened two brackets, then you're in two blocks, while if you're five spaces from the left then you could be in anywhere between one and five blocks in Python (think of the cocking-up-via-copy-and-paste opportunities!). In my experience significant whitespace is far more confusing to new programmers than brackets - brackets, after all, already exist in regular English grammar so everybody knows that you have to close a bracket you open... whereas people are already used to whitespace being totally meaningless, particularly the degree of indentation, so it's a new concept to most people. You can read code with brackets or particularly begin/end and realise instantly that those keywords/symbols are significant; I'd been programming over a decade when I first came across Python code, and it wasn't immediately obvious to me until I realised there wasn't anything but the indentation it could be. People who don't know to look for blocks in the first place would have a problem.

As an illustration of this, from both sides of the fence, when newbies come to the forum to ask for help, they near-universally use 'quote' tags to show us their code, which collapses all whitespace, meaning you can't see the blocks. Maybe they don't realise the whitespace is significant, maybe they didn't realise there was a 'code' tag, maybe they just forgot - but whatever the case, the meaning is lost and it's hard to see the error, particularly if it's actually an indentation problem in the first place. If begin/end or {} or something were used, the code would mean exactly the same thing however it was formatted.

Also, you can't confuse 'begin' or 'end' with a tab character.


I agree it's nice to have cleanly laid-out code. I don't agree that it should be forced on people, and I think it's crazy to expect new programmers to understand that the layout itself has meaning.

[Preludian]

WaWaWa..?? And what about Python? Does it matter in pure python code blocks?