6.10 Development

[PyTom]

I'm getting close to the end of 6.10 development, and the start of the release campaign. So if you have a bug, and haven't filed it in the bug tracker, now would be a good time to do so. While it will still probably take at least the rest of the month to update documentation, add to the demo game, and conduct the release, I'd prefer not to have a lot of bugs dumped on me in the last minute.

Also, if there's a feature you want, now might be the time to ask for it. The next release might not be for a few more months. (Probably, it will be in early 2010.)

6.10 is shaping up to be one of the biggest releases I've done. So people can prepare themselves, here are some of the big changes coming:

The new Animation and Transformation Language (ATL) has been integrated throughout Ren'Py, including the image, scene, show, and the new transform statements. To a large degree, ATL supersedes the Animation, TransitionAnimation, anim.SMAnimation, anim.Blink, Zoom, FactorZoom, RotoZoom, SizeZoom, LiveCrop, Move, Pan, Position, Motion, and Revolve functions. And it does so in a way that is more powerful that those functions. Do you want to have a displayable zoom to different sizes in a repeating pattern? Now you can far more easily write that.

Code: Select all

transform zoom_sequence:
     zoom 1 
     linear .5 zoom 1.5
     linear .5 zoom 1
     linear 1 zoom 2
     linear 1 zoom 1
     repeat

When Ren'Py uses a Transform (including an ATL transform) to display an image, it will record the position. If an image with the same tag is displayed with a transform, Ren'Py will initialize the new transform with the old position. If the new image doesn't use a transform, one is implicitly added. The upshot of this is that Ren'Py will now remember where things were positioned on the screen.

There have been a bunch of other improvements (a new pause statement, config.window_overlay_functions, config.automatic_images), but these are the improvements that might be the most controversial. I want to get them out here now, so if people have questions or concerns, I can take them into account before the release campaign begins.

[jack_norton]

The new ATL system seems really cool ! The only feature request I'd like doesn't concern Renpy itself but an editor with intellisense/code completion, but that's probably too much to ask

[delta]

I got a suggestion to make multiplatform distributions a lot more useful, and I think it's a good idea. Make it so that the Mac OS .app folder is the regular app (i.e. contains all the resources), and have the .sh and .exe use those resources. The zip file would, at the highest level, only include the .app, the .exe and the .sh (plus possibly documentation and license files). Reason: .exe and .sh files are expected to use additional resources (hence the users of said operating systems will not think they can move it anywhere without things breaking), and the .app folder will just look like a regular resource folder to them. OS X users will expect an .app to be portable on its own.

This is perfectly doable and makes a lot of sense.

[PyTom]

The problem is, this would prevent Linux and Windows users from deleting the (useless-to-them) .app to save disk space. So I don't think this is something I'd want to do.

[duanemoody]

this would prevent Linux and Windows users from deleting the (useless-to-them) .app to save disk space

No, no it wouldn't.


The Mac executable and Mac-specific libraries all live in completely deletable directories outside the folder containing the actual game assets (autorun).

As far as disk space wasted on platform-specific code is concerned...we're looking at 16Mb:Mac, 6Mb:Windows and 8Mb:x86Linux specific code.

24 Mb total "wasted" from a Windows user's perspective. In contrast, Ariah devotes 51 of its 136Mb to its OP which will be seen in its entirety by the player once or twice.

Considering the demo alone for KS is about 170Mb and its final size is estimated to be 5x this, I wouldn't call 24Mb a barrier to downloading. But that's me.

[PyTom]

Yes, they can delete it if they drill down three directories, and copy the files out. But that's hardly as convenient as selecting the .app and hitting delete.

It's also not totally unheard of for people to want to either upgrade Ren'Py or upgrade the game after it has been release. I've seen several cases where the creator asks people to put an additional rpy file into their game, to fix a bug that has cropped up. I don't think it makes sense to require Windows and Linux users to have to drill into the mac app to do this sort of fix.

Looking at the stats for LSF, Planet EVN, and renai.us, we have about 88% of users using Windows, 8% using Mac OS X, and 3% using Linux. (The rest of the hits come from phones, playstations, etc.) So I don't think that the standards of a minority platform should control the layout of the cross-platform distribution.

[PyTom]

A fun new feature just added to Ren'Py 6.10: support for Python's with statement.

(Note that Python's with statement has nothing to do with Ren'Py's with statement, which it postdates.)

Code: Select all

python:
    with ui.vbox():
        ui.textbutton("Foo", clicked=ui.returns(1))
        ui.textbutton("Bar", clicked=ui.returns(2))
   
    # ui.close is automatically called.

[JinzouTamashii]

Er, I've been meaning to ask this before because I still feel like beginner with Python $ statements... does Ren'Py take python print statements, while command verb, or "for" loops?

[Jake]

Er, I've been meaning to ask this before because I still feel like beginner with Python $ statements... does Ren'Py take python print statements, while command verb, or "for" loops?

Inside Python blocks you can quite literally write whatever Python you like. You may need to import namespaces for some things, depending on what Ren'Py provides for you (offhand I have no idea), but it's possible, and certainly regular basic control structures like while and for are perfectly fine.

In $-prefixed statements, however, everything you want to do has to fit into a single line, so while/for/if and so on aren't doable because they require at least two lines to do anything in Python. As I understand it, if you have two $-prefixed lines next to each other, they will be run in complete isolation from each other, one after the other.

Print, however, you may find doesn't do what you want. I don't know off-hand where it'll go, but it won't be the Ren'Py game window; I would expect it to go to the stdout stream, which the launcher probably doesn't do anything with, so your output is likely lost most of the time... you may find that after you've packaged up your game and run it from a command prompt that the printed text comes out there.

[JinzouTamashii]

糞... that would be a great way to see in real-time if certain things are occurring... I wonder if there's some way to have them print into a custom-coded debug vbox from init?

[Wintermoon]

In $-prefixed statements, however, everything you want to do has to fit into a single line, so while/for/if and so on aren't doable because they require at least two lines to do anything in Python.

That's technically not true. The following are perfectly valid Python statements:

Code: Select all

if x: print x
for x in [1, 2, 3]: print x

[Jake]

That's technically not true. The following are perfectly valid Python statements:

If Python lets you do that, then fine. I'd not seen it before, and never thought it would, since it's pretty inconsistent with its usual approach to statements.

[killdream]

That's technically not true. The following are perfectly valid Python statements:

Code: Select all

if x: print x
for x in [1, 2, 3]: print x

While Python let you do that, it's certainly not the most "Pythonic" way of doing things. Actually, Python let's you put as much as commands you want in one line, separating them with a ";". Only block commands can't be nested, I guess. So the following will run without any "problems".

Code: Select all

count = 0;
for n in range(5): count += n; print count;

Of course, just because you can do this doesn't mean you should. Mostly because this greatly reduces readability and makes you code harder to maintain. If you plan on doing open-source projects, using this will make every Python-enthusiastic frown at your code as well.

Concerning print statements, Ren'Py doesn't do anything special with them, so they will go on the console window. If you're running on Windows you'll have to run from "console.exe" rather than "renpy.exe", which will give you a console window plus the normal Renpy window. I always use it when I have to test things, it makes everything more pratical.

Aternatively, you can print to a log file if you want.

Code: Select all

log_file = open("log_file.txt", "a") #open for appending
print >>log_file, "your log message."

[PyTom]

Everyone is going to kill me for not thinking of this four and a half years ago.

I just added config.auto_load. This can be set to a save file, and it causes that save file to be automatically loaded when Ren'Py starts. The idea is that a developer can easily jump to their current work, and easily pick where they jump to by saving into (for example) save slot 1.

I'm off to duck and cover now.

[jack_norton]

Haha yes, this actually would save lot of time during development!! Glad you added it