How do we want to do this? We could bake game logic into the board, however this doesn't really help with portability. The board will likely control animation and trigger events within the game, but the game logic should probably be its own class designed to take input from the board and change state accordingly, then the board would refresh/animate new objects to reflect new state. I created the EuchreObjects namespace to handle things related to game logic, and will need to revisit the design for those to try and remember my original plan for how they would fit.
Potentially look at refactoring some of those classes as well. For Card, it is its own object that holds a reference to its model, but some objects I've made to be both the model and the "Euchre Object".
This could be a tough one. Blocked by #2.
How do we want to do this? We could bake game logic into the board, however this doesn't really help with portability. The board will likely control animation and trigger events within the game, but the game logic should probably be its own class designed to take input from the board and change state accordingly, then the board would refresh/animate new objects to reflect new state. I created the EuchreObjects namespace to handle things related to game logic, and will need to revisit the design for those to try and remember my original plan for how they would fit.
Potentially look at refactoring some of those classes as well. For Card, it is its own object that holds a reference to its model, but some objects I've made to be both the model and the "Euchre Object".