Ninedraft
project 3



Due Friday 31st  May, 2019, 20:30





1. Introduction


This project provides you the opportunity to apply concepts taught throughout the course to extend the functionality of a basic 2d sandbox game, in the style of Minecraft & Terraria.



The main concepts involved are Graphical User Interfaces (GUIs) and object-oriented programming. The project tasks are to add features to the game, as described in the requirements below.



You are encouraged to review some similar games, to better understand how this type of game is played, and for inspiration  on advanced features. It is better to do this after reading through this document in its entirety.



Because this project deals with multiple files, while not required, you may wish to investigate a more sophisticated IDE. A popular option is PyCharm, which is free for students. VS Code, which is also free, is another common option. Please note that these tools have significantly more complex user-interfaces than IDLE, so you may find them a little overwhelming if you are only familiar with IDLE.





2. Overview
2.1. Getting Started




The archive

a3_files.zip

contains all the necessary files to start this project. A significant amount of support code has



been supplied so that you begin with a simple application that is almost working.





The main project file is

app.py , which contains an incomplete implementation of

Ninedraft , the top-level GUI



application class. The other files are support code which must not be edited. must be edited for some tasks.

crafting.py

is an exception to this rule, as it





Initially, you do not need to understand much of the provided code, but as you progress through the tasks, you will need to



understand more of this code. You should add code to functionality.

app.py

and modify

Ninedraft

to implement the necessary





You are permitted to create additional files to simplify the separation of tasks (i.e. task1.py, task2.py, etc.), although this is not



required. If you do this,

app.py

must be the entry point to your application (i.e. running it will run your project).





2.2. Pymunk Library
Physics is implemented in the game using the Pymunk library. You will need to install this library in order to implement your

tasks for this project. Pymunk can be installed by running the included setup.py .



3. project Tasks


3.1. Task Overview


This project is broken down into three main tasks:



The first task involves adding lines of code to clearly marked sections within the main projectfile.
The second task involves extending the design to add more interesting functionality to the game.
And the third task involves adding sophisticated functionality to further improve the gameplay experience.


For CSSE7030 students only, there is an extra task that involves doing independent research. In general, as the tasks progress, they are less clearly prescribed and increase in difficulty.

3.2. Task Breakdown


CSSE1001 students will be marked out of 20 and CSSE7030 students will be marked out of 26 based on the following breakdown. Tasks may be attempted in any order, but it is recommended to follow this breakdown, top-down, completing as much as possible of each task before moving on to the next.



Sub–Task Marks


9 marks


App Class 1 mark







Task 1
Basic Features

Mouse Controls 2 marks



StatusView Class 2 marks



Basic Items 1.5 marks



Keyboard Controls 1 mark



File Menu & Dialogs 1.5 marks







7 marks


Task 2

Intermediate Features

More Items 2 mark



Crafting 3.5 marks



CraftingTableBlock 1.5 marks







4 marks

Task 3

Advanced Features

Mobs 2 marks



Furnace 2 marks







6 marks

Post-Graduate Task

Independent Research

Arrow Movement 4 marks



Interaction with Blocks 2 marks





3.3. Mark Breakdown


For each task, marks will scaled according to the following breakdown.





Description Marks




Code is readable. Appropriate and meaningful identifier names have been used. Simple and clear code structure. Repeated code has been avoided.

15%




Code Quality
Code has been simplified where appropriate and is not overly convoluted. 10%


Documented clearly and concisely, without excessive or extraneous comments. 15%





Functionality Components are functional, without major bugs or unhandled exceptions.

Assessed through user testing/playing, not automated testing.

60%




4. Task 1 – Basic GUI




There are a significant number of comments in

app.py

intended to help you complete this task.





4.1. App Class




Write a

main

function that launches the

Ninedraft

GUI. Call this

main

function inside an

if name == …

block.







Modify

Ninedraft

so that the title of the window is set to something appropriate (i.e. Ninedraft, etc.).



4.2. Mouse Controls
4.2.1. Moving: Target
When the player’s mouse is moving over the game world, show the target cursor over the block position they have moused over. If the mouse leaves the game world (either to another widget or out of the window), or moves out of range, hide the preview.



Due to the program structure, once the appropriate tkinter event is bound, the only code that needs be added to achieve this is



in Ninedraft.redraw

(Mouse coordinates for the target cursor are saved when the mouse moves so that

redraw

can use



them when it is drawing).





See the

_mouse_move, redraw

methods on

Ninedraft

and the

show_target, hide_target

methods on

GameView in



game.py .



4.2.2. Left Click: Attacking (Mining)
Allow the player to attack (mine) their target block by clicking the left mouse button. Code already exists to call the attack method of the player’s effective item and to mine the block.



Most of this logic is already implemented. You need to bind the mouse button & retrieve what the block drops when it is fully mined.



Further, when a block is successfully mined, reduce the player’s health/food by an amount of your choosing according to the following rules:



If the player has food (> 0), decrease their food Otherwise, decrease their health



See the

_left_click

method on

Ninedraft .





4.2.3. Right Click: Using or Placing
When the player right clicks, one of two things should happen:



If the player is targeting a block, use that block
Otherwise, place the active item (see place)


Code has been provided that implements this functionality. You only need to bind the appropriate mouse event.





See the

_right_click

method on

Ninedraft .







See  the init , _left_click, _right_click, redraw

methods on

Ninedraft

and the

show_target,



hide_target

methods on

GameView

in game.py .





4.3. StatusView Class




Define a class named

StatusView

which inherits from

tk.Frame . This class is used to display information to the player



about their status in the game. The StatusView ‘s widgets must:



be updated whenever necessary (i.e. when gaining or losing health or food)
be laid out approximately according to Basic GUIExample
contain the following widgets:
Health (first row; left) A label to display the amount of health the player has remaining, with an image of a heart to the left. The health must be rounded to the nearest 0.5 (i.e. half or whole).

Food (first row; right) A label to display the amount of food the player has remaining, with an image of a drumstick to the left. The food must be rounded to the nearest 0.5 (i.e. half or whole).



Note: For convenience, you should have a setter method for each of the relevant widgets. i.e. set_health(health) , etc.



The

StatusView

class should be added to the application in a frame below the

GameView .





4.4. Basic Items


One basic type of item is that which drops a block form of itself when placed. For example:



When the stone item is placed, it is logical that a stone block should appear
Further, when a stone block is mined, it also is logical that it should drop a stoneitem(s)




The class

BlockItem , found in

item.py , represents an item as per #1 above.







For this task, modify the

create_item

function so that it can generate wood & stone items. These should be instances of the



BlockItem

class. E.g.





>>> wood = create_item(‘wood’)

>>> wood BlockItem(‘wood’)

>>> wood.place() [(‘block’, (‘wood,))]

>>> block_id = wood.place()[0][1]

>>> create id)

ResourceBlock(‘wood’)



You do not need to modify create_block , as the relevant code to create wood & stone blocks already exists.



4.5. Keyboard Controls
4.5.1. Movement
When the player presses the space bar, they should jump into the air. This can be achieved by modifying their velocity. Set the velocity to something reasonable, that meets the following requirements:

The y-component must be negative (because computer graphics are drawn with the positive y-axis facing down)

The x-component must not be zero, but should be different to what it was (i.e. if the player was moving left, when they jump, they should also keep moving left, but at a different speed)

Double/triple/etc. jumping is allowed, so you do not need to check that the player is on the ground before jumping



4.5.2. Hotbar
When the player presses a number key (1-9, 0), the corresponding item in the hotbar should be selected. If the corresponding item is already selected, it should instead be deselected. Note that 1 corresponds to the first (leftmost) item in the hotbar, and 0 to the last (rightmost), etc.



4.6. File Menu & Dialogs




Implement a menu bar, with a

File

menu. The File menu should have the following entries:





New Game : Restarts the game

Exit : Exits the application



When the player attempts to exit the application, either by the file menu or otherwise, they should first be prompted with a dialog to confirm that they indeed want to quit the application. Further, if the player dies, they should be informed of this with a dialog, and asked if they want to restart the game.



Note: On Mac OS X (and similar), the file menu should appear in the global menu bar (top of the screen).





5. Task 2 – Intermediate Features


For any subclasses you implement, in addition to the required methods listed, you will also need to override any relevant



methods from the super class that would raise

NotImplementedError . You will also need to modify the relevant

create_*



functions to allow your new things/items to be created.



5.1. More Items




Implement the following subclasses of the

Item

class and add them to the game:





5.1.1. FoodItem




Implement a class called

FoodItem

which inherits from

Item . When a

FoodItem(item_id: str, strength: float)



object is instantiated, it needs to be given an item identifier and a strength. The class must have the following method:



get_strength() -> float: Returns the amount of food/health to be recovered by the player by when used.

place() -> float: Returns an effect that represents an increase in the player’s food/health





Add a stack of 4 of these to the starting hotbar, and modify the food item with 2-strength)

create_item

function so that leaf blocks can drop apples (a





When food is placed, increase the player’s health/food by an amount equal to the food’s strength, according to the following rules:



If the player has lost food (< maximum), increase their food Otherwise, increase their health

Nothing should physically be “placed” in the world. For example:



>>> apple = FoodItem(‘apple’, 2)

>>> apple.place() [(‘effect’, (‘food’, 2))]

>>> apple.get_strength() 2





See

Ninedraft.run_effect





5.1.2. ToolItem




Implement a class called

ToolItem

which inherits from

Item . When equipped, tools damage certain blocks faster than the



hands, and are able to mine materials that the hands cannot (such as stone from stone blocks). A tool is depleted when its durability reaches zero.





When a

ToolItem(item_id: str, tool_type: str, durability: float)

object is instantiated, it needs to be given an



item identifier, the type of tool it will be and the tool’s durability. The class must have the following methods:



get_type() -> str: Returns the tool’s type.

get_durability() -> float: Returns the tool’s remaining durability.

can_attack() -> bool: Returns True iff the tool is not depleted.

attack(successful: bool): Attacks with the tool; if the attack was not successful, the tool’s durability should be reduced by one.





Note: For tools made of a material, such as the stone axe, the

item_id

should be

{material}_{tool_type} , according to



the break tables in item.py



For example



>>> diamond_axe = ToolItem(‘diamond_axe’, ‘axe’, 1337)

>>> diamond_axe.get_type() ‘axe’

>>> diamond_axe.get_max_stack_size() 1

>>> for _ in range(1295):

… diamond_axe.attack(False)


>>> diamond_axe.get_durability() 42



5.2. Crafting


The process of turning items into new items is called Crafting. The player can craft items and reorder their inventory/hotbar in a crafting screen. When the player presses the ‘e’ key, the basic crafting screen should toggle (switch between showing in a new window & hiding). You may assume the player will not interact with the game world while a crafting window is open.





Add the

CRAFTING_RECIPES_2x2

constant to

app.py

with at least three additional recipes of your own, and modify



Ninedraft._trigger_crafting

to open the simple crafting window. Initially, this will only show the inventory & hotbar.







Next, in the file

crafting.py , complete the

GridCrafterView

class according to the comments. You do not need to modify



any other code in this file ( GridCrafterView

is already instantiated in

CraftingWindow._load_crafter_view ).







See

CraftingWindow &

GridCrafter in

crafting.py





5.2.1. Snippets
These can also be found in


5.3. CraftingTableBlock




Implement a class called

CraftingTableBlock

which inherits from

ResourceBlock . When used, this block should trigger



the crafting table screen. From the block’s perspective, this can be achieved by returning an effect from the When mined with the correct tool, this block should drop an item form of itself. For example:

use

method.





>>> table = CraftingTableBlock()

>>> table.use()

(‘crafting’, ‘crafting_table’)

>>> table.get_drops(0, True) [(‘item’, (‘crafting_table’,))]





Add the 2×2 recipe to create the crafting table to

CRAFTING_RECIPES_2x2 . Further, add the

CRAFTING_RECIPES_3x3



constant to

app.py

with at least three additional recipes of your own.







Lastly, extend the

Ninedraft._trigger_crafting

method to open the crafting table screen.





5.3.1. Snippets
These can also be found in



6. Task 3 – Advanced Features
6.1. Mobs


Mobs are non-player-characters in the game. They are living (have health) and can move around. Some mobs can harm the player.



To complete this sub-task, in addition to subclassing Mob , you will need to add additional blocks & items to the game,



including the relevant

create_*

function, and drawing method(s) to the

WorldViewRouter

class. Further, you will need to



handle the case where the player attacks (left-clicks) a mob.



6.1.1. Sheep




Implement a class called

Sheep

which inherits from

Mob .





Sheep move around randomly and do not damage the player.



When attacked, a sheep should drop wool ( wool = BlockItem(‘wool’) ), without taking damage. This wool should be able to be dropped as a block and should be included in at least one crafting recipe.



6.1.2. Bees




Implement a class called

Bee

which inherits from

Mob .





Bees swarm the player, and individually cause a small amount of damage. They move slightly quicker than the player, and swarm toward the player in a semi-random fashion. If there is a honey block ( honey = ResourceBlock(‘honey’, …) ) nearby (within 10 blocks), they will instead swarm to the honey.



The player can attack bees, and with simple tools they should individually be destroyed in one hit.



When the player mines a hive block ( hive = HiveBlock(“hive”) ), 5 bees should spawn and begin to swarm toward the player.



6.2. Furnace


The furnace allows the player access to another form of crafting, called smelting (also known as cooking, baking, melting, drying, or burning). This process involves two items, a fuel source and the item to be heated. For example, the player can cook an apple on wood to produce a cooked apple.



Allow the player to craft a furnace on the crafting table by using a ring of stone (a 3×3 grid, with nothing in the centre). This should yield an item that can be placed as a furnace block, which when used opens the smelting screen, and when mined with a pickaxe drops an item form of itself.



Ensure that the smelting screen shows some sort of icon to represent the smelting — you may use a simple canvas shape in place of the flame shown above.



Lastly, add at least five smelting recipes to create items. You are encouraged to add new items/blocks to make this interesting (i.e. diamond, gold, grain, etc.), although this is not required.





7. CSSE7030 Task – Independent Research
7.1. Advanced Feature
This task involves adding a bow & arrow tool to the game. Add it to the player’s starting inventory.



When attacking, the bow should fire a flaming arrow at a trajectory matching the mouse’s position relative to the player. For



example, if the player is centred at

(200, 200) , and the cursor is at

(100, 100) , the bow should fire at a 45 degree angle



to the left. The further the mouse is from the player, the stronger the arrow should fire, up to some maximum (i.e. 4 blocks away).



It is intended that gravity should cause the arrow to drop, and not necessarily pass through the position on the cursor. Further, the bow should always fire, regardless of whether the target is in range.





Physics in Ninedraft is implemented in the

World

class using the pymunk library, so to successfully complete this task, you



will need to research this library and subclass World .



Further, to achieve full marks for this task, the flaming arrow must immediately destroy certain blocks on contact:



Wood is instantly destroyed and drops nothing

Hive blocks are instantly destroyed, and drop honey ( BlockItem(‘honey’) ) without spawning any bees.





8. project Submission


Note: There will not be a practical interview for the third project.



Your project must be submitted via the project three submission link on Blackboard. You must submit a zip file,



a3.zip , containing the support code.

app.py

and all the files required to run your application (including images). Your zip file must include all





Late submission of the project will not be accepted. Do not wait until the last minute to submit your project, as the time to upload it may make it late. Multiple submissions are allowed, so ensure that you have submitted an almost complete version of the project well before the submission deadline. Your latest, on time, submission will be marked. Ensure that you submit the correct version of your project. An incorrect version that does not work will be marked as your final submission.



In the event of exceptional circumstances, you may submit a request for an extension. See the course profile for details of how to apply for an extension. Requests for extensions must be made no later than 48 hours prior to the submission deadline. The expectation is that with less than 48 hours before an project is due it should be substantially completed and submittable. Applications for extension, and any supporting documentation (e.g. medical certificate), must be submitted via my.UQ. You must retain the original documentation for a minimum period of six months to provide as verification should you be requested to do so.





Change Log
Version 1.1.0 – May 17
It is recommended that you immediately update your support code. However, if you began working on the project in version 1.0.0, you may submit it with version 1.0.0 of the support code.

project Sheet



Redistributed some marks within tasks to more accurately reflect difficulty Clarified how food/health changes in 4.2. Mouse Controls & 5.1.1. FoodItem



Clarified terms

target/attack/mine/use/place

in 4.2. Mouse Controls



Clarified concepts & expanded description in 4.4. Basic Items

Significantly clarified crafting in 5.2. Crafting, 5.3. CraftingTableBlock, & 6.2. Furnace (added snippets to the first two) Fixed typographical errors, annotated relevant types, & added minor clarifications

Added screenshots of crafting to online view; also available in blackboard Reformatted example code to be in the same form as running in IDLE

Support Files


Standardised parameter names:



app.py:

create_block(block_id) ,

create_item(item_id)



block.py:

get_drops(…, correct_item_used)

method of

Block

& its subclasses



Added comments to 100% of provided source code that requires them



Moved

WorldViewRouter to

game.py , and added parameters to init ; should now be instantiated in

app.py



with

WorldViewRouter(BLOCK_COLOURS, ITEM_COLOURS)



Added

Item.get_max_durability

method & added durability display to hotbar



Fixed items not being picked up when colliding with player Mobs:



Renamed

creature.py to

mob.py



Renamed all instances of creature in

world.py

to mob (case-insensitive)



Added abstract

Mob

class & example

Bird

class



Added

time_delta &

game_data

parameters to

PhysicalThing.step

to prevent hacky solutions for



task3/post-grad



Moved

Player ‘s health to parent class to share with

Mob



Merged

geometry.py

into

core.py

(to try and reduce overwhelming number of files)



Added optional parameters task

collision_types, thing_categories to

World in

world.py

to simplify post-graduate



Added

crafting.py

with template for crafting view widget