Phase One Specification
Objectives
This is stage #1 of the course project. The main concepts covered are:
- software development in a small team setting,
- development of a design for a medium-sized software project, and
- developing a simple, flexible and robust design through
appropriate use of Object Oriented design principles and design patterns.
Description
You
have been employed by a small game manufacturer named KnowSys. This
company has more programming talent than game-creation talent. Its developers
create knock off versions of popular games, both board games and
on-line games. Since the games this company develops cannot be exactly
the same as the games on which they're based, the games produced are
always extended and changed in interesting ways (from a programming perspective).
You have been assigned to a development team whose task is to
design an on-line game similar to an on-line game called Bookworm.
The on-line game can be found at www.popcap.com
Description of pieces used to play
The game is played on a 7x7 grid (for this phase) that consists of
random letters.
Preparing to play
The letters are randomized in the game grid
How to play
The player must search for a word in the grid where
the letters are connected horizontally, vertically, or diagonally.
The word must be at least three letters in length. When the word is
entered, the tiles used to make up the word are scored, and then
removed from the board. All tiles above the removed tiles will move
down to fill in the empty spaces. New, random tiles will fill in from
the top.
Scoring
The first tile in each word is worth two points. Each successive
tile is worth 2X the preceeding tile. So, for a three letter word,
the base score would be 2+4+8 = 14 points. For a four letter word,
the base score would be 2+4+8+16 = 30 points, and so on. Since some
letters are more difficult to use than others, each tile may also have
a bonus point value. The bonus points are assigned as follows :
B, D, M, N, R, T, U are worth 5 extra points each, F, H V, W, Y are
worth 10 extra points each, and J, X, and Z are worth 15 extra points
each.
Stage 1 requirements
Please read the following requirements
carefully! While the final game
will require more functionality, the customer expects the following in the
first release.
Functionality
The following functionality must be present in the
system. Note that a graphical user
interface is NOT desired at this point.
A text-based user interface must be provided instead.
- A random 7x7 grid of letters must be generated. For the purposes
of phase one, we can assume that each grid square is equally likely to
be any of the letters in the alphabet, that is, it is a random(26) to determine
which letter shows up in each slot of the grid.
- The game must have a timer. When the game starts, the player will
have one minute to enter each word. If a word is not entered within
one minute, the game will be over.
- Each word must be checked to see if it exists on the board. If it
does not, an error message should be generated to that effect.
- Each word must be checked against a dictionary for
validity as it is entered. The dictionary will be provided to you.
If it is valid, it must be scored,
and the score added to the total, and the tiles removed from the
board and replaced. If it is not valid, an error message should be
generated to that effect.
- Each time the score reaches an increment of 1000 points, the game
will proceed to a new level. Once a new level is reached, all tiles
are replaced with a new random set.
- Entering the command "S" will shuffle the placement of
the tiles randomly.
- Entering the command "Q" will quit the game.
- Entering the command "N" will start a new game.
- Entering the command "H" will display a help screen.
- The score must be displayed on the screen at all times
You should implement all of the functionality
described above for your first submission.
If your team decides that there is too much functionality to reasonably
complete in the amount of time you have, you must consult with your customer
(me). You must present to me (in
writing) your time estimates for the various required pieces of functionality together
with a suggested scope; I will determine an acceptable scope. Grade implications of the reduced
functionality, if any, will be discussed at this time. A team may request a reduction in the
scope of their submission in this manner only once during this first release
cycle.
Package naming
Your code must be placed in packages as appropriate.
None of your code may be in the default package. Your packages must be named “edu.buffalo.cse.teamX.???”, where X is the number of your team and ??? is the name of the
package. You must at a minimum have
one package for your code.
Documentation
You must document every class and every class member
using Javadoc documentation comments. See the Javadoc Tool Home Page
for more information. See in particular the page How to
Write Doc Comments for Javadoc and javadoc
- The Java API Documentation Generator. The javadoc comments must
be submitted along with the project.
Technical guide
You must submit a technical guide which
describes the design of your project, testing that you have done, any required
functionality which your project does not implement or does not implement
properly, etc. The technical guide
must be either a PDF or a Word document.
Teams
Teamwork guidelines
It is important that there is a roughly equal
division of labor amongst teammates. It is unacceptable for one person to be
expected to do most of the work. Given the structure of the program it is also
most unlikely that this person will successfully complete the project.
Teammates who are not doing work will receive a grade of 0 for the project.
If you are having trouble with an unmotivated group
member you should seek to solve the problem at the group level first. If this
does not work, you may seek the aid of the instructor. However, be warned that
when seeking the instructor's aid we will verify the teamwork points given to
the individual. Bottom line is that if that person had previously been given
good reviews, no action will be taken.
Team peer-evaluation mechanism
The project submission for a team is graded as a
whole, but each team member receives an individual grade which is based on that
submission grade. The procedure for calculating individual grades is described
below. The procedure is based on an assessment of each team member's
contribution to the overall project submission. To assess individual member's
contributions we will use a peer-based evaluation mechanism.
Here's how it works. Each person is given 10 points per group member to award.
For example, for a team of five, each team member has 50 points to divide
amongst all the team members, including themselves. A team member may award a
maximum of 15 points to any one person, and a minimum of 5 points to
any one person. If you feel that the person is performing at a level
that merits less than five points, it needs to be adressed outside of
the peer evaluation mechanism. Talk to me about the team member.
Points should be awarded to team members as an
indication of your perception of how much work they did relative to others on
the team. If you feel everyone did about the same amount of work you should
award everyone 10 points. This is the ideal outcome.
Notice that you evaluate your own contribution. Notice
also that you must award all of the points you have available to you. Finally,
be aware that the peer evaluations are submitted individually and are
confidential – your teammates will NOT know how you rated them.
After we get all of the peer evaluations we will
calculate the average of the points allotted to each team member.
Your individual grade project will be your average
score multiplied by the overall project score, divided by 10.
Example
Consider a group made up of Cindy, Peter, Sally and
Ulrik. As usual Sally does a fantastic job, Cindy and Ulrik do a moderate job
but Peter didn't do much of anything. The table below shows the points that
each team member awarded to the others.
|
|
Sally awards
|
Cindy awards
|
Ulrik awards
|
Peter awards
|
average
|
|
Points awarded
to Sally -->
|
12
|
15
|
15
|
14
|
(12+15+15+14)/4 =
56/4 = 14
|
|
Points awarded
to Cindy -->
|
11
|
10
|
9
|
6
|
(11+10+9+6)/4 =
36/4 = 9
|
|
Points awarded
to Ulrik -->
|
11
|
9
|
10
|
6
|
(11+9+10+6)/4 =
36/4 = 9
|
|
Points awarded
to Peter -->
|
6
|
6
|
6
|
14
|
(6+6+6+14)/4 = 32/4
= 8
|
Sally's average score is 14. Cindy and Ulrik each
have an average score of 9. Peter trails the pack with an average score of only
8.
If this team's project submission received 80% overall,
then Sally would get 112% (!), Cindy and Ulrik would each get 72%, but Peter
would get only 64%. Since Peter’s scores were so unbalanced we would look
carefully at the documentation in the code to see what each of the team members
contributed, and based on this we might adjust (either up or down) the score of
any individual; the team as a whole would likely be called in for a meeting to
find out what is happening with the team.
In extreme cases I reserve the right to ignore the
peer evaluations and grade students based on their documented contribution to
the project.
Submission
The submission deadline is on or before 6:59.59 PM
on Wednesday, June 15, 2005.
Last modified: Mon Sep 12 14:52:46 Eastern Daylight Time 2005