1

Final Team Report

Our project is complete
Through beta testers and our own debugging, the product has been adequately tested.
In the early stages of the project, we had toyed with the idea of a multiplayer version of our game. However, due to resource constraints such as screen real estate and level of burden on the user’s computer, we decided not to implement it.

There are currently no known bugs.
With large numbers of graphics on the screen, the frame rate is known to drop to considerably low levels.
As with any game, balance issues and enhancements will always be present.

Get the basics (shortest path, tower targeting and firing) done early. Making the game fun is just as important to the game as actually getting it to work.
Pick a theme early.

Team Epicurity is composed of Colorful People with varying schedules, therefore a large section of our team management is going to be deadline management and team meeting co-ordination. We used a GoogleGroups mailing list to communicate all of team information, as well as scheduling requests and deadline reminders. At the end of each meeting, we spent time discussing and arranging the next meeting.
Team Epicurity team management was a largely consensus approach.

Final team structure. In sections 2.2 and 2.4 of the Project Plan, you described your team's organizational structure and individual responsibilities. You have also revisited this issue in some of your activity reports. Describe the team structure at the end of the semester:

We assigned specialized roles to team members with more experience (i.e. Tyler was in charge of most of the website, since he has experience in the web design field). Since most of the team members still do not own Flash CS3, the majority of the code was done in the lab as a group.
Also, all team members shared responsibility of documentation and deliverables with a rotating assignment of weekly management reports and group creation of Project Plan, SRS, SDS, and VVR/VVP documents.

Casey – Game-play implementation, developer, and intermittent Henderson handler.
Mark – Lead Developer
Matt - Team Leader, developer, and Thomas C. Henderson “handler”
Tyler – Webmaster, Network Admin, and developer

This structure worked extremely well for us, however, if we did it again we would give slightly more power to the team leader to speed up decision making.
Subversion is a great tool for this kind of individual yet consensus approach. Making good use of its lock feature is strongly advised.
Overall our team did an amazing job on this project. When we began working, I thought that the project might, in fact, being a little overwhelming and that it wouldn’t turn out so well. Fortunately, I was dead wrong. The team really buckled down, worked hard, and what we were able to produce was well beyond my expectations. Tyler was able to create our webpage, SVN, forums, high score server, and game hosting with relative ease where it would have taken anyone else on the team an order of magnitude longer to figure out. Mark really bashed his head against the nitty-gritty intricacies of low-level ActionScript and the result were some really efficient algorithms that are the core of our product. Casey was always willing to put in long hours even on nights and weekends to solve any problem that needed a solution whether it was bug fixes, creating new towers, creating new bullets, working on balance, or even helping anyone else with problems they were having.

Using the mailing list made for easy and quick communication most of the time.
If someone did not respond to the mailing list, however, its passive nature became a hindrance to planning.
Tools: GoogleGroups, SVN, bug tracking Forum
Some improvements to scheduling could be made through the use of a collaborative calendar tool.

For testing purposes we used Beta testers and our own debugging skills. The debugging tools was useful for cases that we expected or were worried might fail, while the beta testers were a great source of outside opinions and fresh, objective view points.
For Configuration Management we used Subversion, which was extremely helpful when the group was working together in the lab, but problematic when used by individuals at home. A more effective use of the lock feature would have resolved this issue.
Beta testers worked on successful builds that we pushed to our website, and Tyler was largely responsible for this, with builds being done at various benchmarks in the project’s life-cycle.
For defect tracking we had two procedures: Forum posts and responses for beta testers, and mailing list messages for developers.
Since this project was relatively small in scale, support features did not become a big issue, but as the project developed, and especially as we began integrating, SVN became increasingly useful and important.

Our client for this project was Professor Henderson and our main interaction with him was through documentation.
If there was anything our team would change about our relationship with the client, we would want a client more interested in the actual content of our project, and less concerned with the documentation describing it. In the traditional sense of the term, our relationship with Henderson was not actually a client, and more a manager.

Picking your own project can have its advantages, but you need to have a good idea of what you want to do, or you can quickly fall behind in progress.
Clearly define roles in the team, so if problems arise, it is easy to determine who needs to take charge.
Documentation is a very important aspect of this class. Do not put it off until the last minute or fall behind in logs, as you will have a difficult time recovering.