Patch for you know what

[anne O'nymous]

Thank you mate. I will do my best

You're welcome. I wish you good luck for your game.

 

[79flavors]

The other approach that seems prevalent right now is to write both the [taboo] and [cleaned] versions into your game, but make the [taboo] content inaccessible. In effect, the version of the game you release will always be the [cleaned] version.

However, somewhere in your code (initial startup and/or loading save game), there'd be a bit of code that checks for file that doesn't normally exist. Call it taboo_patch.rpy or something. If that file exists, then set a taboo flag, then in the rest of the code check if the taboo flag is true or false and use the appropriate dialogue/choices/actions.

It's how some games have got around Steam's restrictions. Publish the [cleaned] game, but privately let those players who want to play the "full" version of the game that if they create a dummy file, the gameplay will change accordingly.

It gets around the "your sister"/"landlady's daughter" issues, but means you're doubling up on a lot of dialogue.

The only other thing I would say is that if you imagine your daily life, you don't use the words "mother/daughter/landlady/cousin/brother/etc" all that much. With people you know well, you don't even use their names that often. Games tend to throw "mommy/sis/etc" into the mix every other sentence... even names, but that's not how people speak. Introduce your characters; make sure their relationships are clear, then just remind the player infrequently. If you don't use NPCs name/titles unless you need to... it'll make your life as an author massively easier.

Some pseudo RenPy code that might fit the bill:
(I've not typed/run this in RenPy, so if I've missed something - I'm sure someone will correct me)

default patched_game = False

label after_load:

    call check_for_patched_game

    return

label check_for_patched_game:

    if renpy.loadable("taboo_patch.rpy"):
        $ patched_game = True
    else:
        $ patched_game = False

    return

label start:

    call check_for_patched_game

    if patched_game is True:
        "Welcome to my game about me, my mother and my siblings at my home in the city."
    else:
        "Welcome to my game about me and the people I met when I moved to the big city."

    return

There are undoubtedly more elegant solutions to this code.

You must be registered to see the links

uses init levels so one definition overrides another. I'm just offering this as an alternative. (Not least Anne's solution uses defines rather than straight up variables... which is a much better choice in this case.

Combine all that with Anne's other post about

You must be registered to see the links

and you have a very flexible solution.

 

[Deleted member 416612]

T
(I've not typed/run this in RenPy, so if I've missed something - I'm sure someone will correct me)

default patched_game = False

label after_load:

    call check_for_patched_game

    return

label check_for_patched_game:

    if renpy.loadable("taboo_patch.rpy"):
        $ patched_game = True
    else:
        $ patched_game = False

    return

label start:

    call check_for_patched_game

    if patched_game is True:
        "Welcome to my game about me, my mother and my siblings at my home in the city."
    else:
        "Welcome to my game about me and the people I met when I moved to the big city."

    return

So basically, it will do a check if the patch file exists. If I understood well, for every line in the dialog where I want want the sibling stat to appear, I will have two write two lines? For example:

First dialog:
if patched_game is True:
"Welcome to my game about me, my mother and my siblings at my home in the city."
else:
"Welcome to my game about me and the people I met when I moved to the big city."

next dialog:
if patched_game is True:
"Mother is here."
else:
"The women is here"

Did I understand it well?

 

[Gold613]

Regarding how to structure the dialog it is tricky but not impossible. I found a way and I am going to try it but you are right on how to structure the entire dialog and not to sound retarded. As you said, she is his roommate but he can't bang her as it is not appropriate. Why? Because the rent will go up )))

Well by how much are we talking ? because if it's in between like $5 and $50 for a regular banging....I'd say I can miss that no problem XD, Jokes aside, do you if you can and find something that works well or pretty well at that then by all means go for it, if it works who knows more people might start to adopt or do something similar. Just like what @anne O'nymous or rather the way I understood it that is, Go with a dialogue that can please both sides and are easy to interchange without impacting the game and making it difficult for yourself to do while writing, in the case of pleasing both sides. The problem is of course pleasing the non patched side in terms of writing a game already based on taboo, however in case of a Non taboo one where one wants it in then the roles are reversed.

 

[79flavors]

So basically, it will do a check if the patch file exists. If I understood well, for every line in the dialog where I want want the sibling stat to appear, I will have two write two lines? For example:

That sort of thing yes.

Though, you could combine it with the sort of other examples in this thread based around dynamic naming to use a sort of "best of both worlds" solution.

Borrowing from

You must be registered to see the links

.

   $ mNames = DynamicNames( formal="teacher", informal="laura", fullFormal="my teacher" )
   $ sNames = DynamicNames( formal="tina", informal="a buddy", fullFormal="my classmate" )

I should say I'm talking entirely theoretical here. I haven't written code like this myself.

But what I'm imagining is some hybrid of these two methods, where you write a single line as often as possible (using the dynamic naming solution to swap "mom/landlady", etc) and where that might lead to some weird phrasing, then use the other solution (two lines using "if patched_game").

All of which might be overkill.
At the end of the day, use whichever combination of code you are comfortable with. You're much more likely to finish writing your game if you keep it simple rather than trying to implement something you don't quite understand. It's usually much quicker to look for solutions to problems you've already got than try to solve every problem you "might" run into later before you even start.

 

[Deleted member 416612]

That sort of thing yes.

Though, you could combine it with the sort other examples in this thread based around dynamic naming to use a sort of "Best of both worlds" solution.

Borrowing from

You must be registered to see the links

.

   $ mNames = DynamicNames( formal="teacher", informal="laura", fullFormal="my teacher" )
   $ sNames = DynamicNames( formal="tina", informal="a buddy", fullFormal="my classmate" )

I should say I'm talking entirely theoretical here. I haven't written code like this myself.

But what I'm imagining is some hybrid of these two methods, where you write a single line as often as possible (using the dynamic naming solution to swap "mom/landlady", etc) and where that might lead to some weird phrasing, then use the other solution (two lines using "if patched_game").

All of which might be overkill.
At the end of the day, use whichever combination of code you are comfortable with. You're much more likely to finish writing your game if you keep it simple rather than trying to implement something you don't quite understand. It's usually much quicker to look for solutions to problems you've already got than try to solve every problem you "might" run into later before you even start.

Thank you!

 

[anne O'nymous]

But what I'm imagining is some hybrid of these two methods, [...]

It feel like the best solution, the main objective being to conciliate the charge of works needed by the author, with the expectation of the players.
Using a single solution only will lead to either deception for the players ; the infamous "I can't, I'm your roommate" sentences, by example. Or too much works for the author, who'll have to define too many "part of sentences", or write twice sentences that only have one or two words of differences. But by mixing methods, the author just have to use the one that is adapted to "this line", while still being able to use another method in the next label, because here there will be way more change to do.