how can I create a random NPC with their own stats?

[elhlyn]

I've created a class for these characters but I don't know how to implement them in a way where you can interact and talk them. I'm trying to go for a way for you to recruit these npc and interact with them (the intent is that they would have predefined dialogue but random name, stats, and so on)

the code is what I've gotten down, granted I am whittling down other stats that are pretty much just integers.

Code: Select all

    class charStats(object) :
        def __init__ (self, name, strength, constitution, dexterity,):
            self.name = "name"
            self.strength = strength 
            self.constitution = constitution 
            self.dexterity = dexterity 

Is there anything else I should add on to the class and, I admit this is hard to ask/convey, but how can I make it so that when I go in to the "recruiting" it will generate a new character?

[_ticlock_]

Hi, elhlyn,

If you don't care about side images and fine with the default character style, you can simply use the name instead:

Code: Select all

label start:
    $ npc = charStats("Name", 1,1,1)
    npc.name "Hi, I am [npc.name]"

If you would like to assign some side images or different character style (like text color) you can create a character inside your class:

Code: Select all

image side eileen = "eileen.png"

init python:
    class charStats() :
        def __init__ (self, name, strength, constitution, dexterity):
            self.name = name
            self.strength = strength
            self.constitution = constitution
            self.dexterity = dexterity
            self.char = Character(self.name, image="eileen", what_color = "#0000ff")

Code: Select all

label start:
    $ npc = charStats('Eileen_clone',1,1,1)
    npc.char "Hi, I am [npc.name]"	#Side image  "eileen.png"

[zmook]

Are you asking how you can roll up random stats for a character?

Write a couple functions like this to your CharStats class:

Code: Select all

big_list_of_possible_names = ["Tidus", "Cloud", "Squall", "you should probably have a lot more", ...]

def d6():
    return renpy.random.randint(1, 6)

def make_random_character():
    name = renpy.random.choice(big_list_of_possible_names) 
    str = d6() + d6() + d6()
    dex = d6() + d6() + d6()
    con = d6() + d6() + d6()
    return CharStats(name, str, con, dex)

renpy.random supports rollback, so going back and forth will re-create the same random character.

[henvu50]

Hi, elhlyn,

If you don't care about side images and fine with the default character style, you can simply use the name instead:

Code: Select all

label start:
    $ npc = charStats("Name", 1,1,1)
    npc.name "Hi, I am [npc.name]"

If you would like to assign some side images or different character style (like text color) you can create a character inside your class:

Code: Select all

image side eileen = "eileen.png"

init python:
    class charStats() :
        def __init__ (self, name, strength, constitution, dexterity):
            self.name = name
            self.strength = strength
            self.constitution = constitution
            self.dexterity = dexterity
            self.char = Character(self.name, image="eileen", what_color = "#0000ff")

Code: Select all

label start:
    $ npc = charStats('Eileen_clone',1,1,1)
    npc.char "Hi, I am [npc.name]"	#Side image  "eileen.png"

This is very clean code. Just curious, why would someone use this character stat code (1st post) : viewtopic.php?f=51&t=47911#p476350 , instead of yours? Your way simply wraps Character, while in the post I linked, it seems to extend Character?

[zmook]

Just curious, why would someone use this character stat code (1st post) : viewtopic.php?f=51&t=47911#p476350 , instead of yours? Your way simply wraps Character, while in the post I linked, it seems to extend Character?

You do want to be careful keeping a distinction between defined game *configuration* and conditional game *state*. It can be a subtle concept to grasp, but the most important point is: what do you want to happen if you release an updated version of the game while somebody has a game in progress? Which pieces of information should come from the game file (like dialog, NPC names, quest prerequisites) and which should come from the in-progress save file (like current hit points, relationship status, quest progress)?

Character objects are usually *configuration*. If you change the character's name in development and publish a new version, you expect that character to just be called "Bob" now regardless if some player loads up an in-progress save file. If you decide Bob needs to be stronger, probably that should overwrite, too, or if you want to change their dialog text style or something. But you would *not* want a new version of the game to overwrite the player's progress in making Bob love them -- that's game state.

I would suggest keeping configuration and game state character data in separate objects, each having weak references to the other if you need them. (By weak references, I mean a permanent unique id like "bob", and a way to look up get_Character("bob") and get_NPCState("bob"), when you need them. If you record the Character bob as a property of bobstats, then the Character will get written to the save file, and weird things will happen when you update.)

[henvu50]

Just curious, why would someone use this character stat code (1st post) : viewtopic.php?f=51&t=47911#p476350 , instead of yours? Your way simply wraps Character, while in the post I linked, it seems to extend Character?

You do want to be careful keeping a distinction between defined game *configuration* and conditional game *state*. It can be a subtle concept to grasp, but the most important point is: what do you want to happen if you release an updated version of the game while somebody has a game in progress? Which pieces of information should come from the game file (like dialog, NPC names, quest prerequisites) and which should come from the in-progress save file (like current hit points, relationship status, quest progress)?

Character objects are usually *configuration*. If you change the character's name in development and publish a new version, you expect that character to just be called "Bob" now regardless if some player loads up an in-progress save file. If you decide Bob needs to be stronger, probably that should overwrite, too, or if you want to change their dialog text style or something. But you would *not* want a new version of the game to overwrite the player's progress in making Bob love them -- that's game state.

I would suggest keeping configuration and game state character data in separate objects, each having weak references to the other if you need them. (By weak references, I mean a permanent unique id like "bob", and a way to look up get_Character("bob") and get_NPCState("bob"), when you need them. If you record the Character bob as a property of bobstats, then the Character will get written to the save file, and weird things will happen when you update.)

I read this over and over. I went ahead and did what you said, I shared the code here for anyone who wants it:
viewtopic.php?f=8&t=62330&p=543488#p543488 (second post)

It's a dictionary lookup for a character. One dictionary is for stats or any info that can change through out gameplay. The other dictionary is for the Character objects for each character.

Hopefully it's correct.