My take on using RenPy

[I am Muk]

I have been using RenPy for a while now, making prototypes and trying to implement custom features. I am familiar with programming, so while it's not difficult to add features, the code looks like a horrible mess. I try to clean it up by organizing my code (different folders, using classes, etc.), but for some reason I really, really dislike the screen language when you want to create a custom screen.

However, when you want to make a VN, it's perfect. Even more complex VN's can be organized as you want.

I can imagine that built-in saving, rollback, skipping and settings is a blessing for players. And the fact that it can be freely used by the creator (RenPyTom) is also amazing. Kudos to what he has created over the years.

 

[Bev_]

RenPy is great and anyone who ain't using it for VN's is a poo poo head.

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

 

[cisco_donovan]

I love Ren'Py. Like anything there are good ways and bad ways to organise it, and there are things it does better than others.

I think the screen language is brilliant.

 

[anne O'nymous]

[...] but for some reason I really, really dislike the screen language when you want to create a custom screen.

It's sometime difficult to present things correctly, but not more than with CSS ; so it's probably why it don't really bother me.
But except this, what is it that you dislike with the screen language ? It offer you the power of widgets based screens, with the flexibility of a script language. In top of this it have big dose of dynamism, thanks to text interpolation and realtime built strings.

As for the organization of your code, don't overthink it.
A directory for everything that is Python (classes, functions, etc), one for the core mechanism of your game, and one for the story. Few files grouping accordingly to whatever common point you want, and it will be good.
We have a guy at works who split his personal projects into 26 files, accordingly to the first letter of the function/class/variable. And in fact it's not more stupid, or less effective, than any other way to order all this.

 

[MidnightArrow]

One big problem with screen language, and Ren'py in general, is you're just supposed to remember to prepend "text_" or "what_" when passing parameters to children object. There's a lot of sloppy, slippery coding under the hood, where the names of things are stripped and changed, meaning you need to constantly pore over the manual to discover what you're supposed to type and when.

 

[anne O'nymous]

One big problem with screen language, and Ren'py in general, is you're just supposed to remember to prepend "text_" or "what_" when passing parameters to children object.

hmm...

Screen language do not require parameters, they do not even understand the notion of parameters. It's the good old ui functions that have parameters. But, while they can still be punctually useful, they are outdated and shouldn't be used.

As for the "text_" prefix, it apply only to style properties, yet only the one addressing the text part of textbutton. So, if really it's something difficult for you, what I can understand, just define a style for your button:

myTextButton is button:
    [whatever style properties and their associated values]
myTextButton_text is button_text:
    [whatever style properties, without the 'text_' prefix, and their associated values]

screen whatever():
    textbutton "whatever" style "myTextButton"

Finally, the "what_" prefix apply to Character objects at creation time, and to dialog lines through the "say" statement parameters. In both case the prefix is needed, because each properties that can be addressed this way apply both for the "what" part of the dialog line (the text itself) and its "who" part (the name of the character).

For anything else, parameters are just unique variable names in snake_case. Therefore not more difficult, nor easy, to remember than any parameter in any language.
As long as you keep them in their order of declaration, you can perfectly ignore the name of the parameter. Something like renpy.movie_cutscene([I]filename[/I], [I]delay=None[/I], [I]loops=0[/I], [I]stop_music=True[/I]) can perfectly be wrote renpy.movie_cutscene([I]filename[/I], 0.1, 2). Then the delay will be set at 0.1, and the movie will loop 2 times.
It's only when you skip a parameter in the declaration, or when the parameter is part of an anonymous declaration (the "**properties" in AlphaMask([I]child[/I], [I]mask[/I], [I]**properties[/I] ) that you have no choice but to prefix them with their name.

 

[MidnightArrow]

I (kind of) understand all that now. But when I was learning Ren'py it was very confusing.

 

[osanaiko]

We have a guy at works who split his personal projects into 26 files, accordingly to the first letter of the function/class/variable. And in fact it's not more stupid, or less effective, than any other way to order all this.

What is it like to work with a serial killler?

 

[I am Muk]

RenPy is great and anyone who ain't using it for VN's is a poo poo head.

Spoiler

You don't have permission to view the spoiler content. Log in or register now.

As a player, I like RenPy the most too. But that's because most of the developers use RPGM in a not fun way. They make things repetitive, but there are a few great RPGM games too.

I love Ren'Py. Like anything there are good ways and bad ways to organise it, and there are things it does better than others.

I think the screen language is brilliant.

I find it s little awkward to use, sometimes. Documentation could be more clear, but maybe that's me. But I can use it to create custom screens, so that's cool.

It's sometime difficult to present things correctly, but not more than with CSS ; so it's probably why it don't really bother me.
But except this, what is it that you dislike with the screen language ? It offer you the power of widgets based screens, with the flexibility of a script language. In top of this it have big dose of dynamism, thanks to text interpolation and realtime built strings.

As for the organization of your code, don't overthink it.
A directory for everything that is Python (classes, functions, etc), one for the core mechanism of your game, and one for the story. Few files grouping accordingly to whatever common point you want, and it will be good.
We have a guy at works who split his personal projects into 26 files, accordingly to the first letter of the function/class/variable. And in fact it's not more stupid, or less effective, than any other way to order all this.

The thing is that I use CSS frameworks to not have to worry about it too much. Most of the time I only change SCSS properties, or create a class.

But screen language does what it should do, so it's not a problem to use.