I have a question about what’s the “best practice” for game architecture for something as theoretically simple as “playing a card”.
Namely, the question is, who/what plays the card?
Does the player play the card and do all the work? Or does the player simply tell the Game Manager that this is the card they want to play, and the Game Manager does all the work? Or lastly, does the card Play itself and handle all the interior bits?
I’m asking from a “Best Practices” standpoint - if I decide the game plays the card, does that present some future hurdles, etc. Just looking for some guidance on overall game architecture.
Cards on a screen are a lot like windows on a screen (e.g., a GUI). GUIs are commonly implemented using the Model-View-Controller (MVC) architecture or a similar architecture such as MVVM.
The Model is just data – for example, the game consists of a bunch of Players. Each player has a Hand, which is a list of Cards. Each Card may have its image and some rules or code that specifies what it does when played. (The image is just a reference to an image asset in the project, not an onscreen UI element.)
The View just manages what’s onscreen. For example, there may be a UI element for each Card.
The Controller (maybe this is your Game Manager) coordinates between the Model and View. Ideally the Model and View never talk to each other directly. It takes a little discipline to maintain this division, but it makes many things much easier, such as setting up a new game (just set up the Model, and let the Controller tell the View to update itself according to the Model) and saving games (just save the Model’s data).
The player only ever interacts with the View. When the player chooses a card to play, the View tells the Controller which card’s view was chosen. The Controller looks up the card in the Model and follows its rules / runs its code, which updates the Model. The Model then tells the Controller what data changed, and the Controller tells the View to update accordingly.
I know that wall of text may sound complicated, but it ends up being relatively simple to implement and maintain, especially if you keep in mind that it’s architected a lot like an OS’s GUI system works.