EECS448:Project2
| Navigation |
|---|
| Home |
| Information |
| Classwork |
Contents
Ask David Graham, Attorney at Law
While not required for project 2, there's still time to ask David Graham a question for Wednesday's lecture.
Assessments
DUE THURSDAY OCTOBER 24th BY 11:59PM
Due Date
All teams must have a all artifact other than the as of 11:59pm October 20th. The timestamp will be judged by the final commit on your master branch of the team's github repository.
You can continue to work on other branches but cannot update your master branch after the freeze date. You must demo code base on that master branch as of the code freeze.
Overview
You're all fired! You are no longer working on your projects. Luckily, there are a lot of job opening at other companies. In fact, the market is booming right now and finding a new job for your team should be easy.
You will fork the project of another team's project 1 (see table for details) and complete the requirements for project 2.
You cannot contact the team you inherited from for help of any kind.
Code Requirements
- You must program in the same language(s) and support the same platform as the original team
- Refactoring and bug fixing is allowed
- Adding a GUI to a terminal based implementation is fine
- Other drastic changes need Product Owner (Professor Gibbons) approval
Feature Requirements
Get it up to code
- First, you must get all required functionality from project 1 working, even if the team you inherited from did not
AI Opponent
In addition to playing against a human, you will create an AI to play against. Requirements for the AI:
- Setup
- All AI difficulties place their ships randomly (must still be legal placement)
- Three difficulty modes
- Easy: It just fires randomly every turn
- Medium: It fires randomly until it hit a ship then fires in orthogonally adjacent spaces to find other hits until a ship is sunk
- Hard: Cheater, cheater pumpkin eater! This mode knows where all your ships are and lands a hit every turn
Two Custom Additions
- Your team must decide upon a new addition to the game.
- Verbal approval from professor is required before moving forward
- The ceiling on scope and difficulty is up to your team, but the professor has the right to increase the difficulty if he/she feel necessary.
- Here are some ideas:
- Special shot (e.g. a limited number of 3x3 giant shots)
- Animations
- Sound effects
- Scoreboards
- Ability to move ships after setup
Grading
Team Score (85%)
This portion of the project will be judged by myself and the TA. The project points are broken down into the following sections.
Demo (30%)
- Demos start Monday October 21st
- Desired Features present (10%)
- Custom additions working (10%)
- Stability (5%)
- You demo the code in class and the TA and myself will stress test your application (even after demo if we see fit). Crashes, memory leaks, or other things that you also hate in bad software will be met with penalty.
- User Interface (5%)
- Your product should be intuitive to use. How you accomplish this is up to you. Good rule to stick by: If I need a manual to use your interface, you have a bad interface.
Modularity (10%)
In short, your code should be:
- object oriented
- easily extensible
- divided into logical components (i.e. not one class that does everything)
Code Documentation (10%)
You must use some kind of documentation format/software, such as JavaDoc from EECS 268, to provide documentation of your code. In short, you need to use some means of documentation that can be used to generate HTML documentation of your code. We should be able to open HTML file to find out all the class information such as method names, signatures, pre and post conditions, etc.
On your github repository, have a folder called "documentation" that contains all the generated documentation, readmes, work cited list, and any other needed documentation.
Works cited section (5%)
This will be it's own section in the documentation. Any code that you or a teammate did not write from scratch, must be cited.
Retrospective Write-up (10%)
This is a single document, probably 3-5 pages
- Log of all meetings
- Date, Location (no specific addresses needed. Something like "coffee shop", "Frank's house", "Google Hangout" would suffice), and list of attending members
- Brief description of meeting outcomes
- Description on how work was split between teammates
- Challenges and how they were overcome or dealt with
- Any features that did not make the demo version
- Retrospective on what the team would have done different
Current Team's Evaluation of your team's Project 1 (20%)
The team taking over your project 1 will get a chance to evaluate your work. The evaluation will be based on the following criteria:
- Documentation
- Code extensibility
- Code stability
- Code readability
As the former project 1 owners, you link the new team your github repo and any documentation. I ask that you do not to provide support beyond giving them your work. If there are special cases (e.g. how to deal with personal credentials) we can deal with them on a case by case basis.
Team Assessment (10% of individual grade)
You will evaluate all of your teammates. You will only share the evaluations with me and our TA. The teammates you're evaluating will not have access to these evaluations.
The score one received for this component is an average of all their teammates evaluations. In other words, your teammates evaluation of you will affect your grade for this project.
Link to team evals coming after code freeze date.
Self evaluations (5% of individual grade)
You will evaluate your own performance on the project. You'll have a chance to list your own struggles and successes and give yourself an overall score.
Link to self evals coming after code freeze date.
FAQ
- How much of the project 1 code do we have to keep?
- You are locked into the language and platform, but you can refactor/fix any problems from project 1
- How much help do we have to give the team taking over our project?
- The documentation and code structure should be all the help you need. Unless of course the old team wrote bad code and poor documentation. (Maybe that's why they were fired?)
- But seriously, no going to the old team for help. Part of project 2 is grading the old team's documentation. Not to mention, in the "real world" you wouldn't call up the poor soul that was just fired and ask for help.
Plagiarism
You can use existing libraries and codebases, but you must cite all sources of code you do not create. This includes the code left over from project 1!
Team table
