Repository navigation
Software Architecture
For this project we strove to implement our game using a strict MVC format. Our use of Object Oriented Design ideas is most obvious in our implementation of the Sprite class, which had many different objects that all inherited from it. The sprite class was used for every object that was drawn on the screen, bar the UI. The class that had the highest degree of Cohesion from Sprite was Entity. This is because we used many variables and methods that were already set up in the Sprite class, including images, position on the screen, and size. Because these items didn't need to be used any differently, a high level of cohesion was very appropriate.
However, when it came to objects inherited from Entity, there was a lot less cohesion. This is because there was such a wide range of classes which all shared this one parent class. Entity was for any object that needed to move, or have a collision. Because of this we decided to write many abstract functions, that would be overridden by the classes when they needed to. However, these abstract methods would all be called in functions they all shared. This can be best seen in the update() method, where position was updated by changes in dx and dy for all Entity objects. However, dx and dy were written separately for classes that needed movement, meaning that stationary objects never moved. Another example of using abstract functions for better coupling can be seen in the attack() method. This method was completely overridden for each different entity that needed to attack; This let us keep using the base entity, but allowed completely different functionality for the monsters.
In terms of our development, we planned to follow the Iterative development process to the best we could. This was ultimately the best development style we could have followed, as during the course of the project the ability to go back and test and reevaluate aspects of our design, or address problems we encountered. This makes it, in this case, far superior to waterfall development, where we would not have been able to move on so easily, and go back to address certain features later.
However, one problem with this methodology we found is that the stability of our builds fluctuated wildly. This would occur due to the introduction of a new feature that would cause the functionality of existing features to fail. Perhaps following a protocol more similar to waterfall would ease this problem. One thing to say about this however, is that due to the ease of going back and fixing these problems with an iterative style of development, these problems have less of a hindrance. In waterfall, if we find out that there is a problem with some of the foundations of our code, it is likely that we have already sunk too many hours into it, and built too much on top of it to change it.