Assignment X - Game Project

Objective

Task

Details

1. You may choose from a variety of board games or 1-player solo games listed here. Each of these has been deemed at an appropriate level for this project.
    
2. The minimum requirement is to write a game with a graphic interface as a Java application, which can be played by 1 or more human players on the computer. It should have an intuitive and usable interface, and it should implement the standard set of rules for your chosen game. In the event that you have a game with some rule variations, you should include information in your README file (described below) that clarifies what version of the rules you are implementing.
    
3. General Guidelines for Grading: Since you have the freedom to implement the design, grading for this project will be somewhat subjective. However, here are some guidelines I will be using:
   • Programs will be judged on 3 primary factors -- Correct rules implementation, user interface (GUI), and class/code design
      
     
   • To qualify for an A: Rules of game implemented correctly, playable game, well-designed GUI interface that is intuitive for the user, program fairly robust (erroneous inputs handled, for instance), well-designed object-oriented code. At least one extra feature, that goes beyond the basic game rules (Examples: multiple versions of rules implemented, a save-game feature, etc. If you're not sure whether a certain feature would satisfy this, ask).
      
   • To qualify for a B: Rules of game implemented mostly correctly (perhaps a few flaws, but fixable), usable GUI, playable game, reasonably good code design.
      
   • To qualify for a C: The main aspects of gameplay implemented correctly, so that the game is more or less playable, even if there are some flaws or other rules that didn't get implemented. Some sort of GUI (even if rough around the edges, and not as user-friendly).
      
   • Due to the fact that some games are harder to implement than others, the level of difficulty of implementing a game will factor in as well when judging rules implementations. (For example, Risk has more complicated rules and gameplay than Yahztee).
      
   • Roughly, the grading breakdown is:
     • Rules implementation / gameplay -- 30%
     • User interface (GUI) -- 30%
     • class/code design -- 30%
     • Some extra feature(s), beyond normal game rules -- 10%
     
     
   • Notes on these breakdown items:
     • Rules
       Your game needs to adhere to the standard set of rules for the chosen game. Make sure to provide in your README file any rule variations you may be implementing.
     • User interface
       This will be judged on the overall user experience / user friendliness. Strive for intuitive and appropriate GUI controls. Avoid redundancy (extra clicks just for the sake of having extra controls, buttons, etc). Also strive for a more attractive and clean-looking interface that an average person would WANT to use.
       Also, make sure your game runs on a reasonable screen/window size (like a standard desktop or laptop screen). I should not have to hook up 2 monitors in parallel or one stacked on top of the other to view your game!
     • Code design
       Code design will be judged on appropriateness of object-oriented design, modifiability, readability, easiness to debug. Avoid brute-force copy/paste style coding -- this leads to tedious code that is hard to read, modify, and debug. (When designing a game like this, you want to have code that would make it easy to add new features in the next version, for example).
   
    
4. Guidelines for researching resources
   • As we've been primarily using Java SE 22 in this class (it's the one installed on linprog), make sure your code compiles and runs with the Java 22 SDK (Standard Dev Kit). Don't use features that are ONLY in JDK 23, as that came out during this semester.
   • You may use any of the Java libraries in the JavaSE (standard edition) API
   • It would probably be a good idea to look at many other GUI examples (including the ones we've done in class) and look at the tutorials on the java.sun web site (now on oracle), to help you find other techniques and tips for implementing graphic interfaces with event handling
   • If you find a resource that gives you some ideas -- and especially if you model a portion of your code after another example -- be sure to cite your source in your documentation
   • The coding, however, must be yours! You are to implement your own game logic (i.e. you may not just find an existing implementation of a game and use code found on web searches).
   • Any actual Java code in your program needs to be generated by you (and not auto-generated, for example, by NetBeans or some other IDE).
   • You may use icons, graphics pictures, sounds, etc that you find online. If and when possible, cite your source, and be sure to pay attention to any copyright notices regarding such resources. (Example: If you choose a solitaire card game, it would be a good idea to find image files of cards, for a nicer interface -- it's best to find public domain images for this sort of thing). If choosing a word game, I recommend looking for a standard dictionary file online.
   
    
5. Extra Credit Opportunities -- I'm leaving this wide open. There will be plenty of chances to earn extra credit on this assignment. Anything above and beyond the minimum requirements can be done for extra credit. Be sure to list anything extra you do in your README file, so I know to look for it. Here are just a few possible things you could try, just to give you some ideas (but certainly not limited to these):
   • Save/Open feature, for saving games in progress
   • For a game with rule variations, implement the ability to play using one or more of the variations (or a menu to choose rule settings, if appropriate).
   • More creative and fun visual layouts, possibly incorporating graphics, sounds, animations, etc.
   
    

Resources

• Core download page for the Java SDK
• "The Really Bix Index" of java tutorials - links to tons of tutorials on the java.sun web site.

Deliverables:

• All necessary .class files and resource files that make your program work
• All source code files (.java files) for your program
• A README file (this can be in text format or in html format) that contains any extra documentation for your project. This should include
  • Any details regarding instructions for the game that are not obvious from the set of standard known instructions
  • A description of how to use the interface
  • Any other important details about your implementation, how to run the program, etc
  • Any important details about extras needed to compile your code when unpacked
  • Descriptions of any extra features implemented

  java -jar hwx.jar

If you are working with a partner, each of you should keep an individual log of your own contributions to the project.

Submit your assignment via the Canvas submission links.
If working with a partner, only ONE student in the group needs include the jar file at their Canvas submission link (but do make sure both names of group members are included in your submission's README file). However each partner should individually submit their own log file of contributions/work performed to their own Canvas submission link.
Example:

• Student 1 attaches their log file and the jar archive to their Canvas submission link
• Student 2 submits just their log file at their own Canvas submission link