In particular, it seems to me that using OOP would be the way to go (I'm originally a C/C++ programmer and know a great deal about OOP and how it relates to C/C++, however I'm new to Perl's quirks, so any suggestions as to this would be helpful: I'm planning to read perlboot and perltoot and whatever else may help with this).

Oddly enough, Dr. Conway's book Object Oriented Perl from Manning is an excellent introduction and academic smackdown on the topic of OOP. Like you, Damian also came from a strong C++ background that informs his take on Perl OO.

One comment I'll offer is that having your Card object also knowing about how to display itself can get ugly if you intend to support multiple displays (ascii, web, tk, etc). I would think you'd want a Board class that takes a Hand object (a collection of Cards) and Does the Right Thing based on the game logic and additional display rules that are particular to the display type.

Of course, this may be overthinking the project. Perhaps you should just bang out a quick prototype that works. That will make the redesign go ever so much quicker. Well that's Brooks' theory anyway. :-)

Cheers.