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.dev
    link
    fedilink
    English
    arrow-up
    1
    ·
    9 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_chanceOP
      link
      fedilink
      arrow-up
      1
      ·
      8 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.dev
        link
        fedilink
        English
        arrow-up
        2
        ·
        edit-2
        7 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!

        • ecstatic_chanceOP
          link
          fedilink
          arrow-up
          1
          ·
          8 hours ago

          Thank you for all the suggestions. I will take them into deep consideration.