This is the remaining portion of an assignment previously done by your expert on order 79517 (displayed name:sandeep). The logical file will be provided, the GUI part needs to be made. The file a3spec contains the requirements of the assignment.
CSSE1001 Assignment 3 Due 8pm, Friday 28th May 2021 1 Introduction In Assignment 2 you implemented a text-based game, EndOfDayz. This game was intentionally structured in such a way that the modelling logic and the view classes for displaying content to the user could be modified fairly independently. In this assignment, you will exchange the text-based interface of EndOfDayz with a more sophisticated tkinter-based Graphical User In- terface (GUI), and implement additional functionality. You can find information about tkinter in this introduction to tkinter1 and in this tkinter reference2. In Assignment 3 the user is presented with a map, on which entities are represented by either coloured squares or images. As opposed to Assignment 2, where the step event was triggered by user input, in this assignment the step event is triggered every second for all entities other than the player. The player’s behaviour is triggered by key presses. 1.1 Variations from Assignment 2 When the player picks up an item, that item is added to an inventory, but not immediately applied. The inventory is displayed to the right of the game map. The user can activate and deactivate items by left clicking on them in the inventory. When an item is activated, it should begin working, and its lifetime should decrease by 1 every second. An example of the final game is shown in Figure 1. Additonally, the player can no longer run into a zombie to remove it from the game. 2 Tips and Hints This assignment is split into two tasks, with an additional task for CSSE7030 students. The number of marks associated with each task is not an indication of difficulty. Task 1 may take less effort than task 2, yet is worth significantly more marks. A fully functional attempt at task 1 will likely earn more marks than attempts at both task 1 and task 2 that have many errors throughout. Likewise, a fully functional attempt at a single part of task 1 will likely earn more marks than an attempt at all of task 1 that has many errors throughout. While you should be testing regularly throughout the coding process, at the minimum you should not move on to task 2 until you have convinced yourself (through testing) that task 1 works relatively well. If you are a CSSE7030 student, you should not attempt the CSSE7030 task until you have convinced yourself (through testing) that task 1 and task 2 both work relatively well. 1https://web.archive.org/web/20171112065310/http://effbot.org/tkinterbook/ 2https://anzeljg.github.io/rin2/book2/2405/docs/tkinter/index.html?fbclid=IwAR0MRN_ QOr-A-dYrfoWW2NAFUlrjyoF02PRBUv63OCl3tVBgLvrTXR2NZJ8 1 https://web.archive.org/web/20171112065310/http://effbot.org/tkinterbook/ https://anzeljg.github.io/rin2/book2/2405/docs/tkinter/index.html?fbclid=IwAR0MRN_QOr-A-dYrfoWW2NAFUlrjyoF02PRBUv63OCl3tVBgLvrTXR2NZJ8 https://web.archive.org/web/20171112065310/http://effbot.org/tkinterbook/ https://anzeljg.github.io/rin2/book2/2405/docs/tkinter/index.html?fbclid=IwAR0MRN_QOr-A-dYrfoWW2NAFUlrjyoF02PRBUv63OCl3tVBgLvrTXR2NZJ8 https://anzeljg.github.io/rin2/book2/2405/docs/tkinter/index.html?fbclid=IwAR0MRN_QOr-A-dYrfoWW2NAFUlrjyoF02PRBUv63OCl3tVBgLvrTXR2NZJ8 Figure 1: Example fully functional game (at the end of task 2). Except where specified, minor differences in the look (e.g. colours, fonts, etc.) of the GUI are acceptable. Except where specified, you are only required to do enough error handling such that regular game play does not cause your program to crash or error. If an attempt at a fea- ture causes your program to crash or behave in a way that testing other functionality becomes difficult, comment it out before submitting your assignment. Your marker will not modify your code in order to test functionality. You must only make use of libraries listed in Appendix A. Importing anything that is not in this list will result in a deduction of up to 100%. You may use any course provided code in your assignment. This includes any code from the support files or sample solutions for previous assignments from this semester only, as well as any lecture or tutorial code provided to you by course staff. However, it is your responsibility to ensure that this code is styled appropriately, and is an appropriate and correct approach to the problem you are addressing. 2 3 Task 1: Basic Gameplay Task 1 requires you to implement a functional GUI-based version of EndOfDayz. At the end of this task your game should look like Figure 2. There are three major sections to the GUI; a heading label at the top, the game map (bottom left), and the inventory (bottom right). Figure 2: Example game at the end of task 1. To complete this task you will need to implement various view classes, including a basic graphical interface, which handles most of the event handling that was previously handled in TextInterface and its subclasses. You must use the supplied Assignment 2 solution for most of the modelling, as this solution contains additional functionality that was not required in your Assignment 2. You may create additional modelling classes if they benefit your solution. User input events should cause behaviour as per Table 1. Event Behaviour Key Press: ‘w’ Player moves up one square if the map permits. Key Press: ‘a’ Player moves left one square if the map permits. Key Press: ‘s’ Player moves down one square if the map permits. Key Press: ‘d’ Player moves right one square if the map permits. Left click on inventory view If the left click occurs anywhere on a row containing an item, the ‘activated’ status of that item is toggled (see Section 3.2.3 for details). If the left click occurs elsewhere nothing should happen (in particular no errors should occur). Table 1: Task 1 events and their corresponding behaviours. 3 The player can move independently of the step events. That is, the player can move multiple times within the space of a single step event for the other entities. When the player wins or loses the game they should be informed of the outcome via a message- box, and asked whether they would like to play again. If the user opts to play again, the current game should be reset to its initial state and the user should be able to replay the game. If they opt not to play again the program should terminate. Hint: tkinter’s messagebox.askquestion or messagebox.askyesno may be useful in achieving this. The following sub-sections outline the recommended structure for your code. You will benefit from writing these classes in parallel, but you should still test individual methods as you write them. Within this section we outline some methods that may be useful to write in the view classes for task 1. Type hints are omitted, as it is up to you to determine what these should be. These lists are not necessarily complete and you may include additional methods if they improve the design of your classes. You may also need to add more methods to these classes for task 2 and/or the CSSE7030 task. 3.1 Model Classes Model classes should be defined as per Assignment 2. You may add more modelling classes if they improve the code. You may modify the classes as you see fit, but any changes must be submitted with your assignment. 3.2 View Classes You must implement view classes for the game map and the inventory. However, because these widgets can both be represented by grids of rectangles, you should create an abstract class to factor out the shared functionality. 3.2.1 AbstractGrid AbstractGrid is an abstract view class which inherits from tk.Canvas and provides base functionality for other view classes. An AbstractGrid can be thought of as a grid with a set number of rows and columns, which supports creation of text at specific positions based on row and column. The number of rows may differ from the number of columns, and the cells may be non-square. You must define the constructor for the AbstractGrid class as: • init (self, master, rows, cols, width, height, **kwargs): The parameters rows and cols are the number of rows and columns in the grid, width and height are the width and height of the grid (in pixels) and **kwargs signifies that any additional named arguments supported by tk.Canvas should also be supported by AbstractGrid. The following methods may be useful to include in the AbstractGrid class. • get bbox(self, position): Returns the bounding box for the (row, column) position; this is a tuple containing information about the pixel positions of the edges of the shape, in the form (x min, y min, x max, y max). • pixel to position(self, pixel): Converts the (x, y) pixel position (in graphics units) to a (row, column) position. 4 • get position center(self, position): Gets the graphics coordinates for the center of the cell at the given (row, column) position. • annotate position(self, position, text): Annotates the center of the cell at the given (row, column) position with the provided text. 3.2.2 BasicMap BasicMap is a view class which inherits from AbstractGrid. Entities are drawn on the map using coloured rectangles at different (row, column) positions. You must annotate the rectangles of all entities with what they represent (as per Figure 2). You must use the create rectangle and create text methods from tk.Canvas to achieve this. The colours representing each entity are: • Zombies: Light green (#B8D58E) • Pickups: Light purple (#E5E1EF) • Player and Hospital: Dark purple with white text (#371D33) • Background: Light brown (#B5B28F) Your program should work for reasonable map sizes, and you may assume that the map will always be square (i.e. the number of rows will always be equal to the number of columns). The BasicMap class should be instantiated as BasicMap(master, size, **kwargs). The size pa- rameter is the number of rows (= number of columns) in the grid. Each rectangle should be 50 pixels high and 50 pixels wide. You should set the background colour of the BasicMap instance by using the kwargs. It may be useful to add the following method to the BasicMap class: • draw entity(self, position, tile type): Draws the entity with tile type at the given position using a coloured rectangle with superimposed text identifying the entity. 3.2.3 InventoryView InventoryView is a view class which inherits from AbstractGrid and displays the items the player has in their inventory. This class also provides a mechanism through which the user can activate an item held in the player’s inventory. When a player picks up an item it is added to the inventory and displayed in the next free row in the inventory view, along with its maximum lifetime. Unlike in Assignment 2, the item is not immediately applied. Instead, when the user left clicks on the InventoryView in the row displaying that item, the item is: • ‘Activated’ if the item was not already activated and no other item is currently active. Only one item may be active at any given time. Once activated, the row of the inventory view should be highlighted as per Figure 2, the lifetime should begin to decrease by 1 every game step (i.e. every second), and this change in lifetime should be reflected in the inventory view. • ‘Deactivated’ if the item was activated. The item should no longer be highlighted, the lifetime countdown should stop