-
Notifications
You must be signed in to change notification settings - Fork 3
Iterative and Incremental Development Process
Using an iterative methodology gave the design of our project flexibility for implementation where this greatly improved our game through the changes made by vigorous testing and analysing feedback from stakeholders. We took advantage of this approach by testing our implementation consistently throughout each iteration (week) and took time before the next iteration of what we should change and work on. However, this may have also been a downside to our project, as requirements and designs were not firmly set and could be altered during the implementation process which made us backtrack to find the unnecessary assets.
Due to RUP, our team meetings were very regular and consistent, allowing constant feedback and ideas for the game. Our prototype was created early and we discussed the features that would be most suitable for the game and critical thinking concept within the current environment that was set on the game. Further development on the prototype progressed after the week of our prototype completion and we had fallen behind on our iterative process, as the next iteration was delayed. Thus, an executable was not made during that week and major bugs found were not properly fixed and discussed with the entire team. As the iteration was delayed, the process to improve the performance for the game was also delayed because we had a short time constraint to implement and add our features to the game. The most crucial mistake that we had from delaying an iteration was when we attempted to create an executable with our necessary branches in Github, as there were too many bugs to be fixed and we had a difficult time finding the sources of the problems found in the game.
To improve on this as a team, we should not have missed an iteration during the project, as this greatly affected our development process and team coordination towards the final milestone. We also should have discussed and had fixed features and implementations before finishing our prototype, as the changes caused uncertainty during team sessions and discussions.
Team members are great University students who show up to class and spend their free time in the UG4 computer lab meaning we were regularly together and could take advantage of respected software development processes such as pair programming. The friendly and cheerful team environment encouraged members to suggest their ideas and constructive feedback. The result of our high team cohesion is everyone's ideas are equally represented in the final product.
Due to the nature of the iterative process RUP, we regularly received valuable feedback. Up until our final release the game had few if any bugs due to the constant playtesting from team members and other groups (which was accessible due to our time spent in UG4). Doing this meant the development could quickly advance without worrying about a back-log of problems building up.
The most important problems mentioned were players getting stuck in an impossible to complete state. This included boxes getting trapped up against walls which was resolved by placing an invisible wall that only collided with the boxes. Players dying to mechanical errors such as the placement of spikes and length of water bodies. This was resolved by minimising these interactions as it was not fun or considered critical thinking to lose to this. Eventually, a reset button was included to cover any other situation.
Github was difficult to manage among 8 people where multiple branches were made for each function/feature. The issue here was partially the member's knowledge of git and partially communication.
- git
Members should have been regularly pulling from the master and if they were working on a scene in Unity this should have been a copy scene. They could then pull the latest master and drag in all their prefabs from the copy scene to guarantee zero conflicts. In addition, branch names and commit messages could have been more clear to indicate what exactly was being pushed into the repository. Also, the repository was not kept clean. A lot of unnecessary files were pushed such as demo Unity projects which made cloning take longer and the scripts/assets were not organised. Members should have regularly been pruning their local and merged remote branches to reduce confusion.
- Communication
If tools such as Trello were used better members could communicate what scenes they were working on to further reduce conflicts.
- Github
Other Github features were attempted to be used. Issue tracking was not as active as it could've been. If we had a record of all the bugs in the issue page that members regularly checked we could have assigned tasks to members with not much to do to go fix these bugs rather than members coming across and communicating bugs others had already observed.
We had a lot of ideas we wanted to implement in order to fully flesh out our storyline and game concept. This included a final space level where physics such as lower gravity would be included and possible boss fights. However, we underestimated the amount of time cleanly implementing our concepts and dealing with problems such as merge conflicts would take, also, we spent time developing things that weren't shown in the final product. However, we learnt a lot from this project and if we were to do this all over again with the same starting knowledge I don't think the end result would be much different.
We could have identified time-consuming tasks and cut them off early within iterations and then made changes to our design around excluding the following:
- Scene Persistence
Persistence was a requirement for our level-design as it would increase the complexity of the puzzles we could create and storyline depth. Currently, players are required to backtrack to pick up items they may have missed. However, the time it took to implement and test persistence was not worth it. We could have done without the persistence system and reduced the complexity of our game OR combined all scenes in a level into one scene and moved the game camera when players moved between rooms, however, this would mean dealing with more merge conflicts. The time spent implementing persistence could have been used to implement another level with other mechanics we had discussed such as differing gravity.
- Mini-game
The minigame was not envisioned in our initial game design but a group member was eager to implement and prove his game concept idea. However, the end result did not meet our serious game concept and the clunky controls were confusing to players. The time spent developing the minigame could have been spent developing level ideas the entire team had agreed upon rather than a single members idea.
Trello could have certainly be used more efficiently as suggested. It was only used as a checklist and to divide tasks rather than to indicate what people were working on at any given time. It would have been nice to switch tabs and see what people were working on which would reduce merge conflicts and prevent a lot of headaches.
Travis has the ability to not only run tests but build and upload executables to the cloud. Had we taken advantage of this everytime a pull request was merged we could have the latest version of our application uploaded to somewhere such as Amazon s3. On our final build, a conflict meant the Sound FX was broken and had we had a backup build this wouldn't have been an issue.
Game Overview and Required Features Selection
Mapping Critical Thinking to Game Aspects
Prototype Team Development Log