CS4500 Final Report

April 24, 2008

Team Here For Beer



1. Product Related Information

1.1 Current Status of the Product

  • Here For Beer Tower defense is now a fully playable game. Multiple enemies, towers, and levels have been implemented. There is an infinite number of levels that scale in enemy count and enemy difficulty as the player progresses. Score is tracked, and uploaded to a high score server that has a web-based flash frontend.
  • Towers:
    • 3 individual towers, each having unique capabilities.
    • Each tower has its own upgrade path that scales in price with the power of the upgrade
  • Enemies:
    • 3 individual enemies each with unique animations
  • High Score Server
    • The game persists high scores to a database over the internet
    • A flash frontend has been provided for browsing the database to view current high scores

1.2 Recommended Work

  • Implement sound
  • Add additional enemies
  • Add additional towers
  • Add additional tower special effects
  • Further Balancing
  • Multiplayer support
  • Code Optimization

1.3 Advice to Teams Continuing This Project

  • The game has been fully developed with object oriented programming in mind. Knowing how all of the different types of graphical effects, and game objects interact makes the game very easy to make additions to.
  • Initial sound code has been implemented, it is recommended that this is done similar to the way the direct input class works, as a singleton that manages all of the sound effects and playback.
  • For optimization, some code has been duplicated in the tower class to prevent excessive looping over data structures. This could probably be refactored and consolidated to the parent Tower class.

2. Project Team Information: (Postmortem Analysis)

2.1 Management Objectives and Priorities

  1. Plan: Our priority will be to produce a fully functioning tower defense game. We will be focusing on the core gameplay aspects in order to take full advantage of our limited time. We will break each functional module into sections and assign these to individual team members.
    • Result: Our team created a fully functional tower defense game. Each team member was assigned specific tasks that best suited their unique knowledge of specific components of our game. When there was overlap team members worked together to make sure that the code got written correctly.
  2. Plan: We have decided to meet on weekends. We will all meet around 11:00am on Saturdays. If we cannot meet on Saturday, our alternate day for meeting is Sunday at 11:00am. If this is also not possible, we will discuss a day to meet via e-mail until we find an appropriate time.
    • Result: We met almost every weekend, occasionally personal schedules got in the way of this and we communicated over email. Overall, 80% of the Saturday meetings were met.

2.2 Final Team Structure

  1. Who was responsible for which tasks?
    • Chris worked on most of the rendering code and did a lot of the code review that helped make our game quite efficient. He also created the backend for the high score server, and wrote the communication between the game and the web server.
    • Dax worked on the particle effect system. His system manages thousands of particles at once and is quite efficient. He also had a hand in a chunk of the game logic, and spent a lot of time play testing.
    • Rex worked on mouse input, buttons, towers/placement, and the hud. He also defined various gameplay algorithms and worked to make the game as balanced as possible.
    • Tim worked on a lot of the graphics code with Chris, created the gameboard and the enemies. He did all of the math for pathfinding and tower targeting. He also created a system that allowed easy creation of multiple gameboards.
    • All team members worked on documentation.
  2. Did you rotate any of the roles?
    • When it was needed each team member stepped in to fill the gaps. There was a good amount of overlap and each team member has worked on multiple parts of the game, but also specialized in a particular aspect of the game over the course of the project.
  3. What would your team change about the team structure if you were starting all over with your current experience?
    • All team members performed their roles quite well, I don't think any of the roles would need to change. If anything, more time would be spent play-testing and improving overall game quality, but we were dealing with a deadline and we did the best job that we could.
    • In general, we felt like the documentation was a lot of busywork. Weekly schedules and the high-level design were helpful, but every other part of the project would have gotten done much sooner if we didn't have to spend so much time writing pages of documentation. All members of our team have "real world" programming jobs and have never written so much documentation, even on projects much larger than this one.
  4. What advice do you have for teams wanting to use the same structure?
    • Consider using available libraries for graphics and sound so you can focus on game logic and design.
    • C# with XNA is much easier to develop games for, but C++/DirectX is much more interesting.

2.3 Schedule and Planning

  1. Which aspects of your team's scheduling and planning procedures worked well?
    • Each team member made sure that when they were assigned a task they got it done in a reasonable amount of time. If a team member was working on something that others were dependent on they always made sure they got it done as soon as possible.
  2. Which problems did your team have with scheduling and planning?
    • Occasionally team members were unavailable with meetings, this was handled with lots of email communication.
  3. What tools did your team use to assist you in planning and tracking the project?
    • We used a project management program called Trac to manage our svn repository, and the wiki that we used for documentation.
    • The team also sent a dozen e-mails around per week for meeting and code coordination.
  4. How could your team have improved its scheduling and planning?
    • Require less documentation so we could complete more important tasks quicker and leave room at the end for additional game features and balancing.

2.4 Support Functions

  1. Discuss the effectiveness of your team's quality assurance.
    • Code reviews helped make sure that code was written correctly.
    • Chris spent a lot of time optimizing our graphics code which greatly improved game performance.
    • Game play-testing helped to make the game as balanced and fun as time would allow.
  2. What procedures did the team establish for defect tracking? How successful has the team been in faithfully using these procedures?
    • We did not use a formal approach for this, our team mainly discovered defects through play-testing, when a problem was found the responsible team member was notified so they could make a fix.
  3. What support function lessons did the team learn that would have helped if you had only known them earlier in the semester?
    • The team spent a lot of time early on trying to figure out how to create our graphics system. A third party graphics engine could have helped here, but would have been less interesting to use.

2.5 Work with the Clients

  1. How did your team's relationship with the client worked out?
    • The client helped keep us aware of major deadlines that were approaching via e-mail, and also gave us some feedback on each release.
  2. What would you go back and change about this relationship to make it more effective?
    • The relationship, for what it was, was pretty effective. Perhaps having a formal request process for any requests from the client following a release would have been useful.
  3. What could Dr. A [ed: Prof. T] have done to make the client-team contact more effective?
    • I would have been nice to get a little more in depth feedback on the game following a release. However, the nature of computer game quality is largely subjective, and as long as the Client didn't have any complaints, suggestions were not mandatory for progress.

2.6 Work with Project Mentors

N/A

2.7 Other Issues

  • Our team feels that too much time was spent writing documents that would be seen by nobody except a grader. If this requirement were relaxed we would have had additional time to make our project more interesting, and to possibly add new features and learn more about DirectX.

3. Feedback From the Mentors

N/A

4. Advice to Future Teams

  1. Carefully plan your project before beginning implementation
    • Most CS students should already have this drilled into their head by the time they get to the Undergrad Senior Project, but it especially important to do this when working on a project of this magnitude.
  2. Play to the strengths of your team members
    • Not all CS students are going to have the breadth of knowledge supplied by the entire CS department, but sometimes a large scale project like this requires a large breadth of CS experience. Don't be discouraged if you can't help in a particular part of the project, but use it as motivation to show your skills elsewhere in the project.
  3. Choose your project wisely
    • Since you must put so much work into a project like this, make sure you choose something where the work doesn't go to waste. Challenge yourself!