Software architecture

OO-design and how cohesion and coupling issues were addressed

Using object orientated design was crucial and obligatory to the development of this game. This is because using object orientated programming allows us to make our code work around data, or objects, instead relying solely on methods and functions. This is useful as in any game there is a lot of data being tossed around so abstracting away that data to objects allows for better understanding and re-usability of our code.

Evidence of OO-design

• Encapsulation: Our objects have private variables or attributes (i.e width and height for objects that extend the entity class) and these are can only directly be altered within those objects. They may have public methods that allow those variables or attributes to be altered.

• Abstraction: Objects use private methods that are called or used within the object class. An example of this is the enemy class that has a private method to see if the player is in the enemy's 'vision' circle. This method can only be seen in the enemy class and can't be accessed by the player class but in game play the player can see this behavior play out.

• Inheritance: Objects inherit method and attributes from parent objects. We can see this again with the Enemy class that is the parent class to all different classes. This means that all enemies that inherit from the enemy class can use the "player in range" method.

• Polymorphism: Objects can be instances of parent objects. The fact we can have a 'Player' class and an 'Enemy' class both be children from the 'Entity' class is proof of this.

Cohesion and coupling

The use of OOP allows us to have high cohesion. This is because with each object we make, we abstract away methods and data in the overall program to that particular object which means that object can focus on working with that data while other objects can focus on working with their respective data. Coupling, however, was a fairly bigger issue and at times seemed unavoidable. This is because some classes, such as the enemy object, by essence can't exist without the other object, the player object. To avoid too much coupling, however, a handler class was made so that variables could be passed in between related objects and so if there was some program breaking issue we could simple go to the handler class and check/fix the error there.

Software development methodology and architecture

The main three software methodologies we attempted to stick to in this project were following the 4 rules of simple code design, project slicing and also iterative design. Following these three things helped us stay on track during the development of the project while allowing us to have a some what decent product at each iterative step and maintaining the readability of our code. Using the iterative design also made it easier to develop the architecture of our code to a display class that controlled the canvas, a back-end that contained miscellaneous classes to build the game, and a game class that communicated to both the display and the back-end.