CSCE-315: Programming Studio (Summer 2012)
Project 3:
Updates
Team configuration
The team configuration will be the same as projects 1 and 2.
Project Goal
This project is meant to help familiarize you with:
- the use of XML for data interchange
- mobile phone application development concepts
- mobile phone application development tools
Project Outline
For this project, you will write a mobile phone application (Android) based on the Reversi player you wrote for project 2. The basic requirements are:
- Graphical user interface:
- All game-related function (select difficulty, choose black/white, play turn, undo/redo, etc.) from project 2 should be accessible through a graphical user interface (pop-up selections, touch-screen interaction, etc.).
- There's no need to implement the client-server part.
- Be creative with the graphics. Elegant display and/or innovative user interface will get more points.
- Other features to be added, compared to project 2: An XML file stored on the SD card to keep track of game statistics and high scores. You should define a DTD or XML schema for the game statistics data and use the Android API to validate and manipulate the XML file.
SCRUM
- Start with your product backlog from project 2, and modify it to include the Android-specific parts.
- You will have a running-start, so mark off the parts you've already implemented in project 2 and create an updated burn-down chart and a single sprint backlog (you will have time for only one sprint).
- Optional: If you have time, investigate the use of JUnit (a unit testing framework for Java). You'll get 5% extra credit if you make extensive use of unit testing for this project.
XML
- You need to use DTD or XML schema to formally define the legal syntax for your XML file.
- You must validate your XML data file against the DTD or XML schema everytime you use it.
First decide on that kind of game statistics you will store and make available to the user. At the minimum you should keep a high score table.
- High scores should be kept for individual difficulty levels
- Score can be as simple as the # of your pieces minus the # of AI's pieces at the end of the game.
- You can also factor in play time: fastest win, regardless of # pieces won by, or a combination of score and play time.
Grading
10% Agile computing methodology - setting, using, adjusting backlogs and burndown charts
20% Completeness and quality of game mechanics and AI
20% Degree of integration of game mechanics/AI with the user interface.
30% Graphics display and user interface (include 5% for creativity).
10% XML design and game statistics
10% Code style (naming, layout, etc.)
5% extra credit for extensive unit testing (apply unit testing to the new portion of the code only: no need to retrofit unit testing on the previous game/AI code).
Deliverables
- Design documents, SCRUM product log (with initial burndown chart),
(plus sprint 1 backlog and burndown chart), and XML design (for game statistics).
- The design document requirements are the same as Project 1.
- See the SCRUM tips in project 2 for the product log format.
- The XML design can be rough. You should first decide what information to keep track of. You don't need a full DTD or XML schema. An example XML file would be fine.
- User interface code.
- This will include the bulk of game settings dialog and graphical display.
- Final version.
- Final XML design, game statistics functionality fully implemented.
- Game/AI fully integrated with the graphical user interface.
- An updated version of your design document.
- post production notes (changes you had to make to your design and why, difficulties, solutions, lessons learned)
- individual work load distribution (percentage)
- self-evaluation (briefly discuss how you contributed to the project) and peer evaluation (rate all other team members on the scale of 1 to 5, 5 being best; plus brief comments). Peer evaluation should be submitted individually.
- Development log.