1
VG101 Introduction to Computer and Programming
Project 2
Manuel UM-JI (Fall 2019)
Project Setup
Include simple comments in the code
Split the code over several functions
Extensively test your code and impove it
Start early and respect the milestones
Update the README file for each milestone
Update the Changelog file between two milestones
Archive the files (*.{zip|tar}) and upload on Canvas
After successfully taking their very easy MATLAB midterm Haruka, Kana, and Chiaki, want to know more about programming. So they are thinking of the best way to learn and practice C, but would like it to be fun. Keeping this idea in mind, Haruka suggests to implement their favorite card game, One Card, a very simple shedding game, that is a game where the goal is to be the first one to get rid of all his cards.
The three sisters are pretty happy with this idea, and Kana feels this is a perfect opportunity to really practice good quality coding, and better understand why and how to best organise a large programs.
Overview
One Card is a rather simple game played by n persons over a pre-decided number of rounds r. Two decks of Poker cards, excluding Jokers, are shuffled and c cards are offered to each player. Once everybody has received his cards, the dealer poses a card, face up in front of each player. The game will be played counter-clockwise, starting with the player who received the card with lowest rank. Once the playing order has been decided all those initial n cards are directly put in the discard pile. Finally the first card of the stock pile is laid face-up to initiate the rank and suit.
As the game starts each player, following the defined order, plays exactly one card either following the rank or the suit defined by the previous card. Any played card directly goes into the discard pile, and anyone who is unable to play should draw a card from the top of the stock pile. If the stock pile is exhausted, the discard pile is shuffled and used as stock pile.
As soon as a player has discarded all his cards the rounds stops. All other players receive a penalty equal to the number of cards left in their hands. The player who won the round initiates the following one, all the other rules remain unchanged. At the end of the r rounds the final score of each player is determined by summing up of all his penalties. The person with highest score wins. In case of equality more than one player can be declared winner.
Cards
Cards split into four main categories: Attack:
Cards with rank 2: the next player draws two cards from the stock pile;
Cards with rank 3: the next player draws three cards from the stock pile; Defense:
Cards with rank 7: cancel an attack, i.e. do not draw any card if a 2 or a 3 was played before; 1
Action:
Queen cards: reverse the playing order from counter-clockwise to clockwise or clockwise to counter- clockwise;
Jack cards: skip the next player;
Regular: any other card has no special effect and is only used to match the previous cards rank or suit;
Notes on cards and attacks:
The effect of the attack cards is cumulative.
A Queen or a Jack, of same suit as the previous card, can be played to redirect an attack on the previous player, or the player after the next one, respectively;
When under an attack, a player not playing any special card (2, 3, 7, Q, J) must draw cards from the stock pile, and this ends his turn;
For instance last week when the three sisters took a break during their revision fo the MATLAB exam they played One Card and the following scenario occurred. As Chiaki played 2 Diamonds, Kana 3 Diamonds, and Haruka 3 Spades, everybody expected to see Chiaki drawing eight cards, but she played a Queen such that in the end Haruka had to draw them.
2 Project goals and program structure
As Haruka, Kana, and Chiaki all agree on the importance of a good code structure they decide to follow the advice of their VG101 instructor to never start coding before precisely knowing what to do. Hakura in particular highlights that if they organise their code well they can easily adjust it in the future to add new features without rewriting much. Kana adds that during the C part of their course they will probably learn new things that could be helpful to their project. However it might lead to substantial rewriting of the code as their understanding of programming improves. Chiaki concludes that it is like in real life for developers: they write a program, then check what parts can be improved or made more efficient, then they adjust and fully rewrite some of the code until everything is as good as it can be.
To ensure they go in the right direction they start discussing what they want to achieve.
Project goals
The three sisters starts by thinking of the big picture, what they want there program to do. Obviously they need players and cards, so it makes sense to define options specifying the number of players, how many cards each one of them gets, and the number of decks to be used. Kana recalls that the number of rounds should also be flexible, so an option is also needed for that. Beyond those basic arguments they would also like their program to define a log file saving all the details of a game, and to feature a demo mode. Of course they do not forget the usual help explaining how to run the program and use the options.
2
sh $./onecard -h
-h|help print this help message
log filenamewrite the logs in filename (default: onecard.log)
-n n|player-number=nn players, n must be larger than 2 (default: 4)
-c c|initial-cards=cdeal c cards per player, c must be at least 2 (default: 5)
-d d|decks=d
-r r|rounds=r
-a|auto
use d decks 52 cards each, d must be at least 2 (default: 2)
play r rounds, r must be at least 1 (default: 1)
run in demo mode
Now that the three sisters have clearly defined the main lines of their project, they start thinking of the best approach to minimize their work. For instance Haruka emphasizes that the number of players participating in the game should not impact the clarity and complexity of their code. Similarly, there is no point in writing a completely different program or set of functions for the demo mode: it should take advantage of the regular functions used by other players.
Keeping these ideas in mind they want to define some generic output that can be easily generated independently of the number of players or running mode. A first step would be to always display card following a same order, this will clearly facilitate the choice of the players and the reading of the log file1. After some discussions they all agree on the following arbitrary order for display:
Spades < Hearts < Diamonds < Clubs, and if two cards suits are the same, then use2<3<<10
Reviews
There are no reviews yet.