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

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 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. Figure 1: Basic class relationship diagram for the classes which need to be implemented for this assignment. 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. 2