这是一篇来自澳洲的扑克牌游戏代写，你将创建一个面向对象的基于文本的游戏，其灵感来自于《杀死Spire1》您需要实现本文档第5节中规定的类和方法的集合。程序的输出必须与预期输出完全匹配；输出中的微小差异（如空白或套写）将导致测试失败，从而导致这些测试的标记为零。

Slay the Spire是一种类似流氓的扑克牌游戏，玩家必须制作一副纸牌，他们在遇到怪物时使用。原始的杀戮刺尖游戏的细节可以在这里找到。

1 Introduction

Slay the Spire is a rogue-like deck building card game in which a player must build a deck of cards, which they use during encounters with monsters. Details of the original Slay the Spire game can be found here. In Assignment 2, you will create an object-oriented text-based game inspired by (though heavily simplified and altered from) Slay the Spire1 .

You are required to implement a collection of classes and methods as specified in Section 5 of this document.

Your program’s output must match the expected output exactly; minor differences in output (such as whitespace or casing) will cause tests to fail, resulting in zero marks for those tests. Any changes to this document will be listed in a changelog on Blackboard.

2 Getting Started

Download a2.zip from Blackboard — this archive contains the necessary files to start this assignment. Once extracted, the a2.zip archive will provide the following files / directories:

a2.py

The game engine. This is the only file you submit and modify. Do not make changes to any other files.

a2_support.py

Support code to assist in more complex parts of the assignment, and to handle randomness. Note that when implementing random behaviour, you must use the support functions, rather than calling functions from random yourself.

games

A folder containing several text files of playable games.

game_examples

A folder containing example output from running the completed assignment.

3 Gameplay

At the beginning of the game, the user selects a player character; different player characters have different advantanges and disadvantages, such as starting with higher HP or a better deck of cards. The user then selects a game file, which specifies the encounters that they will play. After this, gameplay can begin.

During gameplay, the player users a deck of cards to work through a series of encounters with monsters. Each encounter involves between one and three monsters, which the player must battle in parallel over a series of turns. At the start of each turn the user draws 5 cards at random from their deck into their hand. Each card costs between 0 and 3 energy point to play. The user may play as many cards as they like from their hand during their turn provided they still have the energy points required to play the requested cards. The user opts to end their turn when they are finished playing cards, at which point the monsters in the encounter each take an action (which may affect the player’s HP or other stats, or the monster’s own stats). When a card is played it is immediately sent to the player’s discard pile. At the end of a turn, all cards in the players hand (regardless of whether they were played that turn) are sent to the discard pile. Cards in the discard pile cannot be drawn until the entire deck has been drawn, at which point the deck is replenished with all the cards from the discard pile. An encounter ends when either the player has killed all monsters (reduced their HP to 0) or when the monsters have killed the player (reduced the player’s HP to 0). If the player wins an encounter, an encounter win message is printed and the next encounter begins. If no more encounters remain, the game terminates with a game win message, and if the player loses an encounter, the program terminates with a loss message. See a2_support.py for the relevant messages. You can find examples of gameplay in the game_examples folder provided in a2.zip. For more details on the behaviour of main, see Section 5.4.

4 Class overview and relationships

You are required to implement a number of classes, as well as a main function. You should develop the classes first and ensure they all work (at minimum, ensure they pass the Gradescope tests) before beginning work on the main function. The class diagram in Figure 1 provides an overview of all of these classes, and the basic relationships between them. The details of these classes and their methods are described in depth in Section 5.

• Hollow-arrowheads indicate inheritance (i.e. the “is-a” relationship).
• Dotted arrows indicates composition (i.e. the “has-a” relationship). An arrow marked with 1-1 denotes that each instance of the class at the base of the arrow contains exactly one instance of the class at the head of the arrow. An arrow marked with 1-n denotes that each instance of the class at the base of the arrow may contain many instances of the class at the head of the arrow. E.g. an Encounter instance may contain between 1 and 3 Monster instances, but only one Player instance.

• Blue classes are abstract classes. You should only ever instantiate the green classes in your program,though you should instantiate the blue classes to test them before beginning work on their subclasses.

5 Implementation

This section outlines the classes, methods, and functions that you are required to implement as part of your assignment. It is recommended that you implement the classes in the order in which they are described. Ensure each class behaves as per the examples (and where possible, the Gradescope tests) before moving on to the next class.

5.1 Cards

Cards are used by the player during encounters to attack monsters, defend, or apply status modifiers. When implementing this class, it is not necessary that you yet understand the mechanics of how these effects will be applied. You will handle this later in your implementation. Card classes simply provide information about the effects each type of card has; they are not responsible for directly causing these effects.

All instantiable cards inherit from the abstract Card class, and should inheret the default Card behaviour except where specified in the descriptions of each specific type of card.

Card

(abstract class)

An abstract class from which all instantiable types of cards inheret. Provides the default card behaviour, which can be inhereted or overwritten by specific types of cards. The __init__ method for all cards do not take any arguments beyond self.

get_damage_amount(self) -> int

(method)

Returns the amount of damage this card does to its target (i.e. the opponent it is played on). By default, the damage done by a card is 0.

get_block(self) -> int

(method)

Returns the amount of block this card adds to its user. By default, the block amount provided by a card is 0.

get_energy_cost(self) -> int

(method)

Returns the amount of energy this card costs to play. By default, the energy cost should be 1.

get_status_modifiers(self) -> dict[str, int]

(method)

Returns a dictionary describing each status modifiers applied when this card is played. By default, no status modifiers are applied; that is, this method should return an empty dictionary in the abstract Card class.

get_name(self) -> str

(method)

Returns the name of the card. In the Card superclass, this is just the string ‘Card’.

get_description(self) -> str

(method)

Returns a description of the card. In the Card superclass, this is just the string ‘A card.’.

requires_target(self) -> bool

(method)

Returns True if playing this card requires a target, and False if it does not. By default, a card does require a target.

__str__(self) -> str

(method)

Returns the string representation for the card, in the format ‘{Card name}: {Card description}’.

__repr__(self) -> str

(method)

Returns the text that would be required to create a new instance of this class identical to self.