So I've been doing all of this refactoring but I figured I should kind of write down how I'm expecting this to play out.
While I was working on implementing various cards I noticed a ton of common behaviors and started getting annoyed at how much copy/paste was happening. I began moving stuff into the Effect classes in order to group the logic and make the individual class files much lighter. Now, most new card implementations are about choosing from a library of known Effects.
The Filters that have been added were originally intended to be a way to apply effects across full groups of minions or to "pick one of these at random". After they were added, though, I realized that there was a whole bunch of duplicated looping logic for dealing with groups of minions.
So at this point, there are three main concepts behind card implementation:
Effects
Filters
Iterators
The actual implementations are all over the place right now as I slowly convert the main game logic to understand and deal with these and, currently, this means there is some amount of overhead in the interactions. But the goal is to bring everything to a point where implementing cards just asks four questions:
What is the effect?
What group of things does it effect? (E.g., cards in hand; minions on the board; cards in the deck.)
What specific cards does it effect? (E.g., one at random; all possible; player's choice.)
When does the effect occur?
Virtually everything from Battlecries to Spell Effects to Triggered Effects can be processed with these four questions and most Hearthstone cards reuse common answers to these questions.
The piece after that will be optimizing the performance and memory usage around Effects/Filters/Iterators. Right now, I am using a primary CharacterIterator and a HandIterator but there is opportunity to streamline that. Instead of worrying about those details right now, though, I'm getting the cards implemented and making sure there aren't any problems with the overall concept.
One of the hopes that I have for this is to define the Effects well enough that we can automatically save time/memory if we detect Effects that don't need, say, a full HearthTreeNode to operate. I just added a SimpleEffect interface in order to deal with the Auras and it seems to work just fine.
Hopefully that all makes sense to you and thanks for having the patience to let me rampage through the code base changing everything. :)
So I've been doing all of this refactoring but I figured I should kind of write down how I'm expecting this to play out.
While I was working on implementing various cards I noticed a ton of common behaviors and started getting annoyed at how much copy/paste was happening. I began moving stuff into the Effect classes in order to group the logic and make the individual class files much lighter. Now, most new card implementations are about choosing from a library of known Effects.
The Filters that have been added were originally intended to be a way to apply effects across full groups of minions or to "pick one of these at random". After they were added, though, I realized that there was a whole bunch of duplicated looping logic for dealing with groups of minions.
So at this point, there are three main concepts behind card implementation:
The actual implementations are all over the place right now as I slowly convert the main game logic to understand and deal with these and, currently, this means there is some amount of overhead in the interactions. But the goal is to bring everything to a point where implementing cards just asks four questions:
Virtually everything from Battlecries to Spell Effects to Triggered Effects can be processed with these four questions and most Hearthstone cards reuse common answers to these questions.
The piece after that will be optimizing the performance and memory usage around Effects/Filters/Iterators. Right now, I am using a primary CharacterIterator and a HandIterator but there is opportunity to streamline that. Instead of worrying about those details right now, though, I'm getting the cards implemented and making sure there aren't any problems with the overall concept.
One of the hopes that I have for this is to define the Effects well enough that we can automatically save time/memory if we detect Effects that don't need, say, a full HearthTreeNode to operate. I just added a SimpleEffect interface in order to deal with the Auras and it seems to work just fine.
Hopefully that all makes sense to you and thanks for having the patience to let me rampage through the code base changing everything. :)