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:
e "This is the first block.
This is the second.
And this is the last block"
Will be equivalent to:
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:
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:
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:
e "This is the first block of text"
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.