|
School of Computing
and Information Technology
| Project 2 ISCG6420 IWD Semester 2, 2019 | 1 |
|
Create
an Interactive Application.
Total
Marks 100
Course
Weighting 50%
Check
Point1: 20 September 2019
Check
Point2: 17 October 2019
Due: 8.30am on Thursday, October 31, 2019 | ||
|
|
Learning outcomes:
| 1. Explain and apply the fundamentals of CSS (Cascading Style Sheets). |
| 2. Explain and apply the fundamentals of JavaScript. |
| 3. Use current client-side website development languages/technologies create a complex commercial or educational website. |
|
4. Use the features of Web/Multimedia authoring packages to create a complex commercial or educational website with effective navigational interface. |
Project instructions:
- You will work in pairs to create a website in your designated dochyper space.
- Project consist of two parts
Part 1 – Create an online booking system for Restaurant
Part 2 – Create interactive game for children
- You will present your part 1 and 2 of the project to the class. Presentation is compulsory. Each pair will have 15 minutes to present their work.
- Your project homepage should include links to both parts. The example of project homepage layout is given below:
Example:
|
E hoa mā Restaurant |
|
Book
Restaurant
Play
Game
Documentation
Part1
Documentation
Part2
|
|
Content |
Project submission instructions:
-
Your Project 2 web site is due by
8.30am on Thursday, October
31, 2019.
- Please put all your files in one folder. In the folder also include a signed cover sheet, this sheet includes declaration that “this submission is my own work, except where clearly referenced”.
- re-name the folder with this format – example project2_FirstStudentName_ID_ SecondStudentName_ID.
- ZIP this folder – using zip program. (DON’T use 7_zip. Don’t use rar!)
- Upload on Moodle link “Submission for Project 2”.
- Don’t upload your project 2 on dochyper yet.
- PLEASE upload your solution on Dochyper on 2 November 2019
- A copy of your submission will be kept by School of Computing and Information Technology for future reference and audit purposes for two years.
Part 1 –Online reservation system for Restaurant [45 marks]
You will develop an online booking system for Hoa Hari Restaurant, using XML as external storage and using JSON to communicate with external APA. This Restaurant has 3 seating areas: two rooms inside and deck outside. Outside deck is available for booking, if weather is permitted.
- Provide documentation for your application. Make the document link available on landing page.
-
Consider the following criteria given
below while developing an online booking system:
- Load your Restaurant data settings from XML files. Users should be able to specify a different number of people and select a date, time and table location. Date range only from today and up to next 3 days for two rooms (inside) and today booking for deck only. Your Restaurant’s layout outline is up to you. Our example is presented on the next page (page 3), Please note it is example only and it is not demonstrating all requirements.
-
Restaurant
layout must be link to data from XML file (room, table, ‘number
of people allow’). This data is presented dynamically on
booking page. Booking page is providing a popup information on
“mouse over” for each table.
- Three tables have already been taken, so users cannot book them.
- Different tables can accommodate a different number of people. Each table has a unique number.
- If table is located on deck, weather permission should be checked using external API. Booking allows if no rain and temperature is above 18 C. Weather condition should be taking from open API, please apply for your own API key. https://openweathermap.org/api.
- You need to have as minimum 6 tables in each room and minimum 7 tables on the deck. (One table is for 8 people, one table for 6 people, two tables for 4 and two tables for 2 people)
- Populate restaurant menu dynamically on the webpage. Menu must be link to data from XML file (image names, description, cost, special requirements)
-
When
populating each menu item layout consider the following:
- User must be able to dynamically see a list of menu items. Each item has image, description, type indication (vegetarian, egg free, gluten free) and cost. You need to have as minimum 12 items on your menu.
- User can select item and specify amount (for example: 2 Chicken Satay meals). Total for current selection should be display, that user can do informative choice.
- If user wants to change their selection they system should be able to update dynamically.
- On user confirmation (room, table number and menu selection) the booking system should calculate total price and provide a full statement/ list of selected items and table number. Summary for booking should have: date, time, name of Restaurant room (or deck), table number, number of people coming, menu selected and total cost.
- After booking confirmation is done- table should be marked as unavailable/booked for that time (plus two hours) and selected date.
- If user decided to add additional table for same day and time booking, his earlier selected table should be marked as booked.
Example of Restaurant Layout
Part 2 –Interactive online game [35 Mark]
You will design and develop an interactive web game for young children using HTML5 elements including Canvas.
Game story:
An animated spaceship is flying in sky and try to shout enemies. It will be shouting enemies in the sky. Spaceship shapes and colour is up to you. Spaceship task is to destroy all enemies and avoid them as they try to destroy the spaceship. Every destroyed enemy will get a score of one. If an enemy crash to the Spaceship, then a score will be deducted by one.
The story board for the game is as follows:
Game development requirements:
Character (Spaceship):
- Spaceship movement is controlled by using the keyboard arrow keys (up, down, left, right).
- You should have additional key (for example “space” ) to allow shouting.
- Shouting device direction changes, when Spaceship moves left or right. Each time Spaceship changes direction the shouting device should be in front of Spaceship.
- Spaceship movement is restricted inside the canvas.
- Every time Spaceship successfully destroy enemy, a score of one is added to the current score and a ‘happy’ sound is played. However, if an enemy touch Spaceship, an ‘unhappy’ sound will be played and crash image displayed and current score will be deducted by one.
- Define and implement Spaceship animation (light flashing, tail movement, projectors movement)
Each enemy has a life cycle which is described below:
Stage 1: a small light blue enemy with a radius = 5px will appear randomly on the any side of canvas.
Stage 2: growing time for each enemy is 5 seconds. Each enemy grows to size of radius = 25px
Stage 3: enemy’s colour changes gradually from light blue to blue in a duration of 4 seconds. Use radial gradient in diagonal direction for the colour change.
Stage 4: Each blue enemy will stay on the side for a duration of 3 seconds and will then start move.
Stage 5: movement time for each enemy is 6 seconds to cross a playable area.
Stage 6: enemy moves fly out of vision if Spaceship is unable to shout it. Or if it moves on the any side of Spaceship it should explode.
Additional requirements for the game:
- Minimum 4 different sounds in the game (like one collision beep and shouting sound, start and end game sounds) and users should be able to control the volume of the sounds.
- Provide feedback with appropriate text messages and sound to the player. For example, a mechanism to display the score to the player or text message in the end of game.
- Time settings which can be changed by player. Default time setting for duration of game is 5 minutes. Other possible value for the duration of the game is 1, 3 and 6 minutes.
- Start button and restart button.
- Overall design and complexity of scenery – background.
- Provide documentation for your application. Make the document link available on landing page.
Part 3 – Individual Task 20%
The grading for this component is weighted depending on how you performed in your homework tasks submitted on time, 10% contribution to the course grade will be taken for each homework’s across all IWD course; 10 homework – 10 marks; each mark is 2%.
Each homework task must be done by requiblue day and any delay up to 3 days will be result in 50%-mark deduction, all other delay is 0% marks.
Marking Guide
Marks for your work will be given according to the following marking schedule:
| No | Item | Criteria | Marks |
|
| Part 1 |
|
|
|
Provide documentation for
your application.
(5 marks)
XML data design ( two
files)
User booking design page
Link on the landing page
| 5 marks = both the design are in Pdf format and link(s) to the landing page is working. Clear explanation of presented data for XML data dictionary and wireframe provided for User booking design page, which has all details required for booking. 2-4 marks = one or two details in documents are missing or link(s) not working or quality of documentation is not up to standard. 1 mark = one of the document is submitted with number of errors, second document is not submitted. |
| |
| Dynamic translation Restaurant name from Maori language to English. User should be able to select a date, time and number of people coming. After that system allow to select Restaurant room, table number (system should allow table booking where number of guest equal or less that table allows. (3 marks) | 3 marks = all three input elements correctly used to develop desired functionality. 2 marks = as above with minor problems. Or one input element missing completely. 1 mark = minimum one element working |
| |
|
Load
Restaurant room settings from XML files. (5
marks)
XML files are defined and linked in the code. java-script reading from XML files. Class for table is defined. Array of instances for each table are populated dynamically. | 5 marks = all the criteria are met. 2-4 marks = one or two minor details are missing 1 mark = number of details are missing 0 = hard coded values for table array |
| |
| Populate each room layout dynamically on the webpage. (9 marks) User must be able to dynamically see table number; how many persons can set here. Already booked tables clearly indicated in your layout and user should not be able to select them for booking.. |
Total
3 marks = for each area layout
For
each room layout
3
marks = all criteria are met.
2-
marks = up to three minor functionally not working based on the
requirements.
1-2
marks = more than three of functionally not working based on the
requirements
|
| |
|
User
must be able to dynamically see a list of menu items. Each item
has image, description, type indication (vegetarian, egg free,
gluten free) and cost. Minimum 12 items on your menu.
(6
marks)
|
Total
6 marks = criteria
are met.
3
-5marks = most of
criteria are met.
2-
marks = up to three minor functionally not working based on the
requirements.
1
marks = more than three of functionally not working based on the
requirements
|
| |
|
If
user wants to change their booking selection they system should be
able to update dynamically. (3
marks)
| 3 marks = booking price is correctly calculated by the system based on the user selection. 1-2 marks – some error(s) |
| |
| On user confirmation (room, table number and menu selection) the booking system should calculate total price and provide a full statement/ list of selected items and table number. Summary for booking should have: date, time, name of Restaurant room (or deck), table number, number of people coming, menu selected and total cost. (6 marks) | 6 marks = booking information is display correctly and price is correctly calculated by the system based on the user interaction. User can see a correct summary for his booking 2-5 marks = booking information is display correctly and price is correctly calculated by the system based on the user selection. User can see a summary but some or number of details are missing. 1 marks = only total is provided and other details are missing |
| |
| After booking confirmation is done- table should be marked as unavailable/booked for that time (plus two hours) and selected date. (3 marks) | 4 marks = criteria are met. 2-3 mark if minor error in implementation. Like seats booked for all week. |
| |
| using JSON to communicate with external APA, weather check done correctly (6 marks) |
6
marks = all criteria are met.
2-5
marks = up to one or two minor functionally not working based on
the requirements.
1
marks = more than three of functionally not working based on the
requirements
|
| |
|
|
|
|
|
|
| Part 2 |
|
|
|
Spaceship movement is
controlled by using the keyboard arrow keys (up, down, left,
right).
(10 marks)
It also needs additional
key to turn the shouting device (for example- blank space).
Spaceship direction
changes, when Spaceship moves left or right. Each time Spaceship
changes direction the shouting device should be in front of
Spaceship.
Spaceship movement is
restricted inside the canvas.
Spaceship head should
always stay under the tree branches.
Every time Spaceship
successfully catches an enemy, a score of one is added to the
current score and a ‘happy’ sound is played.
|
10
marks =All criteria are met.
8-9
marks =All criteria are met with minor error or errors in
implementation. For example: Spaceship can run out of one side of
canvas.
5-8
marks =Most criteria are met with a few errors in implementation.
2-4
marks =Some criteria are met with a number of errors in
implementation.
1
marks = A number of problems in program only a few things work
with minor error.
|
| |
| However, if an enemy touch on Spaceship, an ‘unhappy’ sound will be played and current score will be deducted by one. (12 marks) Stage 1: a small light blue enemy with a radius = 5px will appear randomly on the any side of canvas. Stage 2: growing time for each enemy is 5 seconds. Each enemy grows to size of radius = 25px Stage 3: enemy’s colour changes gradually from light blue to blue in a duration of 4 seconds. Use radial gradient in diagonal direction for the colour change. Stage 4: Each blue enemy will stay on the side for a duration of 3 seconds and will then start move. Stage 5: movement time for each enemy is 6 sec. Stage 6: enemy moves fly out of vision if Spaceship is unable to shout it. Or if it moves on the any side of Spaceship it should create explosion |
12
marks = Enemy’s life cycle met all criteria described.
9-11
marks = Enemy’s life cycle met all criteria described with some
minor error or errors in one or two enemy’s stage.
5-8
marks =Most criteria are met with one of stages missing and some
minor error in other enemy’s stage implementation.
.
2-4
marks =Only some criteria are met with a number of errors in
implementation.
1
marks = A number of problems in enemies stage’s.
|
| |
|
Additional
criteria for the game:
(9 mark)
Minimum 4 different sounds
in the game and users should be able to control the volume of the
sounds.
Provide feedback with
appropriate text messages and sound to the player. For example, a
mechanism to display the score to the player or text message in
the end of game.
Time settings which can be
changed by player. Default time setting for duration of game is 5
minutes. Other possible value for the duration of the game is 1,
3 and 6 minutes
Start button and restart
button.
Overall design and
complexity of scenery – background.
|
9=
all additional game’s criteria are met.
6-8=if
one or two additional criteria are missing and/or functionality
work partly
2-5
= if more than 2 additional criteria are missing
1
= only one additional
criteria implemented with some minor error.
|
| |
|
Additional
criteria for the game:
Provide documentation for your application. (4 mark) Your own game storyboard Testing (Test Cases) | 4 marks = both the design are in Pdf format and link(s) to the landing page is working. 2-4 marks = one or two details in documents are missing or link(s) not working or quality of documentation is not up to standard. 1 mark = one of the document is submitted with number of errors, second document is not submitted. |
| |
|
|
Presentation
(-10
mark – if no presentation)
|
|
|
|
| Check Point 1: Complete Part 1 – 1, 2, 3 Part 2 -1 plus storyboards |
|
|
|
| Check Point 2: Complete Part 1 – 4, 5 ,6 Part 2 -2, 3 |
|
|
|
|
Total marks |
|
|
Rules for Late Submission of Assignments
a. The due dates of assessment work will be notified in course information.
b. Assignments submitted after the due date and time without having received an extension through Special Assessment Circumstances (SAC) will be penalised according to the following:
10% of marks deducted if submitted within 24hrs of the deadline
20% of marks deducted if submitted after 24hrs and up to 48hrs of the deadline
30% of marks deducted if submitted after 48hrs and up to 72hrs of the deadline
No grade will be awarded for an assignment that is submitted later than 72hrs after the deadline.
c. Students submitting assignments after the due date and time will be ineligible to resubmit a failed assignment.
Special Assessment Circumstances – Process
1)
In the first instance, the Student shall complete the approved form to apply for consideration of affected performance and submit the application to Student Central. Except in exceptional circumstances this must be no later than 5 working days after the due date of the Summative Assessment, and with appropriate documentary evidence of both the circumstances and the effect on performance. Except in exceptional circumstances appropriate documentary evidence such as a medical certificate must be dated within 24 hours or one working day of the due time of that Assessment item.
Academic Misconduct
Cheating and Plagiarism are consideblue Academic Dishonesty and will be dealt with under the provisions of the Student Disciplinary Statute.
Do you want to do the best that you can do on this assignment and improve your grades?
You could:
• Talk it over with your lecturer
• Visit Te Tari Awhina or Maia for learning advice and support
• Visit the Centre for Pacific Development and Support
• Contact the USU Advocate for independent advice
• For contact details and more information, go to www.usu.co.nz