Stage 3

Groups: Locate your group assignments here. They are unchanged unless you received an email from me.

Submission: Each group must submit one JAR with their implementation, named Stage3GroupX.jar where X corresponds to the letter assigned to each group. Each submission must include the JUnit tests that you created for your implementation as well as the actual Java source code for your implementation.

Your submission should also include a README file indicating what functionality was implemented for this stage and what functionality does not correctly work.

Each group is also required to send a weekly email to me (CC'd to the rest of the group) about the progress for the week. Each week, the secretary of the group should change. These emails will impact your grade.

For this stage, your group is required to submit a UML diagram, created using Green for the implementation for this stage of the project.

All files must be commented using Javadoc style.

Due: Friday, December 8th at 11:59:59pm.

You must also complete a peer evaluation as described in this document and submit it by 11:59:59pm on Friday, December 8th. Your peer evaluation at this stage should be in a file named Stage3Peer.txt. In this stage's peer evaluations, I would also like you to include a few sentences about how you feel you grew as a programmer in this past semester. What lessons did you learn? Did you feel you advanced your skills throughout the course of the semester?

Assignment

You will continue the implementation a modified version of a game called Lingo. For this stage, you will be doing some last minute cleanup on functionality, introducing a way for the game to check if the word entered was valid, and creating a computer player to play against.

You must pick one of the group's submissions from the LectureCode repository. If your submission was put into the repository, you can select your own, but you will need to implement the additional functionality mentioned below. See notes on candidate submissions below.

Graphical User Interface Cleanup & Game Play Cleanup

You should make sure the following is implemented in your graphical user interface:

The first letter of the word should appear in the first box while the user is guessing. The user should not have to type in the first letter of the guess each time.

Hitting enter at the end of the word should submit it. If there is a button to do the same, that is fine, but hitting Enter should perform the same functionality as that button.

The game should provide a way for the player to "undo" a letter that they have already typed. This undo functionality should be represented graphically on the game (menu or button) and take away the last letter the player typed from the screen. You should use a Stack to implement this functionality. There should also be a keyboard shortcut to this functionality as well (Backspace strongly recommended).

There should be a way for the user to "Start over" at any time during the game or at the end of the game. This is probably best achieved through a button or menu item.

Make sure that the following does not happen while the user is playing the game:

Word the user is supposed to guess: snuffy

User types: snoops

The second s should not be indicated as part of the word because it is not. The first s is in the correct place and there is not another s in the word.

Get a new dictionary

I think everyone will agree that the dictionary file has to go. Here's your chance to make that happen. Find another dictionary file from somewhere. Either eliminate words from enable1.txt or go out to the web and find another dictionary file that will perhaps give someone a chance at winning the game. You should indicate in your README file for this stage how you got the new dictionary and from where.

Let's Give AI a Trie!

You will need to create a Trie to hold the words in the dictionary. You will use this trie in two ways in this stage.

First, it will be a way for the game to check if the user has entered a valid or invalid word as a guess. If the user enters an invalid word, they must be notified and they lose an additional guess. That means, if the player enters an invalid word on the first guess of four, they only have two guesses remaining to try to guess the word.

Second, it will be a way for you to implement a computer player for lonely, bored, crazy, or extremely advanced Lingo players to play against. The user should be given a choice at the beginning of the game for two human players or human vs. computer. One of the tricks of creating a good computer player is to not make it too smart. It should fail at times and succeed at times.

Bonus points: Make three levels of "smartness" for your computer player and have the user select how smart the computer should be.

So you want your own Stage 2, eh?

No problem, in order to earn 100% on this stage of the project, you will need to implement all the previous functionality, plus the following functionality if you choose your own code base from the repository.

You must compare and contrast your code base for Stage 2 with all of the other code bases in the repository. Since there are five other code bases, you must devote a section of the paper to each of them explaining the following:

Pros of the other submission

In what specific ways was their implemenation of certain functionality superior to yours. There should be at least one place where their solution to a particular problem was better than your solution.
In what specific ways was their GUI superior to yours. This includes both the look-and-feel of the GUI as well as its intuitiveness while playing the game. Were the prompts and messages reasonable and helpful?
What merits did the design of their system have?
Good points about their documentation and README file.

Cons of the other submission

Any problems with the functionality of their codebase that you could find (i.e. functionality that did not work as supposed to).
GUI problems with look-and-feel or usability. Was their interface hard to use?
Where did you see design flaws in their system?
Bad points about their documentation and README file.

The above are just guidelines to help you in your writing. You can expand on these ideas or add your own thoughts to the critiques. Pretend this is a product that you are being asked to evaluate to ship to customers, what would you say about it - good and bad.

I expect this paper to be extensive. To indicate to me that you actually looked at the code of the other team, you will probably need at least 5 double-spaced pages per submission to address both good and bad points about that submission. Please create a Word document and include it in your project when you submit your Stage 3.

Notes about Candidate submissions

Candidate C's has quite a large number of graphics and other files. The project itself is quite large - be forewarned before you check it out from the repository.

Candidate F's letters do not come up inside the boxes. This should be fixed before the next stage to look like the other groups. If you use this submission, you need to fix this or points will be deducted from the third stage grade.

Extra Credit

This extra credit is available to all teams, but be fore-warned it is truly extra credit. No support for completing this functionality will be given in class or in recitation. It is an opportunity for you to research something new and implement it in your game.

You can choose to make a networked version of Lingo where two players can compete in geographically disperate locations. The networked capability should only be available for two human players, not a human and AI player. You can research RMI (which is provided by Java), or using sockets for networked capabilities. The choice is yours, but take note that your extra credit will not be graded if you stage 3 functionality is not complete.