Ren'Py Roadmap

In this forum we discuss the future of Ren'Py, both bug fixes and longer-term development. Pre-releases are announced and discussed here.
Message
Author
User avatar
PyTom
Ren'Py Creator
Posts: 16088
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: Ren'Py Roadmap

#106 Post by PyTom »

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.
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.

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.
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.
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:

Code: Select all

init python:
    e = Character("Eileen", color="#8f8")
It's not clear to me how to make that simpler, but I'd appreciate any suggestions, even if I won't commit in advance to adopting them. Image definitions don't need Python in the simple case:

Code: Select all

# Note that the need for init: went away in 6.9
image eileen happy = "eileen_happy.png"
I'm strongly considering auto-definition of images as a new feature. So apart from various definitions, all we have is variable manipulation, right?

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.
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.) :-)


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.
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.
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.
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.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

User avatar
PyTom
Ren'Py Creator
Posts: 16088
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: Ren'Py Roadmap

#107 Post by PyTom »

delta wrote:Exactly. The other problem is that I find Ren'Py's performance to be underwhelming. I understand this is a very basic issue issue of using a non-hardware accellerated interpreted scripting languaged for memory-intensive blitting, and this extremely hard to fix, but a flaw with a reason is still a flaw.
I suspect (and have profiling data to show) that the software blitting is the main slowdown, rather than the interpreted language. All of the performance-critical bits of Ren'Py are written in C.

6.9 is probably about as far as I'll be able to go with software blitting. 6.9 introduces a new framework in which there are only a few drawing primitives involved, which roughly correspond to what one can do with a OpenGL 1.1 card. 6.9.1 will rewrite most of the different operations in terms of those primitives, making it possible to add hardware support in the 7.something timeframe.

To some extent, I'm largely stalling for time when it comes to hardware support, in the hopes that systems without reasonable OpenGL support will become obsolete enough I don't feel bad about not supporting them. In the meantime, 6.9 takes software rendering about as far as I'm willing to go with it. I'm expecting an OpenGL-fullscreen mode to come about relatively soon, which will use hardware support to scale a software-rendered image to fullscreen.
Now, a question. How many of you are actually comparing Ren'Py to other VN engines, especially modern ones like KiriKiri? Because while I think that Ren'Py is at the moment the only sane choice for non-Japanese VN development, that doesn't mean it's superior to them in every regard (for the record, I know KiriKiri and ONScripter well and have dabbled in NSS, RealLive, Novelty and Blade). I think as long as Ren'Py isn't as good as any of them in any regard, there is still room for improvement, which is always worth discussing.
I certainly agree with this. 7.0, while the end of the current roadmap, isn't going to be the end of Ren'Py development. Hardware support, avbin-based movie playback, a better launcher... I have enough to keep me busy for years.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

Counter Arts
Miko-Class Veteran
Posts: 649
Joined: Fri Dec 16, 2005 5:21 pm
Completed: Fading Hearts, Infinite Game Works
Projects: Don't Save the World
Organization: Sakura River
Location: Canada
Contact:

Re: Ren'Py Roadmap

#108 Post by Counter Arts »

delta wrote:The other problem is that I find Ren'Py's performance to be underwhelming. I understand this is a very basic issue issue of using a non-hardware accellerated interpreted scripting languaged for memory-intensive blitting, and this extremely hard to fix, but a flaw with a reason is still a flaw.
Oh yeah... but now many people here actually KNOW how to take advantage of hardware accelerated graphics? If you know you know at a high level what bitting does then you know exactly what special effects to avoid.

If you're going out of your way to make it hardware accelerated, then you better have a darn good graphical reason.
Now, a question. How many of you are actually comparing Ren'Py to other VN engines, especially modern ones like KiriKiri? Because while I think that Ren'Py is at the moment the only sane choice for non-Japanese VN development, that doesn't mean it's superior to them in every regard (for the record, I know KiriKiri and ONScripter well and have dabbled in NSS, RealLive, Novelty and Blade). I think as long as Ren'Py isn't as good as any of them in any regard, there is still room for improvement, which is always worth discussing.
Well I always think that there's a need for improvement regardless of you are number 1 or not.

I make the assumption that ren'py is better or equal in terms of capacities because it is a Turing complete language. It may be inaccurate however it's a rough enough approximation for me in that I reproduce any game system mechanic on ren'py that I have seen in other visual novel engines. Performance is a different matter.
Fading Hearts is RELEASED
http://www.sakurariver.ca

Watercolorheart
Eileen-Class Veteran
Posts: 1314
Joined: Mon Sep 19, 2005 2:15 am
Completed: Controlled Chaos / Sum of the Parts / "that" Midna game with ZONEsama
Projects: Sparse Series/Oddments Shop original cartoon in Pevrea; Cybernetic Duels (fighting game); Good Vibin'
Organization: Watercolorheart Studios
IRC Nick: BCS
Tumblr: adminwatercolor
Deviantart: itsmywatercolorheart
Github: Watercolordevdev
Skype: heartnotes
Soundcloud: Watercollider
itch: watercolorheart
Location: Florida
Contact:

Re: Ren'Py Roadmap

#109 Post by Watercolorheart »

You know, this is probably really out of place, but you are so amazing PyTom. All this time, and you're still working for the English VN community ... you're our cornerstone.

Now if only the Wiki would stay up to date too ...

As for the features I'd like to see, I will always want a graphical language interface to go with the regular coding =_=. Like an auto-fill in feature or a way for it to remember which variables I've named and such ... sort of like an auto-complete. It would save me much copying and pasting or scrolling up to init to see what I named then ... or jumping back to menu13 or scene05 or what have you.
I'm not even the same person anymore

Preludian
Regular
Posts: 81
Joined: Wed Nov 05, 2008 9:10 am
Contact:

Re: Ren'Py Roadmap

#110 Post by Preludian »

BCS wrote: As for the features I'd like to see, I will always want a graphical language interface to go with the regular coding =_=. Like an auto-fill in feature or a way for it to remember which variables I've named and such ... sort of like an auto-complete. It would save me much copying and pasting or scrolling up to init to see what I named then ... or jumping back to menu13 or scene05 or what have you.
I have written about this (a nice plugin) in the JEdit thread. Maybe this helps a bit....

Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Ren'Py Roadmap

#111 Post by Jake »

PyTom wrote: 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.
One reason is that under the present state of the language, in order for this hypothetical editor to affect variables (which I would consider part of the 'necessary minimum set) of VN features, really), it would need to use Python itself. So, one comes to the choice between marking the ones the tool writes as 'special' somehow (about as reliable as a politician) or trying to work out what some subset of Python statements mean, while staying the hell away from some other set of Python statements which look remarkably similar until closely examined.

Another thought is that, with a well-defined interface between Ren'Py code and Python code, it would be much more feasible to write chunks of discrete functionality in Python, utilising the renpy.* methods where necessary, which new users could use whole without having to use any Python to get them into their project. Within a tool or without.
PyTom wrote: 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.
Actually, I wasn't thinking of a textual editor at all - or rather, the text-editor part would be for writing dialogue, and nothing else. Precise textual definitions of transitions or movements or what have you are the domain of the programmer, not the writer.

I would agree that introspection would be a preferrable way to do it to static analysis, but I wouldn't agree that this removes all motivation to make those changes; I still think that they benefit the novice user regardless of a hypothetical really-useful-tool existing.
PyTom wrote: 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.
It is haphazard in the same way that PHP's scripting is haphazard - it can happen at any time, in any place, without warning. And, largely, this is needlessly so. Sure, it's always possible for you and I and the interpreter to tell what's Python and what's not, but you and I and definitely the interpreter are not typical examples of people who can't already program.
PyTom wrote: Right now, the syntax for defining a character is:

Code: Select all

init python:
    e = Character("Eileen", color="#8f8")
It's not clear to me how to make that simpler, but I'd appreciate any suggestions
It's something I would want to think about before giving a proper response, but I would note that getting rid of the brackets and commas might be a start. If integrated into Ren'Py script, and Ren'Py script maintains the significant whitespace, why not follow the same mode, e.g.:

Code: Select all

character e:
    name = "Eileen"
    color = "#8f8"
?

It's not so concise, but people concerned with brevity can always still use the Python. People will often want to split their definitions out onto multiple lines when they're defining a character with more than a couple of attributes anyway.
Server error: user 'Jake' not found

User avatar
Deji
Cheer Idol; Not Great at Secret Identities
Posts: 1592
Joined: Sat Oct 20, 2007 7:38 pm
Projects: http://bit.ly/2lieZsA
Organization: Sakevisual, Apple Cider, Mystery Parfait
Tumblr: DejiNyucu
Deviantart: DejiNyucu
Location: Chile
Contact:

Re: Ren'Py Roadmap

#112 Post by Deji »

BCS wrote: As for the features I'd like to see, I will always want a graphical language interface to go with the regular coding =_=. Like an auto-fill in feature or a way for it to remember which variables I've named and such ... sort of like an auto-complete. It would save me much copying and pasting or scrolling up to init to see what I named then ... or jumping back to menu13 or scene05 or what have you.
That'd be great :3

Now, if it was ever possible and somebody would be willing to sacrifice themselves to do it in the future, I think it'd be helpful, especially for the more allergic to code, it'd be awesome to have more automated stuff. It doesn't have to be a WYSIWYG, really.
I'm thinking of something like....
- 'create new character' -> name it -> set properties
- 'add dialog' -> choose character -> enter text
- 'add character image' -> browse -> add character name -> add expression/pose name
- 'show character on screen' -> choose character and pose/expression -> choose positions -> choose transition
- 'add background image' -> browse -> name it
- 'change background' -> choose background -> choose transition
- 'add pause' -> define length
- 'define variable' -> name it -> set its value
- 'change variable' -> choose variable -> set new value
- 'create menu' -> add menu choice -> enter text -> enter what happens
- 'add label' -> name it
- 'jump/call' -> choose label
- 'create conditional' -> define condition -> enter what happens (-> add elif and repeat?) -> else, enter what happens

... just a thought :P
Image
Tumblr | Twitter
Forever busy :')
When drawing something, anything, USE REFERENCES!! Use your Google-fu!
Don't trust your memory, and don't blindly trust what others teach you either.
Research, observation, analysis, experimentation and practice are the key! (:

User avatar
PyTom
Ren'Py Creator
Posts: 16088
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: Ren'Py Roadmap

#113 Post by PyTom »

Jake wrote: One reason is that under the present state of the language, in order for this hypothetical editor to affect variables (which I would consider part of the 'necessary minimum set) of VN features, really), it would need to use Python itself. So, one comes to the choice between marking the ones the tool writes as 'special' somehow (about as reliable as a politician) or trying to work out what some subset of Python statements mean, while staying the hell away from some other set of Python statements which look remarkably similar until closely examined.
I think part of where we differ is that I don't see the latter alternative as being terribly hard.

Take the case of a character definition. It needs to be placed in an init python block. (The other alternatives is a python block inside an init block, but I'd expect to deprecate that in rpy2.) What's more, an assignment statement has to be on a logical line by itself, and logical lines map 1:1 to physical lines.

So, it's actually pretty easy to find logical lines inside init python blocks, and look for ones that match (say) <name> = Character(<parameters>). Since this has to be on lines by itself, it's also pretty easy to replace wholesale if the editor lets the user change the parameters.
It is haphazard in the same way that PHP's scripting is haphazard - it can happen at any time, in any place, without warning.


I would, respectfully, disagree with this. PHP truly lets you put code anywhere... in the middle of a word. By contrast, Ren'Py is quite strict about where it allows Python code. A python block has to start on a line by itself, outside of any other statement. It's limited (even in effects, except for variable assignment) to the body of that statement, which is either an indented block (in the case of python) or to the end of the line ($).

I think it's an important principle that anywhere we allow a statement, we allow any statement, with Python statements being one of several kinds of statements we allow. At least to me, if I disallowed Python in some places, then people would be asking "Why don't you allow python statements in menus?" or wherever.

The other place Python can appear is as expressions in statements like if, for, and so on. While it would be possible to replace that with a custom expression language, I'm not sure I see any advantage in doing so. (What would the language gain or be missing as compared to Python expressions?)
It's something I would want to think about before giving a proper response, but I would note that getting rid of the brackets and commas might be a start. If integrated into Ren'Py script, and Ren'Py script maintains the significant whitespace, why not follow the same mode, e.g.:

Code: Select all

character e:
    name = "Eileen"
    color = "#8f8"
?

It's not so concise, but people concerned with brevity can always still use the Python. People will often want to split their definitions out onto multiple lines when they're defining a character with more than a couple of attributes anyway.
Until now, I've had a couple of reasons for breaking functionality out into statements:

1) It requires syntax that's hard to express in Python. This is the case for the image, scene, show, and hide statements, which would require the image to be a quoted string.

2) It makes the statement easier to automatically check. This is the case for something play, stop, queue, and voice.

3) Control flow that needs to wrap around Ren'Py statements, so label, call, return, if, while, and menu get to be statements.

4) It can save a lot of typing. This is the case with the say statement, the with statement, and the nvl clear. This will also be the case with the upcoming transform language.

The problem with the proposed character statement is that it doesn't save that much, to feel that it's worth a separate statement that needs to have it's own syntax defined. (I personally think that for non-programmers, both the current syntax and Jake's proposed syntax would be learned more by rote than anything.)

I kinda wondering if the use of the word "python" in "init python" is a mental block to some people, as it makes them feel that they're getting into programming when all they're doing is declaring something. How about a define statement, which is equivalent to a $ statement inside an init block? So one could write:

Code: Select all

define e = Character("Eileen", color="#8f8")
It has a nice symmetry with the image statement, prevents the user from having to care about init python (or blocks, for that matter), and we could restrict it even further to allow only a single assignment statement as the child.

Between define and image, one could have a script.rpy without any init blocks, let alone python blocks.

What do people think?
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

Wintermoon
Miko-Class Veteran
Posts: 701
Joined: Sat May 26, 2007 3:41 pm
Contact:

Re: Ren'Py Roadmap

#114 Post by Wintermoon »

I think the '$' symbol can be eliminated entirely. If a statement is not a valid Ren'Py statement, parse it as a Python statement. Of course that's pretty much the opposite of what Jake is suggesting.

delta
Epitome of Generic
Posts: 525
Joined: Sat Dec 22, 2007 12:59 pm
Projects: yes
Contact:

Re: Ren'Py Roadmap

#115 Post by delta »

I actually had this idea earlier but didn't get around to posting it... it makes little sense to have a particular "image" statement, since Ren'Py can check on its own if what is being defined is an image. So you could just go:

Code: Select all

define "image.png" as some image_name
define "music.ogg" as track_name
define "film.mpg" as film_name
Now, note how I switched the syntax around - this is because the image statement can take a whitespace separated pair as a name, and this tag method is very useful. In my example, everything past "as" would be considered the construct's name. I don't know, maybe music would benefit from tags too? you usually don't want to paly two bgm tracks at the same time.
The rest is left as an exercise for the reader.

User avatar
jack_norton
Lemma-Class Veteran
Posts: 4084
Joined: Mon Jul 21, 2008 5:41 pm
Completed: Too many! See my homepage
Projects: A lot! See www.winterwolves.com
Tumblr: winterwolvesgames
Contact:

Re: Ren'Py Roadmap

#116 Post by jack_norton »

Wintermoon wrote:I think the '$' symbol can be eliminated entirely. If a statement is not a valid Ren'Py statement, parse it as a Python statement. Of course that's pretty much the opposite of what Jake is suggesting.
I think this would be a great thing too. It's annoying to have to add it when I change variables. Also, I didn't know that it doesn't work for dictionaries or other more complex python stuff (so I was wondering what was doing wrong)!
follow me on Image Image Image
computer games

User avatar
PyTom
Ren'Py Creator
Posts: 16088
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: Ren'Py Roadmap

#117 Post by PyTom »

Unfortunately, that isn't possible, since some python is ambiguous with Ren'Py, and the parser needs to know which to expect.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

Wintermoon
Miko-Class Veteran
Posts: 701
Joined: Sat May 26, 2007 3:41 pm
Contact:

Re: Ren'Py Roadmap

#118 Post by Wintermoon »

It is possible.

Code: Select all

def parse_statement(line):
  try:
    return parse_renpy_statement(line)
  except SyntaxError:
    return parse_python_statement(line)
In the worst case, some correct Python statements will be incorrectly interpreted as Ren'Py statements. There are two ways of dealing with this:
  • Leave the '$' as an escape clause for those statements.
  • Disallow those statements, and provide a new Ren'Py syntax for getting the same effect.
(Whether or not this is a good idea is another question, but I think the idea deserves serious consideration.)

Guest

Re: Ren'Py Roadmap

#119 Post by Guest »

Has Ren'Py gotten work here?
http://www.laptop.org/en/laptop/hardware/specs.shtml
I'll try to find hardware locally, but maybe netbook (i.e. EEEPC where it already works) is better deal.

User avatar
PyTom
Ren'Py Creator
Posts: 16088
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

Re: Ren'Py Roadmap

#120 Post by PyTom »

I've heard reports that it has, but that was a while back. The only problem would the CPU and memory usage, but iLiad has less of both.

Netbooks are a better choice for most actual use.
Supporting creators since 2004
(When was the last time you backed up your game?)
"Do good work." - Virgil Ivan "Gus" Grissom
Software > Drama • https://www.patreon.com/renpytom

Post Reply

Who is online

Users browsing this forum: No registered users