Skip to content

Latest commit

 

History

History
136 lines (106 loc) · 7.18 KB

README.md

File metadata and controls

136 lines (106 loc) · 7.18 KB

Monopoly CSC207 Course Project

by Alireza, Cole, Joshua, Tahir, Qingyu, Yanbo, Youssef

Recreation of the game Monopoly using Java Swing in Java 11 for the CSC207 Fall 2022 Course Project at the University of Toronto.

Implemented with the Clean Architecture and SOLID design principles.

Includes save/load capabilities with serialization/deserialization of the GameState object.

Build & Run Instructions:

  • Ensure you are using Java 11. We built and tested this with AdoptOpenJDK Version 11.0.9
  • Run the Main Method in Main.java.

Design Process:

After creating CRC cards to help identify the major classes required, a UML chart was made. This chart helps understand the relationship between the classes, interfaces and abstract classes. The chart also clearly differentiates between Entities, Use Cases, Interface Adapters and Frameworks/Drivers. After finishing the UML chart, implementation began.

The Tile Entities were the first elements to get implemented (two abstract classes, one for Tile and one for Property and nine different tiles). We made an inheritance hierarchy where each Tile Would be accessed through a generic Tile interface (primarily the Tile.action()) method and each type of tile would implement the specific behavior and return a data object TileActionResultModel with what happened. During this phase we also developed the other game entities (Player and Board).

After finishing the Tiles, the implementation of the Use Cases began (eight Use Cases each having their own input/output boundary interfaces). Each "Turn Use Case" corresponds to an action that the player can choose to take on their turn (ex. roll dice to move, mortgage properties). We use dependency injection here where each of the use cases implement their specific Use Case's InputBoundary and take in an OutputBoundary for their presenter.

The Turn Controller is the primary controller object that acts as a facade for all use case methods that need to be called with user inputs. We use dependency injection with the use case input boundaries here to keep the clean architecture.

Game State is an entity that contains the other Game Entities, handles Turn Order, and is the object that is saved when saving or loading a game.

UI classes define the Views for three different windows. We create a default/blank game view layout in the GameView class which is then modified by the presenters to have the appropriate text or buttons or other elements depending on the data passed to the presenters.

There are a few more classes that are not listed above, feel free to look at the JDocs for more information on these!

Test Coverage

Shown below is the automatic test coverage generated by Intellij. We have tests for 100% of our Game Entities with a decreasing amount of tests as we get to outer layers in the clean architecture.

Test Coverage

It appears the reason for the low test coverage percentage is that the UI Classes all have references to other classes and objects (Such as Java awt/Swing elements like JFrames, JPanels or other classes like TurnController which is present in every Presenter object). For instance, the game package does not have 34 classes in it (it has 5 + 2 interfaces) but Intellij is seeing 34. We also are not testing any of the visual elements as we can manually test those. Other than the UI, the complex (methods that are not getters/setters are not tested) are tested thoroughly thanks to more than one hundred tests.

Sample Images

Game Screen (with Inventory screen open)

Monopoly Game Screen

Trade Menu

Trade Menu

Monopoly Board

Monopoly Board Image

Property Title Deeds

Monopoly Board Image Monopoly Board Image

Asset Credit

Images in src/main/resources/assets created by Joshua @JLenander with additional modified Icons: