CPE 305 Project 3 Requirements


Create a "framework" for graphical solitaire games like the ones we made in the previous projects.  Read the Horstmann chapter on Frameworks.
The idea is to build the graphical framework that could work for any board games that have similar characteristics to the one's we've created.  Third-party developers could create extensions or "plugins" for this framework that provide the game logic for a specific game.  Students will demonstrate their Framework by creating a plugin for Minesweeper, Mahjongg, or Collapse AND a different game of their choice. Recall Bloch's advice that we write several plugins to help us assess the soundness of our API (Item 17).

What these games have in common is a grid-based playing board, a panel of control buttons, and a status or message panel. 

It may be helpful if I distinguished an application which is "configurable" from a framework with plugins. A configurable application can change the static elements via data files, property files, preference files, configuration files, or other runtime settings. For example, you can change the map or levels in a game, the colors or images, the qualities of characters, or the size of a board. However, this is not a plugin. A plugin has LOGIC. It alters the BEHAVIOR of the game, not just its appearance. For example, in a Solitaire Framework, a plugin provides different game rules for different solitaire games.

Framework Design

The main class is GridGameLoader who dynamically loads the plugin and initializes all the other components.
GridGUI will manage the placement of buttons, status panel, and the board.
GridGUI will create a grayscale background image from the background specified.
GridGUI will display the board and status panel.
GridGUI is very "thin". All of the event handling is really processed by other classes. (except the display high scores event).
The other elements of the framework are Interfaces and Abstract Classes that define the required components of a plugin.  (There may be concrete helper classes also, e.g. Preferences).

Creating a plugin

Each game ("plugin") will provide:
Each plugin is identified to the framework by a unique string identifier, for example "Hangman".  All the classes the plugin provides must begin with this identifier (E.g., HangmanBoard, HangmanGame, etc.).

For each Button, the plugin specifies the label and the associated behavior. Buttons may be invisible in which case they are invoked via the key shortcut (E.g, "Alt-A" for "About").  (A plugin could have no buttons).

You must create a folder with the name of the plugin to store the resources the plugin needs:
In tree format, the directory hierarchy is:
GridGameProject (directory)

+ GridGameLoader (main class)
   + +libs (directory)
   |    + ini4j.jar

+ gridgames (directory)

| + Grid*.class
   + hangman (directory)
        + Hangman*.class
        + Backgrounds (directory)
        |     + bkgd.jpg
        + PieceImages (directory)
        |     + *.jpg

        + HighScores.txt

        + preferences.ini


Alternative Game Genre

Create a framework for some other style of games, e.g. card games, not grid games.  Student submits a one-page written proposal by Feb 5 describing the genre and two example games.  The description must be clear enough to enable the instructor to invent a new game that would work in your framework.


Pluggable User Interface (extra credit).
Decouple the GUI from the game and demonstrate by having at least two different UI's for the same game. The user selects which UI from a dynamic list created at runtime.  Students may select from:

Testing

You should be able to write a JUnit test that exercises the entire game logic without any user interface code written. (This is called an integration test). Essentially it should be a driver that plays a complete game.

Assessment

30% system test
50% design (Instructor assessment of design quality and student's written design rationale).
20% lab demo

Version 1 Demo (Fri Feb 26)

Students submit their source code via handin before the due date. In lab after the due date, instructor will give you source code for a new & different game.
You have one hour to modify the source code to create a plugin that works with your game. Ideally, you need to change only the names of the methods to match your framework Interfaces. Perhaps change the order of parameters, etc. Submit only the classes you changed to the lab folder handin.
The best submission will require NO changes to their original code at all. It's a 100% runtime plugin. A good solution will require only changes to the Loader class (that holds the main method). We might even mitigate that by coding a "placeholder" during development for the anticipated lab plugin. A poor solution requires changes to game logic classes.

For students developing alternate genre games, the instructor may not have actual code for the plugin, but just the game rules.  In this case, the student will have 24 hours to complete the exercise.

Update: 2/24
Hard Code Plugin Name:  OddEven

You may bring a notebook computer.

Instructor will provide the source code for the OddEven plugin.
You alter it to work with your framework,
and submit the finished source code.

Checklist of features provided, ranked.

Grading

This project combines projects 3 and 4 listed in the syllabus. It's worth 20 points.


Feb 26

10
Text (strings) in the grid, no graphic images.
Create a plugin for Minesweeper, Mahjongg, or Collapse.
Create your own plugin game (grid-style)
Hard-coded plugin names in Loader.
Mar 12
2
graphic images
Mar 12
2
text styles
Mar 12 3
Plugins loaded via dynamic extension (not hard coded)
Mar 12 5
Alternate game genre (not grid-style)
Mar 12 5
Pluggable User Interface (build at least two)

Notice, the total is 25 points, so you can earn 5 points extra credit.

There are two due dates.  Version 1 is due Feb 26 for the lab activity.  Version 2 is due Mar 12 and includes design rationale and class demo.

Version 1 that you use for the lab activity may be a text version of your framework without graphic images.  After the demo you may continue working on your project to add more features  (Version 2).


Design Rationale

A Design Rationale is a discussion of the reasons behind decisions made when designing a system. (Wikipedia article). There are many tradeoffs in design, a few of which we discussed in class. Describe the key design issues raised in your project, what decisions (or tradeoffs) you made, and your rationale. This section may be 3 pages or longer.  Examples of Design Issues

Recommended Format

Issue #N: Describe the issue in a sentence. State it as a question or a tradeoff. For example,
"Should units be in meters or feet?"
"Should the application be portable to mobile devices?"
"Should we provide a way to customize the date output format?"
"Should we use a drop down menu or check boxes to select desired timezone?"
"Should quacking be in a separate Interface or part of the Duck class?"
"Should we use Natural for the score since it's never negative?"
Alternative A: Brief description of the solution
    Advantages:  list advantage of this solution.
    Disadvantages: list drawbacks of this solution.
Alternative B: Brief description of the solution
    Advantages:  list advantage of this solution.
    Disadvantages: list drawbacks of this solution.
(Repeat for all alternatives you considered).
Decision:  Explain which alternative you chose and give your rationale. You need to justify your choice, and why it is superior to the other alternatives. Don't just simply restate it's advantages.

Part 1 Assignment Submission - Due Thur 2/25 9:00pm

  1. Make sure your source code compiles with no errors.   For part 1 it does not have to pass CheckStyle. For part 1 you do not need to print your source code.
  2. Use handin to submit your source code electronically (see below).
  3. The instructor will be testing your submission using BlueJ, so be sure the proper directory structure and project files are included.
  4. Create a brief set of instructions for running your submission.  It needs to include the exact syntax for running the program with your plugins.  It needs to explain the directions for playing the game that you invented for a new plugin.
  5. Create a "known issues" list: Indicate any defects, unimplemented features, missing requirements, outstanding problems, or other issues that you are aware of in your submission.  If there are no issues that you know of,  indicate "No known issues."
  6. Submit typed responses to #4 & #5 to the table in front of the classroom at the next class meeting after the due date.  This must be submitted on time or your will lose the 10 points for this part of the project.
Handing in Your Source Code Electronically
       handin  graderjd  Project3A  Project3A.zip
      


Part 2 Assignment Submission - Due Thur 3/11 9:00pm

  1. Make sure your source code compiles with no errors.   It must pass CheckStyle. (You're allowed 5 violations per 1000 lines of code.)  You do not need to print your source code.
  2. Use handin to submit your source code electronically (see below).
  3. The instructor will be testing your submission using BlueJ, so be sure the proper directory structure and project files are included.  Be sure BlueJ generates the javadoc properly for your source code.
Handing in Your Source Code Electronically
       handin  graderjd  Project3B  Project3B.zip

Project Report
  1. Cover Page:  Project Title (e.g., "Grid Game Framework"), Course and section, Name, Date.
  2. Indicate which features you included: graphic images, text styles, dynamic extension, or pluggable user interface.
  3. Create a "known issues" list: Indicate any defects, unimplemented features, missing requirements, outstanding problems, or other issues that you are aware of in your submission.  If there are no issues that you know of,  indicate "No known issues."
  4. Create a brief set of instructions for running your submission.  It needs to include the exact syntax for running the program with your plugins.  It needs to explain the directions for playing the game that you invented for a new plugin.  Explain how to operate all user interfaces you provided (e.g, Swing AND console).
  5. Design Rationale (as described above).
  6. Submit your typed report to the table in front of the classroom at the next class meeting after the due date.  This must be submitted on time or your will lose the points for this part of the project.