CSSE1001程序语言代做、代写CSS，Python编程、代写c+,java程序

日期：2021-05-19 10:11

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 Interface

(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.

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 feature

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.

via informative and complete docstrings.

Some important or complex blocks of

logic are clarifed by informative comments.

Some comments are extraneous.

Algorithmic Logic &

Design

(25%)

Code is modular, minimising duplication

of logic and keeping data as local as possible.

Symbolic constants are used to

minimise dependency on literal values.

Logic is expressed succinctly and clearly

through the use of appropriate control

structures.

Most code is modular, minimising duplication

of logic and keeping data as local

as possible. Symbolic constants are usually

used to minimise dependency on literal

values. Logic is usually expressed

clearly through the use of appropriate

control structures.

Some code is not modular, resulting in

duplication of logic or excessive sharing

of data. Symbolic constants are only occassionally

used to minimise dependency

on literal values. Some logic is not clear

or uses inappropriate control structures.

Object-Oriented

Program Structure

(30%)

Almost all classes represent single, selfcontained,

concepts in the program. The

GUI’s view and control logic is clearly

separated from the model. Objects do

not break encapsulation by accessing attributes

of other objects. Public interfaces

of classes provide a simple and clear

abstraction of how to use objects of the

class. Inheritance simplifies the design.

Polymorphism allows the design to be

easily extended.

Most classes represent single, selfcontained,

concepts in the program. The

GUI’s view and control logic is mostly

separated from the model. Objects do

not break class interfaces by accessing

attributes of objects of other class types.

Public interfaces of most classes provide

a clear abstraction of how to use objects

of the class. Inheritance usually simpli-

fies the design. Polymorphism allows the

design to be extended in some ways.

Only some classes represent single, selfcontained,

concepts in the program. In

parts of the program, the GUI’s view

and control logic are not clearly separated

from the model. Objects break

class interfaces by accessing attributes of

objects of other class types. Many methods

are made public, when they should

be private, or a few attributes are public.

Some use of inheritance complicates

the design. Polymorphism does not allow