Ren'Py Scoring Message after player choice

[JustTeasingU]

Hi all,
I would appreciate some help regarding this. How can I manage that after every choice, a message to inform about the added points to your score?



You can see here an example with this green window.

Thank you!

 

[barotok]

You could edit the notify screen and use $renpy.notify("Text") or you could make your own screen

Something like this

screen points(mytext):
    
    frame:
       xminimum 200
       xmaximum 250
       xpos 0.9
       ypos 0.15
       background Solid("#6CE942")
       text "{color=#FFFFFF}[mytext]{/color}"
      
    timer 4 action Hide('points')
    
label label1:
    menu:
        "Option 1":
            pass
        "Option 2":
           $char1_relationship += 1
           show screen points("Relationship +1")

 

[JustTeasingU]

Thank you Barotok!

 

[anne O'nymous]

The problem being then that code become heavy.

Every time you've a change in the points value, you've to type both the line where you change the points, and the line where you notify the player about this change. And obviously this open the gate for some bugs. Either you'll decide to write those two lines by yourself every time, and you'll double the risk to make a typo, or you'll copy/past them, and risk to forgot to update the girl name or the kind of point, either in the notification (don't give a good impression to the player, but don't break the game) or the point attribution (the player will don't know about it, but the game will not react like it should).
Therefore, the best approach is to dedicate a part of your code to the point attribution, and trigger the notification from this part.

There's many way to do this, the most basic one is probably this:

# The default values for each character and each kind of points.
default ann_lov = 0
default ann_cor = 0

default sar_lov = 0
default sar_cor = 0

# The code in charge of the point attribution.
# parameters:
#  - who -> Nickname of the character, as used in the variable names.
#  - what -> The value that is changed, as used in the variable names.
#  - value -> The value used to change the number of points.
label points( who, what, value ):

    #  Declare the temporary variable as being local to this label, and the
    # one used for the message. They'll exist in this label, and only in this label.
    $ renpy.context_dynamic( "varName", "message" )


    #  Build the notification message, and the name of the variable to change,
    # starting by the name of the character...
    if who == "ann":
        $ message = "Annabella "
        $ varName = who + "_"
    elif who == "sar":
        $ message = "Sarah "
        $ varName = who + "_"
    else:
        "Oops, an error happened, unknown character '[who]'. Please, notify the author of this game."
        return

    # ... continuing by the kind of point.
    if what == "love":
        $ message += what
        $ varName += "lov"
    elif what == "corruption":
        $ message += what
        $ varName += "cor"
    else:
        "Oops, an error happened, unknown point category '[what]'. Please, notify the author of this game."
        return

    # Finishing to build by the message by adding the value.
    if value < 0:
        # "- 1" is better looking than "-1" for a message.
        $ message += "- {}".format( abs( value ) )
    else:
        $ message += "+ {}".format( value )

    #  Attribution of the point(s).
    # You give to the variable whose name is stored in "varName" the value of this 
    # variable, plus the value to add. 
    #  Note that this value can be negative, in which case it will become a 
    # subtraction.
    $ setattr( store, varName, getattr( store, varName ) + value )

    #  Notify the player the way you want. Here I'll use the screen provided
    # by /Barotok/
    show screen points( message )

    #  And finally return to the game flow
    return

Then you use it like that:

label whatever:

    ann "Hello MC, how are you today ?"
    menu:
        "Ignore her":
            call points( "ann", "love", -1 )
        "Greet her back":
            mc "Oh, hello Annabella, I'm fine, and you ?"
            call points( "ann", "love", +1 )
        "Greet her back and risk a frisky comment":
            mc "Oh, hello Annabella, I'm fine, and you ?"
            call points( "ann", "love", +1 )
            mc "This dress really suit your beauty"
            call points( "ann", "corruption", +1 )

The advantages of such approach are multiple:

1. You need only one line ;
   Less lines to write mean less risk of errors.
2. More independence regarding the technical parts ;
   Whatever how you decide to name the variables, and whatever how you want the message to looks like, they both are not directly depend of the value you'll use to call "points". This permit you to have syntax easier to remember for everything. The "points" label will do the conversion for you, letting you focus on what matter the most, without too much care regarding how things effectively works.
   In my example I decided that the nickname for the girl is the same name that what you use for their "Character" object. It's something you'll use often, and therefore that you'll remember easily. But in the same time, I decided that the "kind of point" will be fully written, what again is easier to remember. This while to names your variables, I used a shorten version in order to not have too long variable names.
3. You can easily change your mind.
   You'll need time to find the right way to notify the player about a point change. You can by example starts with the "+ 1"/"- 2" approach I used in my example, then finally decide that "increase by 1"/"decrease by 2" can be better. Or you can want to be less technical and have "love you a bit more"/"feel less corrupted".
   With the initial two lines approach (attribute the point, then notify, directly from the code) when it happen you'll have to change all the lines regarding the notification. With this approach, you've just to change the message built in the "point" label.
   This again limit the risk of errors when you write your game.

 

[JustTeasingU]

Thank you very much anne O'nymous for your kind response.

I will check it out and see how I can better take advantage of it.

 

[79flavors]

As a learning exercise, I'd also offer another approach...

You clearly had a game that already did more or less what you were hoping to do. You could have taken that game apart and looked how it was put together.

Most games are shipped with some sort of compressed archive containing all the game's scripts and images. Usually something like archive.rpa or scripts.rpa, etc.

There is a tool available here on the site called UnRen. It will unpack the .rpa archives back into the game's underlying script files.
Some developers even go so far as to remove the .rpy source files from their distribution file and just leave the .rypc files necessary to run the game. But UnRen has you covered there too, with another menu option that will recreate the .rpy files for you.

While lots of game run just fine, the underlying code can sometimes be questionable. Just looking at the source code will give you "a way that works", not necessarily the best way to do it. I strongly suspect the code Anne suggested is a better way to handle things than the way most games would be written... But it's often handy to be able to look at a game's code, to try to piece together how it works.

 

[JustTeasingU]

Hi 79flavors,
thank you very much for your response. I didn't know that tool and that's for sure that it'll usefull.

Even so, I have to accept that my code will be always questionable.

 

[Corellien]

I'm testing the barotok/anne O'nymous code and I think I'll use it for my game, with some minor adaptation. Thanks a lot!