Skip to content

PendingAction with tests #75

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

PendingAction with tests #75

wants to merge 1 commit into from

Conversation

miketwo
Copy link
Collaborator

@miketwo miketwo commented Sep 5, 2024

Example of PendingAction with tests.

Lets you specify an action, then publish it to the message bus where others can modify/cancel it, then you can execute it.

So it could let you publish draw_cards(x), to let that be modified. Or blocking(x). Or really anything.

Only supports functions with a single argument.

@vesper-arch
Copy link
Owner

assert str(pa) == "PendingAction: draw_cards(100)"

Asserts can be used without a message?

@vesper-arch
Copy link
Owner

Also by saying it only supports functions with a single argument, do you mean it isn't possible or it's just not implemented yet?

@miketwo
Copy link
Collaborator Author

miketwo commented Sep 15, 2024

assert str(pa) == "PendingAction: draw_cards(100)"

Asserts can be used without a message?

Yep. Not the best practice but quick and easy.

@miketwo
Copy link
Collaborator Author

miketwo commented Sep 15, 2024

Also by saying it only supports functions with a single argument, do you mean it isn't possible or it's just not implemented yet?

Just not implemented. It could easily be expanded to support any number of arguments, but it also makes it a little harder to work with. The idea is to just pass around an object that represents "I'm about to attack/block/buff/whatever for X amount -- does anyone care enough to change/cancel this?".

That would allow most relics/effects/anything reactive to have their code not be mixed in with the player/enemy classes or game engine. The player class shouldn't have any relic-specific things. Like ALL of this should eventually be removed:

self.attacks_played_this_turn: bool = False  # Used for the Art of War relic
self.taken_damage: bool = False  # Used for the Centennial Puzzle relic
self.gold_on_card_add: bool = False  # Used for the Ceramic Fish relic
self.happy_flower: int = 0
self.block_curses: int = 0  # Used for the Omamori relic
self.nunckaku_attacks: int = 0
self.starting_strength: int = 0  # Used for the Red Skull and Vajra relic
self.golden_bark: bool = False  # Used for the Golden Bark relic
# Used for the Molten, Toxic, and Frozen Egg relics
self.upgrade_attacks = False
self.upgrade_skills = False
self.upgrade_powers = False
self.red_skull_active = False
self.inked_cards = 0  # Used for the Ink Bottle relic
self.kunai_attacks = 0  # Used for the Kunai relic
self.letter_opener_skills = 0  # Used for the Letter Opener relic
self.ornament_fan_attacks = 0  # Used for the Ornamental Fan relic

With the right setup, we should be able to implement relics/effects without changing player/combat/message_bus/etc.

@vesper-arch
Copy link
Owner

How would it make it harder? I figure if most of the function calls that have to do with those items (attack, block, etc) use more than 1 argument then it should be implemented

@miketwo
Copy link
Collaborator Author

miketwo commented Sep 15, 2024

Maybe? What are the other args -- cards? player/enemy? target? Is there any relic/effect that's going to change those?

Also, any function that uses multiple args can be reduced to a function of one arg easily with a lambda or functools.partial()

@vesper-arch
Copy link
Owner

uh oh

@vesper-arch
Copy link
Owner

merge conflicts

@miketwo miketwo closed this Oct 8, 2024
@miketwo
Copy link
Collaborator Author

miketwo commented Oct 8, 2024

Easier to start this from scratch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants