辅导program编程、讲解C++程序设计
- 首页 >> Database UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
UM-SJTU JI VG101 (21SU)
Lab Demo Project 2: Simple Risk
Designed by Salty Fish, inspired by JI Board Game Nights
1. Overview
Risk is a board game. It typically involves 3-5 players fighting for land on a board divided into
territories. The game starts with each player taking turns to deploy troops in randomly assigned
territories. Then, players take turns to take initiative. During his/her turn, a player can deploy
new troops, attack other players on adjacent territories and adjust the distribution of his/her
own troops according to specific rules. In the most classic mode, the winner of a Risk game is
the player who eventually successfully eliminates all other opponents by defeating all their
troops and occupying all territories on the board.
This project asks you to follow our guidance to implement a simplified version of
Risk in C. The final product should be a CLI program, i.e., it runs in a text console (or a
terminal) instead of providing a graphical interface. The program is not expected to include PvE
capability.
Your program should be able to:
Ask for number of players (3-5)
Randomly assign initial territories
Print the board
Allow players to deploy new troops
Allow players to perform "attacks"
Simulate random dice rolls (just priting the outcome is enough)
Judge attack results and update the board accordingly
Allow players to move troops and detect illegal moves
Judge when the game is over
See detailed game rules in the "Terms and game rules" section.
2. Milestones and grading policy
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
At the end of each lab session, you are expected to complete a part of this project, called a
milestone. The requirements for each milestone will be documented in the corresponding lab
worksheet.
To finish this project, you are expected to write about 500 lines of code. This is not a small
amount, so we have made two updates to this project:
1. It will last for 4 lab sessions.
2. Each milestone is worth (30 marks) for the corresponding lab.
Each milestone is due Saturday at 22:00. You must submit your code to Canvas before the
deadline to receive points for this part. Your code will be graded on its completeness, not
correctness. Students who make reasonable efforts to complete the tasks for a milestone will
receive full marks for the demo project section of the corresponding lab. On the contrary, nonsensical
code, too few lines of code or irrelevant submissions will receive no point. However, a
deduction may apply if your code style is considered bad. See the "Code quality" section for
details.
Late submissions receive deduction according to this table:
Submit after (or at) Deduction
Saturday 22:00 30%
Sunday 22:00 60%
Monday 22:00 100%
Demo projects are aimed to help you get a sense of what a software project is like and also
practice your programming skills learnt from the lectures. The goal is not to judge your ability.
So you will not need to worry about your grade as long as you try your best to
follow the TAs during the lab.
3. The idea behind this project
Demo Project 1 is about simulation. Project 1 is about data analysis. For Demo Project 2, we
would like to focus on something different， namely, games.
Unlike Demo Project 1 which employs the MVC architecture, Demo Project 2 is designed in the C
way. C is a procedural programming language, as opposed to other schemes including objectoriented
and functional. In C, everything is viewed as sequences of events. You are supposed to
divide the game into several stages, each implemented as a function in a separate .c file and
providing a header file for main.c to #include . We hope you could learn from this project
how procedural programming works by dividing complex processes into smaller ones.
4. Terms and game rules
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
4.1. Player
The game should allow 3-5 players to participate in. Players are referred to by capital letters
through .
4.2. Board
A game board consists of square cells, or territories, in a coordinate system. The
coordinate of each cell is , with the row and column numbers starting from
zero.
Row/Col 0 1 2 3 4
0
1
2
3
4
Each cell can and must always hold one or more troop controlled by the same player, for
example:
One troop owned by
10 troops owned by
are acceptable, but
One troop owned by and one by
No troop
are not.
Territories that share a same border line are considered "connected".
4.3. Game procedure
Note that the original game rules have been modified and adapted for VG101. Please
carefully read through this section to notice the differences.
First, the program should ask for number of players. Then, each player is asked to set a name
before the game starts. The game is divided into two stages: the deployment stage and the
fighting stage.
A
E
5 × 5 = 25
(#row, #column)
(0, 0) (0, 1) (0, 2) (0, 3) (0, 4)
(1, 0) (1, 1) (1, 2) (1, 3) (1, 4)
(2, 0) (2, 1) (2, 2) (2, 3) (2, 4)
(3, 0) (3, 1) (3, 2) (3, 3) (3, 4)
(4, 0) (4, 1) (4, 2) (4, 3) (4, 4)
A
B
A B
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
4.3.1. The deployment stage
First, the program will randomly assign initial territories to each player:
If there are 5 players, each player receives 5 territories.
If there are 4 players, 3 of them receive 6 territories each, and the other player receives 7
territories.
If there are 3 players, 2 of them receive 8 territories each, and the other player receives 9
territories.
For each player and each initial territory assigned to him/her, the program should automatically
deploy 1 troop owned by him/her there. After this process, the program prints the board, and
asks to select a territory of his/her to deploy one more troop there. After finishes, does
the same, then , and so on. When the last player finishes, it is back to 's turn again.
Each player can deploy 15 troops and will not be asked to deploy more once the limit is reached.
This stage is over when all players are finished.
4.3.2. The fighting stage
In this stage, players will take turns, starting from , to initiate attacks. During each player's
turn, the current board should be printed first and he/she can do three things in the order given
below.
4.3.2.1. Deploy new troops
First, the player receives some new troops. The number of new troops is calculated as
, where is the number of territories currently owned by the player. The player is
asked to select a territory owned by him/her to deploy these new troops in. After this step, the
updated board should be printed.
4.3.2.2. Attack other players
Then, the player will be asked whether he/she wants to initiate an attack. If yes, an attack
begins.
The player initiating the attack first choose one of his/her own territory holding 2 or more
troops to perform the attack from (the source territory). Then, the player selects an enemy
territory beside it to attack (the target territory). The player can choose to use troops to
perform the attack, with the the regulation that and where is the
number of troops in the source territory. The defender is allowed to use troops to defend with
the regulation that and , where is the number of troops in the target
territory.
A A B
C A
A
min(⌊t/2⌋, 3) t
m
m ∈ {1, 2, 3} m < s s
n
n ∈ {1, 2} n ≤ t t
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
The attacker than rolls dice and the defender rolls dice. The results should be generated
randomly. The program should output the results of each die roll and judge the outcome by the
following rules:
The largest die roll made by the attacker is compared with the largest die roll made by the
defender, and the same for the second largest if applicable.
For each comparison, the player with a smaller die roll scores 1.
In the case of ties, the attacker scores 1.
For each score, the corresponding player loses one troop.
If the defender loses all his/her troops in the target territory, he/she loses this territory and
the attacker moves some troops there.
The number of troops that the attacker moves to the target territory must satisfy
.
Some examples are given below to help you understand the rules:
Scenario Outcome
, attacker rolls
6 and 2, defender rolls 5 and 2
Attacker wins for the 6 and defender wins for the 2.
Each player loses 1 troop.
, attaker rolls 3
and 3, defender rolls 3 Defender wins. Attacker loses 1 troop.
, attacker rolls
4, 3 and 2, defender rolls 3 Attacker wins. Defender loses 1 troop.
,
attacker rolls 4, 3 and 2, defender
rolls 3 and 2
Attacker wins both dice rolls. Defender loses the
territory. Attacker can move 3 or 4 troops to the target
territory.
After an attack, the updated board should be printed and the player will be asked if he/she
wants to initiate more attacks. The player can initiate infinitely many attacks until he/she
decides to stop or is unable to continue launching attacks, in which case he/she proceeds to the
last step.
4.3.2.3. Adjusting the distribution of troops
Before a player's turn ends, he/she will have a chance to move some troops from one of his/her
territories to another. However, there are several rules:
The two territories must be joined by at least one path on which all territories are
connected, and owned by this player.
At least one troop should be left in the original territory.
m n
p m ≤
p < s
m = 2,t = 3, n = 2
m = 2,t = 1, n = 1
m = 3,t = 2, n = 1
s = 5, m = 3,t = 2, n = 2
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
The player can only perform one such movement.
You are asked to detect and decline illegal moves that do not conform to the given rules.
4.3.3. Defeat and winning
After each attack, if the defender lost, check if he/she has lost all his/her territories. If yes, this
player loses and no longer participates in the game. Other players continue fighting, with the
order unchanged.
Then, check if all territories are owned by the same player. If so, the game ends and this player
wins!
5. Detailed specifications
5.1. I/O format
There are no specific requirements regarding the format of I/O, i.e., how your program collects
and displays information. It is however suggested that you keep it simple. For example, when
you need a player to input a territory that he/she wants to attack, you can do it in this way:
unsigned row, column;
printf("Choose a row: ");
scanf("%u", &row);
printf("Choose a column: ");
scanf("%u", &column);
Or you can do it this way:
unsigned row, column;
printf("Choose a territory: ");
scanf("%u %u", &row, &column);
Choose whatever you like!
The board can be printed as:
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
--------------------------------------
| RISK | 0 | 1 | 2 | 3 | 4 |
| 0 | C 2 | B 1 | A 10| E 12| E 5 |
| 1 | D 2 | B 4 | A 3 | C 8 | C 5 |
| 2 | C 2 | A 1 | A 2 | A 8 | C 4 |
| 3 | B 6 | B 19| A 5 | C 8 | C 4 |
| 4 | B 2 | D 1 | A 5 | C 7 | E 5 |
--------------------------------------
Again, these are just for reference.
5.2. Errorneous input
This project is not aimed to bother you with tedious error detection and handling. Thus, you are
not required to deal with errorneous input. Your program is allowed to crash automatically or
exhibit strange behaviors when any input value is invalid. You may assume that all input makes
sense. But of course, you can implement some basic checks if you want to. In your code,
wherever the situation should not happen, feel free to use exit(1); to tell your program to
crash.
There is one exception: you need to detect illegal moves when a player moves his/her troops at
the end of his/her turn and refuse such moves.
5.3. Code quality
Your code quality will be inspected. A 20% deduction may apply if your code style is considered
bad. Please stick to our rules to avoid receiving this deduction. Generally, you should:
Reuse code wherever possible. Use functions. If you find yourself copying and pasting your
code, you are likely doing it wrong.
Make your code as modular as possible.
Avoid using global variables, unless you have a really good reason to use them.
Give reasonable and meaningful names to your variables and functions.
Use indentation properly.
Avoid "magic numbers" in your code. Give constants reasonable and meaningful names
using preprocessing instructions ( #define ) or global constants.
Keep variables in the smallest possible scopes where they are used.
Write comments for functions and code that is hard to understand if none was provided.
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
6. Algorithms involved
1. Fisher-Yates Shuffle is used to initialize the board.
2. Depth-First Search is used to determine if two territories are joined.
UM-SJTU JI VG101 (21SU)
Lab Demo Project 2: Simple Risk
Designed by Salty Fish, inspired by JI Board Game Nights
1. Overview
Risk is a board game. It typically involves 3-5 players fighting for land on a board divided into
territories. The game starts with each player taking turns to deploy troops in randomly assigned
territories. Then, players take turns to take initiative. During his/her turn, a player can deploy
new troops, attack other players on adjacent territories and adjust the distribution of his/her
own troops according to specific rules. In the most classic mode, the winner of a Risk game is
the player who eventually successfully eliminates all other opponents by defeating all their
troops and occupying all territories on the board.
This project asks you to follow our guidance to implement a simplified version of
Risk in C. The final product should be a CLI program, i.e., it runs in a text console (or a
terminal) instead of providing a graphical interface. The program is not expected to include PvE
capability.
Your program should be able to:
Ask for number of players (3-5)
Randomly assign initial territories
Print the board
Allow players to deploy new troops
Allow players to perform "attacks"
Simulate random dice rolls (just priting the outcome is enough)
Judge attack results and update the board accordingly
Allow players to move troops and detect illegal moves
Judge when the game is over
See detailed game rules in the "Terms and game rules" section.
2. Milestones and grading policy
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
At the end of each lab session, you are expected to complete a part of this project, called a
milestone. The requirements for each milestone will be documented in the corresponding lab
worksheet.
To finish this project, you are expected to write about 500 lines of code. This is not a small
amount, so we have made two updates to this project:
1. It will last for 4 lab sessions.
2. Each milestone is worth (30 marks) for the corresponding lab.
Each milestone is due Saturday at 22:00. You must submit your code to Canvas before the
deadline to receive points for this part. Your code will be graded on its completeness, not
correctness. Students who make reasonable efforts to complete the tasks for a milestone will
receive full marks for the demo project section of the corresponding lab. On the contrary, nonsensical
code, too few lines of code or irrelevant submissions will receive no point. However, a
deduction may apply if your code style is considered bad. See the "Code quality" section for
details.
Late submissions receive deduction according to this table:
Submit after (or at) Deduction
Saturday 22:00 30%
Sunday 22:00 60%
Monday 22:00 100%
Demo projects are aimed to help you get a sense of what a software project is like and also
practice your programming skills learnt from the lectures. The goal is not to judge your ability.
So you will not need to worry about your grade as long as you try your best to
follow the TAs during the lab.
3. The idea behind this project
Demo Project 1 is about simulation. Project 1 is about data analysis. For Demo Project 2, we
would like to focus on something different， namely, games.
Unlike Demo Project 1 which employs the MVC architecture, Demo Project 2 is designed in the C
way. C is a procedural programming language, as opposed to other schemes including objectoriented
and functional. In C, everything is viewed as sequences of events. You are supposed to
divide the game into several stages, each implemented as a function in a separate .c file and
providing a header file for main.c to #include . We hope you could learn from this project
how procedural programming works by dividing complex processes into smaller ones.
4. Terms and game rules
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
4.1. Player
The game should allow 3-5 players to participate in. Players are referred to by capital letters
through .
4.2. Board
A game board consists of square cells, or territories, in a coordinate system. The
coordinate of each cell is , with the row and column numbers starting from
zero.
Row/Col 0 1 2 3 4
0
1
2
3
4
Each cell can and must always hold one or more troop controlled by the same player, for
example:
One troop owned by
10 troops owned by
are acceptable, but
One troop owned by and one by
No troop
are not.
Territories that share a same border line are considered "connected".
4.3. Game procedure
Note that the original game rules have been modified and adapted for VG101. Please
carefully read through this section to notice the differences.
First, the program should ask for number of players. Then, each player is asked to set a name
before the game starts. The game is divided into two stages: the deployment stage and the
fighting stage.
A
E
5 × 5 = 25
(#row, #column)
(0, 0) (0, 1) (0, 2) (0, 3) (0, 4)
(1, 0) (1, 1) (1, 2) (1, 3) (1, 4)
(2, 0) (2, 1) (2, 2) (2, 3) (2, 4)
(3, 0) (3, 1) (3, 2) (3, 3) (3, 4)
(4, 0) (4, 1) (4, 2) (4, 3) (4, 4)
A
B
A B
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
4.3.1. The deployment stage
First, the program will randomly assign initial territories to each player:
If there are 5 players, each player receives 5 territories.
If there are 4 players, 3 of them receive 6 territories each, and the other player receives 7
territories.
If there are 3 players, 2 of them receive 8 territories each, and the other player receives 9
territories.
For each player and each initial territory assigned to him/her, the program should automatically
deploy 1 troop owned by him/her there. After this process, the program prints the board, and
asks to select a territory of his/her to deploy one more troop there. After finishes, does
the same, then , and so on. When the last player finishes, it is back to 's turn again.
Each player can deploy 15 troops and will not be asked to deploy more once the limit is reached.
This stage is over when all players are finished.
4.3.2. The fighting stage
In this stage, players will take turns, starting from , to initiate attacks. During each player's
turn, the current board should be printed first and he/she can do three things in the order given
below.
4.3.2.1. Deploy new troops
First, the player receives some new troops. The number of new troops is calculated as
, where is the number of territories currently owned by the player. The player is
asked to select a territory owned by him/her to deploy these new troops in. After this step, the
updated board should be printed.
4.3.2.2. Attack other players
Then, the player will be asked whether he/she wants to initiate an attack. If yes, an attack
begins.
The player initiating the attack first choose one of his/her own territory holding 2 or more
troops to perform the attack from (the source territory). Then, the player selects an enemy
territory beside it to attack (the target territory). The player can choose to use troops to
perform the attack, with the the regulation that and where is the
number of troops in the source territory. The defender is allowed to use troops to defend with
the regulation that and , where is the number of troops in the target
territory.
A A B
C A
A
min(⌊t/2⌋, 3) t
m
m ∈ {1, 2, 3} m < s s
n
n ∈ {1, 2} n ≤ t t
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
The attacker than rolls dice and the defender rolls dice. The results should be generated
randomly. The program should output the results of each die roll and judge the outcome by the
following rules:
The largest die roll made by the attacker is compared with the largest die roll made by the
defender, and the same for the second largest if applicable.
For each comparison, the player with a smaller die roll scores 1.
In the case of ties, the attacker scores 1.
For each score, the corresponding player loses one troop.
If the defender loses all his/her troops in the target territory, he/she loses this territory and
the attacker moves some troops there.
The number of troops that the attacker moves to the target territory must satisfy
.
Some examples are given below to help you understand the rules:
Scenario Outcome
, attacker rolls
6 and 2, defender rolls 5 and 2
Attacker wins for the 6 and defender wins for the 2.
Each player loses 1 troop.
, attaker rolls 3
and 3, defender rolls 3 Defender wins. Attacker loses 1 troop.
, attacker rolls
4, 3 and 2, defender rolls 3 Attacker wins. Defender loses 1 troop.
,
attacker rolls 4, 3 and 2, defender
rolls 3 and 2
Attacker wins both dice rolls. Defender loses the
territory. Attacker can move 3 or 4 troops to the target
territory.
After an attack, the updated board should be printed and the player will be asked if he/she
wants to initiate more attacks. The player can initiate infinitely many attacks until he/she
decides to stop or is unable to continue launching attacks, in which case he/she proceeds to the
last step.
4.3.2.3. Adjusting the distribution of troops
Before a player's turn ends, he/she will have a chance to move some troops from one of his/her
territories to another. However, there are several rules:
The two territories must be joined by at least one path on which all territories are
connected, and owned by this player.
At least one troop should be left in the original territory.
m n
p m ≤
p < s
m = 2,t = 3, n = 2
m = 2,t = 1, n = 1
m = 3,t = 2, n = 1
s = 5, m = 3,t = 2, n = 2
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
The player can only perform one such movement.
You are asked to detect and decline illegal moves that do not conform to the given rules.
4.3.3. Defeat and winning
After each attack, if the defender lost, check if he/she has lost all his/her territories. If yes, this
player loses and no longer participates in the game. Other players continue fighting, with the
order unchanged.
Then, check if all territories are owned by the same player. If so, the game ends and this player
wins!
5. Detailed specifications
5.1. I/O format
There are no specific requirements regarding the format of I/O, i.e., how your program collects
and displays information. It is however suggested that you keep it simple. For example, when
you need a player to input a territory that he/she wants to attack, you can do it in this way:
unsigned row, column;
printf("Choose a row: ");
scanf("%u", &row);
printf("Choose a column: ");
scanf("%u", &column);
Or you can do it this way:
unsigned row, column;
printf("Choose a territory: ");
scanf("%u %u", &row, &column);
Choose whatever you like!
The board can be printed as:
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
--------------------------------------
| RISK | 0 | 1 | 2 | 3 | 4 |
| 0 | C 2 | B 1 | A 10| E 12| E 5 |
| 1 | D 2 | B 4 | A 3 | C 8 | C 5 |
| 2 | C 2 | A 1 | A 2 | A 8 | C 4 |
| 3 | B 6 | B 19| A 5 | C 8 | C 4 |
| 4 | B 2 | D 1 | A 5 | C 7 | E 5 |
--------------------------------------
Again, these are just for reference.
5.2. Errorneous input
This project is not aimed to bother you with tedious error detection and handling. Thus, you are
not required to deal with errorneous input. Your program is allowed to crash automatically or
exhibit strange behaviors when any input value is invalid. You may assume that all input makes
sense. But of course, you can implement some basic checks if you want to. In your code,
wherever the situation should not happen, feel free to use exit(1); to tell your program to
crash.
There is one exception: you need to detect illegal moves when a player moves his/her troops at
the end of his/her turn and refuse such moves.
5.3. Code quality
Your code quality will be inspected. A 20% deduction may apply if your code style is considered
bad. Please stick to our rules to avoid receiving this deduction. Generally, you should:
Reuse code wherever possible. Use functions. If you find yourself copying and pasting your
code, you are likely doing it wrong.
Make your code as modular as possible.
Avoid using global variables, unless you have a really good reason to use them.
Give reasonable and meaningful names to your variables and functions.
Use indentation properly.
Avoid "magic numbers" in your code. Give constants reasonable and meaningful names
using preprocessing instructions ( #define ) or global constants.
Keep variables in the smallest possible scopes where they are used.
Write comments for functions and code that is hard to understand if none was provided.
UM-SJTU Joint Institute Demo Project 2 Description VG101 (21SU)
6. Algorithms involved
1. Fisher-Yates Shuffle is used to initialize the board.
2. Depth-First Search is used to determine if two territories are joined.