Final Report

• 1.1 Current Status of Product
• Our game has been released. It can be downloaded from our team website
• While we have spent lots of time testing networking and gameplay; it would have been nice if we had more time to look for things like memory leaks.
• We were able to implement all of the features we planned.



• 1.2 Recommended Work
• We have noticed a significant slow down after the game has been playing for some time. We suspect a memory leak. We have done some work to isolate where the leak is occuring, but it would be good to get this leak sealed. Other work includes designing more original artwork for our game in order to enhance the game's entertainment value.



• 1.3 Advice to Teams Continuing This Project
Our project is pretty straightforward. We split the game into 4 main areas, which can be clearly seen from the source code. We recommend that future teams do the same, as it helps avoid stepping on each other's toes. Another recommendation is to be aware that this is a threaded application, if the game is extended make sure that any variables you modify have a lock if necessary.

• 2.1 Management Objectives and Priorities
The primary objective of management was to ensure that all of our milestones were reached on time, and that at each step we were meeting or beating our set expectations. We placed a high priority on meeting each week to discuss our progress. We also emphasised a spirit of team work; making sure that any blocking problems a single member is faced were promptly dealt with by the team. The team also placed a high priority on developing quality software by reviewing each other's code and tracking any bugs that were discovered.


• 2.2 Final Team Structure

Andrei: Graphics, code management

Mark: Game procedure

Nate: Game engine, sound

Tom: Networking, Level Editor, game procedure


• We kept the same team roles throughout the project. However, the boundaries between our project domains began to blur as we neared the end of the project. At that point, everybody began to focus on problems / improvements anywhere int the program; regardless of who was responsible for that area.


• Our team structure worked great. We recommend that future teams follow our example of splitting up the work.


• If a future team chooses to use our structure, they should notice that we divided the sections into different libraries in the SVN repository. Each member can be assigned to get to know each of the libraries and how they work. This way everybody doesn't have to understand everything about the whole project.


• Team leader member review

Andrei: Great job designing graphics library. Always at team meetings, with ideas and contributions.

Mark: Worked hard putting the different components together and debugging problems. No problems with contributions or participation.

Nate: Implemented game engine, and wrote awesome music for game. Came to all meetings, always participated.

Tom: Got networking working, and blew everybody away with an awesome level editor. Completely participated and had many contributions.


• 2.3 Schedule and Planning


• We outlined a decent schedule in our project plan. However, we did not take into account the large amount of time that it would take to debug / enhance the game during the final few weeks. This led to an easy workflow for the first 2/3 of the semester, but a huge crunch-time in the end. We had to combine lots of development, testing, and enhancing in the last week to get everything ready for release. The main tools we used to track product progress was the product plan, and our weekly meeting. We followed the plan to make assignments each week, and tracked that progress in next weeks meeting. The best improvement we could have made with scheduling would have been to finish development a few weeks earlier, and leave plenty of time for debugging.



• 2.4 Support Functions


• From the beginning we decided that we would track any problems in the game with email. This worked great for the game, as it was really easy and natural to send an email when a bug was discovered. Everybody was notified by these emails, and these bugs could be discussed in our next meeting. In this way any bugs that were hard for a single member to deal with, could be discussed as a group. However, with email, it is really hard to track things like bug history. We would have to search our emails and separate bug reports from normal group correspondence. Most of our bugs followed the process of being reported, fixed, and then no more comment about them; so a bug history is probably not that important for our project. It may have been useful to switch to some more official bug tracking mechanism, but there was no major dissatisfaction with how bugs were tracked in our system. The major change we should have made to improve our project would have been to assign more time for QA all throughout the project.



• 2.5 Work with the Clients


• No client. Tom helped us with anything we needed.


• 2.6 Work with Project Mentors


• We did not have any project mentors.

• We did not have any project mentors.

1. Create a schedule that sets aside the last 2 weeks for QA and debugging.
2. If possible, clearly separate areas for each team member to work on individually.
3. QA each component as it is finished, and not everything all at once in the end.