Software Architecture

Our OOP design makes use of children which reuse the parents' code. We are able to employ a great deal of inheritance by creating parent classes such as Entity, which gave way to children classes like Static Entity, Creature, Player, and Enemy. This way, we could make several different types of entities that were almost the same, but just had different images, health, sizes or dropped different things. This made it very easy to create another object of a class or another child class and change it slightly. We attempted to maximize cohesion by creating Manager classes and a Handler. Specifically, Managers for Items and Entities. This way, the number of new methods that must be created per each instance of the class drastically reduced. in addition to that, when considering interactions between Entities, such as Players and Enemies, the Entity Manager makes it easier to establish collision conditions. The Handler is passed into nearly every class and has getters and setters for them so that each class can access the conditions and methods of other classes. This way, the game design gains greater complexity, as more and more factors and associations are accounted for.

We stuck quite closely to the Rational Unified Process. We used the brainstorming and Design Doc stages for the Inception of the project, and then developed a general base code from online tutorials and provided Java examples to accomplish minimum requirements, incrementing to achieve more of them as we added more features. For each feature or design aspect that we added, we created a series of iterations to test it, generally trying to avoid proceeding if it was a major feature that wasn't working, but leaving it for later if it was something we felt was a lesser priority than something else. After Implementation, we did a significant amount of Testing and Assessment, to try and find every case of a glitch that we would need to fix. We also got several people to beta test our game and provide feedback, and due to each player's different play styles, we were able to uncover far more glitches and bugs than we would have if we were creating the game in an isolated environment, and fixing them made the game stronger as a result.

We found our way of programming to be superior to the Model-View-Controller design pattern. This was because the MVC design pattern to be quite limiting and ineffectual for our game. The level of complexity we required for the game was such that it became very tiresome to manage once the number of our classes exceeded 15. The way we have aimed for high cohesion, the flexibility of design and world generation, our prototype will maintain stability in future game development if another developer would wish to add more features and expand the scope of the game.