This is stage #3 of the course project. The main concepts covered are:
Now that the GUI has been developed, the honchos and KnowSys want
to add some more complex rules to the game to make it more fun to
play. These will make it more fun to program, too, of course.
The following functionality must be present in the
system.
The Graphical User Interface
In this phase, we will be enhancing several aspects of the GUI.
The main components that will be added/enhanced are :
-
Drag select : in addition to clicking on letters in the grid to
specify the word being entered, the user should be able to click and
drag the mouse across the letters of the word in order. Each new
letter should be marked as the mouse enters the letter. If the user
drags to select a word, then releasing the mouse button at the end
of the drag motion should submit the word. Clicking and double
clicking, or clicking and hitting the submit button should still
also work.
-
Indicator arrows : As letters are selected for a word, arrows should
be drawn that indicate the order that they are selected in. These
arrows should point from one box to the next in order that they were
selected. Ideally, they will span between boxes, but it is
acceptable if the arrows are entirely within the letter box. The
arrows will disappear when a word is submitted, or discarded by
right clicking or starting a word somewhere else.
-
Splash screen : When the game is stared, a splash screen that has
some cool graphic should appear while the game is loading, and stay
displayed in the middle of the screen for 3 seconds.
Preparing to play
Letter selection : in order to make the game more interesting, the
selection of letters will no longer be completely random. The random
letter selection algorithm will be biased towards letters that are
more useful in forming words. When a new " random " word is
generated, there is a 30 percent chance that it will be a vowel.
There is a 20 percent chance it will be in the group B, D, M, N, R, T,
U. There is a 20 Percent chance it will be in the group F, H V, W, Y,
J, X, Z. There is a 30 Percent chance that it will be any other letter.
How to play
Method of play remains unchanged from phase 2.
Scoring
The scoring mechanism will remain the same as in phase one, with the
following changes :
-
Bonus word : at the start of the game, you must randomly select a
three letter word from the dictionary. This will be the bonus
word. The bonus word must be displayed on the screen at all times.
If the user completes the bonus word, then they should get 500 bonus
points, and a new random bonus word should be chosen and displayed.
-
Time bonus : if a word is entered in under 10 seconds, a 10 point
time bonus will be added to the total score for that word.
Other functionality
Red tiles : Now, instead of ending the game, when the timer runs
out a "red tile" will be added to the top of one of the
columns (at random). The red tiles behave as follows : each time a
word is entered, or each time the timer runs out, all red tiles on the
board will move one spot downwards in the column, destroying whatever
letter is beneath them (and a new random tile will be added to the top
of the column). If a red tile touches the bottom of the column, the
game is over.
Red tiles can also be created by making small words. If a word is
only 3 letters long, there is a 2 percent chance at level 1,
increasing by 2 percent at each level, that a red tile will be created.
Help screens : At the start of the game, and whenever a new element
(bonus tile, bonus word, red tile, new level) is introduced, a popup
(or overlay) should tell the player about that new element. The popup
or overlay should also allow the user to disable these hints.
The game should pause if the mouse leaves the game screen. While
paused, the timer should stop, and no input should be allowed. A
dialog should pop up saying that the game is paused, with a button to
click to continue. The game should unpause when the button is clicked.
The game should also pause if the escape key is hit.
The high scores should now be stored for all scores. After
each game, the player should be prompted for their initials, and after
they enter them, they will be taken to the list of high scores, with
their current score selected and viewable. Each score should display
the rank (posiion) in the list, the initials, and the score. Each one of their scores
(determined by initials) should be displayed in a different color than
the other elements in the list. There should also be a new menu entry
labelled "Reset High Scores" that will wipe out the high
score list.
Bonus round : Every five levels, the game should have a bonus round.
A dialog will pop up explaining that this is a bonus round, and how
the bonus round works. The user will be presented with a new screen,
and the timer will count down 2 minutes. The user will have those 2
minutes to enter as many words as possible. All words in the bonus
round are worth 10 times their normal score, including all bonuses.
After the bonus round, it should display the longest and highest point
words just as with a regular round. Note that the normal timer and
red tiles should not be present in the bonus round.
Extra Credit
Animation
For those feeling brave, there is an extra credit opportunity. You
can get an extra 5% extra credit if the tile movement when the red
tiles advance, and when new tiles come in, is animated so that the
tiles "slide" down into their new positions.
You should implement all of the functionality
described above for your second 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 second 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 12:59.59 PM
on Friday, December 9, 2005.
Last modified: Mon Nov 14 10:06:14 Eastern Standard Time 2005