Abstract
Monopoly has been integrated into learning environments from the primary academic years of students as an activity stimulus for strategic thinking. A creative “Medway” based monopoly game does not only provide a way of digital strategic learning but eliminates the need of a player-banker. In addition, contemporary studies highlight the use of the Monopoly game as a mechanism for introductory finance accounting.
This report presents a technical understanding of the design and implementation of Monopoly, a Medway-based edition written in Java. It will explore how the desired goal of the software is accomplished through the implementation of conceptual models, Eclipse and the Agile development methodology. The report will also comprise of technical difficulties which were encountered in meeting goals.
1.0 Introduction
Board games and other older means of entertainment seem to have faded away as time has gone by. This report will aim to find how we could revamp a classical game to resolve issues we have identified, through our respective personal experiences in the current modern society.
There are several reasons why we have chosen to pursue this project. Firstly, in this modern day and age, it seems to be difficult to find methods of entertainment which also provide learning opportunities. Especially, as students, we have found when we are in a state of boredom it is problematic to find an activity which could provide a direct sense of entertainment. Secondly, when starting University students are often forced to enter a completely different world. This by itself is not a problem. The problem stems from the difficulties which arise from having to make new friends and communicating and interacting with people you have never met before.
Taking these factors into consideration and carefully considering the projects which we were available to us, the unanimous decision was to produce a digital desktop version of Monopoly. However, rather than imitating the classical template the final decision was to replicate the game to suit the specific problem identified; this was achieved by basing the game to the Medway council.
The intention of the game is to defeat the problems identified, as such the game will be specifically targeted towards students based in the Medway area; especially those of the University of Kent and Greenwich. There will be several measures of success when defining the success of the project including both our end of year grade and more importantly whether the product is used as a solution to previously outlined problems.
2.0 Background
Monopoly is a historical game, which stems back to the early 20th century. The game was originally designed and developed by Elizabeth J. Maggie in 1904 [1]. The traditional game we all know today as ‘Monopoly’ was originally referred to as ‘The Landlords Game’ when introduced by Maggie [1]. Although Maggies’ introduction marks the birth of the game it does not properly outline the establishment. Monopoly was properly established and published in 1934 by C.B. Darrow; it was Darrow who introduced the elements of the game we currently know today, including entities such as community chest and chance cards [1]. Since then, over 1044 variations of the game have been designed and published including the ‘University of Kent 50th Anniversary Edition’, ‘Monopoly Here and Now World Edition’ and much more [2].
Through our own research, we found many students from around the world have also undergone a similar project. However, when looking at attempted desktop versions made by other student using Java we could identify several limitations. As such one of our main goals was to cancel the limitations of previous versions of the game. In relation to the group, each member had different reasons for wanting to undergo the project. All members of the group are Business Information Technology student as such we had a minimal but substantial knowledge regarding Java. We have all gained relevant skills through modules such as ‘Introduction to Object-Orientated Programming’; where we were taught the fundamentals of Java alongside ‘Application Project’ where we were tasked with the arguably similar objective of creating a replica of the connect four game. However, since then we do not feel like we have been given the opportunity to both progress and display our acquired skills further. As such, all members were enticed when given the opportunity to do this. In relation to the game itself, some group members were not aware of the history or even how to play it; this provided a great opportunity to properly learn about the game and understand the hidden objectives which we most likely missed when we were younger.
Moreover, board games have retained popularity due to the social aspect of enabling people to connect to one another. Professor Eugene Provenzo (University of Miami) stated that Monopoly combines both strategy and chance, which makes the game interesting; allowing it to maintain its popularity [3]. Burt Hochberg even exclaimed that Monopoly has become part of the culture [3], emphasising to us as a group the significance of enterprise in our society.
To summarise, the game has a rich history routeing back to 1904. However, members of the group were not aware of this history and were more than eager to learn. Members of the group were also eager to find opportunities to improve programming skills; the mixture of these two elements alone has made this project an overall perfect suitor for all group members.
3.0 Aims
The project outlined to us by our supervisor was to build a Monopoly platform implementing monopoly rules that allow users to play against each other or against a computer. We initially tried to integrate Artificial Intelligence as well as a multiplayer option. However, we encountered many problems which were stifling our progress. As a result, we decided to preserve with a Monopoly game that provided a platform for 2-4 players.
Our aims were as follows:
• To build an interactive game that provides good entertainment value and learning opportunities – as Monopoly teaches players how to invest and dominate an economy
• To produce a Monopoly game based on the Medway area
• To encourage interaction between students from different backgrounds when they come to university – as entering new surroundings can be daunting.
Overall our aims can be categorised as trying to create a game that entertains University of Kent (Medway campus) and University of Greenwich (Medway campus) through a relatable personal touch.
4.0 Related Work
Before we started developing our game board and UI, we carried out research by searching for different versions of the monopoly game, and more specifically versions which were developed in Java.
The original and official game developed by Hasbro has been duplicated using various programming languages, where rules and the icons have been designed in multiple ways. There are several versions on YouTube however, the versions available all lacked a well-designed GUI and limited user interactivity.
After more research was carried out, we came across a better version which was showcased on ‘gameslol.net’. This version had animation, colour and a well-designed GUI. It allows the players to play against each other, computer and choose their level of difficulty. This was by far the best version that we accessed as it had the desirable features.
5.0 Organisation and Development
5.1 Scrum Agile Development
Scrum is one of the several agile software development methodologies; it is an iterative and incremental process for software development [4]. Features of the scrum framework consist of cross-functional and self-organising teams [4]. This was one of the highlighted reasons for our use of the framework.
Pre-starting the process we identified that all members of the team felt they had strengths within all aspects of the process; whether it be documentation or coding. As such, we felt it was important to implement a model which allows all group members to express their skills. By implementing the model, the following roles were assigned: product owner, scrum master and team members (testers, developers, quality assurers etc.) This helped create a clear but flexible hierarchy within the group whereas all members knew their main purpose. The scrum process consists of the following artefacts: product backlog, sprint backlog and burndown charts [4]. The use of these artefacts maximised our planning and allowed the creation of a clear roadmap to be followed.
Requirements of the product were also simplified with the use of user stories, and presented in a way which can be understood by all stakeholders of the product. The final aspect which encouraged the use of the framework were the ceremonies including items such as sprint planning, sprint review, sprint retrospective and daily scrum meetings [4]. These ceremonies had several advantages throughout the development of the software. Firstly, we were able to set clear goals for each iteration using ‘sprint goals’ this meant all members were aware of the proposed achievement for the current sprint. Secondly, visibility of progress was vastly increased through the several meetings. Finally, team members could identify issues and obstacles which they faced and collectively we were able to overcome them together; ultimately increasing productivity and cohesion within the group.
5.2 Requirements Document
As a group, we felt that making a requirements document would further highlight how we would create the Monopoly Game accounting for all required functionalities. It also enabled us to consider how we would go about making the game.
A requirements document must serve as a reference tool, which members of the development team can refer to when needed to gain an insight of what the project entails.
Moreover, a requirements documents entails a section for user requirements definition. User requirements are high-level statements describing a systems’ functionalities. In the document, these are communicated as functional and non-functional requirements. A functional requirement is one that displays a systems services whereas non-functional requirements are requirements that do not describe what a system will do but how it will do it.
5.3 Risk Document
A risk document was prepared to produce an extensive analysis of possible risks which could potentially pose a problem or hazard to the development of the product. Within the document was an in-depth analysis of all the possible obstacles which may be potentially damaging to the product.
The analysis consisted of two frameworks. Firstly, the traditional identification, ranking, management and tracking [5]. Secondly, we identified how the use of the scrum framework could be used to mitigate the impact of identified potential risks. As a group, the decision of conducting a risk assessment before beginning the project stemmed from the vast benefits offered. Including some of the following: we were able to build a ‘risk awareness’ culture within the group; whereas all members were aware of potential risks and had an idea about how to mitigate or avoid these risks from occurring. Moreover, group members could quickly identify hazards which could limit the progression of the development cycle and contain them. Finally, and most importantly, standards were set outlining the standards expected when working on the project using both self-made quality standards and default code of conducts including ‘The Scrum Alliance Code of Ethics’ [6] and ISO 25010 standard [7].
5.4Quality Plan
Before software is launched to the public, it is crucial for it to go through various assurance and testing procedures. A software quality assurance plan specifies the techniques and approaches needed in a project to establish a fully functional product that meets specified requirements. The quality assurance procedure includes the integration of various testing methods to guarantee a high level of validation and verification aiding the development of a reliable software product. The correlation between the level of reliability and customer satisfaction suggests it is important to keep reliability high in within the system, ensuring satisfaction from the software users.
Software quality assurance benefits the system and project in many ways, for example, programme errors and bugs are often discovered at early stages, improving the quality of the system and reducing chances of failure.
6.0 UML Diagrams
6.1 Class Diagram
UML class diagrams are utilised to depict the static view of an application, the fundamental elements of the diagram are classes and their relationships. A class is a characterisation of a concept, the possible attributes and operations correlated with it [8]. Hence, we used a class diagram to define our Monopoly application to create a visual observation of classes; aiding with the implementation of the game.
We felt when designing the game, a class diagram was essential as it enables a developmental team to construct executable code for an application. This is because class diagrams clearly showcase the mapping with object-oriented languages such as Java (mapping with object-oriented languages such as Java [9].
6.2 Use Case Diagrams
Use case diagrams were utilised to demonstrate how two actors (player and banker) would interact in the system.
Use case diagrams administers itself as a tool of communication amidst potential users and software requirements developers to comprehend what requirements of a software system are [10].
Use case diagrams make it possible to assess the behaviour of a system before the code is programmed and be applied as a plan during the software development process [10]. Moreover, use case diagrams can also provide a foundation for how software is tested [10]. Use case diagrams also provide a visual representation of functional requirements which further strengthened our knowledge of what the game needed to encompass to be successful.
The player use case diagram was constructed to outline the player interaction with the Monopoly game we wanted to build. There is also a description of this use case diagram that explains the players interact with the system and why certain things happen to visualise the game and how we would program these functionalities.
In Monopoly, a banker handles transactions in the game. For us, to progress, we felt it was crucial to outline how a banker interacts with the system to fully integrate monopoly rules in our monopoly platform. There is also a description of this use case diagram that explains the bankers’ interaction with the system and to visualise their actions in the game and give a greater understanding of how to program these functionalities.
6.3 Sequence Diagram
The reason for using a sequence diagram was that it allowed us t¬¬¬¬o visualise how the objects will interact with the system and how messages are sent to the object.
6.4 User Interface Design
The development and implementation of the user interface (UI) was a simple process which began with sketches, to develop a visual representation and layout of the Monopoly game. The sketches were key to the development of the GUI because after being drawn, Photoshop was used to add graphics and colour to the intended board. Most components of the user interface are developed in Photoshop and then implemented using JLabels and displayed with us of JFrames, an example of this is seen in the chance and get out of jail card. User Interface design is the design of the software which factors various perceptions from the visual and interaction design with the focal point to maximise user interactivity and experience.
The perfect interface is derived from understanding the users’ desire, being consistent in design and ensuring system communicates with user interaction, in the case of this project building a monopoly platform that implements monopoly rules and allows users to play against each other or against a computer. Moving on, after researching other monopoly versions which were developed in Java, it was brought to attention that there is a lack of a creative GUI amongst the different versions. Each version simply focused on the functionality while ignoring aesthetic aspects. This made having a well-designed GUI one of the priorities in the project, which included factors such as making icons easy to understand and access.
Overall, the software was designed to accommodate multiple users. Hence, the decision of placing the action buttons all in one section of the interface was preferred. As this increases usability¬¬¬¬ by making overall game interaction simple and as efficient as possible.
7.0 Design and Implementation
7.1 System Architecture
The design of our product consists of two packages; including eighteen closely¬¬¬¬¬¬¬¬¬¬¬¬ related classes.
Monopoly comprises of forty square spaces; which all hold similar but variating attributes. Within the actual design of the code, each square is generalised within an abstract class ‘Square’ which outlines common attributes which will be held by all subclasses such as name, position and most importantly an abstract method ‘executeMove’ which will be implemented by these subclasses. The reason for this is because in the game, as players’ land on different types of squares, different behaviours are executed for example if a player was to land on a community chest space 1/15 random actions will occur.
These variant types of squares are the subclasses including railway station, utility, special square, property and card. ‘Card’ is also an abstract class with two children classes, community chest card and chance card; as they share similar attributes. Figure 1 provides a visual representation of the relationship of these classes. Once completed the square classes were initialised into an array in the ‘Game’ object.
The player class was also crucial; holding all attributes and player information i.e. token and name. These classes and objects were then tied together with the GUI classes. Flow charts demonstrating the series of processes are revealed within the corpus. Following such an architecture led to an overall efficient working system.
Figure 1: Class Diagram
7.2 Design Implementation
Although the system was compiled and implemented using Java (Eclipse IDE) most of the graphical aspects were fashioned using Photoshop. This includes the design of the board, buttons and all other visual aspects of the system. Player positions were allocated through pixel calculation; this involved the extensive use of measurements and mathematics (x and y values of the relevant locations).
An example of the initial planning stages for player positions can be seen in figure 2. Once again, the Photoshop ruler tool was pivotal for this process. In addition, Java swing tools were heavily used in the design of the GUI.
Figure 2: Pixel Calculation
7.3 Player Movement
One of the most difficult aspects of the system was possibly the movement of the player, this required a relationship between the Square, MainGUI and square classes. Once positions of icons were set (including player icons, bought property, houses and hotels) in the square class the relationship with the MainGUI class was created; starting from the ‘rollButton’ action listener. Once activated the dice rolls; engaging the switch statement to display the correct image dependent on the random values selected. An attribute called ‘displacement’ is then called upon implementing a while statement decrementing the value rolled. Once completed, the ‘movePlayer’ method is called which implements an equation which can be translated into simple English: ‘the players ‘current position + a loop is called incrementing the value rolled, this value is then divided by the number of squares and the remainder value is used to set the new player position; for example, a player may be on index 20 and rolls 7 this translates to (20+7 % 40) = 27. Finally, if the player goes past the ‘GO’ square (39 array index) their balance is then increased by 200. Once this process is completed ‘paintComponent’ is called upon using the players’ array index to draw the icons new position. The final stage includes the abstract ‘executeMove’ method earlier mentioned is then called upon dependent on the type of square the player lands on. A flow chart representing this process can be seen in figure 3.
7.4 Execute Move
The abstract method ‘executeMove’ is implemented by all the subclasses of the square class. Specific rules of each class were implemented in each subclass adhering to the rules of the original Monopoly game. In relation to the chance and community card
2018-4-11-1523468730