In this final assignment we combine our knowledge of files, collections, graphics, and everything else to create modules making up a fun word game...
All files (coming soon...)
Boggle
Boggle is a word game a bit like Scrabble. Given a set of
letters, players find valid words among them. In our version,
only one
person at a time plays the game, racing against the clock to score as
many points as possible. Longer words earn more points than
shorter words. The letters come from a grid, and the
words have to be spelled by letters that are adjacent on the
grid. Consecutive letters can be adjacent horizontally,
vertically, or diagonally. A letter square can be used in more
than one word. Full
rules for the commerical Parker Brothers game, along with
illustrations, can be found on a Boggle web
site. Some of the rules would be quite difficult to implement (like the one allowing plurals of nouns), but your game should do as job a job as is practical at sticking to the rules as described. However, you don't need to attempt any part of the game that involves multiple players.
The design of the game program has been divided into three parts or "modules", a Model, and View, and a Controller. Each team of students will implement one or more versions of each of the modules. For added zest, a full game can be formed by mixing and matching modules from different teams! Mostly this will happen in the second week of the project, but the design has to be carefully followed from the start to make it possible. There will be some limitations on what you can do and how your classes are packaged to make the Mix 'n Match possible.
Your Task
Implement versions of each of the game modules. Each module is defined by a particular Java interface.Implementations can be "shallow" or "deep". A shallow implementation is somewhat better than a mere stub. The methods in it return reasonable values so that other modules can be tested with it, but don't have to be fully functional or elaborate. A "deep" implementation is a full, working version which may be quite elaborate. During the first week you should implement shallow versions of any two of the modules, and a deep version of the third module. During the second week you should implement deep versions of all modules, and will be able to revise your original deep module, too.
The final application should have View with a graphical user interface in a frame. The grid will show the letters available to form words. The frame will show the game status information, such as whether a game is currently in progress, how much time remains, the score, etc. Information about the modules (authors, etc.) will be available.
Here are brief descriptions of the modules. More information can be found by browsing the Java interfaces. Also, as the project progresses, you will gradually see better how the pieces have to fit together.
Controller: The Controller handles primary interaction with the system and the user. The main method is part of the Controller. The Controller has references to the other modules. It may get information from the playerr (user) and pass it to the appropriate module. When the program starts, the Controller is in overall control of the session. A user can play as many games as desired without restarting the application. For each game, the Controller sets things in motion. This includes tasks such as reinitializing the score, making sure the game grid is renewed, starting a timer, etc. When the time runs out, the Controller ends that game, but the session remains active in case the user wants to play again.
Model: The Model contains the data which makes up the game. For example, the Model knows what letters are on the grid and where. It can tell if a proposed string is valid or invalid. Normally, the Model should do this with reference to a "dictionary". The dictionary is a file or other source of valid words. The Model also knows how to assign a score to each word, based on various rules it knows. Finally, the Model knows what the score of the game is at any given time.
View: The View is responsible for displaying the game to the user. For example, it determines how the grid should look (color, size, placement, etc). It paints the letters on the grid but does not determine what those letters should be. The View gets information about the game from the Model. The View might also interact with the Controller when user interaction is required. (In many applications, it is difficult to make a clean separation between the View and the Controller. For Boggle, the interfaces generally define which module is responsible for different aspects of the game).
Supplied files
There are three major interfaces that must be implemented, one each for the Model, View, and Controller. There will other classes and interfaces available eventually, mostly as examples or suggestions for implementation. Some data files (like word lists) may be posted, too.You will notice that the files, including some that you have to create, are spread out over at least four packages. It will be quite important to have each file in the proper package, as the Mix and Match tool depends on that.
Written reports
In addition to the programs, please prepare these materials:1. A written report along the usual lines, prepared by you and your partner together.
2. A diagram showing the relationships of all the classes used in the project (whether your own code, supplied code, but NOT libraries this time)
3. A description of how your game differs (in the rules, etc, not in how it looks) from the official version.
4. Screen snapshots (specified later)
5. A confidential, printed report, one per person, which describes the extent and nature of your own contributions to the project (second week only).
Getting Started
1. Think of a short nickname for your team. This will be necessary for other teams to identify the authors of the classes they are working with.2. Look at the Boggle web site. Play a couple of practice games with your partner. You don't need elaborate equipment for this. Just draw a square with letters on it.
3. Browse through all of the supplied code.
4. Write absolutely minimal stubs for all the modules. This will help you see how the parts should fit together. Once everything is compiling and executing, expand a few of the stub methods slightly to try to get something that feels like a game, even if much of it is missing. For example, the initial view doesn't have to be graphical. You could print all the information on the console! The model might accept all words as valid, and might keep the score at 0. Perhaps initially, all the letters on the grid would be the same, etc.
5. Once you have reasonable shallow implementations for all the modules, pick one to concentrate on for the first deep implementation.
Second week activities and beyond
After the first turn-in has past, all of the modules will be posted and available for mix and match testing with each another. There will be a special tool to facilitate this (one of the reasons why the set-up is complicated, and why we are keeping our fingers crossed that nothing goes wrong).After the second turn in, each team will meet with a TA to demonstrate the game int person. This demo will contribute heavily to the project grading. There will be a sign-up for demo appointments. Both partners must show up, on time, or the project will not be graded. At the demo, each team will show its three components running together, and will also have to show that any one of their modules can run well with modules from any other teams. More later about these appointments and how to prepare for them.
Turn in (by 8/5 at 9:00pm, one per team):
- Shallow versions of two modules, and a deep version of the
third. The turn-in form will have separate areas to facilitate
this.
- A short written report (not a full final report), stating
mainly what modules are being turned in, and giving any instructions
needed for running or interpreting the program. State briefly
how what is turned in now differs from what you plan to complete by the
end of the program.
Turn in (by 8/12 at 9:00pm, one per team):
- Deep versions of all three modules (including the one which you
turned in as deep the week before -- it is fine to make a revised
version of it).
- Turn in any paperwork (written reports, screen snapshots, etc.) in class on the day following the electronic turn-in. Include three screen snapshots. One should show your program (all three of your own modules) just after the program starts, before a game is in program. One should show your program with a game in program, at a point where at least one word has been correctly selected. One should show the same situation as just mentioned, but this time with someone else's view (your Controller and Model). Make sure your names are on each piece of paper and staple everything together (except the individual reports, which should be handled separately and folded for confidentiality).