-
Notifications
You must be signed in to change notification settings - Fork 0
Software development process
Agile methodology practices were followed, where each iteration was controlled by feedback which included revaluation and revision. We followed the rational unified process, an iterative and incremental process that aims to produce higher quality software, and higher quality of life for the development team.
The development process of the game was divided into three stages: Initial, Beta, and Final. We first implemented the basic structure and functionalities for Initial such as a singular map with a player and basic enemies moving in random directions. Beta added more features such as different movements for the wolves, a boss level, and pick up items and different rooms/levels. Final included adding the sound effects and more visual cues, implementing scores, different difficulties, as well as creating the different screens such as Main Menu, Win screen and Lose screen. Each stage / iteration had an executable release in which testing was implemented.
After looking at the specifications from the Project description, we focused on the storyline of the game which we tried to make appeal to the target audience of a 12 year old girl. We used modelling processes to come up with the general structure of how the game would look like, and what set of logic the game should follow. We then drew a couple of sketches of screen diagrams, followed by a discussion of its strengths and weaknesses. We had a lot of ideas on features we could implement and finally narrowed these down to a few that would add the most to the game experience. A low fidelity of the game was then drawn up in Photoshop. This also contributes to feedback as users can visualize how the end product may look. Detailed modelling is extremely important in creating high quality software. Changes in the design of the game can be easily made in this early stage of design development. B. Implementation Phase Next was the implementation phase where we began the implementation of our code. We made sure to comment our code often, so that we would have a better understanding of our code. We also refactored our code relatively often, in particular at the end to ensure that our code was of high quality and didn’t include any redundant classes or methods. Variables and methods were named using camel case, and again, this increases the readability of the code, and is incredibly important for maintenance purposes. Implementation was heavily incorporated with testing, in particular when new features were added. Since we followed an agile process, this resulted in many short iterations where each step was repeated, with a heavy focus in feedback.
We used a private Git repository on GitHub for version control. GitHub is a sub-version control system that allows multiple developers to contribute to a common repository of code. New branches were created for specific features. This made it easy to work simultaneously on the code and merge back into the main branch once the feature was done. We each worked on different features at a time. For example, William was working on the enemy movement while I was working on the pick-up features. This ensured that the classes we would be making changes to were different and thus would cause minimal conflict. However, in saying this, it didn’t restrict us in making changes to classes that the other person could also be making changes to. During the development process, I could have committed files more often. This would have made it safer, so I could revert back to a previous version if I had made a mistake.
Although we didn’t have a formalized process for testing, we did test the game extensively every time a new feature was added. However, our testing process could have been improved. A lot of the tests could have been made easier and potentially even automated with Java tools. This would have significantly improved the development process by saving a lot of time and effort as well increasing the robustness of the game. We also didn’t extensively test features we created around the initial stages when new features were added. New features added might have introduced new bugs that didn’t exist previously, causing an earlier feature to break. In our game, we implemented keys that would act as shortcuts to different rooms or access to different pick up items that would make testing to be easier. For example, pressing ‘C’ would allow the user to have access to the cupid’s bow item, as normally they are hard and take a long time to obtain.
Throughout the development process, we were given a lot of helpful feedback from our classmates and friends (although they were not all part of the target audience group, their feedback was useful). We particularly focused on whether the objective/mission was intuitive enough, and whether the game was too hard or too easy etc. We also got some users to playtest the game in its early stages for feedback. This was further used for the next iteration. Feedback is incredibly important in creating a high-quality design that would fit the user requirements especially since we intend to create an application that would be centered around users. As we observed how users interacted with the game, this gave us lots of ideas on how we could improve. For example, we noticed that not many people were noticing that their weapons were upgrading since you need to press a key to switch weapons. We found a solution which was creating a dialog window the first time one of those weapons would come up. We also added sound effects and visual cues as aid. Another example is that people found it was hard to stab the wolves with the dagger.