Ren'Py 6.12.1+ Planning Thread

[Samu-kun]

I'd be on board for it, as long as the old system is still left in place as is.

[doomonyou]

Launcher/Code Browser.
Say/menu tagging.
Translation Framework.
Tutorial Game.
Aside from documentation, which is always good, these there the most interesting points so far. I look forward to the updated tutorial and the say tagging if I understand that right. Is there anyone besides me who likes the look of the current launcher?

[Spiky Caterpillar]

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.

Is there any easy way to make the shift-U updates available as context diffs as well? (As that makes it much easier for me to merge a Ren'Py update with my internal customizations.)

Separation of feature updates and bugfix updates would be useful for game-makers, but might be impractical.

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.

Treating 'eileen happy bikini' and 'eileen bikini happy' as the same image is probably a good thing, but automagically resolving incomplete attribute lists will break games in unexpected ways - if you add 'image eileen spacesuit mad = "esm.png"' near the end of development, all of a sudden 'show eileen mad' *might* make her put on a spacesuit on the beach - or, worse, if the attribute resolver relies on helpful hints like what image tags were shown before, result in one path to the same scene leading to her wearing a spacesuit on the beach while the one the developer tests most often doesn't.

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.

Eek! The software renderer is a major feature for me - there seem to be a fair number of systems out there where the 3D drivers are subtly broken, and I couldn't find any pure open source drivers that supported hardware acceleration on nVidia or ATI cards the last time I looked.

Falling back to software when the hardware renderer isn't working right for whatever reason offers a much better gameplay experience than telling the user to upgrade their drivers (and/or video card) does, IMO.

The software renderer seems reasonably self-contained - how practical would offloading maintenance on someone else be? (As, if you drop software support, I'd likely wind up maintaining my own fork anyhow.)

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.

Hmm. This does seem interesting. Possibly a little too magical, but rather tempting. And it would bring the good bits of automagic image resolution in without the ambiguity.

Code: Select all

label beach_scene:
    $ e.image = 'eileen'
    $ e.tags = 'bikini'
    # Equivalent to 'show eileen bikini happy'
    e(happy) "Ah, there's nothing like a warm ocean breeze."
    # Equivalent to 'show eileen bikini sand annoyed'
    $ e.tags = ('bikini','sand')
    e(annoyed) "It would be better if Weather Control hadn't set it to 'sandstorm', though."

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

You can set a default transition in an image's on show event up in the init block. (Though, IIRC, it will then ALWAYS use that image's on show event when the image is shown.) I think ATL properties other than events inherit, so

Code: Select all

    image ornithopter:
        'images/ornithopher.png'
        xanchor .5
        yanchor .5

    show image ornithopter:
        xpos 400
        ypos 310

would wind up centered at 400,310.

And now for my wishlist:
Development headers (and binaries, if applicable) for the 6.12.0 renpy-deps, to make it easier to (cross-)compile add-ons without having to get all the dependencies to build successfully on my machine first. Or an equivalent to 6.11's tegl so I can get into GL from Python.

ATL blocks in hide statements, so

Code: Select all

show virginia normal at discenter
# some stuff
hide virginia:
    linear .5 alpha 0.0

works as might be expected - I can get the same effect by specifying an on hide block up in the show statement, but for complicated scenes it can wind up being confusing.

[jack_norton]

Eek! The software renderer is a major feature for me - there seem to be a fair number of systems out there where the 3D drivers are subtly broken, and I couldn't find any pure open source drivers that supported hardware acceleration on nVidia or ATI cards the last time I looked.

Uh, are you talking about linux only, or even PC ? Afaik if you have both DX/GL, you have covered everything - even those crappy netbooks with horrible Intel videocards!
That said, it could maybe be worth keeping SW rendering and have it ignore some new commands like advanced cross-fading systems or more. Simply those effects wouldn't work in SW mode.

[Spiky Caterpillar]

Well, the lack of pure open source drivers is only really relevant for Linux - but the nVidia drivers that ship with Win2K and the (ATI, I think it was?) drivers that Hanako's 10.4 laptop was using (at least as of mid-2010) both showed bugs in 6.11.

Not getting fancy new dissolves in SW mode (at least until I decide I want them enough to get off my posterior and add support for them myself) wouldn't be a problem for me, though.

[jack_norton]

Ah well if you talk about MacOS, it's the OS that's bugged by default you only need to pay the yearly tribute to Mr. Job to have a "new" (LOL) Os with same features as before, less speed and "bugfixes"

[PyTom]

I'll address Spiky's other concerns when I have more time, but since I've thought about it a bit, but here are my thoughts on transitioning away from the software renderer.

First, this isn't something I'd want to happen right away. I don't want to touch the rendering code again for a while, as I want my focus to be on improving visual novel development for a while. Adding in DirectX support is simple in comparison to some of the changes I plan to make, and the goal is to monitor feedback from the next few releases until I'm sure that none-to-few people are using the software renderer.

There are several features that I can easily implement in GL, that are hard to do elsewhere. Some of these are:

* Color transformations on displayables.
* Non-rectangular imagemaps.
* Distortion effects, like whirls and waves.

Implementing these in the software renderer would much more than double the amount of work I'd have to do for them - so I've been putting them off.

There's also the observation that the software renderer is a source of bugs, especially because I don't test it very often. (This is doubly true of scale.py, which was a huge hack in the first place.) Getting rid of it would reduce my support burden a little bit, which would be nice.

Really, what I would like is a software-based OpenGL renderer I can use when hardware rendering isn't possible. Mesa is pretty slow, though, especially on the older systems that are likely to be the ones with problems. I need to try linking against Offscreen Mesa to see what it's like. Help with getting something like this working would be appreciated.

Finally, I'll point out that both examples Spiky gives are older systems. Windows 2000 was replaced by XP over nine years ago, and Microsoft stopped supporting Windows 2000 in July 2010. The last release of OS X 10.4 was in November 2007, so it's also on the old side. (Firefox is dropping support for it, for example.)

Linux is a big problem, as there have been some recent systems that don't have OpenGL support. (Like the OLPC.) Ren'Py does run fairly well under Mesa, at least on my (admittedly powerful) box, and it's probably possible to avoid expensive effects in some cases.

I think it does make sense to slowly advance the minimum software/hardware requirement so that we can take advantage of the advancement in computers. In 2011, a computer that doesn't have shader-based video hardware is broken.

[Megaman Z]

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.

Treating 'eileen happy bikini' and 'eileen bikini happy' as the same image is probably a good thing, but automagically resolving incomplete attribute lists will break games in unexpected ways - if you add 'image eileen spacesuit mad = "esm.png"' near the end of development, all of a sudden 'show eileen mad' *might* make her put on a spacesuit on the beach - or, worse, if the attribute resolver relies on helpful hints like what image tags were shown before, result in one path to the same scene leading to her wearing a spacesuit on the beach while the one the developer tests most often doesn't.

Assuming I'm reading it right, in the context of the example PyTom gave, Ren'Py would end up changing from "eileen happy bikini" to "eileen mad bikini", a change of one tag/attribute. A change from "eileen happy bikini" to "eileen mad spacesuit" would be a change of two tags/attributes. I'm pretty sure there is the chance for ambiguity under certain conditions, but that wouldn't be one of them.

[Naeddyr]

About image tags, my old suggestion from here http://lemmasoft.renai.us/forums/viewto ... 53#p115553 is still apropos.

It would be nice to have a tag-definition system with indentation instead of repetition.

And the "update tag" stuff was already mentioned.

[Hollow Gourd]

Would it be possible to implement text speed variations in a future release?
As described in this thread, at present, it's apparently only possible to change the speed of ALL of the text rather than having some of the text appear at a faster or slower rate.

I believe this would be a very useful feature for certain projects.

[Friendbot2000]

Although I am new to RenPy, I am no stranger to Python and coding. I have one suggestion and a few comments.
I would really like to see RenPy diverge from the visual novel niche and move into other styles of gameplay. Granted if you are inventive enough you can achieve a lot with the current system, but it could be made easier to deal when a creator wants to integrate a complex combat system like that of Fire Emblem (a system I am trying to develop in RenPy) into their visual novel. My current struggle is trying to model it after some of the newer Fire Emblem games (hi-res 3-d images, complex animations, destructible terrain, etc ). I am making headway, but it certainly has been a headache.

In closing, I do have a comment for you all. I think it was mentioned earlier in the thread that someone had a fear that RenPy would evolve into a "drag and drop from the menu" kind of game engine. I find that really disconcerting and I in no way wish to see that happen. I think PyTom has done an incredible thing with RenPy and in my opinion it would ruin the engine if he took out coding from Game Programming. Game designers shouldn't be afraid to code. Python and RenPy are some of the easiest languages to learn and get the hang of and if you take out the programming experience from making a game, I don't think you will reap all the benefits from the experience. Just a warning from a crotchety old programmer. Now get off my lawn.

[jack_norton]

I agree, while you can add features to make the creation of VN easier, I think that considering Renpy only as VN tool is incredibly reductive.
That said, I don't think it pytom should make a full RPG framework, because it can change so much based on individual tastes. I would see more benefit in essential libraries or "routines" (lol that's an old word).
Examples of libs that can be useful to make a RPG, but not just a RPG:
- A star pathfinding with terrain values
- A map system
- Tile/iso map system
- Inventory

Or perhaps find ways to port renpy to Flash/HTML5
(this is a sort of a joke since I constantly annoy him privately with this, and he always replies that it's impossible haha)

[DaFool]

Although I am new to RenPy, I am no stranger to Python and coding. I have one suggestion and a few comments.
I would really like to see RenPy diverge from the visual novel niche and move into other styles of gameplay. Granted if you are inventive enough you can achieve a lot with the current system, but it could be made easier to deal when a creator wants to integrate a complex combat system like that of Fire Emblem (a system I am trying to develop in RenPy) into their visual novel. My current struggle is trying to model it after some of the newer Fire Emblem games (hi-res 3-d images, complex animations, destructible terrain, etc ). I am making headway, but it certainly has been a headache.

In closing, I do have a comment for you all. I think it was mentioned earlier in the thread that someone had a fear that RenPy would evolve into a "drag and drop from the menu" kind of game engine. I find that really disconcerting and I in no way wish to see that happen. I think PyTom has done an incredible thing with RenPy and in my opinion it would ruin the engine if he took out coding from Game Programming. Game designers shouldn't be afraid to code. Python and RenPy are some of the easiest languages to learn and get the hang of and if you take out the programming experience from making a game, I don't think you will reap all the benefits from the experience. Just a warning from a crotchety old programmer. Now get off my lawn.

The key is to have Frameworks, or sets of scripts that provide additional implementation depending on the genre of game.

Here's the best battle framework for Ren'Py thus far:

http://www.eviscerate.net/article/rpg-b ... gine-renpy

I'm currently making an HD game with prerendered 3D graphics with it.

(There's also the one used for Planet Stronghold, but I doubt jack norton will license that out ^_^)

It's a best-kept secret that the one-click-build in Ren'Py makes it one of the most powerful 2D engines out there.

[jack_norton]

I won't license it because is a mess, and would be practically unusable without my support I need to review it and clean the coding, since I understimated the amount of work needed to make a full RPG framework, so had to rush the coding...

[SusanTheCat]

I would see more benefit in essential libraries or "routines" (lol that's an old word).

Wouldn't that be "modules" for python.

Susan