Ren'Py Making Renpy walkthrough mods

[KasimirVT]

I wanted to start making walkthrough mods but dont really know where to start. I dont have much programming experience und would welcome any tips and advice on how to get started.

 

[eevkyi]

Since renpy is a script-based engine, the minimum you need is a text editor to modify the rpy files and some knowledge of the

You must be registered to see the links

. Depending on how you want to build these mods, you may end up needing to

You must be registered to see the links

. If the game only comes with rpyc/rpa files, use the UnRen tool or follow this guide.

I recommend using

You must be registered to see the links

as your editor, along with the "

You must be registered to see the links

" and "

You must be registered to see the links

" extensions, to speed up your work and avoid certain errors/typos.

 

[osanaiko]

There is a long and informative thread about the topic of a "walkthrough mod" in the forum somewhere.
From my memory, it was mainly anne O'nymous correcting the mistakes made by a beginner programmer.
However, i can't find it again. oh well.

One thing you can try is to find some examples of existing walkthough mods and learn from the Renpy code.

 

[anne O'nymous]

There is a long and informative thread about the topic of a "walkthrough mod" in the forum somewhere.
From my memory, it was mainly anne O'nymous correcting the mistakes made by a beginner programmer.

You mean this post? It's a bit outdated but still apply.

Be noted that, when it come to walkthrough, the way to do it isn't the same depending if you mod a game, or if it's your game. For a mod, it should be done as I (globally and superficially) explained in the post, but for dev including an optional walkthrough in their own game, it's through

You must be registered to see the links

that it should be done.

Since renpy is a script-based engine, the minimum you need is a text editor to modify the rpy files [...]

No, no and no.

I know that it's tempting; "hey, look, I have access at the source code, lets just modify it". But it's the best way to turn your mod, walkthrough or other, into a burden, and to possibly break the game in an invisible way.
People should starts to stop with this approach.

Editing the source mean that every single update, whatever if it's a real update adding content, or just a bug fix, have to have its own version of your mod. And, obviously, you'll need to manually make the change for every single one of those updates, because even a years old menu option can have been rephrased, or a menu extended.
But when you make it as an additional layer that rely on callbacks, you're less depending on those changes. The rephrasing of a menu option would be an issue, but it's not really difficult to have a small tool catching those changes for you. Almost all other changes would be totally transparent for your walkthrough mod.
Cherry on the cake, by doing your walkthrough (or mod) that way, there's high chance for it to be compatible with any other mods made for the game. Something that matters even more for a walkthrough, because players will not have to choice between your walkthrough and an existing mod.

 

[eevkyi]

No, no and no.

I know that it's tempting; "hey, look, I have access at the source code, lets just modify it". But it's the best way to turn your mod, walkthrough or other, into a burden, and to possibly break the game in an invisible way.
People should starts to stop with this approach.

Editing the source mean that every single update, whatever if it's a real update adding content, or just a bug fix, have to have its own version of your mod. And, obviously, you'll need to manually make the change for every single one of those updates, because even a years old menu option can have been rephrased, or a menu extended.
But when you make it as an additional layer that rely on callbacks, you're less depending on those changes. The rephrasing of a menu option would be an issue, but it's not really difficult to have a small tool catching those changes for you. Almost all other changes would be totally transparent for your walkthrough mod.
Cherry on the cake, by doing your walkthrough (or mod) that way, there's high chance for it to be compatible with any other mods made for the game. Something that matters even more for a walkthrough, because players will not have to choice between your walkthrough and an existing mod.

At no point did I recommend any particular approach, as my post acknowledges that the op is a complete beginner and only offers some general info/references.

Considering that the op didn't specify which games they intend to create these mods for, it's not impossible that they will only opt for completed games that the developer no longer needs to release any patches for, minimizing a good part of the work in terms of maintenance.

Regarding compatibility with other mods, no modder is obligated to worry about that, even more so when it comes to a beginner who literally still needs to learn the basics about the engine before even considering any more complex approach. At this moment, the focus should only be on developing a mod that works as the op wants, from the beginning to the end of the game, without breaking it or causing any other serious bug. As they gain more experience, they can consider refactoring everything and using a more compatible solution if they wish.

 

[anne O'nymous]

At no point did I recommend any particular approach, [...]

You only address the modification of the RPY files, and it's explicitly this part, and this part only, that I addressed.

as my post acknowledges that the op is a complete beginner and only offers some general info/references.

And there's absolutely nothing "advanced" in the use of callbacks. In fact, it's more beginner friendly than a direct code edition, because you don't have to care about the consequences.
Editing directly the code need for you to understand what it actually do, and it's far to be rare that someone come asking for help, precisely because his edition broke the game. This while the worse than can happen when you rely on callbacks is that your mod/walkthrough will not works.

Considering that the op didn't specify which games they intend to create these mods for, it's not impossible that they will only opt for completed games that the developer no longer needs to release any patches for, minimizing a good part of the work in terms of maintenance.

And so it's a good enough reason for him to learn nothing from his walkthrough creation?
Because there's really nothing to learn there. You just search for menu: and then edit the option to add "increase [this]", "close [that] route". It teach you how to edit a text, nothing more...

Regarding compatibility with other mods, no modder is obligated to worry about that,

It's a question of respect for those who will use it.

even more so when it comes to a beginner who literally still needs to learn the basics about the engine before even considering any more complex approach.

Do you even have the starts of a clue regarding what you talk about?

Here's how fuckingly complex (so complex that it need at least a master degree in coding) a transparent walkthrough mod would looks like:

init python:
    #  List of labels with a menu that need to be edited.
    labelsToHijack = [ "someLabel", 
                       "otherLabel",
                       [...] ]

    #  Hijack those labels for them to firstly pass through your own code.
    for atom in labelsToHijack:
        config.label_overrides[atom] = atom + "_wt"
        config.label_overrides[atom+"OUT"] = atom

    #  Where the magic happen.
    #  If the text is in the WTentries dict, it's a menu option that need to be 
    # updated by the walkthrough. Return the original text, with the walkthrough 
    # help after it, in a smaller size. Else, return the text unchanged.
    def smtfCB( text ):
        if text in WTentries:
            return WTentries + " {size=10}(" + WT_entries[text] + "){/size}"
        else:
            return text

    #  Will be called each time a dialog line or a menu option is processed by Ren'Py.
    config.say_menu_text_filter = smtfCB

#  Dictionary where the data will be stored. 
#  Full text of the menu option as key, walkthrough information as data.
default WTentries = {}

#  Use the hijacking labels to define WTentries for the menus in the corresponding label
label someLabel_wt:
    #  In a Python block to benefit from the multi lines syntax.
    python:
        #  Fill WTentries with the accurate values.
        WTentries = { "go to coffee": "open a new girl route",
                      "stay at home": "[optional] sex scene with Alex",
                      [...] }

    #  Return to the normal game flow as if nothing happened.
    jump someLabelOUT

label otherLabel_wt:
    python:
        WTentries = { "Buy flowers": "increase Alex love",
                      "Buy 50 shades of lewd": "increase Alex lewdness",
                      [...] }
    jump otherLabelOUT

Sometimes, but rarely it will need a bit more. But it's not really more difficult to do, for this refer to the post linked in my previous post.

Seven lines of actual code, and the rest is basic variables assignation, as well as label definition with a jump to exit them... If a beginner can't do this, then he also can't actually edit the source code without messing with it.

In fact, it need more knowledge to know what the "hint" should be, than to know how to add them to the menu options. This because you need to understand what the variables mean, follow the code because there's effects that are applied later in the scene, and track the flags possibly raised or lowered in order to know what they'll change later in the game.
While a majority of Ren'Py games follow a basic approach, there's many that don't. Some massively rely on called labels, so you need to be able to track the path in your head. Other rely on function instead of direct assignation for their stats change, or rely on functions for their tests. So you need to understand how those functions works to be able to understand the implication of each choice.
And it's without counting the games that turned, or at least tried to turn, Ren'Py into an event responding engine.

 

[eevkyi]

You only address the modification of the RPY files, and it's explicitly this part, and this part only, that I addressed.

You simply misinterpreted my post and rushed to correct something I never stated, especially considering that in the very next sentence I mention the possibility of using python, illustrating the possibility of more advanced solutions.

And there's absolutely nothing "advanced" in the use of callbacks. In fact, it's more beginner friendly than a direct code edition, because you don't have to care about the consequences.
Editing directly the code need for you to understand what it actually do, and it's far to be rare that someone come asking for help, precisely because his edition broke the game. This while the worse than can happen when you rely on callbacks is that your mod/walkthrough will not works.

Do you even have the starts of a clue regarding what you talk about?

Here's how fuckingly complex (so complex that it need at least a master degree in coding) a transparent walkthrough mod would looks like:

init python:
    #  List of labels with a menu that need to be edited.
    labelsToHijack = [ "someLabel",
                       "otherLabel",
                       [...] ]

    #  Hijack those labels for them to firstly pass through your own code.
    for atom in labelsToHijack:
        config.label_overrides[atom] = atom + "_wt"
        config.label_overrides[atom+"OUT"] = atom

    #  Where the magic happen.
    #  If the text is in the WTentries dict, it's a menu option that need to be
    # updated by the walkthrough. Return the original text, with the walkthrough
    # help after it, in a smaller size. Else, return the text unchanged.
    def smtfCB( text ):
        if text in WTentries:
            return WTentries + " {size=10}(" + WT_entries[text] + "){/size}"
        else:
            return text

    #  Will be called each time a dialog line or a menu option is processed by Ren'Py.
    config.say_menu_text_filter = smtfCB

#  Dictionary where the data will be stored.
#  Full text of the menu option as key, walkthrough information as data.
default WTentries = {}

#  Use the hijacking labels to define WTentries for the menus in the corresponding label
label someLabel_wt:
    #  In a Python block to benefit from the multi lines syntax.
    python:
        #  Fill WTentries with the accurate values.
        WTentries = { "go to coffee": "open a new girl route",
                      "stay at home": "[optional] sex scene with Alex",
                      [...] }

    #  Return to the normal game flow as if nothing happened.
    jump someLabelOUT

label otherLabel_wt:
    python:
        WTentries = { "Buy flowers": "increase Alex love",
                      "Buy 50 shades of lewd": "increase Alex lewdness",
                      [...] }
    jump otherLabelOUT

Sometimes, but rarely it will need a bit more. But it's not really more difficult to do, for this refer to the post linked in my previous post.

Seven lines of actual code, and the rest is basic variables assignation, as well as label definition with a jump to exit them... If a beginner can't do this, then he also can't actually edit the source code without messing with it.

In fact, it need more knowledge to know what the "hint" should be, than to know how to add them to the menu options. This because you need to understand what the variables mean, follow the code because there's effects that are applied later in the scene, and track the flags possibly raised or lowered in order to know what they'll change later in the game.
While a majority of Ren'Py games follow a basic approach, there's many that don't. Some massively rely on called labels, so you need to be able to track the path in your head. Other rely on function instead of direct assignation for their stats change, or rely on functions for their tests. So you need to understand how those functions works to be able to understand the implication of each choice.
And it's without counting the games that turned, or at least tried to turn, Ren'Py into an event responding engine.

What seems simple to an experienced developer/modder isn't necessarily simple to a complete beginner who has clearly stated they have no idea where to start.

Manually editing a sentence in a dialogue to correct a typo, for example, will certainly be simpler for a beginner than other solutions that, however better they may be, will inevitably require additional knowledge.

And so it's a good enough reason for him to learn nothing from his walkthrough creation?
Because there's really nothing to learn there. You just search for menu: and then edit the option to add "increase [this]", "close [that] route". It teach you how to edit a text, nothing more...

You imply that not following best practices right away means the modder won't learn anything, when in fact, doing things in a less-than-ideal way initially is also part of the learning process and experimentation as a whole, which always ends up resulting in progress.

While it's great to demonstrate good practices, we must never forget that each person has their own pace for improvement and that this shouldn't be imposed in a pedantic or hostile manner.

It's a question of respect for those who will use it.

Just as a developer isn't obligated to create a legacy version of their game simply to cater to retro enthusiasts who enjoy playing on older machines running windows xp, a modder shouldn't have to do any extra work to ensure compatibility if they don't want to or don't consider it important for the target audience.

 

[anne O'nymous]

You imply that not following best practices right away means the modder won't learn anything,

I explicitly said that he won't learn anything coding related because he is doing nothing coding related. It's not the same...

Just as a developer isn't obligated to create a legacy version of their game simply to cater to retro enthusiasts who enjoy playing on older machines running windows xp, a modder shouldn't have to do any extra work to ensure compatibility if they don't want to or don't consider it important for the target audience.

You know that you're comparing two things that are absolutely not the same, right?

What you wrote is exactly the same than saying: Car manufacturers don't have the obligation to include the possibility for their cars to be pulled by horses, and for the same reason people who add rooftop on cars don't have the obligation to make it so the doors can still be opened.