Lab Two: Game On!

Our first lab (Pennywise) got us back into the swing of things. The implementation itself followed closely from the Beetle Game that Drake presented in the text. We talked about design, encapsulation, and many other topics (equality, process, etc.). 

In this lab, you're going to have a bit more freedom.

First Choice: What Game?

At the end of Chapter 3 in Data Structures and Algorithms in Java there are three games. Choose one.

If you wish, you may chose a game that is not detailed here, but you must at least discuss it with me first. The game should have a representational component that might be well supported by a Vector or Matrix.

Grading

The laboratories are criterion referenced assignments. This means that it does not matter how well the person next to you does: all that matters is how well you do. It isn't easy to get right, necessarily, but I'll try—and in doing so, I'll try and be fair.

What does this mean, though? In a picture:

criterion-grading

I will make the criteria for the lab explicit. You can choose to do enough work to earn a C. If you do, you will get a C. If you choose to do more work, you can earn a B. If I say you meet the criteria for the B, then that's it. Or, you can push to earn the A. Note that an A means excellent, and sometimes earning an A will be challenging. This is the way it should be.

I like this kind of grading because it allows you to choose how hard you will work, and what you will strive for. If you feel the criteria are unfair, you should discuss that with me early (perhaps on the mailing list, even).

Failure to earn a C means failure. The grading scale goes from F, to C, to B, to A. There are no D laboratories. Also, there are no "B+" labs.

Checkpoint: Barely Awesome

A Barely Awesome lab achieves the following:

  • A complete Matrix or Vector class (as described in problem 2.30 in the text.)

  • A class encapsulating the game state (eg. board, tokens, and so on) with methods to manipulate that state.

  • A "driver class" that allows a user to play the game.

  • A game play loop that is bug-free, but potentially incomplete. You should (at least) detect end-of-game conditions, but you might assume that players only make legal moves.

  • A README in your BlueJ project that is complete (all the fields filled out), and includes a copy-pasted game session. 

  • Reasonably formatted code.


It is expected that you will ask questions/communicate with me if you have questions about whether you have achieved a passing lab.

Checkpoint: Pretty Awesome

A Pretty Awesome awesome lab achieves surpasses a Barely Awesome lab in the following ways: 

  • All data in your program is encapsulated as cleanly as reasonably possible. Further, all interactions with that data are, whenever possible, mediated by method calls into the encapsulating class. For example, if you want to know whether a player has lost, then there should be a method called hasPlayerLost() as part of the game state that returns a boolean—you should not be doing these calculations within the driver class.

  • All methods in all classes have a comment before them that describes their behavior in plain language.

  • All code is consistently formatted: all indentation is consistent, and all bracketing is consistent as well. 

  • All output from your program is readable/reasonably formatted.

  • Your game loop is complete. Specifically, reasonable error checking (eg. preventing impossible plays) is in place. Exceptional behavior (eg. a user inputting a string when a number is expected) is an acceptable error at this time.

It is expected that you will ask questions/communicate with me if you have questions about whether you have a Pretty Awesome lab.

Checkpoint: Completely Awesome

A Completely Awesome lab achieves surpasses a Pretty Awesome lab in the following ways: 

  • All comments before methods are formatted using JavaDoc rules. (See here, and more specifically, here. You may find better examples online, and are welcome to share them on the course mailing list. Remember, if your classmates also do well, it does not hurt you.) The side effect of this is that all of your comments in the BlueJ "Documentation" view should look amazing, and be informative. (I shouldn't have to read your code to know what it does.)

  • Your README includes a short reflection on what aspects of the lab were most challenging, most surprising, and most frustrating. You aren't constrained to those categories, but that gets you started.

  • A Completely Awesome lab typically adds something creative or kinda cool into the mix. For this lab, though, that requirement is waived... but you're still welcome to do so.

It is expected that you will ask questions/communicate with me if you have questions about whether you have a Completely Awesome lab.

Submission

Check your code in on time, and send me an email letting me know it is done.

Please include in the subject line of your email 

[DS 112] LAB SUBMISSION

That would make my life a bit easier. If you have questions, ask them in a separate email; your lab submission should just tell me it is done and the name of your lab, not tell me a story. If you tell me a story in your submission message, you will make Domo Kun cry.

When you are done with your lab, you can play Super Domo Smash Bros.

Creative Commons License Creative Commons BY-NC-SA 3.0 Licensed where possible.