Ren'Py Things/Configs/Code to keep in mind while setting up the project

[crabsinthekitchen]

Never really had the occasion to test it, so what's so wrong with

You must be registered to see the links

?

If you just want to grant achievements in Steam, it works fine. achievement.grant("Achievement name") to grant it and achievement.sync() at init block in case you unlock achievements in offline mode (or in non-Steam version) is all you need.

It just doesn't really do anything else. Built-in achievement is basically a string id and optionally a max stat at which it's unlocked. Everything else: notifications, list of achievements, descriptions, icons, is on the backend it calls and default

You must be registered to see the links

just stores unlocked achievements in persistent._achievements and implementing your own backend is not documented

 

[79flavors]

I'm currently kicking myself for forgetting these two...

• NEVER use $ renpy.pause(,hard=True) in any form. Hard pauses are the invention of the devil and should be banned.
  
  
• If your game needs to use pause, try to always specify a time too (like pause 1.5).

Lots of developers seem to think pause means "stop". It doesn't. Though I can understand why they can think that.
Plus there are lots of games out there, written by lots of developers who mistakenly thought the same thing. Don't copy their mistakes.

RenPy has an "auto advance" feature that allows the player to set a timer which means the player doesn't have to constantly click the mouse or press space or whatever. The time is calculated based on the length of the dialogue that was just displayed in combination with whatever preference the player set.

This is the primary reason why:

    show screen my_screen1
    pause

... is a bad idea. As that pause doesn't actually STOP RenPy continuing when the auto-advance timer runs down.

The other reason developers use pause is to show an image or animation on screen without any dialogue before continuing to the next image or animation.

... and while they are testing (without auto-advance being switched on)... that's fine. The image/animation is shown and they sit and stare at it as long as they like before clicking the left mouse button to move on.

With auto-advance though....

In the case of two images being shown... The first image is shown, then because there is no actual dialogue - the pause lasts about a quarter of a second (slightly longer if you're using with fade or with dissolve)... then the next image is shown. Not really giving your player time to see the first image.

In the case of an animation followed by an image... The same thing happens. The animation might be 5 seconds long, but that pause means things advance in barely any time at all and the player doesn't get to see the full thing.

There is no real downside to pause {time} compared with just pause. My only advice is to make each pause slightly longer than you think it should be - as you are already aware of what you are seeing/looking for - whereas a player will need a little bit extra time to figure that out.

Edit: Anne points out below that $ renpy.pause({time}) is preferable to pause {time} because pause can be bypassed if the player disables transitions in the preferences.
He's told me that before, but I forgot.

Seriously... Hard pauses are evil. Don't be evil.

 

[Deleted member 1121028]

NEVER use $ renpy.pause(,hard=True) in any form. Hard pauses are the invention of the devil and should be banned.

Indeed it's rather crappy.
Shoot for the stars :

screen DisableAction:
    imagebutton:
        idle Solid("#00000000")
        xpos 0 ypos 0
        xsize config.screen_width ysize config.screen_height
        action NullAction()
    timer delay action Hide("DisableAction")

\o/

Spoiler

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

 

[anne O'nymous]

If your game needs to use pause, try to always specify a time too (like pause 1.5).

Yes to what you said, but no to the way to do it. Always prefer the use of renpy.pause to pause if you define a delay.
Without delay, the statement just call renpy.pause, but with a delay it rely on a transition. This mean that if the played decide to disable the transitions in the preference menu, this will also skip the pause...

The other reason developers use pause is to show an image or animation on screen without any dialogue before continuing to the next image or animation.

... and while they are testing (without auto-advance being switched on)... that's fine.

Fine, but 100% annoying.
Having to click twice (once for the image, once for the dialog line) each time the image change is one click too many.

Of course, you past time building the scene then rendering it, you are proud of the result and what to show it. I understand that, but there's the h key that we just need to press in order to hide the interface and only see your image. And we do it when we want. It's the key here, "when we want", never force the player, especially when it's uselessly.

Seriously... Hard pauses are evil. Don't be evil.

And anyway any advanced (or curious) player have the piece of code that totally disable the "hard" part.
Using a hard pause exceptionally, I can understand, there's surely few case where it can help. But the instant it become too frequent, it's all the hard pause that will be skipped, breaking all the effect you wanted to add in your game.

 

[Deleted member 1121028]

Using a hard pause exceptionally, I can understand

I had a prototype where there is a flashback kind of thing. Most friends didn't get it. Maybe I could render b&w (it was meh), but that 2 seconds transition (clock turning backward) was needed.

But yeah, if it's for piss off the player, make no sense, but sometime it's a real narrative need.

 

[anne O'nymous]

But yeah, if it's for piss off the player, make no sense, but sometime it's a real narrative need.

I'm thinking about some kind of visual countdown for the case I need it myself. It's probably less annoying when you aren't just blindly put face to a waiting time that will last you have no fucking clue how long.

But in the same time I hope that I'll not have to use it.

 

[Deleted member 1121028]

I'm thinking about some kind of visual countdown for the case I need it myself. It's probably less annoying when you aren't just blindly put face to a waiting time that will last you have no fucking clue how long.

But in the same time I hope that I'll not have to use it.

In the grand scheme of things, I'm not sure hard transition matter a lot (just use it when it matter). Nor it's ever been an important subject.