-
Notifications
You must be signed in to change notification settings - Fork 0
Discover our Implementation
First of all the entire project is based on the Model View Control (MVC) architecture, in the Model you can find all the game-related classes such as the Table, the Player and so on; the Controller contains all the logical information for game-flow handling; finally you can think of our View as a simplified Model decorated with classes for I/O to optimize the user experience. What follows is a detailed description of the project implementation devided by packages.
The Model package is composed mainly by five parts: the Table, the Player, the Cards (normal and leader), the Effects, the Actions.
The Table does not have a lot of game-logic, instead it works as a container of other classes such as the Players, the Bans and the Positions. In particular, to develop different kind of Positions (Tower, Market, Council, Yield and Product), every position inherits from an abstract class called Position, that may have a Familiar for example, and adds some of its specific information (e.g. the TowerPosition has a Card), as you can see from the picture.
The Player obviously represents a player of Lorenzo il Magnifico so it has four Familiars, a StaticList (list limited to a maximum size) of Cards for each color, a List of LeaderCards, a List of Request to handle the game-flow of the Cards and some State variables to handle some special effects (e.g. the can positioning everywhere effect ofthe Leader Card Ludovico Ariosto ).
The Card class represents a generic game card, so it is mainly composed by a name (to identify it), a List of possible Requirements, a List of possible Costs and three Lists of Effects (Immediate: enabled when the Card is taken, Permanent: enabled during all the game, Final: enabled at the end of the match). In addition, a Card contains all the logic for the payment, effects and requests management. Instead, the LeaderCard class represents a simpler version of a Card: it has only a LeaderRequirement (that handles the logic of LeaderCards requirements) and three possible Effects: the OnceARound effect, the Permanent one and the OnDiscard effect.
The Effects of the Game have been implemented using a Strategy Pattern, thus every effect inherits from the abstract class Effect and must implements the enableEffect(Player p) method that enables the effect on the Player; thanks to this pattern we can easely add new type of effects. In this hierarchy falls every type of effect: the Card related, the LeaderCard related, the Position related and the Ban related.
One of the last, but more important, part of the Model are the Actions: classes that incorporates the concept of a PlayerMove. We developed this classes using both the Strategy and Command pattern, the former allow us to easey handle different type of Action using the checkAction() and doAction() methods while the latter is convenient for the management of the various round of the game. To create an Action we used a Factory pattern (the ActionCreator class) to encapsulate the creation process.
Finally, in the Model package you can also find a package for the Resource of the game, for the Exceptions and one for the Enumerations that we introduced during the development process (ActionType, EffectType, Response, ResourceType and so on).
The View package contains an abstract class View that is used to implement the CLI and GUI views. This class encapsulate all the operations required to handle the I/O of the game (asking a new move, resolving a card request, enabling a leader card and so on) which are then better refined in the concrete classes.
The Controller package is essentially made by two classes: the first is the GameLogic, which manages the flow of the entire game, while the second one is the CardsCreator, which load the cards of every round from file.
The GameLogic keeps track of the state of the game by a ordered List of Players, a List of Request and a List of LeaderRequest such that it can handle asynchronous game-flow (e.g. Enabling a leader card while another player is playing). Every round it ask the CardsCreator to load and shuffle the four deck of cards to place on the TowerPosition, this class is based on a State Pattern such that can easily switch from different file of Cards depending on the round number.
To guarantee the portability and configurability of the project we devoted an entire package to manage the configuration files. To do that we used both the .json format and the Gson library for parsing and writing operations; when required (such as for the cards Effects) we used the Reflection technique, so we implemented a Serializer class that adds such informations during the file building phase and then extrapolate them during the parsing phase. So to configure this files you can use the specific Builder class for the file you want to configure and just follow the on screen instructions.
Since this videogame has been developed to be played in a distribuited mode we added some intermediates in our MVC architecture, for this reason there are a ServerView and a Client classes. The former mediates the communication between the View and the Controller while the latter mediates between the Model and the View.
Every communication lean on a wide hierarchy of Messages that is easily managed by a Visitor Pattern implementation, one for the server side (ControllerVisitor) and another for the client side (ViewVisitor). In this way the hierarchy will be simply expanded with more new messages, simply adding the new message and implementing the visit(GenericMessage newMessage) method in the ViewVisitor and in the ControllerVisitor, and finally the message must implement the visit(Visitor v) method inherited by the Visitable interface.