RunThrough - MaCShorb/CardGame GitHub Wiki
This code is all pre-216 and pre-comprehension that Unity projects should use a component programming design, rather than a OOP design. So there's some clean up and refactoring to do. I also tried to make a few changes while in 216 which threw off the spaghetti even a bit more: mainly seen in the CardDatabase section where I tried to abstract out towards a generic database class. That and I tried adding a unit test runner, but I don't think that broke anything.
Main thing to keep in mind is we can change any code. All functionality described is just how it "currently" is, not what it eventually ought to be.
Script rundown:
Card Script:
Card has a name, text, cost, tier, and type. ActionCodeShells will be removed. Card adjusts color of frame based on card type.
Character Script:
Character data storage.
ClickComponent:
Put on an object, and then other components on that object can subscribe to events MouseUp, MouseEnter, and MouseExit and act accordingly.
CVSReader:
I didn't write this code. It reads CSV files. I use it to read in card info.
DelegateScript:
This was put in place for plan of eventual multiplayer. Would send out game happenings from one GameInputHandler to all GameInputHandlers.
GameBoardScript:
Allows for delegate execution on all players, monsters. Will remove.
GameInputHandler:
Mostly unneeded logic stuff. Main idea is a card wants a target, so GameInputHandler subscribes to all applicable target objects and notifies the card when a valid target is clicked. Then the card runs its code on that target.
HistoryScript:
Attempt at history of events, like hearthstone has on the side of the board.
MoveComponent:
Self explanatory.
PlayerScript:
I had all deck code and workings stored in PlayerScript. Mostly subscribing and unsubscribing to cards as they enter and exit hand. Should really be handled in hand component, which will be new for Magic CCG implementation.
UIActionExecutor:
Execute code stored in an action.
Class Rundown:
Action
All logic. Storing code in class to eventually be run later. The actual code is stored in CardDatabase, and the action executes this code through delegates. In future should be no need for database, all actions can be represented in .txt file
CardDatabase:
Code for every card. All logic, very clunky.
Deck:
A lot of this code can be reused, except for the fact that deck has it's own hand. A hand should be distinct from a deck.
Everything else:
Will delete.