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

  • ecstatic_chance@mander.xyzOP
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    1 day ago

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

    • 0101100101@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 day 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
        link
        fedilink
        arrow-up
        1
        ·
        1 day 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.dev
          link
          fedilink
          English
          arrow-up
          2
          ·
          edit-2
          1 day 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!