Working Towards 6.14

[PyTom]

Once 6.13.1 is out - with fixes for the newly reported bugs - I'll be turning my attention to 6.14. Here are some of the things I have planned for that release, in the approximate order I plan to work on them.

Scope Support for Python Blocks. The idea here is that the python statement will be extended with a new "in" clause. These new scopes will support rollback, just like the main Ren'Py scope does, and will be able to be imported from using the Python import and from statements. This should help a bit with the organization of Ren'Py programs containing complex Python code - such as the new launcher.

Launcher Rewrite. I'm planning to rewrite the launcher. The interface will be rewritten from scratch using screens, but some of the older code (like the distribution code) will be cleaned up and included. Plans for this include:

• Visual improvements.
• The ability to determine what resources from common/ are actually required by a particular game.
• Code navigation support. At the very least, I'd like a creator to be able to click on a label, and have that label open in a text editor. I'd also like this to extend to images, names, and screens.
• Translation support. The ability to scan over code and create or update a translation file.
• An updater, with the ability to create update files when you build a distribution. Ideally, this will be a component that you can include in your games. I'd also like it to be able to update a .rpa file without having to re-download the whole thing. (This may be limited to 6.14-created .rpa files.)

Speed Improvements I'd like to focus on improving the time between when the user clicks and when the new screen is displayed, and the user can click again. I've already done some of this - some changes to screens to make them faster to display. But I expect that more can be done.

RAPT - Ren'Py Android Packaging Tool A launcher plug-in that will give one-click (to be fair, after some guided setup) creation of Android applications.

I'm not sure of the licensing for RAPT. I'm considering making it a commercial product. On one hand, if I was able to get a large enough stream of income from Ren'Py, I'd be able to devote even more time to it - time that right now is devoted to my day job. OTOH, a small amount of income is the worst of both worlds - I wind up with an additional support burden, but not enough income to offset it - and the money is taken from creators who could use it for other things.

(It's times like this that I wish I knew how to make a legit business plan.)

[jack_norton]

Updater! WOowoo
(Spiky provided me with a cool updater but linux only and my poor skills weren't enough to use it)

About the RAPT lincensing, probably the best is a one-time fee? you already do support now after all.

[mugenjohncel]

It's times like this that I wish I knew how to make a legit business plan.

Mmm... someone said business plan?... Finally, a chance to show off a bit of my expertise...

What you need is to license it "per project"

With this you hit several Angry Birds with one stone. By doing a "per project" license, you not only maximize the potential income (let's say a particular dev made three games, you'll get paid three times) you also limit / control the amount of possible support that will come with each license (You'll only be obligated to support per license... and even better, if a particular dev licensed say three times for three games and a problem arises in say one of them, chances are solving the problem for that particular problem will also apply to the other two games since the underlying engine is literally the same for all three which is Renpy saving you time and headache)... In all seriousness, you have already given so much simply by creating and maintaining Renpy for free that it's about high time you get some form of compensation other than bragging rights and personal satisfaction... I think most devs will understand it...

"POOF" (And now I'm expecting a bunch of Tomatoes thrown at me by several known commercial devs... hides)

[jack_norton]

Or he can do two things, unsupported one-time fee, and supported license

[yummy]

About the rpa updater: how about using an updater that processes files according to their parity, like the files you download from newsgroup to repair corrupted files (par and par2 files)?

[Spiky Caterpillar]

Parity files are only really useful when you're dealing with an unreliable transmission medium. Ren'Py's current updater uses cryptographic hashes to check to see if a file's changed and downloads only the changed files; hashes of file segments are theoretically possible.

Also, while I'm not a cryptographer, last I looked, it appeared that vanilla RSA signatures may have been broken a few years ago; while there is a padded RSA approach that's supposed to get around this, the padded one was patented at the time.

[jack_norton]

If I remember correctly an updater I was checking uses this method: http://en.wikipedia.org/wiki/Delta_encoding

[PyTom]

Also, while I'm not a cryptographer, last I looked, it appeared that vanilla RSA signatures may have been broken a few years ago; while there is a padded RSA approach that's supposed to get around this, the padded one was patented at the time.

I don't believe these attacks are relevant to the way Ren'Py uses RSA. There's an attack that uses the chinese remainder theorem to recover plain texts, but since we're just signing, this doesn't apply. The exponent for the keys we use is also in the good range.

There are some unlikely attacks that padding might prevent. It would be pretty easy to fake a signature for a file with md5s of 00000000000000000000000000000001 or 00000000000000000000000000000000 - but I don't think there's an attack against md5 that allows this. I'm also a little scared by crypto patents on padding, I don't know if they've expired yet.

The strategy I'm considering for the next-gen updater will be:

1) Create a tar archive out of the non-generated files on disk - pretty much everything by .pyc and .pyo files.
2) Use zsync to update that file based on the information stored on the server.
3) Decompress the tar archive, putting the files in the right places.

This should be a robust strategy - we already produce tar archives as part of the build process, so we know that works, and if step 1 fails to include a file, the result will be a larger download, not a failed upgrade. Zsync should also be smart enough to deal with moving content between files, and with updating an rpa.

There may be some small changes in tar and rpa generation to help zsync out, like making sure the files are stored in a deterministic order. We'll probably also want to deal with timestamps and executable bits separately, so the generated tarf files are more similar.

Using delta compression, like bsdiff, would likely yield somewhat smaller downloads. But it would also require O(n**2) delta files, where n is the number of released versions - the nice thing with zsync is that it only cares about the target version.

[Counter Arts]

For now we can just have multiple rpa files?

Edit: Also where would be the file/code I would need to run to generate a new rpa with only the files I specify?

[PyTom]

multiple rpa files work, but there isn't code in the launcher to create them.

[cyrus_zuo]

Would RAPT include the ability to make stand-alone .apk games (ones that did not depend on loading in the RenPy app - as I believe is currently required?).

I looked at the Android side of things in regards to phones, but I really think tablets are the device to aim for. It's a better screen size for VNs I think (actually for everything, but certainly for VNs).

As a developer, considering the business equation (how you'd make money on putting your game on Android), what I'd look for (dream for?) is:
- Small file size (you're already addressing this)
- Ability to make stand alone .apks (so customers don't need to download anything else)
- Typical Android expected functionality (move to SD card for example)
- Easy Add-in of ads (b/c I'd expect most would go the Free w/ads route in trying to monetize their games)

Just some thoughts.

[PyTom]

Would RAPT include the ability to make stand-alone .apk games (ones that did not depend on loading in the RenPy app - as I believe is currently required?).

Ren'Py games are currently standalone on android.

- Small file size (you're already addressing this)

I've been working on this, and the 6.13.1 android version will have smaller files.

- Ability to make stand alone .apks (so customers don't need to download anything else)

We have this.

- Typical Android expected functionality (move to SD card for example)

I'll consider this.

- Easy Add-in of ads (b/c I'd expect most would go the Free w/ads route in trying to monetize their games)

I'll consider some sort of ad plug-in mechanism.

[cyrus_zuo]

Awesome, and apologies I hadn't noted the stand-alone ability of the .apks! That's tremendous! (and maybe I'm just remembering incorrectly, b/c I had thought that RenPy had to also be downloaded in order for games to played)

Thanks for considering the SD card functionality. On the ads bit, it might be a great thing for you to build a business plan around. Selling the module that allows people to put in ads easily would help developers to directly monetize their games, so it is sort of a win-win directly in the revenue chain.
As always, your incredible efforts are very appreciated.

[wizzardx]

The next release sounds pretty interesting

In terms of a business plan, you might consider dual-licensing Ren'Py, or some Ren'Py-related services? The wiki article is over here:

http://en.wikipedia.org/wiki/Multi-licensing

eg: MIT for free/non-commercial use, but a fee for commercial use. Does Ren'Py have a lot of people who use it for commercial/for-profit games? I'm sure that some of them wouldn't mind sending some cash your way.

Especially if you gave some extra perks for having a paid license. For instance extra support, or giving priority to fixing their problems/feature requests, or hosting-related help (eg: give them a larger quota on your server for hosting their games and providing a nicer update system for their users). Or, providing extra promotion for their games (eg: banners or ads for their games, on the forum and/or wiki, or possibly inside non-commercial VNs, if developers put a banner component into their project to help support development, and the ads are tasteful and interesting).

Plus, it might help a bit if you have a paypal button on the site a bit more clearly (I have to go looking to find information about that in the support section), or have occasional fund-raising events like Wikipedia does. You might also consider running google adsense on here, or even within VNs themselves).

Something else you could do is make some more advanced features available earlier to licensed users, and they only get released as part of the free version later on. For instance, ATL might have been a paid-for feature, that took a bit longer to get to the free version users (after the next cool thing came out).

Another idea might be licensing or re-selling high quality art, music, font packs, and themes. For instance: Forum members here could get a bit of income on the side for their contributions to that, and then it gets sold as part of an official paid-for add-on pack for Ren'Py, to let people make VNs more easily if they don't have easy access to nice art or designers. For instance, RPG Maker VX has some pretty nice default art built into it. And then periodically sell new and updated Ren'Py add-on packs.

I guess I could carry on with these ideas for a while, but I think you get the general idea...

One downside of course is that the Ren'Py project would get a lot more of a "commercial" feel to it (like regular paid-for software), that might turn off some members of this community who like it the way it is now.

[cyrus_zuo]

Yeah, the more I think about it, the more I like the ads module .

The issue is for developers that VNs are something difficult to make money on selling. So a paid version or paid assets are likely only to appeal to a very small group.
VNs on Android is interesting, but there have been a lot of challenges selling games on Android, it is a platform that expects 'free.' (The Angry Birds guys at Rovio have talked about this a good bit)

So ads allow anyone to casually earn some income off of a free game on Android, w/o having to sell it directly. That seems like something that would appeal to a larger group of RenPy users than the other options discussed so far.

Anyway, just a thought.