Ren'Py 6.12.1+ Planning Thread

[PyTom]

Okay, 6.12.0 has been out for nearly a week now. I've been under the weather, but I'm feeling better, so I think it's time to begin planning features for the next few Ren'Py releases. The goal here is to throw some ideas on the table, to get people's feedback on them, and on other features that fit with the theme of the release.

The main goal of the next few releases will be to try to make visual novel makers more productive. This is a shift from the last few releases, which tended to focus on adding support for new platforms (GL, Android), and interface customization (Screen Language).

One goal that I have is to reduce the length of a development cycle. For the last few new-feature releases, it's been about 6 months between releases. I'd like to move to a faster model, where I release a Ren'Py every month or two. More importantly, during previous release cycles, there were multi-month periods where I wasn't able to release a working Ren'Py (with new features), even if I wanted to. So what I'd like to do is to keep Ren'Py runnable, and make informal pre-releases every couple of weeks.

From a game-maker's perspective, the big benefit is I'll hopefully become more responsive to feature requests. The hope is that I'll be able to make pre-releases to a shift+U update, and you'll be able to start using the new features immediately. You'll also be able to expect that prerelease to become a final release within a month or two. This means that Ren'Py updates can benefit games on a timely basis, even for short-to-moderate length games.

So what am I planning on working on?

Bug Fixes. There have been some bugs reported in 6.12, so I'll be addressing them fairly quickly.

Monlogue Mode. I'd like to change the way dialogue works so that lines consisting entirely of whitespace can be used to delimit blocks of text spoken by a character. This means that:

Code: Select all

e "This is the first block.

   This is the second.

   And this is the last block"

Will be equivalent to:

Code: Select all

e "This is the first block."

e "This is the second."

e "And this is the last block"

While this is a slight behavior change, my guess is that this won't affect most games, and I think it could reduce the amount of typing people do, especially in narration-heavy NVL-mode games.

Image Attributes. Right now, the code:

Code: Select all

image eileen happy bikini = "ehb.png"
image eileen mad bikini = "emb.png"

show eileen bikini happy

Will give an error. But should that really be the case? It seems like it might make sense to treat everything after the image tag as an "attribute", and then to try to find an image that matches the set of attributes we have defined.
In that case, it may not even be necessary to specify all the attributes when updating an image. If after the code example above, we wrote:

Code: Select all

show eileen mad

It probably makes sense to show the eileen bikini mad image. There are some details as to how this would work with things like image prediction and backwards compatibility, but those are (probably) resolvable.

Show side. A lot of games are using show_side_image, but I'm not sure the current system is the best. It would be possible to allow people to just specify what image is to be shown, using something like "show side eileen happy". I'm not sure this is the best solution, however.

Really, this would be a good place for people's feedback - how do you _want_ to specify those side images?

Launcher/Code Browser. I'd like to rewrite the launcher, for several reasons. The first is to make it use screens, as I suspect its code will be a lot clearer when screens are used. However, a bigger change would be to add code browser functionality to the launcher.

The idea here would be that the launcher would have a list of images, labels, characters, and so on. There would also be better text editor integration, and clicking on one of the entries in the list would bring you to the corresponding thing in the code. That means people would be able to jump around the code more freely.

I'd also like the launcher to become better-looking, so if people want to help me, that would be excellent.

Say/menu tagging. I'd like a tool that can go in and tag lines of dialogue and menus with some sort of tag, that would then be accessible by other code. For example, after running the tool, a script might look like:

Code: Select all

@e1491
e "This is the first block of text"

@e1492
e "This is the second block of text"

These tags could be used for a bunch of things. We'll be able to output a file mapping tag to script lines, and this could be used for automatic voice. It will also be used by the translation framework (below) and perhaps by some sort of floating frame director-style framework.

This is another part where feedback could be nice.

Translation Framework. I'd like to have some sort of system for dumping tag/text pairs, so that people can translate them. We'd then want to let people edit that file, and Ren'Py would use it to translate an existing game.

I don't have much experience with translation, so I could probably use some help designing this format. Or at least pointers in the right direction.

Tutorial Game. The tutorial game needs a lot of work. I've been getting some negative feedback from people from the new game. At the very least, there needs to be a way to dump code to a text editor, so people can copy/paste it. I also think it's time the whole thing got an overhaul.

We have a lot of skilled people, so maybe we can discuss this and someone can take over parts of this for me. I do want to write at least some of it, as writing/directing games gives me ideas on how to make those tasks easier. But at the same time, I have trouble looking at Ren'Py as a new user - I'm the only Ren'Py user to never learn it, after all.

I think a total rewrite is reasonable at this point - Ren'Py has changed massively over the past couple of years, and the tutorial game hasn't kept up.

Documentation. Documentation is going fairly well, with a few new chapters every release. For 6.12.1, I want to document transforms and transitions, and I think that shouldn't be a problem.

Some other things I'd like to put some time into:

All-in-one Android. I'd like the Android build to be able to make games that include Ren'Py with them. This is more Pygame for Android than Ren'Py specific, but Ren'Py will benefit, and the user experience on that platform will be better.

DirectX I'd like the windows build to use DirectX instead of OpenGL. This would be done through the ANGLE OpenGL ES -to- DirectX translator used by Chrome and Firefox, so while a seemingly major change, it probably won't take much time to implement - if it works at all.

Hardware statistics collection. When Ren'Py switches into software rendering mode, I'd like to give the user the option of sending data back to me that would help me understand why.

Once few-to-no people use the software renderer, I'd like to eliminate it entirely, and begin taking advantage of OpenGL/DirectX accelerated rendering. Also, not having to deal with the software renderer, and the bugs in it and its scaling mechanism would make my life easier.

Text Rewrite. The text class needs a rewrite both for speed and functionality reasons. I'm not quite ready to get started on that, but at some point I'll want to look into new requirements, and decide which make the cut.

I'm nor promising all of this for 6.12.1 - that's probably not going to happen. This is likely several releases worth of ideas, and I'm sure I'll come up with more ideas as I actually start coding. But I would like to get people's feedback as to which are important, and suggestions as to how to make this better. I'd also like other suggestions as to how one can make visual novel-making easier. And there are a bunch of places where people could help out, even without going into the deep parts of Ren'Py.

[Samu-kun]

More requests.

-A "set default transition for all character sprites" function. Do I really have to write "with dissolve" at the end of all 90000 character show commands in my game?
-An ATL command that combines xpos with xanchor 0.5. In 99% of the cases, xanchor is always going to be 0.5 anyways, so it's a waste of time to have to set xanchor to 0.5 whenever you want to use xpos. e.g. xshow 0.3 automatically sets xpos 0.3 and xanchor 0.5.

[PyTom]

I seem to recall having some trouble getting that automatic dissolve working, but I'll at least try again. (I don't recall what the problem was, offhand.) A big problem is that you specify "character show" - Ren'Py doesn't have any idea as to what is a character image and what is a background, effect, etc.

Also, say you have two character show commands in a row? Should we have one dissolve, or two? I lean towards one, but I could be convinced that the other way is better - it's certainly more regular.

I'm thinking a reasonable name for Samu's second thing would be "xcenter". There would probably also be "ycenter" for consistency. (Note to self: This should be in styles, screen language, ATL, and Transform)

[Aleema]

Really, this would be a good place for people's feedback - how do you _want_ to specify those side images?

I like all my variations of sideimages in one place. I love that they work passively, too. Having "show side whoever" might be okay for newbies, but to me, that's one more line of code I would have to write. I assume you'll keep the old system working like usual, though. But I do think that more lines like that is inefficient and should not be encouraged, my personal preference aside.

I think you're onto something with the "auto" code from SL. I typically name my images with the same prefixes, but with the specific emotion tacked on at the end, and then that callname for the emotion goes straight into the game. I rarely name a file "smile" and then call it by "happy" in the game. So some method that can intuitively pick up on what you're calling the emotion in the game could then search for that file based on that name could reduce lines of code extensively. And not only do I think this would be a neat feature for side images, but as a mutation of ConditionSwitch as well.

As for how, specifically, I would like to see side images defined, definitely make it passive. Perhaps make ShowingSwitch inherent and expected, since side images are rarely not also used with emotions. Something like:

Code: Select all

sideimage eileen:
    xpos 0.0 ypos 1.0
    showing "eileen.png" side "eileen_side_sad.png"
    showing "eileen_happy.png" side "eileen_side_sad.png"
    showing "eileen_sad.png" side "eileen_side_sad.png"

But doing a showingswitch only won't work for main characters that don't show full sprites, so some way to do a conditionswitch is still necessary:

Code: Select all

sideimage eileen:
    xpos 0.0 ypos 1.0
    conditionswitch:
        "variable_to_watch"
        None "eileen.png"
        "happy" "eileen_happy.png"
        "sad" "eileen_sad.png"

Just to build off of the syntax you're already using. I recently had to clean up a complex ConditionSwitch one of my writers messed with because she forgot commas, so this simplification would likely be used. If this already exists and I'm a dumb**** for suggesting something that already existed, sorry. >_<

The idea here would be that the launcher would have a list of images, labels, characters, and so on. There would also be better text editor integration, and clicking on one of the entries in the list would bring you to the corresponding thing in the code. That means people would be able to jump around the code more freely.

If that's what you wanna do ... *was fearing this day would come* So long as it doesn't turn into "you can manipulate your entire project from the launcher," I don't mind. If it comes down to ... you can upload your images via the launcher and it codes it for you, I'd be wary of the direction of Ren'Py. But that's a bridge we'll cross when we get to it.

Outside of that worry, having a really big game does make finding the exact labels you to edit want very hard! I would love to see some sort of label/block organizer, because my scrolling finger does break while editing sometimes.

The tutorial game needs a lot of work. I've been getting some negative feedback from people from the new game. At the very least, there needs to be a way to dump code to a text editor, so people can copy/paste it. I also think it's time the whole thing got an overhaul.

If you need help with the tutorial, I like blathering like I know something (and then you come in and tell me I'm wrong). If nothing, I can give input on the future tutorial. I liked the old one, though. It didn't, like ... catalogue every little thing for me, so I had to go through various lessens to find the invert feature, but other than that, looking at the code is how people should learn. Right now, it's all show and few tell. So having a good way to jump from the game to the code is what I can suggest. Heavily encourage they see the code as it's being executed. Perhaps explaining what a string, integer, and boolean are and such, too. There's a lot of jargon in the documentation, like "tuple", that even native English speaker scratch their head about.

I'm thinking a reasonable name for Samu's second thing would be "xcenter". There would probably also be "ycenter" for consistency. (Note to self: This should be in styles, screen language, ATL, and Transform)

I vote "yay" for x/ycenter. I often have to do both, and I need things centered waaaay more than I need them to the left. How would it work? True/False?

[DaFool]

/gives standing ovation

I just checked the tutorial again and the running script reference was indeed removed... why was it so? Is it no longer compatible?

I prodded mugenjohncel to overhaul the BGs of 'The Question' so it might be a good idea to upgrade The Question as well... preferably with a running script reference and showing each common display method (e.g. NVL, show side image). Currently it's too simplified.

Then the tutorial can be the "insert everything that Ren'Py does" and catalogues all the advanced features and frameworks.

[jack_norton]

The changes seems great. DX on Windows is also a very good thing at least for commercial casual game developers

[Samidarenina]

I'd got 2 suggestions.

The first is about the way renpy display new text. It would be nice to add the ability to choose a "soft" display - every new character gets displayed with a raise of opacity, not just an instant display like it was untill now. I believe the presentation would look much more fluid that way, but I'm worried that it might be a performance problem (though I kinda doubt it as I've seen nscripter games that've done it already).

Another suggestion is a bit more complicated and is about improving the rollback system. The idea came to me after playing Remember11. In the game, text history is displayed as a normal window with all the previous text, but with the addition of the ability to jump to previous lines by simply clicking on the correlating textIt gives the possibility of jumping back to the previous parts without destroying atmosphere. Again, I don't know how this would work performance-wise.
The biggest problem I have with the current system is that, mostly in case of horror games or just tense situations that require a good atmosphere, the music, sound and pictures all return which completely ruins the atmosphere just to read one little line you missed. Rollback, of course, is really practical, and I find it a great idea, but I still believe it to sometimes heavily ruin atmosphere which a system like in Remember11 prevents. Of course, you still have the possibility of jumping to previous parts, it just doesn't force it on you.
Anyway, thank you very much for listening to my little rant and I hope you'll at least consider some of it. I really feel like it's worth doing, but there's a ton of different opinions and everyone is entitled to one which is why I'll understand if you've got other priorities or just think that those things aren't really that important.

Sami

[Greeny]

If you're going to be updating more often, it might be a good idea to start with an automatic updater of sorts.

[papillon]

While this is a slight behavior change, my guess is that this won't affect most games, and I think it could reduce the amount of typing people do, especially in narration-heavy NVL-mode games.

Since I'm not really a renpy user yet I want to check to see if I understand this - does this mean it will automatically force more places where the user has to click in order for the text to continue, when large amounts of text are displayed in NVL mode?

That's probably the exact opposite of how I want it to behave.

For dialog, yes, I can see the practicality of automatically assuming it's a separate statement unless special commands were put in to indicate otherwise. But I personally hate games that make you click all the time for short phrases, particularly in NVL mode, unless it's extremely important that you not see one until you've finished the last, and was intending to make use of page-of-narration between dialog scenes in a potential secret project.

[jack_norton]

A thing I'd like to see now that we can use GL, is the possibility to flip in horizontal/vertical displayables at runtime. Just flipping a pose can result in more variety for the players (I know I can do it in photoshop, but that means having x2 sprites amount in the game and I think now should be possible to do it in real-time).

[Alex]

It seems like it might make sense to treat everything after the image tag as an "attribute", and then to try to find an image that matches the set of attributes we have defined.

Won't it be a "bad habit"? Practically everyone use computers everyday and such simplicity in Ren'py might leads to confuse in working with other programs... Just my thought.

Documentation. As for ATL and SL, it would be very helpful if documentation has some examples, looking more like real part of code. I mean, "init" block, some screens and ATL-things declarations, "start label" with code that shows that screens etc.

[Greeny]

Documentation. As for ATL and SL, it would be very helpful if documentation has some examples, looking more like real part of code. I mean, "init" block, some screens and ATL-things declarations, "start label" with code that shows that screens etc.

Seconded. Often I find it much easier to learn by reverse-engineering a piece of working code than to actually get a definition of what does what.

Also, just a thought, but I was thinking, and this is probably me being a little behind with the times, but maybe it would be worth considering to port Renpy for the "interactive DVD" format? You could just burn a dvd and anyone with a dvd player could play it on their tv. At least, for games that don't have incompatible features.

Of course I don't know if that's at all viable.

[PyTom]

Also, just a thought, but I was thinking, and this is probably me being a little behind with the times, but maybe it would be worth considering to port Renpy for the "interactive DVD" format? You could just burn a dvd and anyone with a dvd player could play it on their tv. At least, for games that don't have incompatible features.

I don't think this would be a productive use of my time. That format was horrible, compared to the PC format. I don't think anyone would choose it compared to a computer or smartphone. (IIRC, the main reason for it was to get games into places that won't sell software, like bookstores.)

[Juxtaposition]

I don't know if this would be possible to do, but what if Renpy offered support for implicit show statements? As it stands now, you have to write a show statement every time a character changes expression. There are things one can do to speed up or automate the process, but it's still a lot of work, especially if your VN happens to be very long.

Suppose instead of this:

Code: Select all

 
show eileen happy

e `It's such a beautiful day!`

You could do this:

Code: Select all

e (happy) `It's such a beautiful day!`

Much less work, more readable scripts, and the writer doesn't have to switch between coding and creating or suffer the burden of writing the script first and then going back to put in thousands of stage directions.

Let's take the idea a step further. Suppose the characters in your VN have a variety of different outfits. Under this new scheme, you'd have to do something like this when a character needs to wear something different:

Code: Select all

e (bikini_happy) `Ah, there's nothing like a warm ocean breeze!`

Not a big deal, really. You could define your image as "b_happy" to differentiate it from Eileen's normal_happy. It's not a lot of extra typing. It does introduce lots of opportunities to screw up if you mistype the prefix though. It would be handy if you could specify which outfit a character was wearing and Renpy would automatically append the right prefix. Here's what the code might look in practice:

Code: Select all

$ bikini = [ (A list of all of Eileen's bikini images, such as eileen_bikini_happy, eileen_bikini_mad, etc.)  ]


label beach_scene:
	
	# We'll make sure Eileen is properly attired for her outing.
	$ e.spriteset = bikini
	
	e(happy) `Ah, there's nothing like a warm ocean breeze!`
	# Renpy searches the spriteset list, finds the happy image, and displays it.

[PyTom]

Hm... the implicit show is kinda interesting, although a fairly radical change. It would integrate fairly well with things like image attributes, and side images. It would be fairly easy to make it optional, though. But it may be too magical. What do people think?