For your final project, you will be implementing a card game as a Java applet. The game can be any card game that you want. It can have any number of players. It should be clear from your interface how to play your game. You don't have to display all the rules of the game, but it should be clear what each button or control does. If the game has a score or if there's betting involved, your applet should keep track of the score or the amount of money each player has.
The game can be any card game you want. It doesn't even have to be a standard deck of cards. (Uno would be a fine choice.) If you want to, you can simplify the rules a bit. For example, if your game was blackjack, then you don't necessarily have to implement splits and doubles. If you really want to, you can invent your own card game.
Your game doesn't have to display pictures unless you really want to. You can just use text labels to display what cards are what. You may find the characters ♠, ♣, ♥, and ♦ useful (their HTML entity references are ♠, ♣, ♥, and ♦). Or you can just use text alone (e.g., "queen of hearts", "four of diamonds").
If your game is a multiplayer game, you can choose whether to have a computer opponent or to have multiple players taking turns on the same computer.
If you have an idea for your game that breaks one of the guidelines I've set but that you really want to do anyway, let me know, and I'll tell you if it's okay.
Here are some suggestions of possible card games that you might want to implement.
I recommend that you implement your deck of cards as a List object (specifically, an ArrayList) and not just as a simple array. There are a lot of convenient methods that use lists. In particular, Collections.shuffle() is a good way to randomize the order of the elements in a list. You can read about lists (and collections in general) here, but we'll also talk about them in class on Tuesday.
I highly recommend that you have a working version of the project that you can show to me by Thursday (Friday at the latest). When you turn in the project on Saturday, there will be no chance to fix any mistakes.
When you've created the applet and the web page, log on to the class OnCourse page, go to the Assignments tab, and submit your assignment there. Include the URL for your web app (including the port number) with your submission. I would also like you to attach the source code for your applet as a separate file.
The final project is due, Saturday, August 2nd at 11:59pm.
Grading for the project will be different than it was for your homework assignments and labs. If you do the bare minimum* needed to fit the requirements and the game works properly, you will get a B (85%) on your project. If your game is harder to implement, or if your implementation is well-polished, then you can get more points. If it's a lot more complex or very well-polished, then you might even be able to get more than 100%. If there are some bugs in your implementation, then I may deduct points. You can still get a C (70-79%) with a few bugs if they are minor. If there are serious bugs that make it so that the game is often unplayable, you may get a D or an F. If the game won't load at all, then you will get a low F, possibly even 0, depending on what's in your source code.
By bare minimum, I mean something like high-low, where the player gets one card and the opponent gets one card, and whoever has the higher card wins.
Since I've added the project, I had to slightly alter how your grades will be calculated. The project will be worth 10% of your grade. Your participation score is now only worth 10% of your grade and not 20%. If you're enrolled in both 3-week sessions of CSCI-A 290 or 590, then this change will only affect your grade for the second 3-week session.
After looking at the way a few of you are getting started, I figured some of you might want some guidance on how to get started. We're working in an object-oriented programming language, and the OOP way of dealing with a new kind of thing is not to find some code to represent the thing and then working with that. The OOP way is to make a new type of thing, to make a new class, and to add a bunch of methods to that class to do all the work for you, so that the main block of code is readable and not too long.
Playing cards are more complicated than the simple number cards we created in class. Each card has a value (king, queen, ace, five, etc.) and a suit (clubs, hearts, etc.). So it makes sense to have a Card class, which might look something like this:
public class Card {
String value;
String suit;
public Card(String v, String s) { ... }
//sets value and suit for a new card. The constructor.
public String toString() {
//returns a string describing the card
public int getNumericalValue() { ... }
//returns the value as an integer. Might be different
//for different games. (in blackjack, a queen is worth 10,
//but in War, it's worth 12)
public boolean sameSuit(Card otherCard) { ... }
//true if the two cards have the same suit
public boolean sameValue(Card otherCard) { ... }
//true if the two cards have the same value
public boolean isBigger(Card otherCard) { ... }
//true if this is bigger than the other card
//probably uses getNumericalValue()
}
Of course, you'll have to fill in the definitions of the methods yourselves. I'm not going to do all the work for you. But the idea here is that you can work with a list of cards (something of type List<Card>) instead of a list of integers or strings. And any time you need to do something with cards (like checking to see if one is bigger than the other, or deciding whether two cards have the same value or same suit, or adding up the numerical values of some cards), you can use one of the methods you created for the cards.
Of course, you don't have to do it exactly like this. If you want to store the value as an integer instead of a string, that's perfectly reasonable. Heck, you could even store your suit as an integer (or a character or a couple booleans even). But when it comes to writing your toString() function, make sure the output is readable to a human. What I mean is that you could have the a Card with value=12 and suit=3, but when the toString() method should return something like "Queen of Hearts" or "QHearts" or "Q♥".
Also, depending on your game, you might not need all of these methods, and you might want some we don't have here. But whatever game you're doing, you definitely want to have a constructor and a toString() method, so that you can create new cards and display them. The game of War probably only needs the isBigger() method, although to write that method, it might be nice to have the getNumericalValue() too. Blackjack probably only needs the getNumericalValue() method. Something like poker or rummy or solitaire that depends on whether cards are consecutive or not might want something like isOneBiggerThan(). A solitaire game that differentiates between red and black cards might want a getColor() method.