The Good, The Bad and The Stirred Up
quantasticjourney.blogspot.com
Here, I am generating multiple events for a character. Each output has a two sentence storyline. Jimmy will not be stirred up easily. Jimmy ...

My third blog post. I added variation in the tense of the generated text as well as another possible action for the character.

  • 0101100101@programming.devEnglish
    1·
    6 hours ago

    I’ve only glanced down your code and am not familiar with your previous efforts. Combine insulting and stirred-up to one class. “CharacterTraits” or so. This then makes it easier to add more traits like happiness, warmongering, intelligence, luck etc.

    • ecstatic_chance@mander.xyzOP
      1·
      4 hours ago

      They currently have the parent class “Action” for their common attributes and methods. Does that cover what you are suggesting?

      • 0101100101@programming.devEnglish
        1·
        4 hours ago

        They currently have the parent class “Action” for their common attributes and methods. Does that cover what you are suggesting?

        I didn’t see, but if they want a trait that has a completely set of different methods? I’m not a big fan of interface-esque classes unless the API is absolutely solid. In this case it would not be.

        • ecstatic_chance@mander.xyzOP
          1·
          3 hours ago

          A set of different methods would warrant assignment to a different class. So far no character traits warrant that. What is the alternative to interface-esque classes? If you could provide a dummy code example that would be great. What would make the API solid? Thank you for all the suggestions.

          • 0101100101@programming.devEnglish
            2·
            2 hours ago

            Why not have one class that has a level for each trait, which are scored 0-100, 0-10 etc. so… self.luck = 7.3 self.anger = 4.0 and so on. And then there’s one method that determines the action. That’s going to be so much easier to maintain, extend, and work with.

            class CharacterTraits:
  def __init__(self, luck, anger, magic, ...):
    self.luck = luck
    self.anger = anger
    # and so on

    # maybe keep a list of previous actions which could inform the next action state
    self.history = []

  def get_action(self):
    # do whatever to decide action
    action = ...

    # then add it to history
    self.history.append(action)

    return action

            and then the calling code determines what’s output to the screen. So, internally, the class is just responsible for one thing - hte business logic. Maybe another class Game could be responsible for outputting the strings, taking user input etc. If the UI were to change at a later date, the CharacterTraits class stays the same, but only the Game class would need to be modified. Instead of - as I understand it - all the classes currently would have to be updated (a maintenance nightmare!)

            I only had a really quick look down the code so I may be missing the point entirely, but that’s the direction I would go down.

            EDIT: the get_action method could take in some args, like opponent_traits or some kind of situation, maybe even add additional methods like is_lucky to return a bool as to whether a situation that requires luck has been successful or not. Another method could be has_won_fight(opponent_traits) and the method compares strength, luck, magic whatever, to the opponent to decide whether the character has won. And so on. By keeping it simple like this, it’s a lot easier to work with!