To be honest, I don't understand why the python integration would be a problem with editing Ren'Py script. The python is all contained in easy to parse constructs, so that it should be possible to treat it opaquely as far as the editor is concerned.Jake wrote:ii) It would be far more useful to be able to read in projects which had been edited by hand elsewhere, or originally written outside of the editor, which isn't a practicably surmountable problem what with Ren'Py script having its current haphazard integration with Python.
Is the eventual intent to create lists of characters, transitions, at functions, images, and so on, so that autocompletion becomes possible? I think that the best way to do this would be to add introspection support to Ren'Py itself, rather than have an editor try to do the introspection directly. Even if we were to separate Ren'Py script from Python script, unless we prevented the Python side from being able to define things, we wouldn't be able to autocompete.
Or am I missing some other advantage?
I wouldn't call the Python integration "haphazard". It's relatively pervasive, but it's always possible to tell what's python and what's not.
Could you give some examples of a suggested syntax? I freely admit that Move is overly complicated, but that's something I'll be fixing in the next release. Right now, the syntax for defining a character is:Primarily, I would like to see it possible to write a VN in Ren'Py - including all 'normal' functionality, moves and variables and character/image definitions and so on - without having to write a line of Python. Currently you need Python to define Characters and to do variable manipulation at the very least. This would be a benefit for new users because like it or not, the distinction between Python and Ren'Py script and when to use $ signs and so on isn't immediately obvious.
Code: Select all
init python:
e = Character("Eileen", color="#8f8")
Code: Select all
# Note that the need for init: went away in 6.9
image eileen happy = "eileen_happy.png"
So far, I'm not seeing anything that (with script versioning) would be a breaking change. (Which is a disappointment, since I'd love a breaking change to come around so I can clean up some cruft.)These could both be realised without requiring any change to the Ren'Py distribution size, and without preventing any games which could be written before from being written now. It would be a breaking change, scripts prior to this change would need fixing up to work after it, but Ren'Py's had those before. And in fact, since Tom's talking about a whole new version of the script spec., it wouldn't even necessarily be a breaking change.
This is a good idea. There is the issue of how the theme would be loaded and saved, but that's something that could be worked out somehow.As a total aside, I also think that a Theme Editor would be useful, a graphical tool which gives you property-box modification of the various properties and styles needed to make a theme, which saves out as a .rpy file and associated assets. Maybe even an .rpa with everything in it? But that's separate, and for that matter could be distributed separately, before anyone starts worrying about the distribution size.
I am interested, but I just don't see the mix as being much of a problem when it comes to tool development. I think this is because (due to my education) I'm quite skeptical of static analysis, and much prefer introspection as a way of finding out information from code.But then, PyTom's already said he's not interested in any of these changes, because he apparently thinks that the ecclectic mix of Python and Ren'Py Script that we have at the moment is a good thing. I disagree, but it's his project and I can't be bothered to maintain a fork. I also think it would be worth not using significant whitespace, but that's also been discounted.