AimTo give you practical experience in database modelling, no.docx

Aim:
To give you practical experience in database modelling,
normalization and writing SQL statements to query a relational
database
Assignment Summary:
The project specification details provided in this document and
you must use only given specifications to come up with your
solution. Make appropriate assumptions where ever required.
Please make sure that your group must meet your lecturer/tutor
at least twice to update the progress of your assignment.
Background Information for Sample Database Project:
Australian Manufacturing Company (AMC) requires a database
system to manage their stores, employees, products, suppliers,
patrons and orders.
The following information has been gathered about current
business activities of AMC.
AMC has many stores in different cities across Australia. Each
store has unique store number and other details like name,
contact details (phone number, email address and fax number)
and location details (postal address composed of street number,
suburb, state and postcode).
There are many departments within each store, for example, HR,
accounts, finance and sales etc. each department is uniquely
identified by department number. AMC also records department
title, phone number and email address.

Each store has a number of employees. Each department is
supervised by a department supervisor and each store is
managed by a store manager who both are employees of AMC.
Each department has a single supervisor only i.e. the department
supervisor is also the supervisor for all the employees work
within that department.
Each employee is referenced by unique employee number, name
(first and last names), address, mobile number, email, TFN,
salary and joining date. An employee’s salary is recorded
differently as per his or her employment type. Employees can be
employed as fulltime or casual basis. For a fulltime staff,
annual salary is recorded and hourly rate for a casual staff.
Each store creates payslips for all employees work in that store
on a weekly basis. As a minimum payslip number, no of hours
worked, employee detail, store detail and gross pay are
recorded.
AMC sales different products like fashion, health, beauty,
electronics etc. Each product is characterised by product
number, name, brand, description and price.
Each product can be supplied by one or more supplier and each
supplier can supply one or many products. AMC also keeps
appropriate details of their suppliers.
Each store maintains an inventory of their products available for
sale. The quantity of each product available in store and the
quantity ordered are kept.
AMC patron visits the store and shops in the store. Each
customer is characterised by customer number, name (first and
last names), mobile number and address.

A patron may place orders. An order contains one or many
products at a time. A store keeps track of order number, order
date, product(s) ordered and quantity ordered for each product.
2 | P a g e
The proprietors of AMC have appointed your group as Database
System Consultant to analyse, design and develop conceptual
data model and physical database. They want a software/online
application in future to be built on the database you design so
that the operation of the AMC is greatly improved.
Your created models must accommodate the provided
requirements. It is understandable that the provided information
may not sufficient to create model that centralise all the data
appropriately. You are free to make assumptions about their
business activities if require. Make sure you record your
assumptions.
System Requirements:
The system is a prototype system and as such is not a full
production version. You will be required to enter a
representative sample data into your tables in order to test the
design and operation of your database.
Project Specification:
1. Part A: Entity Relationship Diagram (20 marks)
1. Your first task is to study the Case study requirements and
gather as much knowledge to list all the main Entities and

attributes.
2. Create an Entity Relationship Diagram (ERD) to help you
decide on the relationships.
Your entity relation diagram that models your database design
should:
i. Include all entities, relationships (including names) and
attributes.
ii. Identify primary and foreign keys.
iii. Include cardinality/ multiplicity and show using crow’s feet
or UML notation.
iv. Include participation (optional / mandatory) symbols if
applicable.
The ERD should be created as part of a Microsoft Word
document. Hand-drawn diagrams will not be accepted. It is
recommended that you complete your ERD using Draw.io, Visio
or try www.gliffy.com (Search for ERD gliffy to get started).
2. Part B: Normalisation (10 marks)
1. Normalise all entities and relationships in optimal normal
form. Provide the normalised schema and discuss the level of
normalisation achieved for each relation. You goal should be
normalise all entities in 3NF. Provide the reasons for any
relation that is not maintained in 3NF.
3. Part C: Relational schema and MySQL database (35 marks)

1. Create relational schema that matches ERD and normalised
schemas you created in Part A and B. The schema should
include suitable data validation, integrity and referential
integrity constraints, for example, types and length of
attributes, primary and foreign keys etc. Make sure you follow
standards, naming conventions and notation. (10 Marks)
3 | P a g e
2. Using MySQL, you are required to develop a demonstration
prototype system (database) that stores data for AMC stores,
employees, products, suppliers, patrons and orders. Create a
new database called AMCDB. Create tables according to your
relational schema created in step 1. (20 Marks)
Follow a standard naming convention for table names and also
field names. Avoid using spaces and any special characters in
table and field names. Use underscore_case or use camelCase to
separate parts of a name.
You are required to be consistent in tables’ name, fields’ name,
data types, field size and key constraints with relational schema
created in step 2.
3. Add at least three records into each table. (5 Marks)
4. Part D: SQL (24 marks)
Use the AMCDB database that you created in MySQL to design
and execute SQL queries that answer the following questions.
Number your answers to each question clearly. The answer to

each questionmust be tabulated as shown in the example below
and include the SQL statement and also the output that is
produced when you execute the statement in your database. The
output includes the records that are listed and also the message
that appears when you run the SQL statement.
For example:
Question 1:
SQL:
SELECT lName, position
FROM Staff
WHERE salary > 20000;
Output:
+
-------+----------
+
| lName | position |
+
-------+----------
+

| Brand | Manager
|
| White | Manager
|
+
-------+----------
+
2 rows in set (0.03 sec)
Do not use screen captures to display the SQL statement or the
output.
You should right-click on the MySQL Command Prompt
window; choose Mark and then press the [Enter] key to Copy
and then Paste into your Word document that includes the
answers to all questions.
Format and indent the clauses in your SQL statements for better
readability and understanding as shown in the example above.
Statements must be syntactically and semantically correct.
Format both the SQL and also the Output in Courier New 10 or
11 point.
4 | P a g e

1. List the full name of Patrons, phone number and address in
the descending order of customer number. The full name is
comprised of first and last name joined with single space. Use
the alias Customer full name for the composed column heading.
(2 marks)
2. List all the products having price less than $100. (2 marks)
3. List the product number, product title, quantity ordered, unit
price and total amount per product (unit price * quantity
ordered) for order having order number 1005. (3 marks)
4. List name, full address and fax number of stores that has the
word ‘George’ anywhere in the street component of address.
Your query should consider the case sensitivity of the street as
well i.e. the stores with words ‘George’, ‘GEORGE’, ‘george’,
‘GeorGe’ etc. in street should be returned by your query too. (2
marks)
5. List all the orders having at least two different products
ordered. (2 marks)
6. List customer number, name and address of all the customers
who has not placed any order. (2 minutes)
7. Retrieve first name, last name and employee number of all
the employees along with department name and store name
where they work. (3 marks)
8. For each store, display store name and number of employees
works in account department. (2 marks)
9. List all the orders placed for financial year 2018 i.e. orders
placed after 30/06/2017 and before 01/07/2018. (2 marks)

10. Retrieve customer number and the total number of orders
placed by each customer. (2 marks)
11. For each order, retrieve the order number, order date and
number of products ordered in it. Sort the output in descending
order of order number. (2 marks)
5. Part E: Personal Report - Every group member needs to write
this part individually and add to the documentation (4 marks)
1. Write a page to the AMC proprietors as a personal reflection
that describes your experience building the database. You can
discuss any challenges / difficulties that you experienced or
solutions that you found. Comment on any limitations and / or
strengths of your database design. Comment on whether your
database meets all the system requirements as specified in
Project Specification. Avoid making excuses or comments that
reflect negativity. Include an acknowledgement of all students
you have spoken to about the assignment.
6. Part F: Report Layout, SQL script and presentation (7 marks)
1. Deliverables for Parts A, B, C, D and E must be printed as a
report with a cover sheet attached. See Administrative Details
on page 10 for more details. Your report must include header
and footer that include all the group members’ name and student
number, unit name, assignment name, and page numbers. Your
report must be checked for spelling and grammar. Your report
must also be formatted so that it is well set out and easy to read.
a) Each group must submit a single zip file on Moodle which
contains all the assignment files (single word file with

deliverables for parts A – D, separate
5 | P a g e
personal reports for each group member, MYSQL backup script
notepad file and presentation).
b) The SQL that can be used to restore your database should
also be uploaded to Moodle. You can create the SQL for your
database as follows:
Use the mysqldump command to create a text version of the
database. Use mysqldump to create SQL file that contains a list
of SQL statements which can be used to restore/recreate the
original database.
The syntax is as follows:
$ mysqldump -u [uname] -p[pass] [dbname] > [backupfile.sql]
WHERE:
[uname]
Your database username
[pass]
The password for your database
[dbname]

The name of your database
[backupfile.sql] The filename for your database backup
You do not need to log on to MySQL. For example, from the
DOS command prompt, the syntax is:
e:xamppmysqlbin>mysqldump -u root MyDB >
e:MyDB_bak.sql
This will create the SQL file that can be used to restore your
database.
OR ---
You can save your script as you go to notepad.
You are also required to present your work in the class. The
presentation can be around 5 to 10 minutes long.
7. Submission
a. When to submit
Refer to the Unit Description for due date, extensions and late
submission policy. b. What to submit
Part A
(1) Copy and paste the ERD that you created using Word, Visio,
or other software into your Word document.
(2) Title your AMC ERD.

Part B:
Include in your word document normalised schema and
discussion on which normal form each relation is in. Provide the
reasons for any relation that is not maintained in 3NF.
Part C:
6 | P a g e
(1) Include the relational schema in your documentation. The
following is sample tabular format on relational schema. You
are free to add more columns if required.
Table Name:
Field Name Data type Length Key Constraints
(3) Provide database schema of your AMCDB in your word
document. Title your AMCDB Database Schema. Below is
sample. Arrange the tables so that thelines joining tables do not

cross over (if possible). Copy and paste your diagram into your
Word document as illustrated by the following example:
DreamHome Database Schema:
(4) Use the DESCRIBE command to describe the structure of
each table in your AMCDB database. Do not use screen
captures. The following is an example of how each table should
be documented:

Part D:
(1) The answer to each SQL query question must be clearly
numbered and tabulated as shown in the example below.
Question 1:
SQL:
SELECT lName, position
FROM Staff

Output:
+
-------+----------
+
| lName | position |
+
-------+----------
+
| Brand | Manager |
8 | P a g e
| White | Manager |
+-------+----------+
2 rows in set (0.03 sec)
1. Add a heading immediately above the table to identify the
question number.
2. Include both the SQL statement and also the output that is
produced when you execute the statement in your database. The
output includes the records that are listed and also the message
that appears when you run the SQL statement.
3. Do not use screen captures to display the SQL statement or
the output. Copy the text of your SQL statement and also the
output into the table.
4. Edit the keywords of your SQL statement (if necessary) to

appear in uppercase as shown by the example above. Field
names and table names should be entered in upper or lowercase
as they appear in the database schema.
5. Format and indent the clauses in your SQL statements for
better readability and understanding as shown in the example
above. Statements must be syntactically and semantically
correct.
6. Format both the SQL and also the Output in Courier New 10
or 11 point or smaller in order to avoid wrapping.
7. Marks will be deducted where students fail to follow the
requirements given above.
Part E:
1. Include your personal report as per instructions given.
Part F:
1. PART A, B, C, D and E plus the SQL Script as described in
PART F in the specification.
2. Presentation

9 | P a g e
Administrative Details:
Deadlines: There will be NO extensions except where Calendar
rules apply. Deadlines mustbe met, unless an acceptable medical
certificate covers 25% or more of the lead-time between the
assignment and the deadline. Other absences must be accounted
for by substantiating documentation, for example a police
accident report or statutory declaration. Any assessment
activities missed for medical (or other acceptable substantiated)
reasons must be completed by a new deadline that will be
assigned in negotiation with the lecturer.

The Penalty for Late Submission of assignments is 5% of the
total marks for each day (or part thereof, including weekends)
the assignment is late. For assignments received more than 7
days after the due date, the assignment will be assessed, but a
zero mark will be awarded.
Electronic failure causing delay: In most work submissions you
have a final deadline but itis recommended that you submit well
before this time. Timely submission is your responsibility
– last minute technical disaster will not be accepted as a reason
for late submission. You are expected to have discipline in time
management, to make back-ups, and always have the back-ups
available for submission.
Your report is to be presented as a hard copy. All assessment
activities that are handed in must be presented to a professional
standard and must include:
1. A hard copy to be submitted to the designated lecturer or
nominated alternative by the due time and date. It must have a
title page which includes the student’s name and ID number,
title of assignment and a signed statement that the work is
exclusively the student’s own work and that there has been no
plagiarism or collusion. Reports without acoversheet will not be
accepted.
2. A footer to be shown on every page that includes students’
name, ID number and page #.
3. A soft copy of your report to be submitted on Moodle. The
same assignment deadlines apply to this submission format.
E-mailing of your assignment will be accepted only after
consultation with the tutor. If emailing, through arrangement
with the tutor, send the document as an e-mail attachment in MS

Word or PDF format. The subject line in the e-mail must
include student name. When sending e-mails please request an
automated receipt. Where there is doubt asto whether the
assessment activity was submitted on time, no claims for timely
submission will be accepted if there is no receipt.
Submissions not clearly identified with the author’s details as
outlined in the points above will not be marked and may result
in a 0 grade for that activity.
PLAGIARISM AND COLLUSION Any submitted work that
contains plagiarism or collusionwill be reported to the
appropriate authorities according to the University policy and
will receive an automatic zero ‘0’ mark for the assignment.

10 | P a g e
Final Report Structure:
Your final report must comprise the following parts:
Title Page
o Report title
o Names and Student IDs for group members
Table of Contents
o Should be auto-generated from Heading Styles in MS Word.
Background
o Requirements / Business Rules
o Mission Statement / System Definition
o DBMS Selection
ERD x2
o Use Gliffy.com or draw.io or Visio or any other tool to create
the Conceptual model. This is to show your design.
Normalised Schema
o Normalised schema
o Appropriate arguments provided on leaving each entity in
normal form which you considered as optimal

Database Schema
o Show each table design
o Include a screen capture of Designer tab to show table
relationships in MySQL.
o Records for each table
Foreign Key Constraints
o Show as screen captures for all tables with foreign keys.
X12 SQL Statements
o Show statement and output formatted using Courier New
o Statements should be similar to the examples given and may
include any of the following elements:
· WHERE clause with examples of various conditions (Like,
Between, =, AND / OR, IN, etc.)
· ORDER BY clause
· Concatenation to combine values including alias
· Expressions to calculate results
· 2 or 3 table joins using either new or old syntax
· Subquery
· Functions to aggregate data (SUM, MIN, MAX, AVERAGE,
COUNT) including sub-totals (GROUP BY)

Group Report
o Challenges &
Solution
s
References
o Harvard Style
o If you do not have any than just reference the prescribed text.
11 | P a g e

Database Management for BusinessDatabase Project
(Assignment) 2019 T1
Database Management for Business
Student Name: _______________________________ Student
ID: ___________
I acknowledge that this project is my own work, that there is no
collusion with other students, past or present, and that any work
used from another source has been correctly cited and
referenced (using the Harvard style).
Signed: _________________________________Date:
____________________
Marking Guide for Assignment
Part
Task
Total

Marks
A
ER Diagram:
20
Completeness of ER diagram, included all essential entities,
attributes
and relationships with names, cardinalities and participation (10
marks)

Primary and foreign keys (4 marks)
Resolution of many to many relationships (3 marks)
All assumptions clearly noted (3 marks)
Deduct marks (4 marks) if incorrect and inconsistent notation
used
B

Normalisation
10
All relations are in appropriate format (7 marks)
Appropriate arguments provided on leaving each entity in
normal form
which you considered as optimal (3 marks)
C

Relational Schema (10 marks)
35
Schema matches ERD. All tables and attributes included with
appropriate formatting i.e. data types, field size, allow null
value or not
etc. (5 marks)
Primary and foreign keys included, foreign keys with reference
to

primary table (3 marks)
Appropriate notations (2 marks)
MYSQL Database (20 marks)
Consistent translation from relational schema to MYSQL
database (15

marks)
Appropriate naming convention used (5 marks)
Records in MYSQL Database (5 marks)
At least 3 records present in all tables (3 marks)
Additional records shown (2 marks)
D

SQL & Output
24
12 | P a g e
Database Management for Business
Database Project (Assignment) 2019 T1

Q10
2
Q11
2
E
Personal Report
4
F
Report Layout, Presentation and SQL DDL Script
7

Late Penalties 5% each day late
Total:
100
Comments:

Summary on “The Quality of Social Simulation: An Example
from Research Policy Modelling”
The article explores the quality of a simulation. The authors test
and apply assessment mechanisms using a sample policy
modeling. The design aspect of simulations like Caffe Nero
resembles that of a scientific social simulation (Ahrweiler &
Gilbert, 2014). The authors develop models from a specified
target by decreasing the attributes of the latter progressively. In
each case, the aim is to derive a factor from the model that
cannot be obtained automatically from the target. The article
utilizes Caffe Nero simulation and the science simulation
because travelling to Venice would be time consuming and
expensive, and they cannot obtain information from the ‘real
system’ to determine its behavior.

The authors use the standard view and the constructivist
approach to evaluate each of the simulations. Based on these
evaluations, the authors argue that a simulation is useful when
one obtains the desired results from what they would have
derived from the original target; the exploration of the
simulation is influenced by the experiences, anticipations and
experiences of the society members that utilize it. This would
divert the user community’s attention to a highly viable
approach to evaluate the efficiency of a policy modeling
sample. To test this assumption, the authors examine concrete
policy modeling and conclude that initial discussions and
negotiations with the user community to determine their
questions were iterative, interactive, and user-driven.
“The user community plays a vital role in providing
data for calibration of the model because it is rather complex to
confirm the availability, quality, and existence check, and data
for database and format requirements” (Doran & Gilbert, 1994).
From a user’s perspective, the quality of the simulation will
depend on efficiency while calibrating the model and the quality
of the primary data. Also, the user community has to cross-
examine the credibility of the results of the simulation and has
to affirm their quality.
What alternative methodology can facilitate the realization of
credible simulation results with minimal practical

contingencies?
References
Ahrweiler, P., & Gilbert, N. (2014). The Quality of Social
Simulation: An Example from Research Policy. Miguel,
Amblard, Barceló & Madella (eds.) Advances in Computational
Social Science and Social Simulation Barcelona: Autònoma
University of Barcelona, DDD repository
<http://ddd.uab.cat/record/125597>
Doran, J. and N. Gilbert (1994): Simulating Societies: an
Introduction. In: J. Doran and N. Gilbert (eds.): Simulating
Societies: the Computer Simulation of social Phenomena.
London: UCL Press, 1-18.
Strategic Information Systems 1
NFO1110 / COMP9001 Assignment 2
Adventure

Deadline: 11:59 PM, Sunday 26th of May 2019 AEST.
Weighting: 15% of the final assessment mark.
At the heart of each adventurer burns a passion: a passion for
gold, for glory, for treasure or
fame, or an
intense, burning desire for the world to be alright so that they
could be left the hell alone. And
each adventurer
– no matter how noble, no matter how fickle or selfish they may
be, is defined by the journey
upon which they
embark.
And yours, it appears, has taken you here: to the foot of a
temple to a forgotten god, long since

lost to time.
Seek you knowledge? Seek you fame? Seek you treasures
beyond compare? Herein lay trials for
you to
overcome, dear adventurer, and the only way to go is in.
Credits: Pixabay, Uploaded by Enrique Meseguer on Nov. 13,
2017 .
Overview
Description
For this assignment, you will write a simulation of a fantasy
adventure, or a dungeon crawl. The
user will be
given controls that allows them to move through rooms and
locations in search of trials and
tribulations to

overcome (for fun and profit).
Implementation details
Your program will be written in Python 3. The only Python
modules allowed for import are sys .
To help you begin, a scaffold has been provided. Your entire
program must be contained in the
files room.py ,
simulation.py , item.py , quest.py , and adventurer.py . You
should implement the functions in
these files to
the best of your ability. You may create new functions to help
you as you see fit, but you cannot
modify any

existing function signatures (i.e. you cannot change the amount
of arguments that an existing
function can
take).
Help and feedback
You are encouraged to ask questions about the assignment on
the discussion board, on Ed.
During your tutorial in Week 12, you can also ask your tutor to
review your code. Your tutor
may provide
feedback either during the class, or outside the class on Ed.
Please ensure your code is comprehensible before requesting
feedback. We recommend that your
code
adheres to the PEP 8 style guide, and is commented

appropriately.
Staff may make announcements on Ed regarding any updates or
clarifications to the assignment.
You can ask
questions on Ed using the assignments category. Please read
this assignment description
carefully before
asking questions. Please ensure that your work is your own and
you do not share any code or
solutions with
other students.
Submission
You will submit your code on the assignment page, on Ed. You
are encouraged to submit

multiple times. After
each submission, the marking system will automatically check
your code against public test
cases.
These public tests do not cover all parts of the specification and
your code. The complete test
suite contains
both public and hidden test cases, and your code will not be run
through this suite until after the
assignment
deadline.
Please ensure you carefully follow the assignment specification.
Your program output must
exactly match the

output shown in the examples.
Warning: Any attempts to deceive or disrupt the marking system
will result in an immediate zero
for the
entire assignment. Negative marks can be assigned if you do not
properly follow the assignment
specifications, or your code is unnecessarily or deliberately
obfuscated.
Milestone
To ensure you are making regular progress on this assignment,
you must have achieved a
minimum level of
functionality in your submission by May 19th, 11:59 PM AEST
(Week 11 Sunday) to receive a

portion of the
marks. See the Milestone Submission section at the end of this
document for further details.
Program Details
Unless otherwise specified, all string values discussed in this
program specification can be
assumed to be
single-line strings.
The Adventurer
The user is represented by an Adventurer class, which you can
define in the given adventurer.py
scaffold. An
Adventurer object represents the character that the user
controls. It has three primary attributes:
An inventory , which keeps track of all the items that the user

has collected throughout the
course of the
game. When an Adventurer object is first created, this attribute
is empty.
A skill level. This represents the character’s ability to overcome
physical challenges within the
game.
This integer value begins at 5 , and never goes lower than 0 .
A measure of will power. This represents the character’s ability
to overcome mental challenges,
resist
mind-affecting effects, and influence other creatures. This
integer value also begins at 5 , and
never goes
lower than 0 .

The adventurer.py scaffold specifies a few methods that should
be implemented for the purposes
of
handling this object. This is true for all other scaffold files
provided for this assignment. Feel free
to add
as many more methods as you feel is necessary.
Rooms
Each room – or location – in the game is represented by an
object of the Room class, which you
can define in
the given room.py scaffold. A Room object has the following
attributes:

A name
A quest that can be/has been completed in this room. In some
rooms, no such quest exist (i.e. this
attribute has value None ). The room’s appearance changes
based on whether or not the quest has
been
completed, or if a quest exists in it at all.
An attribute for each of the cardinal directions: north , south ,
east , and west . Each of these
attributes
might be:
Another Room object that can be reached from this room by
moving in the appropriate direction,
or
The value None , in the case that no other rooms can be reached

from this room by going in the
specified direction.
When the user enters a Room or when the LOOK command is
invoked, a display representing
the Room is
printed to standard output . Such a display consists of:
A visualisation of the room and its possible exits: a box that is
11 lines tall and 22 characters
wide.
When an exit is present from any cardinal position (north,
south, east, west), the centre of the
corresponding wall on the map is replaced with letters, like so:
A line indicating the name of the room. It follows the form: You
are standing at the .

A separate, single line containing a short description of the
room. This description changes based
on
whether or not a relevant quest has been completed in this
room.
If there are no quests that are relevant to this Room , its
description should read: There is nothing
in this room.
+———NN———+
| |
| |
| |
| |
W E

| |
| |
| |
| |
+———SS———+
You are standing at the Foyer.
There is nothing in this room.
>>> WEST
You move to the west, arriving at the Workshop.
+——————–+
| |

| |
| |
| |
| E
| |
| |
| |
| |
+——————–+
You are standing at the Workshop.
>>>
Items

Every item in the game is represented by an object of the Item
class, which you can define in the
given
item.py scaffold. An Item object has the following attributes:
A name . This can be quite lengthy (e.g. a foul-smelling
bouquet of flowers .)
A shortname . This is usually a key word from the item’s full
name . (e.g. bouquet , or flowers .)
skill_bonus – An integer value. When an Adventurer is carrying
an item in their inventory , its
skill_bonus is added to the Adventurer ‘s skill level.
will_bonus – An integer value. Works just like skill_bonus , but
for the Adventurer ‘s will power
instead.

When a user invokes the CHECK command, they can attempt to
examine an Item more closely
by specifying
an item by its name or shortname . So long as the Item exists in
the player’s inventory , doing so
allows them
to see the Item ‘s full name , its skill_bonus , and its will_bonus
. For example:
Quests
You, the player, are an adventurer with a purpose: an adventurer
with a quest, or perhaps many
quests – tasks
for you to complete in exchange for a reward (fame, glory,
money, more treasure, you name it).
In our

program, such tasks can be represented by Quest objects. A
Quest object has the following
attributes:
A reward – some Item that is added to the player’s inventory
once the Quest is complete.
A quest action – a special action that can only be activated in
the Room that the Quest can be
completed
in. More on this later.
A quest description – a brief description of what the quest might
entail, like a hint.
before_text – This is what is printed as part of a Room’s
description if the Quest can be
completed in

that room, but the Quest is not yet complete.
after_text – This is what is printed as part of a Room’s
description if the Quest can and has been
completed in that room.
requirements to complete the quest. You can expect this to
always be a single string in two parts:
For example: SKILL 10 , WILL 6 , etc.
You can and probably should make some extra variables for the
Quest object that may not be
included in the scaffold.
fail_msg – This is printed when an Adventurer attempts to
complete a Quest , but their skill or
will
values are too low.

pass_msg – This is printed when an Adventurer attempts to
complete an Quest and succeeds!
>>> CHECK
Check what? Shield
Shimmering Shield
Grants a bonus of 5 to SKILL.
Grants a bonus of 2 to WILL.
A room that the Quest can be completed in (i.e. a Room object
that is affected by this Quest ‘s
before_text and after_text ).
This is a lot to take in, so let’s illustrate this with an example:
Okay! Let’s assume that this quest exists, and let’s see what we
might see when we enter the
Library . Let’s

assume that our Adventurer is currently carrying no items.
Reward: Tiny Cat
Action: FEED CAT
Description: FEED a hungry cat!
Before_text: A tiny cat mewls at you pathetically from a corner
of the room. It looks hungry.
After_text: There is nothing of note here – just books.
Requirements: WILL 7
Fail_msg: You offer the cat some food, but it runs away from
you!
Pass_msg: You offer the cat some food. It happily accepts, and
climbs up on your shoulders.
Looks

like you made a friend!
Room: Library
+——————–+
| |
| |
| |
| |
W |
| |
| |
| |
| |

+——————–+
You are standing at the Library.
A tiny cat mewls at you pathetically from a corner of the room.
It looks hungry.
>>> FEED CAT
You offer the cat some food, but it runs away from you!
>>> L
+——————–+
| |
| |
| |
| |

W |
| |
| |
| |
| |
+——————–+
It looks hungry.
Oh no, it looks like we don’t have enough WILL to complete
the quest! Let’s try another
example, but this
time, we are carrying some items that boost our Adventurer ‘s
WILL to a value of, say, 8 .

Note that when a Quest is complete, the relevant Room ‘s
description changes!
>>>
+——————–+
| |
| |
| |
| |
W |
| |
| |
| |

| |
+——————–+
It looks hungry.
>>> FEED CAT
You offer the cat some food. It happily accepts, and climbs up
on your shoulders. Looks like you
made a friend!
>>> LOOK
+——————–+
| |
| |
| |

| |
W |
| |
| |
| |
| |
+——————–+
There is nothing of note here – just books.
>>> INV
You are carrying:

– A Will-Booster
– A Tiny Cat
>>>
The CONFIG files
When the program begins, it creates a series of rooms, items,
and quests with different attributes
based on
the configuration files passed to it through the command line.
Your program will receive the
following
information (in the order given) as command line arguments:
path_config – the name of a file containing the list of all
connections between rooms in the
program.

Use this file to determine how many Room objects you have to
create! Each line is of the form:
Where START and DESTINATION are the names of rooms, and
DIRECTION indicates a
cardinal direction
(north, south, east, west) that the user can use to move between
START and DESTINATION .
For example:
When the program starts, the Adventurer begins in the FIRST
room specified by this file.
item_config – the name of a file defining all the items to be
found in the adventure on each line.
Each
line is of the form:

Where item_name indicates the item’s full name, and shortname
indicates an abbreviation of
item_name
that the user can use to refer to it when entering commands. For
example:
quest_config – the name of a file defining all of the quests to be
completed throughout the course
of the
game. Each line is of the form:
Examples of these configuration files are available in the
provided scaffold. Empty lines
encountered in any
config file can be safely skipped/ignored. Check for the files
paths.txt , items.txt , quests.txt
respectively.

If fewer than 3 arguments are supplied, print: “Usage: python3
simulation.py ”
and exit the program.
If any one of the configuration files are invalid (that is, they
don’t exist), print: “Please specify a
valid
configuration file.” and exit the program.
Similarly, if an empty path_config file is given, print: “No
rooms exist! Exiting program…” and
exit the
program. If an empty item_config or quest_config file is given,
the program should run
normally.
START > DIRECTION > DESTINATION

On each line of this output, the left side before the dash is
always padded so that it is 11
characters in width.
LOOK and L
Displays the room that you are currently in.
>>> QUIT
Bye!
>>> HELP
HELP – Shows some available commands.
LOOK or L – Lets you see the map/room again.
QUESTS – Lists all your active and completed quests.
INV – Lists all the items in your inventory.

CHECK – Lets you see an item (or yourself) in more detail.
NORTH or N – Moves you to the north.
SOUTH or S – Moves you to the south.
EAST or E – Moves you to the east.
WEST or W – Moves you to the west.
QUIT – Ends the adventure.
>>> LOOK
+———NN———+
| |
| |
| |
| |

| |
| |
| |
| |
| |
+——————–+
You are standing at the Entrance.
>>>
QUESTS
Shows a list of all the quests in the game.
Each line of the list comes in four parts:

A two-digit number of the form #XX , padded by 0 s.
A quest name (the quest’s reward ), padded out to 21 characters.
A quest description, and
If the quest is complete, a tag that says [COMPLETED] at the
end.
>>> L
+———NN———+
| |
| |
| |
| |
| |
| |

| |
| |
| |
+——————–+
>>>
>>> QUESTS
#00: Singing Sword – PULL the sword from the stone.
#01: Shimmering Shield – SHINE an old shield until it
shimmers.
#02: Trembling Tome – CALM a trembling tome in the

workshop.
#03: Glistening Goblet – STEAL a glistening goblet from a
distracted denizen.
>>> QUESTS
shimmers. [COMPLETED]
workshop.
distracted denizen.
If ALL quests are complete (or if there are no incomplete
quests), print the list normally. Print a
new line, then:
=== All quests complete! Congratulations! === , and end the
program.

INV
Shows a printout of the user’s inventory.
If the user is carrying nothing, it instead says:
CHECK
Allows the user to examine items. it will ask them for a second
input, which can be an item’s
name or its short
name.
>>> QUESTS
[COMPLETED]

workshop. [COMPLETED]
distracted denizen. [COMPLETED]
=== All quests complete! Congratulations! ===
>>> INV
You are carrying:
– A Shimmering Shield
– A Singing Sword
>>> INV
You are carrying:
Nothing.
>>> CHECK

Check what? Shimmering Shield
Shimmering Shield
>>> CHECK
Check what? Shield
Shimmering Shield
>>>
If no such item exists in the user’s inventory, it will instead
print:
Inputting ME the second time around allows one to examine
their in-game statistics, and will

print out the
statistics of any item they are carrying, as well.
>>> CHECK
Check what? ME
You are an adventurer, with a SKILL of 5 and a WILL of 5.
You are carrying:
Shimmering Shield
With your items, you have a SKILL level of 10 and a WILL
power of 7.
The final line talks about what the user’s statistics are after all

bonuses from items have been
applied. If the
adventurer is carrying nothing, print the following:
>>> CHECK
Check what? ME
You are carrying:
Nothing.
power of 5.
>>> CHECK
Check what? Grass Sword
You don’t have that!

| |
+———SS———+
There is nothing of note here.
>>> EAST
You move to the east, arriving at the Parlour.
+——————–+
| |
| |
| |
| |
W |

| |
| |
| |
| |
+——————–+
You are standing at the Parlour.
A couple of fat cats are here, playing cards.
>>>
If there is no room that can be accessed from by moving in the
specified direction, they will
instead print:
>>> EAST

You can’t go that way.
Invalid Commands
If the user enters an invalid command, print You can’t do that.
and ask for another command.
>>> CRY
You can’t do that.
>>>
Quest Actions
A quest action is a special action that can only be activated in
the Room that the relevant Quest
can be
completed in. This is an attribute that has been stored as a
string in a relevant Quest object. Each
Room can

only contain one Quest , and so can only have one relevant
quest action .
The output following a quest action is contingent on two things:
1. Whether or not the quest has been completed, and if not,
2. Whether or not the Adventurer has enough SKILL or WILL to
complete the quest.
For cases 1 and 2, let’s assume that we are working with a quest
that has yet to be completed.
Case 1: If the Adventurer inputs a quest action without enough
SKILL or WILL to complete the
quest, they
will receive the quest’s fail_msg , and nothing changes.
+——————–+
| |

| |
| |
| |
| |
| |
| |
| |
| |
+———SS———+
You are standing at the Courtyard.
A beautiful silver sword has been wedged deep into a stone
pedestal here.
>>> PULL SWORD

You struggle to pull the sword from the stone, but despite your
best efforts, it doesn’t budge.
>>> L
+——————–+
| |
| |
| |
| |
| |
| |
| |
| |

| |
+———SS———+
pedestal here.
>>>
Case 2: If the Adventurer inputs a quest action and is capable of
completing the quest, they will
receive the
quest’s pass_msg , the quest’s reward will be placed in their
inventory , and the description of
the room
should change.
+——————–+

| |
| |
| |
| |
| |
| |
| |
| |
| |
+———SS———+

pedestal here.
>>> PULL SWORD
You heave against the stone and pull the sword free from its
grasp. You hear the sharp hum of
the
blade as it moves through the air – a job well-accomplished.
>>> L
+——————–+
| |
| |
| |
| |
| |

| |
| |
| |
| |
+———SS———+
A stone pedestal lies in the centre of the room, devoid of
swords.
>>>
Case 3: The quest is already complete. Regardless of the
Adventurer ‘s SKILL or WILL value,
they will see the

following message: You have already completed this quest.
+———NN———+
| |
| |
| |
| |
W E
| |
| |
| |
| |
+———SS———+

An old, battered shield rests against the wall here.
>>> SHINE SHIELD
The shield shines and shimmers like a mirror made of steel. You
decide to take it with you.
>>> SHINE SHIELD
You have already completed this quest.
>>>
Case 4: If you attempt the right quest action , but in the wrong
room, you’ll receive this message
(as if you’d
just entered an invalid command):
+———NN———+

| |
| |
| |
| |
W E
| |
| |
| |
| |
+———SS———+
>>> PULL SWORD

>>>
Submission and Mark Breakdown
Submit your assignment on Ed in the Assignments section of the
Assessments tab. The marking
breakdown of
this assignment is as follows (15 marks total).
3 marks will be awarded as a progress mark, as described in the
Milestone Submission section
below.
4 marks will be awarded for code correctness, assessed by
automatic test cases on Ed. Some test
cases

will be hidden and will not be available before the deadline.
8 marks will be given through hand-marking.
2 of these marks will be for code style, readability, and
appropriate code comments.
A further 2 marks will be on general code/logical correctness
(does your program basically
function
as it should, but fails the automarking for some reason?)
The remaining 4 marks will be awarded for the submission of
test cases.
Submitting Test Cases
A test case is numbered, and consists of the following files
(where XX is the number associated
with that test

case, e.g. 01 ):
XX_input.txt – The input for your test case.
XX_path.txt , XX_item.txt , XX_quest.txt – path, item, and
quest configuration files for your test
case.
XX_expected.txt – The expected output for your test case.
Such test cases should be placed in a tests directory, which
should be included when you upload
your
program for submission on Ed. Justifications for each test case
must be written in a
README.txt file in this
tests directory.

For the sake of clarity, an example test case (numbered 00 ) and
the README.txt file has also
been
included the scaffold, inside the tests directory.
You are expected to build a suite of at least 9 test cases. If
you’re unsure of where to start, it is
recommended
that you attempt to build one trivial and one non-trivial test
case for each command, because a
portion of the
marks awarded will be for the amount of coverage offered by
your test cases.
Using Test Cases
For reference, this is how we expect to use your test cases. You
can do the same thing in your

terminal in
order to test your code yourself:
python3 simulation.py XX_path.txt XX_item.txt XX_quest.txt <
XX_input.txt > XX_actual.txt
diff XX_expected.txt XX_actual.txt
The first line creates a new file, XX_actual.txt , that contains
the output of your program given
your test
case’s input. The second line compares the contents of
XX_actual.txt and XX_expected.txt , and
will notify
you if they are any different (i.e. the program fails your test
case).
If the second line produces no output, the program has passed
your test case ( XX_actual.txt and

XX_expected.txt are the same).
Milestone Submission
2 marks will be awarded for a submission before May 19th,
11:59 PM AEST (Week 11 Sunday)
that meet the
following criteria:
1. The program runs without crashing.
2. The program can successfully detect the existence of
configuration files (and appropriately
handles cases
where no configuration files exist).
3. The draw() function in room.py can draw an empty room,
with no exits.

4. The take() function in adventurer.py actually changes the
contents of the Adventurer ‘s
inventory.
5. Given a complete path_config file and empty item_config and
quest_config files, the game
can receive
commands (in any order) without crashing. The following
commands should print the first line
of
output correctly:
HELP
QUIT
LOOK and L
INV (Since the user has no way to receive any items, you only
have to account for the case

where
the user is carrying nothing).
CHECK
1 mark will be awarded for submitting a suite of three test
cases. Make a test case for each of the
following
cases:
There are 3 quests to complete. It is possible to complete all 3
quests, but only if you do them in
a
specific order.
There are 3 quests to complete. It is possible to complete one of
the quests, but due to the

requirements
of the other two, no more can be completed.
quests and end with a WILL value
of 0 .
Academic declaration
By submitting this assignment, you declare the following:
I declare that I have read and understood the University of
Sydney Student Plagiarism:
Coursework Policy and
Procedure, and except where specifically acknowledged, the
work contained in this
assignment/project is my own
work, and has not been copied from other sources or been

previously submitted for award or
assessment.
I understand that failure to comply with the Student Plagiarism:
Coursework Policy and
Procedure can lead to severe
penalties as outlined under Chapter 8 of the University of
Sydney By-Law 1999 (as amended).
These penalties may
be imposed in cases where any significant portion of my
submitted work has been copied
without proper
acknowledgment from other sources, including published works,
the Internet, existing programs,
the work of other

students, or work previously submitted for other awards or
assessments.
I realise that I may be asked to identify those portions of the
work contributed by me and
required to demonstrate
my knowledge of the relevant material by answering oral
questions or by undertaking
supplementary work, either
written or in the laboratory, in order to arrive at the final
assessment mark.
I acknowledge that the School of Computer Science, in
assessing this assignment, may reproduce
it entirely, may
provide a copy to another member of faculty, and/or
communicate a copy of this assignment to a

plagiarism
checking service or in-house computer program, and that a copy
of the assignment may be
maintained by the
service or the School of Computer Science for the purpose of
future plagiarism checking.
Adventure_Scaffold/simulation.py
from room import Room
from item import Item
from adventurer import Adventurer
from quest import Quest
import sys

def read_paths(source):
"""Returns a list of lists according to the specifications in a
config file, (source).
source contains path specifications of the form:
origin > direction > destination.
read_paths() interprets each line as a list with three elements,
containing exactly those attributes. Each list is then added to a
larger list, `paths`, which is returned."""
# TODO
return None

def create_rooms(paths):
"""Receives a list of paths and returns a list of rooms based on
those paths. Each room will be generated in the order that they
are found."""
# make variables which temporarily store name of room
# and also stores the direction of next room and
# the name of the next room
name_of_room_list = []
direction_list = []
destination_list = []

name_of_room = ""
direction = ""
destination = ""
pathfile = open(paths ,"r")
# if len(pathfile)==0:
# print("No rooms exist! Exiting program...")
while True:
temp = pathfile.readline()

if temp == "":
break
result = [x.strip() for x in temp.split('>')]
name_of_room = result[0]
direction = result[1]
destination = result[2]
direction_list.append(direction)
destination_list.append(destination)
if (len(name_of_room_list) == 0):

name_of_room = Room(name_of_room)
name_of_room.set_path(direction,destination)
name_of_room_list.append(name_of_room)
count = 0
for i in range(len(name_of_room_list)):
if name_of_room_list[i] != name_of_room:
count +=1
if count == len(name_of_room_list):
name_of_room = Room(name_of_room)
name_of_room.set_path(direction,destination)
name_of_room_list.append(name_of_room)

return name_of_room_list
return None

def generate_items(source):
"""Returns a list of items according to the specifications in a
source contains item specifications of the form:
item name | shortname | skill bonus | will bonus
"""
# TODO
return None

if len(sys.argv) < 4:
print("Usage: python3 simulation.py <paths> <items>
<quests>")
sys.exit()
try:
file_path = sys.argv[1]
file_item = open(sys.argv[2],"r")
file_quest = open(sys.argv[3],"r")
create_rooms(file_path)

## code here
# file_path.flush()
# file_path.close()
file_item.flush()
file_item.close()
file_quest.flush()
file_quest.close()
except FileNotFoundError:
print("Please specify a valid configuration file.")
sys.exit()

adv = Adventurer()
room = create_rooms(file_path)[0]
room.draw()
print("")
while True :
commands = input(">>> ").upper()
if commands == "QUIT":
print("Bye!")

sys.exit(0)
elif commands == "HELP" :
print("HELP - Shows some available commands.")
print("LOOK or L - Lets you see the map/room again.")
print("QUESTS - Lists all your active and completed
quests.")
print("INV - Lists all the items in your inventory.")
print("CHECK - Lets you see an item (or yourself) in more
detail.")
print("NORTH or N - Moves you to the north.")
print("SOUTH or S - Moves you to the south.")
print("EAST or E - Moves you to the east.")
print("WEST or W - Moves you to the west.")
print("QUIT - Ends the adventure.")

print("")
elif commands == "LOOK" or commands == "L":
print("")
elif commands == "QUESTS":
print("")
elif commands == "INV":
print("You are carrying:")
adv.check_self()
elif commands == "CHECK":
item_string = input("Check what?")
elif commands == "NORTH" or commands == "N":
room = room.move(commands)

elif commands == "SOUTH" or commands == "S":
elif commands == "EAST" or commands == "E":
elif commands == "WEST" or commands == "W":
else:
print("You can't do that.")
print("")
# TODO: Retrieve info from CONFIG files. Use this
information to make Adventurer, Item, Quest, and Room
objects.

# TODO: Receive commands from standard input and act
appropriately.
__MACOSX/Adventure_Scaffold/._simulation.py
Adventure_Scaffold/adventurer.py
class Adventurer:
def __init__(self):
# initialize the inventory as an empty list
self.inventory = []
def get_inv(self):
return self.inventory
def get_skill(self):
"""TODO: Returns the adventurer's skill level. Whether this
value is generated before or after item bonuses are applied is

your decision to make."""
...
def get_will(self):
"""TODO: Returns the adventurer's will power. Whether this
value is generated before or after item bonuses are applied is
your decision to make."""
...
def take(self, item):
self.get_inv().append(item)
def check_self(self):
"""TODO: Shows adventurer stats and all item stats."""
# print("You are an adventurer, with a SKILL of 5 and a WILL
of 5")
if len(self.inventory) == 0:
print("Nothing.")
print("")
...
__MACOSX/Adventure_Scaffold/._adventurer.py

Parlour > WEST > Foyer
Workshop > EAST > Foyer
__MACOSX/Adventure_Scaffold/._paths.txt
Adventure_Scaffold/tests/00_item.txt
__MACOSX/Adventure_Scaffold/tests/._00_item.txt
Adventure_Scaffold/tests/00_quest.txt
__MACOSX/Adventure_Scaffold/tests/._00_quest.txt
Adventure_Scaffold/tests/00_input.txt
LOOK
CRY
N
S
QUESTS
__MACOSX/Adventure_Scaffold/tests/._00_input.txt

Adventure_Scaffold/tests/00_expected.txt
+---------NN---------+
| |
| |
| |
| |
| |
| |
| |
| |
| |
+--------------------+
You are standing at the Garden.
>>>
+---------NN---------+
| |
| |
| |
| |
| |
| |
| |

| |
| |
+--------------------+
You are standing at the Garden.
>>> You can't do that.
>>> You move to the north, arriving at the Plaza.
+--------------------+
| |
| |
| |
| |
| |
| |
| |
| |
| |
+--------------------+
You are standing at the Plaza.
>>> You can't go that way.

>>>
__MACOSX/Adventure_Scaffold/tests/._00_expected.txt
Adventure_Scaffold/tests/README.txt
00 - No quests, room with no exits.
__MACOSX/Adventure_Scaffold/tests/._README.txt
Adventure_Scaffold/tests/00_path.txt
Garden > NORTH > Plaza
__MACOSX/Adventure_Scaffold/tests/._00_path.txt
__MACOSX/Adventure_Scaffold/._tests
Adventure_Scaffold/quests.txt
Singing Sword | PULL SWORD | PULL the sword from the
stone. | A beautiful silver sword has been wedged deep into a
stone pedestal here. | A stone pedestal lies in the centre of the

room, devoid of swords. | SKILL 10 | You struggle to pull the
sword from the stone, but despite your best efforts, it doesn't
budge. | You heave against the stone and pull the sword free
from its grasp. You hear the sharp hum of the blade as it moves
through the air - a job well-accomplished. | Courtyard
Shimmering Shield | SHINE SHIELD | SHINE an old shield
until it shimmers. | An old, battered shield rests against the wall
here. | There is nothing of note here. | SKILL 3 | You shine and
buff the shield as much as you can, but you cannot seem to
return it to its former glory. | The shield shines and shimmers
like a mirror made of steel. You decide to take it with you. |
Foyer
Trembling Tome | CALM TOME | CALM a trembling tome in
the workshop. | A voluminous tome trembles violently in its
bookshelf, threatening to bring the whole thing down on itself. |
All is calm in this room. A battered, but well-stocked bookshelf
keeps things together along the western wall. | WILL 5 | You
reach forth to try calming the book, but the bookshelf just
trembles harder! Did that book just snap at you with... teeth? |

You reach out and stroke along the spine of the Trembling
Tome. You hear the sound of ruffling pages, and the shuddering
stops, allowing you to check out the book with no problems. |
Workshop
Glistening Goblet | STEAL GOBLET | STEAL a glistening
goblet from a distracted denizen. | A couple of fat cats are here,
playing cards. They stop from time to time to drink from the
glistening, ruby-encrusted goblets beside them, to varying
degrees of success. | A couple of fat cats are here, engrossed in
a game of cards. | SKILL 12 | You reach for the goblet, but one
of the cats notices you and swats your hand away, hissing. | You
distract one of the cats for a good while, just petting it. The fur
is really soft, and they purr receptively to your touch - which is
just as well, because that gives you the time to steal a
Glistening Goblet from right under their noses. | Parlour
__MACOSX/Adventure_Scaffold/._quests.txt
Adventure_Scaffold/quest.py
class Quest:

def __init__(self, reward, action, desc, before, after, req,
fail_msg, pass_msg, room):
"""TODO: Initialises a quest."""
...
def get_info(self):
"""TODO: Returns the quest's description."""
...
def is_complete(self):
"""TODO: Returns whether or not the quest is complete."""
def get_action(self):
"""TODO: Returns a command that the user can input to attempt
the quest."""
...
def get_room_desc(self):
"""TODO: Returns a description for the room that the quest is
currently in. Note that this is different depending on whether or
not the quest has been completed."""
...
def attempt(self, player):

"""TODO: Allows the player to attempt this quest.
Check the cumulative skill or will power of the player and all
their items. If this value is larger than the required skill or will
threshold for this quest's completion, they succeed and are
rewarded with an item (the room's description will also change
because of this).
Otherwise, nothing happens."""
...
__MACOSX/Adventure_Scaffold/._quest.py
Adventure_Scaffold/item.py
class Item:
def __init__(self, name, short, skill_bonus, will_bonus):
"""TODO: Initialises an item."""
...
def get_name(self):
"""TODO: Returns an item's name."""
...
def get_short(self):

"""TODO: Returns an item's short name."""
...
def get_info(self):
"""TODO: Prints information about the item."""
...
def get_skill(self):
"""TODO: Returns the item's skill bonus."""
...
def get_will(self):
"""TODO: Returns the item's will bonus."""
...
__MACOSX/Adventure_Scaffold/._item.py
Adventure_Scaffold/room.py
class Room:
def __init__(self, name):
self.name = name

self.North = False
self.n_room = ""
self.South = False
self.s_room = ""
self.East = False
self.e_room = ""
self.West = False
self.w_room = ""
def get_name(self):

return
def get_short_desc(self):
file_quest = open('quest.txt','r')
read_quest = [file_quest.readline().strip("|")]
if read_quest == "":
return "There is nothing in this room."
else:
return read_quest[1]
def get_quest_action(self):
"""TODO: If a quest can be completed in this room, returns a
command that the user can input to attempt the quest."""

def set_quest(self, q):
"""TODO: Sets a new quest for this room."""
def get_quest(self):
"""TODO: Returns a Quest object that can be completed in this
room."""
def set_path(self, dir, dest):
"""TODO: Creates an path leading from this room to another."""
if dir == "NORTH":

self.North = True
self.n_room = dest
return self.North and self.n_room
elif dir == "SOUTH":
self.South = True
self.s_room = dest
return self.South and self.s_room
elif dir == "EAST":
self.East = True
self.e_room = dest
return self.East and self.e_room
elif dir == "WEST":

self.West = True
self.w_room = dest
return self.West and self.w_room
def draw(self):
if self.North == True:
print("")
print("+---------NN---------+")
print("| |")
print("| |")
print("| |")

print("W E")
elif self.East == True and self.West == False:
print("| E")
elif self.West == True and self.East == False:
print("W |")
else:
print("| |")

print("| |")
print("| |")
print("+--------------------+")
get_name = "You are standing at the {}.".format(self.name)
print(get_name)
self.get_name()
print("There is nothing in this room.")

def move(self, dir):
"""TODO: Returns an adjoining Room object based on a
direction given. (i.e. if dir == "NORTH", returns a Room object
in the north)."""
if dir == "N":
dir == "NORTH"
elif dir == "S":
dir == "SOUTH"
elif dir == "E":
dir == "EAST"
elif dir == "W":
dir == "WEST"

if dir == "NORTH":
if self.North == True:
dest = self.n_room
else:
print("You can't go that way")
return self
if dir == "SOUTH":
if self.South == True:
dest = self.s_room
else:

return self
if dir == "EAST":
if self.East == True:
dest = self.e_room
else:
return self
if dir == "WEST":
if self.West == True:

dest = self.w_room
else:
return self
print("You move to the {}, arriving at the
{}.".format(dir.lower(),dest.name))
dest.name()
return dest
...
__MACOSX/Adventure_Scaffold/._room.py

__MACOSX/._Adventure_Scaffold
Strategic Information Systems 1
NFO1110 / COMP9001 Assignment 2
Adventure
Deadline: 11:59 PM, Sunday 26th of May 2019 AEST.
Weighting: 15% of the final assessment mark.
At the heart of each adventurer burns a passion: a passion for
gold, for glory, for treasure or fame, or an
intense, burning desire for the world to be alright so that they
could be left the hell alone. And each adventurer
– no matter how noble, no matter how fickle or selfish they may
be, is defined by the journey upon which they
embark.
And yours, it appears, has taken you here: to the foot of a
temple to a forgotten god, long since lost to time.
Seek you knowledge? Seek you fame? Seek you treasures
beyond compare? Herein lay trials for you to
overcome, dear adventurer, and the only way to go is in.
Credits: Pixabay, Uploaded by Enrique Meseguer on Nov. 13,
2017 .
Overview
Description
For this assignment, you will write a simulation of a fantasy
adventure, or a dungeon crawl. The user will be

given controls that allows them to move through rooms and
locations in search of trials and tribulations to
overcome (for fun and profit).
Implementation details
Your program will be written in Python 3. The only Python
modules allowed for import are sys .
To help you begin, a scaffold has been provided. Your entire
program must be contained in the files room.py ,
simulation.py , item.py , quest.py , and adventurer.py . You
should implement the functions in these files to
the best of your ability. You may create new functions to help
you as you see fit, but you cannot modify any
existing function signatures (i.e. you cannot change the amount
of arguments that an existing function can
take).
Help and feedback
You are encouraged to ask questions about the assignment on
the discussion board, on Ed.
During your tutorial in Week 12, you can also ask your tutor to
review your code. Your tutor may provide
feedback either during the class, or outside the class on Ed.
Please ensure your code is comprehensible before requesting
feedback. We recommend that your code
adheres to the PEP 8 style guide, and is commented
appropriately.

Staff may make announcements on Ed regarding any updates or
clarifications to the assignment. You can ask
questions on Ed using the assignments category. Please read
this assignment description carefully before
asking questions. Please ensure that your work is your own and
you do not share any code or solutions with
other students.
Submission
You will submit your code on the assignment page, on Ed. You
are encouraged to submit multiple times. After
each submission, the marking system will automatically check
your code against public test cases.
These public tests do not cover all parts of the specification and
your code. The complete test suite contains
both public and hidden test cases, and your code will not be run
through this suite until after the assignment
deadline.
Please ensure you carefully follow the assignment specification.
Your program output must exactly match the
output shown in the examples.
Warning: Any attempts to deceive or disrupt the marking system
will result in an immediate zero for the
entire assignment. Negative marks can be assigned if you do not
properly follow the assignment
specifications, or your code is unnecessarily or deliberately

obfuscated.
Milestone
To ensure you are making regular progress on this assignment,
you must have achieved a minimum level of
functionality in your submission by May 19th, 11:59 PM AEST
(Week 11 Sunday) to receive a portion of the
marks. See the Milestone Submission section at the end of this
document for further details.
Program Details
Unless otherwise specified, all string values discussed in this
program specification can be assumed to be
single-line strings.
The Adventurer
The user is represented by an Adventurer class, which you can
define in the given adventurer.py scaffold. An
Adventurer object represents the character that the user
controls. It has three primary attributes:
An inventory , which keeps track of all the items that the user
has collected throughout the course of the
game. When an Adventurer object is first created, this attribute
is empty.
A skill level. This represents the character’s ability to overcome
physical challenges within the game.
This integer value begins at 5 , and never goes lower than 0 .
A measure of will power. This represents the character’s ability

to overcome mental challenges, resist
mind-affecting effects, and influence other creatures. This
integer value also begins at 5 , and never goes
lower than 0 .
The adventurer.py scaffold specifies a few methods that should
be implemented for the purposes of
handling this object. This is true for all other scaffold files
provided for this assignment. Feel free to add
as many more methods as you feel is necessary.
Rooms
Each room – or location – in the game is represented by an
object of the Room class, which you can define in
the given room.py scaffold. A Room object has the following
attributes:
A name
A quest that can be/has been completed in this room. In some
rooms, no such quest exist (i.e. this
attribute has value None ). The room’s appearance changes
based on whether or not the quest has been
completed, or if a quest exists in it at all.
An attribute for each of the cardinal directions: north , south ,
east , and west . Each of these attributes
might be:
Another Room object that can be reached from this room by
moving in the appropriate direction, or

The value None , in the case that no other rooms can be reached
from this room by going in the
specified direction.
When the user enters a Room or when the LOOK command is
invoked, a display representing the Room is
printed to standard output . Such a display consists of:
A visualisation of the room and its possible exits: a box that is
11 lines tall and 22 characters wide.
When an exit is present from any cardinal position (north,
south, east, west), the centre of the
corresponding wall on the map is replaced with letters, like so:
A line indicating the name of the room. It follows the form: You
are standing at the .
A separate, single line containing a short description of the
room. This description changes based on
whether or not a relevant quest has been completed in this
room.
If there are no quests that are relevant to this Room , its
description should read: There is nothing
in this room.
+———NN———+
| |
| |
| |
| |

W E
| |
| |
| |
| |
+———SS———+
>>> WEST
You move to the west, arriving at the Workshop.
+——————–+
| |
| |
| |
| |
| E
| |
| |
| |
| |
+——————–+
You are standing at the Workshop.
>>>
Items

Every item in the game is represented by an object of the Item
class, which you can define in the given
item.py scaffold. An Item object has the following attributes:
A name . This can be quite lengthy (e.g. a foul-smelling
bouquet of flowers .)
A shortname . This is usually a key word from the item’s full
name . (e.g. bouquet , or flowers .)
skill_bonus – An integer value. When an Adventurer is carrying
an item in their inventory , its
skill_bonus is added to the Adventurer ‘s skill level.
will_bonus – An integer value. Works just like skill_bonus , but
for the Adventurer ‘s will power
instead.
When a user invokes the CHECK command, they can attempt to
examine an Item more closely by specifying
an item by its name or shortname . So long as the Item exists in
the player’s inventory , doing so allows them
to see the Item ‘s full name , its skill_bonus , and its will_bonus
. For example:
Quests
You, the player, are an adventurer with a purpose: an adventurer
with a quest, or perhaps many quests – tasks
for you to complete in exchange for a reward (fame, glory,
money, more treasure, you name it). In our
program, such tasks can be represented by Quest objects. A

Quest object has the following attributes:
A reward – some Item that is added to the player’s inventory
once the Quest is complete.
A quest action – a special action that can only be activated in
the Room that the Quest can be completed
in. More on this later.
A quest description – a brief description of what the quest might
entail, like a hint.
before_text – This is what is printed as part of a Room’s
description if the Quest can be completed in
that room, but the Quest is not yet complete.
after_text – This is what is printed as part of a Room’s
description if the Quest can and has been
completed in that room.
requirements to complete the quest. You can expect this to
always be a single string in two parts:
For example: SKILL 10 , WILL 6 , etc.
You can and probably should make some extra variables for the
Quest object that may not be
included in the scaffold.
fail_msg – This is printed when an Adventurer attempts to
complete a Quest , but their skill or will
values are too low.
pass_msg – This is printed when an Adventurer attempts to

complete an Quest and succeeds!
>>> CHECK
Check what? Shield
Shimmering Shield
A room that the Quest can be completed in (i.e. a Room object
that is affected by this Quest ‘s
before_text and after_text ).
This is a lot to take in, so let’s illustrate this with an example:
Okay! Let’s assume that this quest exists, and let’s see what we
might see when we enter the Library . Let’s
assume that our Adventurer is currently carrying no items.
Reward: Tiny Cat
Action: FEED CAT
Description: FEED a hungry cat!
Before_text: A tiny cat mewls at you pathetically from a corner
of the room. It looks hungry.
After_text: There is nothing of note here – just books.
Requirements: WILL 7
Fail_msg: You offer the cat some food, but it runs away from
you!
Pass_msg: You offer the cat some food. It happily accepts, and
climbs up on your shoulders. Looks
like you made a friend!

Room: Library
+——————–+
| |
| |
| |
| |
W |
| |
| |
| |
| |
+——————–+
It looks hungry.
>>> FEED CAT
You offer the cat some food, but it runs away from you!
>>> L
+——————–+
| |
| |
| |
| |
W |
| |

| |
| |
| |
+——————–+
It looks hungry.
Oh no, it looks like we don’t have enough WILL to complete
the quest! Let’s try another example, but this
time, we are carrying some items that boost our Adventurer ‘s
WILL to a value of, say, 8 .
Note that when a Quest is complete, the relevant Room ‘s
description changes!
>>>
+——————–+
| |
| |
| |
| |
W |
| |
| |
| |
| |
+——————–+

It looks hungry.
>>> FEED CAT
You offer the cat some food. It happily accepts, and climbs up
on your shoulders. Looks like you
made a friend!
>>> LOOK
+——————–+
| |
| |
| |
| |
W |
| |
| |
| |
| |
+——————–+
There is nothing of note here – just books.
>>> INV
You are carrying:
– A Will-Booster
– A Tiny Cat

>>>
The CONFIG files
When the program begins, it creates a series of rooms, items,
and quests with different attributes based on
the configuration files passed to it through the command line.
Your program will receive the following
information (in the order given) as command line arguments:
path_config – the name of a file containing the list of all
connections between rooms in the program.
Use this file to determine how many Room objects you have to
create! Each line is of the form:
Where START and DESTINATION are the names of rooms, and
DIRECTION indicates a cardinal direction
(north, south, east, west) that the user can use to move between
START and DESTINATION . For example:
When the program starts, the Adventurer begins in the FIRST
room specified by this file.
item_config – the name of a file defining all the items to be
found in the adventure on each line. Each
line is of the form:
Where item_name indicates the item’s full name, and shortname
indicates an abbreviation of item_name
that the user can use to refer to it when entering commands. For
example:
quest_config – the name of a file defining all of the quests to be

completed throughout the course of the
game. Each line is of the form:
Examples of these configuration files are available in the
provided scaffold. Empty lines encountered in any
config file can be safely skipped/ignored. Check for the files
paths.txt , items.txt , quests.txt respectively.
If fewer than 3 arguments are supplied, print: “Usage: python3
simulation.py ”
and exit the program.
If any one of the configuration files are invalid (that is, they
don’t exist), print: “Please specify a valid
configuration file.” and exit the program.
Similarly, if an empty path_config file is given, print: “No
rooms exist! Exiting program…” and exit the
program. If an empty item_config or quest_config file is given,
the program should run normally.
START > DIRECTION > DESTINATION
item_name | shortname | skill_bonus | will_bonus
Singing Sword | sword | 10 | 2
Reward | quest action | quest description | before_text |
after_text | requirements |
fail_message | pass_message | room
Commands

Unless stated otherwise, all commands are case insensitive.
QUIT
At any point, the user may end the simulation.
HELP
The simulation lists all valid commands and their usage.
On each line of this output, the left side before the dash is
always padded so that it is 11 characters in width.
LOOK and L
Displays the room that you are currently in.
>>> QUIT
Bye!
>>> HELP
HELP – Shows some available commands.
LOOK or L – Lets you see the map/room again.
QUESTS – Lists all your active and completed quests.
INV – Lists all the items in your inventory.
CHECK – Lets you see an item (or yourself) in more detail.
NORTH or N – Moves you to the north.
SOUTH or S – Moves you to the south.
EAST or E – Moves you to the east.
WEST or W – Moves you to the west.
QUIT – Ends the adventure.
>>> LOOK
+———NN———+
| |

| |
| |
| |
| |
| |
| |
| |
| |
+——————–+
>>>
QUESTS
Shows a list of all the quests in the game.
Each line of the list comes in four parts:
A two-digit number of the form #XX , padded by 0 s.
A quest name (the quest’s reward ), padded out to 21 characters.
A quest description, and
If the quest is complete, a tag that says [COMPLETED] at the
end.
>>> L
+———NN———+
| |
| |
| |

| |
| |
| |
| |
| |
| |
+——————–+
>>>
>>> QUESTS
shimmers.
workshop.
distracted denizen.
>>> QUESTS
workshop.

distracted denizen.
If ALL quests are complete (or if there are no incomplete
quests), print the list normally. Print a new line, then:
=== All quests complete! Congratulations! === , and end the
program.
INV
Shows a printout of the user’s inventory.
If the user is carrying nothing, it instead says:
CHECK
Allows the user to examine items. it will ask them for a second
input, which can be an item’s name or its short
name.
>>> QUESTS
[COMPLETED]
workshop. [COMPLETED]
distracted denizen. [COMPLETED]
>>> INV
You are carrying:
– A Shimmering Shield

– A Singing Sword
>>> INV
You are carrying:
Nothing.
>>> CHECK
Check what? Shimmering Shield
Shimmering Shield
>>> CHECK
Check what? Shield
Shimmering Shield
>>>
If no such item exists in the user’s inventory, it will instead
print:
Inputting ME the second time around allows one to examine
their in-game statistics, and will print out the
statistics of any item they are carrying, as well.
>>> CHECK
Check what? ME
You are carrying:
Shimmering Shield

power of 7.
The final line talks about what the user’s statistics are after all
bonuses from items have been applied. If the
adventurer is carrying nothing, print the following:
>>> CHECK
Check what? ME
You are carrying:
Nothing.
power of 5.
>>> CHECK
Check what? Grass Sword
You don’t have that!
>>>
NORTH or N | SOUTH or S | EAST or E | WEST or W
Moves the user to a connecting room in that specified direction.
+———NN———+
| |
| |
| |
| |

W E
| |
| |
| |
| |
+———SS———+
There is nothing of note here.
>>> EAST
You move to the east, arriving at the Parlour.
+——————–+
| |
| |
| |
| |
W |
| |
| |
| |
| |
+——————–+
You are standing at the Parlour.
A couple of fat cats are here, playing cards.
>>>
If there is no room that can be accessed from by moving in the

specified direction, they will instead print:
>>> EAST
You can’t go that way.
Invalid Commands
If the user enters an invalid command, print You can’t do that.
and ask for another command.
>>> CRY
>>>
Quest Actions
A quest action is a special action that can only be activated in
the Room that the relevant Quest can be
completed in. This is an attribute that has been stored as a
string in a relevant Quest object. Each Room can
only contain one Quest , and so can only have one relevant
quest action .
The output following a quest action is contingent on two things:
1. Whether or not the quest has been completed, and if not,
2. Whether or not the Adventurer has enough SKILL or WILL to
complete the quest.
For cases 1 and 2, let’s assume that we are working with a quest
that has yet to be completed.
Case 1: If the Adventurer inputs a quest action without enough
SKILL or WILL to complete the quest, they
will receive the quest’s fail_msg , and nothing changes.

+——————–+
| |
| |
| |
| |
| |
| |
| |
| |
| |
+———SS———+
pedestal here.
>>> PULL SWORD
You struggle to pull the sword from the stone, but despite your
best efforts, it doesn’t budge.
>>> L
+——————–+
| |
| |
| |
| |
| |
| |

| |
| |
| |
+———SS———+
pedestal here.
>>>
Case 2: If the Adventurer inputs a quest action and is capable of
completing the quest, they will receive the
quest’s pass_msg , the quest’s reward will be placed in their
inventory , and the description of the room
should change.
+——————–+
| |
| |
| |
| |
| |
| |
| |
| |
| |
+———SS———+

pedestal here.
>>> PULL SWORD
You heave against the stone and pull the sword free from its
grasp. You hear the sharp hum of the
blade as it moves through the air – a job well-accomplished.
>>> L
+——————–+
| |
| |
| |
| |
| |
| |
| |
| |
| |
+———SS———+
A stone pedestal lies in the centre of the room, devoid of
swords.
>>>
Case 3: The quest is already complete. Regardless of the
Adventurer ‘s SKILL or WILL value, they will see the
following message: You have already completed this quest.

+———NN———+
| |
| |
| |
| |
W E
| |
| |
| |
| |
+———SS———+
>>> SHINE SHIELD
The shield shines and shimmers like a mirror made of steel. You
decide to take it with you.
>>> SHINE SHIELD
You have already completed this quest.
>>>
Case 4: If you attempt the right quest action , but in the wrong
room, you’ll receive this message (as if you’d
just entered an invalid command):
+———NN———+
| |
| |

| |
| |
W E
| |
| |
| |
| |
+———SS———+
>>> PULL SWORD
>>>
Submission and Mark Breakdown
Submit your assignment on Ed in the Assignments section of the
Assessments tab. The marking breakdown of
this assignment is as follows (15 marks total).
3 marks will be awarded as a progress mark, as described in the
Milestone Submission section below.
4 marks will be awarded for code correctness, assessed by
automatic test cases on Ed. Some test cases
will be hidden and will not be available before the deadline.
8 marks will be given through hand-marking.
2 of these marks will be for code style, readability, and
appropriate code comments.

A further 2 marks will be on general code/logical correctness
(does your program basically function
as it should, but fails the automarking for some reason?)
The remaining 4 marks will be awarded for the submission of
test cases.
Submitting Test Cases
A test case is numbered, and consists of the following files
(where XX is the number associated with that test
case, e.g. 01 ):
XX_input.txt – The input for your test case.
XX_path.txt , XX_item.txt , XX_quest.txt – path, item, and
quest configuration files for your test case.
XX_expected.txt – The expected output for your test case.
Such test cases should be placed in a tests directory, which
should be included when you upload your
program for submission on Ed. Justifications for each test case
must be written in a README.txt file in this
tests directory.
For the sake of clarity, an example test case (numbered 00 ) and
the README.txt file has also been
included the scaffold, inside the tests directory.
You are expected to build a suite of at least 9 test cases. If
you’re unsure of where to start, it is recommended
that you attempt to build one trivial and one non-trivial test
case for each command, because a portion of the

marks awarded will be for the amount of coverage offered by
your test cases.
Using Test Cases
For reference, this is how we expect to use your test cases. You
can do the same thing in your terminal in
order to test your code yourself:
python3 simulation.py XX_path.txt XX_item.txt XX_quest.txt <
XX_input.txt > XX_actual.txt
diff XX_expected.txt XX_actual.txt
The first line creates a new file, XX_actual.txt , that contains
the output of your program given your test
case’s input. The second line compares the contents of
XX_actual.txt and XX_expected.txt , and will notify
you if they are any different (i.e. the program fails your test
case).
If the second line produces no output, the program has passed
your test case ( XX_actual.txt and
XX_expected.txt are the same).
Milestone Submission
2 marks will be awarded for a submission before May 19th,
11:59 PM AEST (Week 11 Sunday) that meet the
following criteria:
1. The program runs without crashing.
2. The program can successfully detect the existence of
configuration files (and appropriately handles cases

where no configuration files exist).
3. The draw() function in room.py can draw an empty room,
with no exits.
4. The take() function in adventurer.py actually changes the
contents of the Adventurer ‘s inventory.
5. Given a complete path_config file and empty item_config and
quest_config files, the game can receive
commands (in any order) without crashing. The following
commands should print the first line of
output correctly:
HELP
QUIT
LOOK and L
INV (Since the user has no way to receive any items, you only
have to account for the case where
the user is carrying nothing).
CHECK
1 mark will be awarded for submitting a suite of three test
cases. Make a test case for each of the following
cases:
quests, but only if you do them in a
specific order.
There are 3 quests to complete. It is possible to complete one of
the quests, but due to the requirements

of the other two, no more can be completed.
quests and end with a WILL value of 0 .
Academic declaration
By submitting this assignment, you declare the following:
I declare that I have read and understood the University of
Sydney Student Plagiarism: Coursework Policy and
Procedure, and except where specifically acknowledged, the
work contained in this assignment/project is my own
work, and has not been copied from other sources or been
previously submitted for award or assessment.
I understand that failure to comply with the Student Plagiarism:
Coursework Policy and Procedure can lead to severe
penalties as outlined under Chapter 8 of the University of
Sydney By-Law 1999 (as amended). These penalties may
be imposed in cases where any significant portion of my
submitted work has been copied without proper
acknowledgment from other sources, including published works,
the Internet, existing programs, the work of other
students, or work previously submitted for other awards or
assessments.
I realise that I may be asked to identify those portions of the
work contributed by me and required to demonstrate
my knowledge of the relevant material by answering oral
questions or by undertaking supplementary work, either

written or in the laboratory, in order to arrive at the final
assessment mark.
I acknowledge that the School of Computer Science, in
assessing this assignment, may reproduce it entirely, may
provide a copy to another member of faculty, and/or
communicate a copy of this assignment to a plagiarism
checking service or in-house computer program, and that a copy
of the assignment may be maintained by the
service or the School of Computer Science for the purpose of
future plagiarism checking.

AimTo give you practical experience in database modelling, no.docx

Recommended

More Related Content

Similar to AimTo give you practical experience in database modelling, no.docx (6)

More from simonlbentley59018 (20)

Recently uploaded (20)

AimTo give you practical experience in database modelling, no.docx