CPSC 329 Software Development Fall 2017

CPSC 329 Project 2: Game!

Objectives

The primary goal of this project is to pull together the techniques and tactics relating to understanding and design into the construction of a larger program. A secondary goal is to continue thinking about and working on effective teamwork.

Specific goals include:

Teamwork and Collaboration

This is a group project. Teams are:

Team members are expected to contribute fully to their team.

For the team parts of the project, getting help from or discussing ideas with others not in your group is allowed with limits as detailed in the collaboration policy. Parts of the project designated as "individual" (such as the reflection) should be done solely by the person handing it in.

In all cases, coming to office hours is always OK. (And encouraged!)


Specifications

Software

You work for a game company which specializes in adaptations of classic board games. Two games have been proposed for the next big release: Igel Ärgern (also known as "Hedgehogs in a Hurry") and Pente.

Your task is to implement one of these games. (More information on the games can be found below.) Since the company would like to get the software on the market as soon as possible, it has been decided that the first release will include only functionality needed to support the user goal of "playing the game with friends seated around the same computer". Part of your task will be define exactly what that functionality will be. (Extra credit is possible for additional functionality.)

Your program should also have a well-designed UI - the company hopes to make money by selling a series of upgrades with additional features, but customers turned off by a poor user interface aren't likely to buy new versions of the game.

Understanding and Design Documents

As part of the development process, you should identify features and requirements and produce CRC cards, a use case diagram, use cases, sequence diagram(s), and a class diagram.

Coding Style

You are expected to follow the course coding standards.

Testing

Pre- and postconditions and other structural invariants should be checked. Automated testing should be incorporated into the development process. Overall, testing should be incorporated in a way that is easy to use during development and easy to remove for release. This means mechanisms like throwing IllegalArgumentExceptions for preconditions violations, using assert to check invariants, and separating the implementation of test cases from the code being tested. Printing out messages is useful for debugging but should not be considered part of testing.

Teamwork

As with project 1, you should continue explicitly working on team skills. In particular:

Note on dividing up tasks: It is ultimately up to the team to decide how to divide up the work of completing the project and to do so in such a way that everyone is satisfied about the others' contribution to the team. However, keep in mind that this is also an important opportunity for learning and practice, so everyone should make sure that they feel comfortable with all of the different elements of the project (including the understanding and design phases). Practices like working in pairs and peer review of various components can help ensure that everyone is able to be involved in each phase.

Collaboration Tools and Version Control

As with project 1, you are required to use a collaborative tool such as Google Drive for the meeting minutes and other team documents not part of your Eclipse project, and SVN for your code and other files that are part of your Eclipse project.

For SVN, use hedgehogs or pente as the name of the subdirectory within the repository (this should go under one team member's repository directory) and "single project layout" when you share the project. Make appropriate use of version control, including committing and making branches when it is appropriate to do so. Informative commit comments are expected.


Game Information

Igel Ärgern

Board game description and information:

Your program should support the goal of playing the standard version of Igel Ärgern with 2-6 human players (who are all sitting in front of the same computer).

Pente

Board game descriptions and information:

Your program should support the goal of playing Pente against another person (who is also sitting in front of the same computer) using the standard rules. You do not need to worry about supporting any of the alternate rules.


Due Dates, Deliverables, Handin, and Grading

Due Fri Oct 6 at the start of class

By this point you should have completed the understanding and code design phases of the project.

One handin per group:

Due Fri Oct 13 at the start of class (*)

By this point you should have completed the design of your program's user interface.

One handin per group:

(*) Handin by 10/13 is strongly encouraged, but it will be accepted until 10/16.

Due Fri Nov 3 at the start of class

This is the main project handin. You should have a complete program!

One handin per group.

Due Mon Nov 6 at the start of class

The last stage involves reflection on the process and result.

One handin per person.

Hand in a hard copy of everything except the teamwork assessment on Canvas. Be thoughtful in your responses; a rough estimate is approximately three pages of writing in total (but what you say is more important than the exact length).

Grading

Good programming style and following the course coding conventions is expected, and will be reflected in the functionality grade.

Some extra credit is possible for a fancier user interface and/or appropriate additional features beyond the minimal specifications, but note that extras will not count if the requirements are not met - make sure that you identify what is essential and budget your time so that you end up with a working program that meets the specifications.

All members of the group will receive the same grade for the understanding, design, software, and testing portions of the grade. All members of the group will also receive the same grade for the portion of the teamwork component that is based on the meeting minutes and the use of version control. The individual handins (design critiques, reflections, and individual contributions to the team components) will be graded individually. (Contributions to the team will count under the "Participation" part of the overall course grade.)


Valid HTML 4.01!