代写program编程、代做C++程序设计

日期：2021-07-01 11:04

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.