Usage

The README.md file included with the gofish game does not contain any explicit instruction in compiling or executing the program. However, because it is written in Python, one can naturally assume that any compilation of the code is unnecessary if the user has had prior experience working with the language. On the other hand, a complete neophyte would be left staring at the terminal, wondering what to do, when a single line of direction in the README would have sufficed in guiding the user to a successful invocation of the program.

With that said the game does run as advertised and does so without any errors. Upon program execution, the player is dealt a handful of cards and must ask the dealer for a card of the same value in the hopes of completing a set. A complete set consists of four cards of the same value, which is then attributed to the player who completed the set and is removed from gameplay. Players will continue to query one another for cards until all sets have been completed.

Style

The game is composed of two Python files: gofish.py and cards.py, both of which are devoid of any sort of commenting. Nevertheless, the structure of the code itself, as well as the naming of the functions and variables, make it quite clear what each section of the program is responsible for. Gofish.py can be interpreted as both the engine and the interface of the program. It contains the main loop and the print statements which allow the user to interact with the program. Cards.py is a separate class file that specifies a default constructor for a deck of playing cards as well as their associated functions. This class file is imported by Gofish.py, allowing for some degree of modularity when it comes time to implementing another program involving playing cards.

Error checking for user input is minimal. Though the program can handle invalid combinations of integer inputs, it will immediately terminate if a character not corresponding with any of the card values in the deck is entered. The program will also prematurely terminate if nothing is typed, but is passed as an input anyway through the enter key.

Philosophy

The game adheres most closely to the Roguelike Pattern. User commands consist of single characters with no input from the mouse. The interface is static and is composed of ASCII characters arranged in tiers of horizontal lists. In regards to simulating a two-player card game, the Roguelike Pattern is an acceptable interface choice. However, I would avoid using this interface pattern when implementing additional players or rule sets that rely on cards with complex attributes (MTG comes to mind). In these scenarios, I would opt for a full-fledged graphical interface.

Due to the inherent nature of the game, the program is verbose. Not all is lost on the Rule of Silence however. The most vital information pertinent to player are the values of the cards he or she is holding in the current hand. Sets that have been already completed can be hidden away until the end, which is when the game reveals the winner. Such a design choice would introduce an element of surprise in the case where a player who thought himself to be doing well is upstaged by the dealer.

Suggestions for future iterations of the game: when the dealer has multiple copies of the card I asked for, I should not have to repeat myself over and over again in requesting all copies of that card.

Implement comprehensive error checking for user inputs.

Overall, not a bad game.