CMSC 335 Summer 2016 Projects

Sorcerer's Cave Strategy - Notes

By Nicholas Duchon


Cave Project


I should point out that a missing readme file (approach/design/test plan documentation, say docx or odt format) will result in losing 60 points. Normally I would just return such a project ungraded and ask for a resubmission with the missing file.

Problem domains and objectives

The project is designed to exercise the following technologies:

  1. Date from test file(s), stored internally as instances using ArrayList class.
  2. Same using Map class.
  3. Adding JTable and JTree.
  4. Adding client/server model and threads.


For all projects, the grading and deliverables are as follows:

  1. Java source code files
  2. any configuration files used
  3. a well-written Word document describing:
    1. your overall design, including a UML class diagram showing the type of the class relationships
    2. description of how to set up your application
    3. your test plan, including test data and results, with screen snapshots of each of your test cases
    4. your approach, lessons learned, design strengths and limitations, and suggestions for future improvement and alternative approaches

Your project is due by midnight, EST, on the date posted in the class schedule. Your instructor's policy on late projects applies to this project.

Submitted projects that show evidence of plagiarism will be handled in accordance with UMUC Policy 150.25 — Academic Dishonesty and Plagiarism. 

Format - ND: I really don't care about this - make the document easy to read and comprehensive, and don't waste paper.

Documentation format and length. The documentation describing and reflecting on your design and approach should be written using Microsoft Word, and should be no more than five pages in length and no less than two pages. The font size should be 12 point. The page margins should be one inch. The paragraphs should be double spaced. All figures, tables, equations, and references should be properly labeled and formatted using APA style.


This activity is awarded 15% for projects 1, 2 and 3, 20% for project 4 of the total grade in the course. In the grade book, the total number of points will be set to 100. The project elements will be assessed as follows:

Attributes Value
Project design 20 points
Project functionality 40 points
Test data 20 points
Approach documentation 15 points
Approach documentation grammar and spelling 5 points
Total 100 points


The main problem with rubrics in this class is that the projects are complicated and there are many ways to be non-compliant. I am more than happy to discuss any of the following issues to help clarify the requirements for the projects.

You should not do these things:

(F: -2) text area does not resize nicely. Using fixed sizes for the various displays is a bad idea.

(F: -3) JFileChooser should start at dot.

(F: -2) The display was not wide enough to show the search now button.

(F: -2) I should not have to import the file more than once.

(T: -1) test results presented but no test data files were submitted, so I cannot easily verify or do my own testing to reproduce your test results.

(A: -20) no approach documentation

(F: -3) JFileChooser should start at dot.

(F: -5) search found true??? Tell us the thing your found, not just that it exists.

(F: -10) I could not have been clearer, the required internal data structure was a tiered structure, with, for example, a Party listing its members, not a single list of all the creatures in a single structure.

(F: -2) the while loops around scnFields should not be there. I had to remove these loops in the Creature and Treasure classes to read the dataZ.txt input file.

(F: -3) The program does not accept the dataZ.txt input file, apparently because of the additional fields in the creature lines. Spec said extra information on lines should be ignored.

(F: -4) only one weapon and treasure per creature is are displayed??? I had to use the debugger to confirm that all the artifacts are actually being inserted into the artifact ArrayList. After fixing a few lines to allow the program to read dataZ.txt.

Also, in the Treasure input lines, the weight should be allowed to be Double, so the Scanner should be using nextDouble, which would match the declaration of this field in the Treasure class of this code. In fact, the code should be using the Scanner methods next, nextInt and nextDouble, not next, then Double.nextDouble and Integer.nextInt.

(D: -4) the classes Creature, Party, Artifact and Treasure should not be internal to the class SorcerersCave.

(F: -3) search should also be by type, index, name, not just name.

(F: -3) The problem was really pretty trivial in searching - and I could have helped you solve it fairly quickly if you had posted your code and explained something about what the problem symptoms were. The problem is that a null pointer exception was thrown during the search, and the cause was because most treasures had no name, so the name field of the GameElement class was not initialized, and was left null because no value was given to the field. The simplest solution is to immediately initialize the name field to an empty string:
String name = "";

(F: -2) your try at fonts is clever, but I don't have Parchment on my computer, so the display is not working correctly, which means that I had to change the font sizes to be considerably less interesting so that I could read the display. Also, the use of setBounds is generally a bad idea, particularly when moving to a different computer.

(F: -5) find by type causes as stack overflow. Searching for a name gives way too many copies of the target person. Recursive searches are really not appropriate in this data structure. For example a Party should only search its members, but the members should not be recursively searching themselves or calling the same method again (Party.findByType(String) in this case). And there seem to be even deeper problems with the search by type.

(A: -15) there is a UML drawing, but no text documentation (a readme file).

(T: -10) no test data file attached, and no explanation of testing procedures

(F: -5) did not use JFileChooser to find file at run time - asking the user to type the name of a file is not ok.

(F: -5) no display of entire structure, no scrolling text area.

(F: -1) the weight in treasure should be a double, not an int.

I really like that you have more than one test case submitted with your project, but it would have been nice in the documentation to say something about what makes each special - perhaps not much, but even that comment would be helpful.

(D: -1) Java class names should all start with an initial capital letter: driver --> Driver.

(F: -1) The display leaves off important fields. For example, the initial display leaves off the index, which we should eliminate from the project after the data file is read for p2, but here there is a provision for searching on that field, then in the search on Type, the result leaves off the creature's name. This is kind of picky, but it is the difference between a really friendly interface that can be used to efficiently test the program, and an interface that just looks pretty but leaves the tester (me!) wondering. I feel bad complaining about this since otherwise, the interface is very pretty, and does a nice job of indicating the elements and who owns them.

(T: -1) test results presented but no test data files were submitted, so I cannot easily verify or do my own testing to reproduce your test results.

(F: -10) I could not have been clearer, the required internal data structure was a tiered structure, with, for example, a Party listing its members, not a single list of all the creatures in a single structure.

The structure this code makes no sense at all. There is a major difference between extending a class from parent to child, and a class containing instances of some other class in a structure. Here, the parent class should be something like GameElement, with Party, Creature, Treasure and Artifact children of that class, but the Party class should have an ArrayList of members, meaning that each Party will have its own list of its members, which will be different from the list of members of all the other parties.

(F: -2) the ShowAll display text area does not scroll - this is not ok since the program is meant to handle rather a large amount of data and the only way to see it all is by scrolling.

(F: -2) there is a subtle point about opening a file - this code uses new File (JFileChooser.getSelectedFile().getName());
The problem is that this will only look for files in the current directory since the entire location specification is not being used. The code should look like this:
               fileName = cavefc.getSelectedFile().getName();
                    inputFile = new Scanner (cavefc.getSelectedFile());
//                inputFile = new Scanner(new File(fileName));

(F: -3) this program won't handle the data file dataZ.txt generated by my sample program. The treasure weight should be a double, not an int, so the Treasure class should be modified, including the constructor to do nextDouble rather than nextInt.

The program really shouldn't be complaining about comment lines.

(F: -2) I am not sure what is going on, but when I search for Witch as a Party, I get a lot of output, which seems unreasonable.

(F: -5) It would be nice to have a button that shows the indented internal data structure. The current display only shows the lines of text as they are read in from the file, but does not display the internal structure.

Sorting - in p2, the sorting will be within the parent collection. So the creatures in a party, or the treasures for each creature, not all the creatures in the entire cave.