Poke′mon Assignment 2 Semester 2, 2021 CSSE1001/CSSE7030 Due date: 16:00, 8th of October, 2021 GMT+10 1 Introduction Loosely speaking, the engine of a game computes the state of the game whereas the graphical user interface displays the state. For instance, in chess, change_position was part of the game engine whereas print_board is part of the GUI. For this assignment implement a (simplified) game engine for Pokemon battles. For those unfa- miliar with how Pokemon battles play out, a video example is provided here.1. The extent to which our engine differs from the real game is described in Section 3. You are not developing a GUI because we have provided one (so you can play the game whose engine you wrote). You are required to implement a number of classes and their subsequent methods which are described in Section 4. Any changes to these requirements will be listed in a changelog under the Assignment 2 folder in Blackboard. 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 that test. 2 Getting Started Download a2.zip from Blackboard — this archive contains the necessary files to start this as- signment. 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 Constants, functions, and classes you may find helpful for writing the engine. Read the docstrings in order to understand how to use them in your solution. game.py If you wish, run this file to play the your Pokemon game. battle view.py Instruction for drawing the game to the screen. 1https://youtu.be/s37zGwC0Z7Y t=32 1 data.py Data about Pokemon, moves and trainers, used in the game. images A folder with images used by the battle view. 3 Gameplay The general structure of a Pokemon battle is given in the next section, followed by a more in-depth description of each component. 3.1 Overview Pokemon battles take place between two trainers, say, Ash and Brock. Both Ash and Brock have a roster of (at most) six Pokemon, that battle until all Pokemon in one roster have fainted. Trainers can only ever have one Pokemon on the battle field while the rest are in reserve. Battles are turn-based. Each turn, a trainer may select an action to perform. These actions have priority, and are enacted in order of that priority. If a Pokemon faints in battle, the only valid action its trainer may take, is to switch it out for another non-fainted Pokemon from the roster, presuming one exists. If all Pokemon in a roster have fainted, the trainer whose Pokemon are left standing is the winner, and the battle ends. 2 3.2 Actions Each turn, a trainer may perform one of the following actions: Fight: Order the Pokemon on the field of battle to use a move. Item: Use an item from their inventory Switch: Swap the active Pokemon with one from the roster. Flee: The trainer attempts to flee from the battle. When valid actions are applied, they alter the battle from one state to the next. 3.3 Pokemon Each Pokemon in the roster has the following attributes: Name: A name. Type: An elemental type which influences how vulnerable the Pokemon is to certain moves. Level: A general measure of how strong a Pokemon is. Health: Also referred to as HP (health points), when a Pokemon’s health reaches 0, it is said to have fainted. Stats: A description of the Pokemon’s attack and defense capabilities. Pokemon stats increase with level. Moves: A maximum of four moves that the Pokemon can use while battling. 3.4 Moves Like the Pokemon itself, each move has an elemental type which determines how effective it is against other Pokemon. Each move also has a number of uses before it cannot be used again. Moves have the further subcategories: Attacks: If successful, reduce the health of the enemy Pokemon. Buffs: Increase (i.e. strengthen) the current Pokemon’s stats. Debuffs: Decrease (i.e. weaken) the enemy Pokemon’s stats. 3 4 Implementation There are many more classes required for this assignment that are not describe in the gameplay section. The class diagram below lays out all of these classes, and the basic relationships between them. Hollow-arrowheads indicate inheritance (i.e. the “is-a” relationship). Dotted arrows indicates composition (i.e. the “has-a” relationship). Figure 1: Basic class relationship diagram for the classes which need to be implemented for this assign- ment. Strategy and its subclasses are Masters-only tasks. A few of the relationships (e.g. between Action and Battle) have been ommitted for the sake of formatting. The precise relationships are captured in the documentation referenced in the next section. 4.1 What goes inside each class This assignment uses online documentation, that is accessible on the CSSE1001 website.2 You will find a description of each class and its required methods at the link. 4.2 Where to start When implementing a spec where each component has dependencies, it is often best practice to start with the components that have the least dependencies. In this case, both the ActionSummary and PokemonStats classes have no dependencies and should therefore be implemented first. It is also recommended that you leave Action and its subclasses until last. The CSSE1001 youtube channel has some video examples 3 of how to attack a spec like this, that you might find useful. 2http://csse1001.uqcloud.net/assignments/a2.html 3https://youtu.be/DcVqhoCJDx0 4 4.3 ActionSummary Messages Every time an action is ‘applied’ to the game state, it returns a corresponding ActionSummary containing the effects of that action. This section details the messages expected from applying each action. Flee: On success: Got away safely! On failure: Unable to escape a trainer battle. SwitchPokemon: If trainer’s turn and their Pokemon has not yet fainted:
