Design Specification - Astro Exploration

GAME13-374: DESIGNING FOR EMERGING TECHNOLOGY (182)
DESIGN SPECIFICATION DOCUMENT
astro
exploration
BY OLIVIA MEREDITH & SAMUEL TULLOCH
AN EDUCATIONAL AUGMENTED REALITY TOOL
VERSION 2 - 06/08/18

REVISION HISTORY
GROUP ASSESSMENTS
EXECUTIVE SUMMARY
1.0 INTRODUCTION
1.1 PURPOSE & PRODUCT SCOPE
1.2 REFERENCES
2.0 OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE AND FUNCTIONS
2.2 TARGET AUDIENCE AND CHARACTERISTICS
2.3 ASSUMPTIONS, DEPENDENCIES & CONSTRAINTS
2.4 USER DOCUMENTATION
3.0 EXTERNAL INTERFACE REQUIREMENTS
3.1 USER INTERFACES
3.1.1 GENERAL LOGICAL CHARACTERISTICS
3.1.2 MENU FLOW
3.1.3 GUI STYLE GUIDE
3.2 HARDWARE INTERFACES
3.3 SOFTWARE INTERFACES
3.4 COMMUNICATION INTERFACES
4.0 SYSTEM FEATURES
4.1 PLANET CARDS
4.2 QUESTION CARDS
4.3 COMBINING CARDS
4.5 CARD PLAY MAT
5.0 STORYBOARDS AND ASSETS
5.1 STORYBOARD - EXPLORATION
5.2 STORYBOARD - USING THE CARD PLAY MAT
5.3 ASSETS
5.3.1 PLANET TEXTURES
5.3.2 PLANET CARDS
5.3.3 QUESTION CARDS
5.3.4 ADDITIONAL GRAPHICS
5.3.5 AUDIO & SCRIPTS
6.0 RISK MANAGEMENT
7.0 SCHEDULE & TIME BUDGET
7.1 WORK PACKAGES & DEPENDENCIES
7.2 SCHEDULES
APPROVAL
GROUP MEMBER TIME LOGS
TABLE OF CONTENTS
PG.03
PG.04
PG.06
PG.07
PG.23
PG.35
PG.38
PG.09
PG.14
PG.27
PG.44
PG.45
NOTE: SECTION HEADINGS CAN BE CLICKED ON TO NAVIGATE THE DOCUMENT

REVISION HISTORY
As this specification document is a continuation of our Augmented Reality class practical mini-assignment submitted 02/07/18,
the revisions made for Version One refer to the changes made between our initial practical and our Assignment One submission.
Revisions for Version 2 are those that were made between the Assignment One and Assignment Two submissions.
name date reason for changes version
TEAM-BASED 03/07
Decided to incorporate question cards with proximity-based interactions as an additional element with the goal of prolonging
engagement, making the application less of a gimmick and putting more focus on education.
1
SAMUEL 09/07 The card play mat was incorporated into the project plan as an error prevention strategy. 1
TEAM-BASED 11/07
Added the concept of difficulty levels with time trial “challenges” to add a sense of goal based motivation, prolonging
engagement, and offering rewards.
1
TEAM-BASED 12/07 The design of the planet cards’ was altered to be more relevant and recognisable. 1
OLIVIA 17/07 Sourced “free for commercial use” fonts to replace those used in the prototype and created original GUI assets. 2
OLIVIA 18-24/07
Made multiple changes to the augmented reality image targets as we worked to develop designs that achieved balance
between a consistent aesthetic and being different enough for the software to not get them confused at different angles.
2
TEAM-BASED 31/07
Decided against incorporating difficulty levels in the form of time trial challenges. After seeing the way children at Open Day
were interacting with the application as a group and the enthusiasm that created, it was seen as an unnecessary feature that
would contradict one of the application’s strengths.
2
TEAM-BASED 03/08 Decided against including atmospheric music, aside from on the menu screens. See page 34 for more information. 2
TEAM-BASED 05/08
Having decided against offering a time trial mode, the physical reward became unnecessary too. It no longer made sense to
offer a physical reward when we were encouraging group interactions, and it is believed the questions and their associated
points offer an appropriate level of optional competition.
2
03/51

GROUP ASSESSMENT
1.0 team effort put into this project:
2.0 what areas still need improvement?
Although the team’s communication is usually quite good, there are times when frustration has gotten the best of us. This has happened when trying to communicate diver-
gent ideas or approaches. We can improve this aspect of our team dynamics by slowing down, listening more closely and being more thoughtful when choosing words.
4. if you were not able to complete your project, explain why and what happened?
The project was successfully completed on time.
additional comments:
As the project’s team members are very different and have many skills in separate areas, we are doing our best to work to our strengths.
Olivia produced the majority of this specification document, however Samuel’s ideas and ability to find design solutions has been incredibly beneficial to the project’s direc-
tion. As we continue on to the next stage, Samuel will be responsible for the majority of the C# script requirements and associated functionalities, whilst Olivia will focus on
project management, the graphical user interfaces and other visual design elements.
(FORMATIVE) TEAM SELF-ASSESSMENT - GRADE OUT OF 100 - [ 80 ]
(FORMATIVE) OLIVIA’S SELF-ASSESSMENT - GRADE OUT OF 100 - [ 90 ]
(FORMATIVE) SAMUEL’S SELF-ASSESSMENT - GRADE OUT OF 100 - [ 50 ]
3.0 What areas of the project are you most proud of?
The project team’s ability to brainstorm together, communicate effectively, manage conflict, find ways to best manage our differences and work to our strengths.
In addition to this, the project itself is something to be proud of. We are proud of the project we have envisioned, we feel passionate about its purpose, and we are eager to
continue into the development stage as we work to bring it into fruition.
04/51
Assignment #1 - 16/07/18

GROUP ASSESSMENT
1.0 team effort put into this project:
2.0 what areas still need improvement?
We would have liked to incorporate more research into this project to provide support for our claims and to prove the application’s benefits. Unfortunately, the project’s scope
didn’t allow for this however we do intend to work on this aspect as we move forward with the project.
4. if you were not able to complete your project, explain why and what happened?
The project was successfully completed on time.
additional comments:
As the project’s team members are very different and have many skills in separate areas, we personally feel as though we did a great job at working to our strengths.
We are very pleased with what we have accomplished in such a short period of time and we look forward to continuing to work on the project beyond the submission of this
piece of assessment.
(FORMATIVE) TEAM SELF-ASSESSMENT - GRADE OUT OF 100 - [ 95 ]
(FORMATIVE) OLIVIA’S SELF-ASSESSMENT - GRADE OUT OF 100 - [ 95 ]
(FORMATIVE) SAMUEL’S SELF-ASSESSMENT - GRADE OUT OF 100 - [ 90 ]
3.0 What areas of the project are you most proud of?
Again, the project team’s ability to work together, communicate effectively, manage conflict, and finding ways to manage our differences and work to our strengths is believed
to be integral to the project’s success. We are proud of where our hard work has gotten us and we’re eager to keep moving forward to see where we can take the project to
next.
05/51
Assignment #2 - 06/08/18

EXECUTIVE SUMMARY
The purpose of this project is to design and develop an accessible mixed reality application targeted towards achieving the prolonged engagement of primary school-aged
students in a play-based activity with valuable educational benefits.
The outcome of the project is an Android application with an accompanying deck of physical cards that can be used to learn about our solar system and the planets within it.
By bringing mixed reality into the classroom, learning can be more playful, social and less structured, with the goal of encouraging exploration, discovery and problem solv-
ing. The application can be used to keep little minds fresh and stimulated amongst more didactic learning sessions or the normal classroom routine (Eady & Lockyer, 2013).
With the combination of tangible cards and augmented digital content, users’ interactions with the application are hands-on and manipulation is carried out in a more mem-
orable way. With planet cards providing appropriately textured and animated models of the card’s corresponding planet, along with buttons providing access to interesting
facts specific to the planet that’s being explored, users will be able to acquire knowledge in an interesting way and then test their new-found knowledge with the question
cards’ interactive proximity-based functionality used to test the answers’ validity.
The project’s outcome is expected to be positive with the application resulting in effective prolonged engagement with play-based education.
An additional desired outcome is for the project’s design to competently exhibit potential as an expandable and adaptable model capable of addressing many different
aspects of primary education.
06/51

1.0 INTRODUCTION
1.1 purpose & product scope
Astro Exploration is an engaging educational Augmented Reality tool targeted towards primary school students and teachers. The tool involves users interacting with a set of
physical collectible cards that provide augmented visualisations with interactive functionality when looked at with a smartphone that has the application installed.
As Interactive Media and Design students majoring in Computer Games, studying gamification whilst acquiring skills for emerging technology development has ignited a
passion for reimagining engagement in education and Astro Exploration seemed like a great place to start.
We are aspiring to design and develop meaningful applications that can have positive impacts on primary education as we continue to transition from the Information to the
Hybrid Age. It is believed that an effective way of doing this is by using mixed reality technologies to facilitate play-based learning. By presenting students with a different
way of learning, the project aims to promote prolonged engagement that can help bridge the gap between play and education.
In addition to tutorial information, there are two types of physical cards; planet cards and question cards. Put simply, the planet cards provide information and the question
cards quiz the user on that information.
Whilst running the application, looking at any one of the planet cards with the smartphone will provide an animated augmented visualisation of the corresponding planet with
on-screen buttons to show and hide interesting facts about the planet being explored. In addition to this, looking at a question card will display digital three-dimensional text
with interactive functionality involving the ability to react when a planet card is in close proximity. The functionality allows for feedback to be provided based on the planet
card being a correct or incorrect answer to the question.
An advantage of the application is its accessibility, as it has been developed for smartphones and includes access to the printable accompaniments. The result is a fun educa-
tional tool that is affordable and easy to incorporate into the classroom.
On a larger scale, the goal is for this project to be the first stepping stone or selling point that showcases only a small part of a number of different themed collections pro-
vided by a business that produces educational Augmented Reality collectible cards. By tapping into the trading card market, children are encouraged to build their collection
much like the classic Pokémon cards, although this concept brings this fun together with learning.
07/51

1.0 INTRODUCTION
Bertrof. (2011). Game Sound Correct [Audio]. Retrieved 9th July 2018, from https://freesound.org/people/Bertrof/sounds/131660/
CubicBrain. (2018). How to click objects on screen with Vuforia AR & Unity3D (Ray-casting in AR). Retrieved 30th June 2018, from https://www.youtube.com/watch?v=hi_KDpC1nzk
Decree, P. (2014). Space Travel [Audio]. Retrieved 3rd August 2018, from http://freemusicarchive.org/music/Parvus_Decree/Aeon_1_Aegra/01-Space_Travel
Eady, M., & Lockyer, L. (2013). Tools for learning: technology and teaching strategies. Retrieved 15th July 2018, from
http://ro.uow.edu.au/cgi/viewcontent.cgi?article=1413&context=asdpapers&sei
Larabie, R. (n.d.). Good Times Font. Retrieved 17th July 2018, from https://www.1001fonts.com/good-times-font.html#license
Lightning Laboratories. (2010). Experience Design for Mobile Augmented Reality [SlideShare, slide 24]. Retrieved 10th July 2018, from
https://www.slideshare.net/ubik/experience-design-for-mobile-augmented-reality
MADType. (n.d.). Abel Font. Retrieved 17th July 2018, from https://www.1001freefonts.com/abel.font
Pixabay. (n.d.). Abstract Art Astronomy [Image]. Retrieved 27th June 2018, from https://www.pexels.com/photo/abstract-art-astronomy-background-220071/
Solar System Exploration. (2018). NASA Science. Retrieved 27th June 2018, from https://solarsystem.nasa.gov
Solar Textures. (n.d.). Solar System Scope. Retrieved 27th June 2018, from https://www.solarsystemscope.com/textures/
Themusicalnomad. (2014). Negative Beeps [Audio]. Retrieved 9th July 2018, from https://freesound.org/people/themusicalnomad/sounds/253886/
1.2 references
08/51

2.1 product perspective & functions
Astro Exploration is designed to be utilised within a primary school classroom environment to form an engaging connection between play and learning.
The physical cards provide tangibility allowing for hands-on interaction and manipulation with the digital augmented elements that result in a compelling mixed reality
experience. This approach also makes it easier to work together with others whilst using the application.
PLANET CARDS PROVIDE ANIMATED AUGMENTED VISUALISATIONS OF THE CORRESPONDING PLANETS AND RELEVANT FACTS
- The visualisation includes buttons that can be tapped on-screen to show and hide interesting facts about the planet being explored
QUESTION CARDS ALLOW USERS TO TEST THEIR KNOWLEDGE WITHIN THE MIXED REALITY MEDIUM
- To answer a question, users bring the corresponding planet card alongside the question card where they will then be notified if they are correct or to try again
- The question cards have a number on the back which represents how many points the question is worth
SOME CARDS CAN BE COMBINED TO CREATE ADDITIONAL ELEMENTS
- Bringing two combinable planet cards together can trigger an additional augmented card that can then be used as an answer to some of the questions
(Combination Question cards)
THE CARD PLAY MAT CAN IMPLEMENTED FOR A MORE EFFICIENT PLAY ENVIRONMENT AND EASE OF USE
- Errors involved with proximity interactions are minimized
- Allows for users to be more focused on the task at hand
09/51

USER CLASS PROFILE - CHILDREN
GENDER Irrelevant
AGE GROUP 8 to 12 years of age
LOCATION English speaking countries
OCCUPATION Student
EDUCATIONAL LEVEL Years 3 to 6 (Primary School)
EXPERIENCE Perhaps only 5% have interacted with an augmented reality
application before, and they are unlikely to have used it in the
classroom or for educational purposes.
TECHNICAL EXPERTISE Comfortable with technology and quick to learn new concepts.
Intermediate to advanced knowledge of smartphones, tablets
and personal computers.
Hillcrest Christian College. (2017). Junior Learning Community [Image].
Retrieved 10th July 2018, from https://www.hillcrest.qld.edu.au/our-college/jlc
description
The primary user class is children in primary school. This group may find themselves
feeling a bit understimulated in the classroom, and they may be longing for playtime
but this application aims to bring fun into the classroom so this user class can feel
more engaged by the learning process.
user objectives
This user class loves to play, interact with things and one another. They are hoping
for an application that will engage them in a new and exciting way. Through the
incorporation of mixed reality, the primary user class will be enthused by the three-di-
mensional hologram-like visualisations, they will want to compare their trading cards
with their friends, and learn the facts so they can be successful with answering the
questions.
user expectations
• that the application won’t take long to learn how to operate before they can start
• that the application will involve both visual and auditory stimuli
• to be able to close the facts after reading them so they don’t get in the way
• to be able to play together and compete with one another
• for the questions to be well balanced with regards to their difficulty
• that the application will run smoothly (no bugs, errors, or noticeable load times)
• to receive a sense of satisfaction upon successfully completing the questions
2.2 TARGET AUDIENCE & CHARACTERISTICS
PRIMARY USER CLASS
10/51

Pixabay. (2017). Portrait of Young Woman [Image].
Retrieved 10th July 2018, from https://www.pexels.com/photo/portrait-of-young-woman-against-white-background-325924/
description
The secondary user class is primary school teachers. This group is used to teaching the
same content over and over again, and is interested in incorporating mixed reality
into the classroom. As young people have become increasingly connected to their
portable devices, this user class can benefit from tapping into that engagement, using
gamification, and ultimately bridging the connection between education and play.
user expectations
• that the application won’t take long to learn how to operate before they can start
• that the application will contain correct and relevant facts
• for the questions to range in difficulty so the application is more versatile
• that the application will run smoothly (no bugs, errors, or noticeable load times)
• for the required equipment to be accessible and low cost
• that the application does not rely on sound
• that the application won’t require an internet connection to run
11/51
USER CLASS PROFILE - TEACHERS
GENDER Irrelevant
AGE GROUP Roughly 25 to 55 years of age
LOCATION English speaking countries
OCCUPATION Primary School Teacher
EDUCATIONAL LEVEL Bachelor’s Degree
EXPERIENCE Unlikely to know much about Augmented Reality, or to have
personally engaged with the medium.
TECHNICAL EXPERTISE Intermediate knowledge of smartphones, tablets and personal
computers.
user objectives
Not only would they like mix things up for themselves, but they are also hoping to
make the classroom a more interesting place with the goal of helping children to be
more engaged in learning. This user class aims to encourage enthusiasm, and find
more effective ways of delivering the curriculum.
secondary USER CLASS

2.3 assumptions, dependencies & constraints
It is assumed that the project’s target user classes have the ability to use mobile devices, have access to a printer, are able to read basic English and are capable of following
simple instructions. A related constraint that exists prior to achieving the stretch goal of developing for iOS is that the project will only be available to Android users by side-
loading the APK.
One particular dependency this project has from a technical perspective is with regards to the software required for the application’s success. Without Unity and Vuforia, there
would be no application to add augmentation to the physical cards. However, with mixed reality technology being such a fast-developing industry, it is valuable to recognise
the possible issues that could arise with software updates, outdated online tutorials, and errors not yet dealt with by the developers of software the project is reliant on.
Technological development could come unexpectedly, resulting in software not operating as it once did only days before. These changes require adjustment periods which can
place constraints on fulfilling the project’s requirements within the original time frame. With these possibilities in mind, some minor stretch were incorporated into the proj-
ect’s schedule.
Another technical dependency correlating with time constraints is the ability to maintain file progress over an extended period of time. This means that there will be many dif-
ferent files involved (Adobe Illustrator files for interfaces, Adobe InDesign documentation, image targets, audio assets, a Unity project and scripts) that are at risk of becoming
corrupted or being lost with a hardware failure. If any progress was lost due to technical issues of the aforementioned kind, problems would arise with the project running on
schedule, as time has not been allocated for contingencies of this nature. Preventative measures will be carried out at each milestone in attempt to prevent any significant loss
of progress. These measures will involve backing up files to an external hard drive as well as keeping a copy of the application file on an allocated Google Drive.
The way agile project management will be used to deal with time constraints is documented in 6.0 Risk Management.
Lastly, the prototype created in the lead up to commencing this formal design specification document contained content only licensed for personal use. This project was consid-
ered to be dependent on finding alternatives for these elements that were royalty free for commercial purposes, so we worked hard to achieve this and original content was
produced where necessary (e.g. interface graphics). This dependency did not quite effect bringing the brief into fruition, however it was integral to successfully fulfilling the
project’s goals, benefits for the target user classes and to minimise constraints as the project progresses. By working to eliminate external licensing, the project has been able
to maintain its potential for implementation in schools, use in the media and at the very least, forming a part of the project members’ online portfolios.
12/51

2.4 user documentation
Users are provided with a download link that includes the application’s APK file (to be installed on the user’s Android device) and two print-ready A4-sized PDF files; one
containing the deck of cards and another for the card play mat.
The PDF for the deck of cards will contain front and back images of the eight planet cards, eight question cards and a tutorial card (please see below) which can then be
printed, folded and glued together to make the cards (17 cards = 34 individual images, estimated to require 7 pages). Printing on cardboard is preferable, however the cards
being created from two layers of paper (front and back imagery) should provide adequate structure for the images to be tracked by the Augmented Reality software.
The tutorial information is also provided via the application’s menu screen.
13/51

3.0 external interface requirements
3.1 user interfaces
3.1.1 GENERAL LOGICAL CHARACTERISTICS
3.1.2 MENU FLOW
The produced application contains a series of user interfaces designed for ease of use and learnability suitable to those who are inexperienced with the technology and mixed
reality. To ensure a high-quality interface design, the structure has been carefully considered, simplicity is valued, interactive elements are made especially visible, and feed-
back to user interaction is to be provided in all instances, both visually and via sound. The GUI Style Guide outlined in 3.1.3 exhibits many of these features, whilst showing
the design’s tolerance and reusability.
Once the application has been opened on a smartphone and following the branded splash screen, the Main Menu screen will be presented. This menu will contain the title
along with three large buttons with the items ordered hierarchically with regards to their common use (most commonly used items listed first). The first button will be titled,
“Exploration”, the second will be, “Tutorial”, and the third will be, “Downloads & Credits”.
The first button will act as a call to action. Selecting this first menu item will appeal to those who are keen to engage with the application and figure out how it works on their
own or come back and find out how it works later. It will also be suitable for those who are playful and practical, are aware of Augmented Reality, have some existing knowl-
edge of Astro Exploration, or are return users.
The second menu option titled, “Tutorial” will take the user to a screen where they can find out how to use the application. Although the approach to user interfaces will be
instinctual for the majority of the user class, this is where the application ensures learnability for a broad range of experience levels by providing a comprehensive yet succinct
instruction manual.
The third menu option titled, “Downloads and Credits” is the screen that directs users
to where the downloadable cards can be found and provides a little bit of
information about who we are as the designers and developers of the application.
14/51

3.1 user interfaces
3.1.2 menu flow - continued...
15/51

3.1 user interfaces
TITLES: good times
OTHER: Abel
BACK BUTTON APPEARS ON EVERY SCREEN ASIDE FROM THE MAIN MENU
16/51
3.1.3 GUI STYLE GUIDE
To ensure freedom and versatility, alternatives to the restrictive licensed fonts used in the prototype were sourced. Those featured in the application are free for commercial
use. The GUI is original, only it draws inspiration from the InstantGUI pack that was used for the prototype.

3.1 user interfaces
3.1.3 GUI STYLE GUIDE - continued...
physical cards
PLANET CARDS (x8) QUESTION CARDS (x8)
TUTORIAL CARD (x1)
FRONT
FRONT
FRONT BACKBACK
BACK
17/51

3.1 user interfaces
The user interfaces are designed using a monochromatic colour scheme. With different shades of blue, black backgrounds and white text, the effect is simple and visually
appealing, whilst helping to create an aesthetic that can be easily associated with space and science. The physical cards are kept black and white for simplicity and to allow
for a more economical setup for users who are printing their cards at home. However, the branded back adds a pop of colour to increase appeal but this is separate from the
application’s functions.
The use of colour highlights and shadows gives the illusion of depth, particularly with the gradients on the buttons, which helps to communicate to the user that there are
opportunities for interaction. The change of shade and sound effect upon touching the interface provides visual and audible feedback that acknowledges the user’s touch.
colour
#000000 #002051 #164DA4 #19A3F0 #FFFFFF
Good Times is a modern, exaggerated and stylised sans-serif typeface.
- All uppercase; no characters contain ascenders or descenders.
- Shallow curves and bowls (as well as the middle stroke of the “E”) remain only
half closed (disconnected from stem).
- Shallow curves and gaps add to an angular aesthetic.
- Wide characters and narrow tracking create a very grand-looking font.
FONT
OTHER: AbelTITLES: good times
Abel is a classic, crisp sans-serif typeface. It contains rather narrow characters, a
mixture of curved and straight lines and a lighter weight.
- Ascenders and descenders perhaps + 40% of the x-height
- Very versatile, as it has a classic look that could be adapted to different purposes
- Neat, legible, modern and clean... which makes it ideal for this application.
18/51

3.1 user interfaces
contrast
repetition
alignment & proximity
The monochromatic colour scheme brings many opportunities for effective creations of contrast, as do the two chosen typefaces. Deciding not to incorporate too
many colours into the user interfaces has allowed for harmony when the planets are in view, as opposed to being overwhelmed with too many colours. Taking a neat
approach allows for the planets and their textures to contrast and stand out from the other elements with the goal of creating more of a “wow-factor”. The fonts used
vary greatly with their character widths, with Good Times being very stretched out length ways and Abel being condensed.
By keeping the GUI Style Guide simple, the interfaces work with repetition to create a more refined, stylistically powerful whole. By using the same sprite for all the
buttons (aside from back button), opportunities for interactivity will be more recognisable to the user. Image targets for the Augmented Reality are also designed to
appear very similar, although the planet and question cards will be easily deciphered from one another, which adds to the unified aesthetic of the application and its
accompanying cards.
The fact buttons that appear when looking at the planet cards with the smartphone are in close proximity to the card that houses the target for the augmentation. The
collection of four buttons are aligned neatly in a 2x2 grid with some proximity between them to signify them being separate yet still united. In addition to this, their
proximity from where the planet sits above has been carefully considered to allow for everything to be viewed comfortably.
Once fact buttons have been pressed, the corresponding information is aligned alongside the button it belongs to which is using alignment and proximity to commu-
nicate association to the user. The “x” is a recognised symbol used to close the facts. It’s centered and in close proximity to the buttons, which also communicates its
association.
The top-left aligned left pointing arrow is used as a recognised symbol for returning to the previous page. This alignment is commonly used, however the tutorial
screen won’t assume any knowledge to ensure learnability for all users.
19/51

3.2 hardware interfaces
As an educational mixed reality tool, multiple objects are required to engage with the application. These objects include an Android smartphone, and the deck of cards. A card
play mat will also be offered as a recommended addition to improve the user experience by aiding with interaction and card placement, although it is not a core part of the
experience.
This project is designed for use on an Android smartphone, although one of the project’s stretch goals is to also make the application available on iOS.
The application will be designed with a screen aspect ratio of 16:9, however it will be made to scale to the screen size of the hardware. To ensure the proper layout, sizing and
proximity is maintained when scaling across different screen resolutions and ratios, testing will be carried out on a Samsung Galaxy S8+ (1440 x 2960 pixels, 18.5:9 ratio).
Although design and testing will be optimised for smartphone devices, we note that it is also possible to engage with the application on tablets. Using a tablet has the benefit
of a larger viewing area, thus allowing for more targets to be viewed concurrently, however the application works best by holding the device in one hand, leaving the other
hand free for the cards. A tripod or stand of sorts may be easier for some but the application has been designed to operate well without one.
By designing for smartphones, the application is incredibly accessible. Being built for a device so many of us carry around in our pockets everywhere we go will be a great
advantage for the project, as it allows for its benefits to conveniently reach the target user classes in an affordable way.
The application (APK file) is estimated to be <65MB. No cookies or player preferences are required to be stored by the hardware or software.
With the Astro Exploration application installed on your Android device and the accompanying collector cards, simply open the application and it’s ready to go. Once the ap-
plication is open, the branded splash screen will be displayed, followed by the main menu screen. From there, users can proceed to free exploration, check out the tutorial, or
view the downloads and credits screen to find out how the downloadables can be accessed as well as some information about the creators of the application. The only interac-
tions with the hardware that are required are tapping on the screen to make selections.
20/51

3.3 software interfaces
The application is developed using Unity 2017.3.1f1, along with the Vuforia plugin which allows for the incorporation of Augmented Reality.
Some of the steps involved in developing an Augmented Reality project in Unity are outlined below:
- A Vuforia developer account is created online
- From there, a license key is created which is then connected to the Unity project
- Images are uploaded to a specified database to form Targets that are recognised by the software
- Image targets are added to the Unity scene (linked to the license and database), along with a Vuforia AR Camera
- 3D & 2D objects can then be added as children to the targets, which tells the software to show those objects when the camera has recognised the corresponding target
Once Image Targets are parents of other items and the setup technicalities are covered, the application is built and run on an Android device:
- Android APIs are required to be correctly installed before the application can successfully be built out as an APK which can then be run as an application on the
Android smartphone.
- Following the APK’s installation, the application is run and it will appear similar to the camera mode
- The application’s AR camera will be searching for image targets that appear on the license’s selected database/s.
- When the camera is looking at one of the image targets and the software recognises it to have other attached (child) items, those items will appear as they do in the
Unity project, although augmented in relation to the physical corresponding target.
As the user makes a menu selection or taps on a button, the software will recognise that touch as a prompt to begin the functions specified in the underlying code. For in-
stance, menu screens interactions mostly result in scene changes, and buttons use boolean algebra to control the active states of objects.
The nature of this technology can quickly become much more complex and interesting with the addition of C# scripts, interactivity and animations. For example, the Astro
Exploration application includes rotating planets, buttons that trigger different events, audio feedback, particle effects, combining elements for new possibilities and proximi-
ty-based interactions.
21/51

3.3 communications interfaces
In order to share the data required to operate the application, including the accompanying documentation, a download link will be provided via the application’s menu screen
that will include the Astro Exploration APK file, a print-ready A4 size PDF document containing images of the front and back of the 17 cards and another containing the card
play mat. This download is estimated to be around 350MB.
Due to the project’s scope and time constraints, a professional website will not yet be available as a trustworthy sharing mechanism at the time of the project’s completion.
However, the aforementioned link will be provided via the application’s Facebook page, which will aim to still achieve a degree of professionalism. A stretch goal is to publish
the application on the Google Play Store for Android and the Apple App Store for iOS, as well as having a website dedicated to the project with direct download links.
Once the application’s APK has been sideloaded, the application itself will contain further communication in the form of the credits screen. This screen will contain information
about the project’s developers. This credits screen will contain authorial information that’s embedded within the APK, meaning it won’t be easy for this information to be
removed thus ensuring users will have access to the developers’ information and contact details if they have any enquiries, technical issues or just hope to stay in touch to find
out about future projects.
22/51

4.0 SYSTEM FEATURES
4.1 planet cards
The planet cards are used to display an animated, 3D visualisation of the planets, along with educational facts associated with that planet. There will be eight of these cards,
each containing access to four facts (distance, size, environment and random).
The cards are physical items that house the Augmented Reality image targets for the planets they are used to represent. The planet’s name will be displayed on the top of the
card, so users can find the planet they are looking for outside of the augmented reality. The default augmented view of a planet card is a textured sphere and four buttons.
The planet cards have the highest priority as without them, there would be no content for the question cards to ask about and there really wouldn’t be much purpose to devel-
op for Augmented Reality. In addition to this, the cards contain image targets that are tracked by the application to prompt the augmented elements to be displayed.
The user will direct the smartphone at the planet card whilst using the Astro Exploration application, which will then display a visualisation of the planet they are tracking
along with four information buttons. Each button can be pressed by tapping on the screen of the smartphone which will show a text box containing the associated fact about
the planet. The buttons respond to the user’s touch both visually and with a sound effect which lets them know their tap has been registered. Users can press the “X” button
below the fact buttons to close the information interfaces.
- Unique image targets will need to be designed and coordinated with Vuforia for Augmented Reality functionality which will be used to display each planet and their
corresponding facts after the image target has been recognised by the application on the smartphone.
- Each planet card’s augmented planet will be animated to rotate, which will bring life to the visualisation and increase immersion.
- The Planet cards’ augmentation will include four main buttons that will display information when the user presses those buttons (on-screen tap).
- To display the information when the button is pressed, a C# script that will state when button A is pressed show button A information will be required. This script will be
applied to each instance as required.
- To close the fact interfaces, there will be a button that has the ability to close all information that is currently showing.
4.1.1 description & priority
4.1.2 stimulus / response sequences
4.1.3 functional requirements
23/51

4.0 SYSTEM FEATURES
4.2 question cards
Question cards are used to add more depth to the application, to provide a mental challenge, physical stimulation, as well as social opportunities to compete and cooperate
with others - all of which work to create a compelling Augmented Reality experience (Reid Hull, as cited in Lightning Laboratories, 2010). These cards are used to challenge
the user based on the knowledge they have acquired by exploring the facts associated with the planet cards. There will be eight of these cards, all of which will be labelled
with, “question”, and have a number on the back which states how many points that question is worth (based on the difficulty of the question). Having the ability to keep
score can create a more compelling experience by providing small groups with opportunities for competitive or cooperative social engagement (Billinghurst, 2002). The de-
fault augmented view of a question card is a stylised graphic containing a question along with how many points will be received when correctly answered. This feature has the
second highest priority, as it allows for the application to reach all three dimensions of a compelling experience and brings more purpose to the use of Augmented Reality.
The user will direct the smartphone at the question card whilst using the Astro Exploration application, which will then display an augmented text box containing a question
based on the facts contained in the planet cards. Upon deciding which planet they think is the answer to the question, the user will place the planet card next to the question
card. Visual and sonic feedback will be provided based on the user’s correct or incorrect answer. If they have answered correctly, the user will place the card face down in their
points pile. If they have answered incorrectly, the user will be prompted to try again or place the question card at the bottom of the question card deck.
- Unique image targets will need to be designed and coordinated with Vuforia for Augmented Reality functionality which will be used to display each question card’s GUI
containing the card’s question.
- Upon deciding on an answer to the question and placing the corresponding planet card next to the question card, the application will trigger visual and sonic feedback
based on correct and incorrect answers. This will be done by showing the words, “correct” whilst playing a simple upbeat chime for a correct answer and “try
again” along with a monotone sound for an incorrect response. For example, if the question’s correct answer is Earth and the player places Earth next to the question card,
the word “correct” will appear from the question card and a chime of success sound will play. It is noted that these audio assets require a C# script with functions written to
trigger the appropriate sound at the appropriate times.
- In addition to this, another C# script will be required to handle how each question card will respond to each planet card through the use of colliders (with “is trigger”
checked) and tags for identification
24/51

4.0 SYSTEM FEATURES
4.3 combining planets
Some planets cards have the ability to create an additional augmented card if they are combined with another planet card by being placed in close proximity to one anoth-
er. This feature adds additional depth and a sense of playful mystery to answering questions by encouraging users to think outside the box and get experimental by trying
different combinations to create new potential answers to questions. This feature has a medium to low priority rating (third in line). This is due to the project not requiring
this feature to function, although its addition contributes to the application being less of a gimmick, as you need the combination of the physical and digital media to find the
answers to some of the questions.
Users will need to put two planet cards next to one another to trigger the event that will display an augmented card beneath them. The card created by combining two physi-
cal cards is purely digital (only exists in Augmented Reality) and is unique to the two planet cards that display it. After placing two combinable planet cards aside one anoth-
er, a sound will play as the additional augmented card is displayed. Upon forming the additional card, the user can then solve the question by placing the two planet cards
above to place the additional augmented card aside the question card.
- The planet cards with combinable capabilities will require colliders (with “is trigger” ticked), as well as tags for identification
- A C# script with a function that sets the additional augmented card/s to true when the relevant combinable planet cards have collided with one another.
- The additional augmented card/s will also need colliders (with “is trigger” ticked), as well as tags for identification
- A C# script that provides interaction between the additional augmented card/s and the corresponding question card/s
25/51

4.0 SYSTEM FEATURES
4.4 card play mat
The card play mat is an additional feature that keeps the users within a specific zone while interacting with the application. This allows for users to be more focused on the
task at hand whilst minimising potential errors involved with proximity interactions.
- The mat will contain card-sized rectangles with labels for the cards they are intended for (Question Card Zone, Question Zone, Answer Zone and Points Deck, as well as two
Combination Zones).
- Users are encouraged to place the cards in their respective areas/zones during setup.
- The map is a physical object that has no Augmented Reality functionality and is used only as a guide to create a smoother user experience.
Adding zones so that users know where to place the cards allows for a clearer more defined experience.
- The card play mat will need to be designed to be relatively sturdy and resilient for presen-
tation purposes, however a printable version will suffice as the simple design
won’t be too demanding of printer ink.
- The card play mat will require clearly defined and labelled zones for the sake of both
learnability and usability.
26/51

5.0 STORYBOARDS & ASSETS
5.1 storyboard - exploration
27/51

5.1 storyboard - exploration, continued...
28/51

5.2 storyboard - USING THE CARD PLAY MAT
29/51

5.3 assets
5.3.1 Planet textures
All textures have been sourced from solarsystemscope.com/textures and have been distributed under Attribution 4.0 International license, meaning “you may use, adapt, and
share these textures for any purpose, even commercially.”
MERCURY VENUS EARTH
MARS JUPITER SATURN & RINGS
URANUS NEPTUNE
30/51

5.3 assets
5.3.2 Planet CARDS
IMAGETARGETFORAR
31/51
BACK OF CARDS

5.3 assets
5.3.3 question CARDS
32/51
IMAGETARGETFORAR
BACK OF CARDS

5.3 assets
5.3.4 additional GRAPHICS
33/51
DIGITAL CARDS FORMED BY COMBINING PLANET CARDSCORRECT & TRY AGAIN VISUAL FEEDBACK FOR QUESTIONS

5.3 assets
5.3.5 aUDIO & SCRIPTS
SOUNDS SCRIPTS
BUTTON TAPPED
TARGET FOUND
QUESTION CORRECT
QUESTION INCORRECT
MENU SCREEN BACKGROUND MUSIC
BUTTON MANAGER - SHOW FACTS
BUTTON MANAGER - HIDE FACTS
(Also using Vuforia’s DefaultEventHandler.cs to reset when tracking is lost)
PROXIMITY FOR QUESTION ANSWERS (USING COLLIDERS)
BUTTON MANAGER FOR SCENE MANAGEMENT / MENU SCREENS
34/51
Background music is played seamlessly across the menu screens to enhance the ambience along with contributing to the application’s theme. The decision was
made to stop the music once entering the main play-mode (“Exploration”) as the application is designed for use in a classroom environment.
The intention is for the application to be used by multiple students (or groups of students) concurrently (within the same room, running on multiple devices) and it
is believed that it would be disruptive and distracting for the application to be emitting music whilst in use.
The decision to offer a button that turns audio on and off was carefully considered however we decided against it based on the belief that devices can be set to
silent mode if necessary, but by providing purposeful audio feedback without the addition of ambient music, users can engage with the application and enjoy the
sound effects that provide feedback to interactions whilst in close proximity to others who are also using the application. Prioritising harmonious concurrent use is
believed to assist with versatility, appeal to the project’s target market and enhance the user experience.

6.0 risk management
Specifically assigning and assessing risks against the features involved in the project is an important aspect of the process.
agile project management
As the project designers are new to agile project management, the schedule has been designed in a way that minimises the risk of the project being unable to reach its goals
of being completed to the desired level by the due date for completion. This management strategy has been implemented in a number of small ways including keeping the
first sprint short and not overly cumbersome, by deciding to have four sprints over the course of three weeks which allows for time to be more concentrated on a smaller
number of features with regular opportunities to check-in and adapt if need be, and by spreading out the more complex features across the sprints. However, it’s important
to mention that although the more complex features have been spread out, they are not left too late in the schedule. By placing the critical feature (coding for proximity) in
the second sprint, a risk management strategy has been put in place by providing room for the feature to extend beyond the plan if absolutely necessary, whilst avoiding the
project failing to meet its deadline. This strategy is especially important because of the risks associated with emerging technologies like Augmented Reality, and the unpredict-
ability that comes along with it.
team dynamics
Secondly, team relationships is another risk factor that is important to identify, especially as this directly correlates with how arising issues are dealt with, and how the project
is able to adapt to move forward. By establishing team norms, members have a chance to agree on common goals and boundaries which can definitely help when conflict
arises.
In addition to these project management-based risks, there are a few that exist with the project’s functions and their ability to be developed in a way that achieves the goals
of the application at large.
The first of these risks is the target user classes struggling to grasp the concept of Augmented / mixed reality which could impact their ability to fully engage with the applica-
tion. The second is the application not capturing the user’s attention, which relates to the desired benefits being unachievable without prolonged engagement, and lastly is the
risk of the project becoming outdated due to technological development or outrun by competitors before the project is able to reach its full potential.
35/51

6.0 risk management
GRASPING THE CONCEPT OF AUGMENTED / MIXED REALITY
With regards to the risk of users not being able to grasp the concept, it is quite possible seeing as it is unlikely the target user classes would have interacted with technology of
this kind before. This risk impacts the project by creating the requirement for an in-depth instruction manual that is both detailed and concise, which will aim to communicate
the necessary information whilst avoiding becoming overwhelming and thus unappealing. If this balance isn’t achieved, there is a serious risk of losing users with shorter
attention spans which could also prevent the application from reaching its full potential. Another strategy that will be used is player testing, whereby users will be monitored
as they navigate the application without prior knowledge or assistance. Any issues that arise or questions asked will be taken into consideration and the tutorial information
will adapt accordingly. This process will assist with improving efficacy and providing more well-rounded direction.
ACHIEVING PROLONGED ENGAGEMENT
With children being the primary target user class, the risk of being unable to achieve prolonged engagement is common with many applications, especially those that are
intended for educational purposes. It is hoped that Astro Exploration will be able to keep the user from becoming bored or distracted, however it is difficult to monitor how
much stimulus is required as it is a factor that varies so greatly from one person to the next. The project aims to encourage use of the question cards for quizzing as opposed
to simply looking at the augmentations and not properly engaging with the more educational elements. User testing will be helpful with monitoring the efficacy of this strat-
egies, with the possibility of the findings creating a need for additional factors to enhance engagement over longer periods of time. Some examples of additional factors that
could be incorporated would be a reward system, more visual effects, some form of levels and additional content (other cards or different themes).
BECOMING OUTDATED OR OUTRUN BY COMPETITORS
The risk of the project becoming outdated due to technological developments is one that is reliant on external factors as it is a natural part of life, out of our control and
common place with emerging technologies, however this factor will be used as motivation to push forward and do what we can to get our application into classrooms as soon
as we can. If the project shows true longer-term potential, a patent may be required however for now, the project will make note of being licensed under a Creative Commons
license (licensing specifics are to be decided). One strategy for minimising the risk of competitors superseding the application is being aware of the market with the aim of
discovering possible additions that could be made to the project.
CONTINUED...
36/51

6.0 risk management
UPON REFLECTION
Assessing the risks involved in the project along with implementing management strategies and allocating time for regular reflection has been integral to the project’s success-
ful completion.
Taking an agile approach to project management helped us to avoid falling behind, especially when multi-tasking with other projects as every small task was broken down
with their related dependencies having already been taken into consideration. The schedules with sprints provided quick and easy ways of catching a glimpse of where we
were at and what needed to be accomplished before moving on.
Developing a work breakdown structure was invaluable for a busy team with other commitments, as members could self-manage what they needed to accomplish, and the
sprints incorporated into the agile schedule, along with the weekly status reports that coincided with team meetings avoided the risk of team members letting one another
down, or preventing one another from moving on with dependency related tasks.
Committing to the weekly status reports helped with keeping ourselves in check, as they encouraged us to refer back to the schedule, reflect on our team dynamics and the
tasks at hand, and make incremental adjustments where necessary.
Lastly, carrying out testing on a regular basis and backing up files were valuable activities that allowed for us to manage risk.
CONTINUED...
37/51

7.0 schedule & time budget
7.1 work packages & dependencies
7.1.1 WORK BREAKDOWN STRUCTURE
38/51

7.1.2 dependencies
7.1 work packages & dependencies
39/51

7.2 schedule
40/51

7.2 schedule - CONTINUED...
41/51

7.2 schedule - CONTINUED...
42/51

7.2 schedule - CONTINUED
As seen in the agile schedules on the previous pages, sprints have been used to establish four mini-milestones between the due dates of assignment one and two.
Milestone 1, 2 and 4 revolves around our weekly meetings taking place each Thursday morning. This time is an opportunity to discuss our weekly status report and SWOT
analysis, which is to be prepared prior to the meeting, assess the project’s progress, address any issues, and generally touch base with the goal of ensuring effective team
dynamics, communication and risk management.
Milestone 3 was put in place with the goal of bringing the project to a functional and presentable level in time for Bond University’s Open Day - 2018.
TASKED LISTED BELOW EACH MILESTONE SHOULD BE COMPLETED BY THE DATE SPECIFIED
43/51

approval
CLIENT: BOND UNIVERSITY
JBirt
DATE: 6TH OF AUGUST, 2018
DR. JAMES BIRT, BIT(Hons) PhD
PROJECT MEMBER:
OMeredith
OLIVIA MEREDITH, LEAD DESIGNER & DOCUMENTOR
PROJECT MEMBER:
S. J,J, Tulloch
SAMUEL TULLOCH, DESIGNER & LEAD CODER (C#)
NOTE: SIGNATURES ARE FOR PRESENTATION PURPOSES ONLY
44/51

group member time logs
olivia meredith
DATE Time TASK DESCRIPTION
03/07 1.5HRS Team meeting - conceptualisation and brainstorming.
04/07 3HRS Made note of ideas following yesterday’s team meeting, consulted criteria for documentation, devised rough plan for work breakdown & de-
signed InDesign document aesthetics.
05/07 1HR Continued discussion about concept and execution (project and specification).
08/07 1.5HRS Began Purpose & Scope, Product Perspective & Functions, and User Documentation.
09/07 1HR Team meeting - worked on document (made notes, discussed division of duties, continued with InDesign).
1HR Team discussion detailing execution (concept ideas and document work breakdown).
3HRS Continued project timeline and work breakdown, revised lecture notes for incorporation of newly acquired theory-based knowledge, continued
InDesign document.
10/07 4HRS Gathered sources and worked on APA referencing list, Target Audience & Characteristics (one primary, two secondary), consolidation / refine-
ment of Samuel’s start on System Features.
11/07 2.5HRS Team brainstorming session for an additional element – decided to incorporate levels of difficulty in the form of a time trial, with a physical
reward for completion. Refined Project Schedule (GANTT chart) and updated it accordingly, completed the Work Breakdown, and worked on this
week’s status report.
1.5HRS Completed Project Schedule (had been using one of Excel’s template but rebuilt it to allow for more accuracy [broke weeks into days], and added
precise dates to plan project completion).
3HRS Continued on Weekly Status Report (Incl. general project management and personal planning). Created reusable tables for future status reports.
SUBMISSION OF STATUS REPORT - 1 OF 4
12/07 5HRS Approval, Storyboards (x4), further Project Management research and refinement.
13/07 4HRS Continued Design Specification - User Interfaces
2HRS Continued Design Specification - Assumptions, Dependencies and Constraints
2.5HRS Continued Design Specification – Hardware, Software & Communication Interfaces
45/51

olivia meredith - continued...
14/07 1HR Revised Lynda Videos about Project Management
1.5HRS Converted tradition waterfall approach schedule to a refined Agile Schedule, split into sprints & aligned with the Dependencies flowchart in 7.1.2.
2HRS Finalised Storyboards & completed Assets section
3HRS Wrote Risk Management with insight gained from Lynda Project Management videos, whilst building from Sam’s notes.
2HRS Worked on System Features (consolidating Sam’s notes, maintaining consistencies)
15/07 1.5HRS Wrote Purpose & Product Scope
1HR Wrote Product Perspective and Functions + Executive Summary
2.5HRS Consolidated Sam’s notes for the Challenges System Feature as well as refined details of technicalities and reformatted functional requirements
of all System Features
1HR Completed the User Documentation + Software and Communication Interfaces sections
2HRS Team meeting – clarified functional requirements for system features with Samuel, discussed progress and made final group decisions regarding
design direction details
1.5HRS Checked the document for spelling and grammatical errors, finalised the Assumptions, Dependencies and Constraints section, wrote the Group
Assessment and the Revision History (with the assistance of Samuel’s notes)
16/07 3HRS Finishing touches, incorporated additional references, made minor alterations to wording for more effective communication.
SUBMISSION OF ASSIGNMENT 1 - DESIGN SPECIFICATION
17/07 2HRS Sourced replacement fonts (with free for commercial use licences) + designed planet and question cards
18/07 1HR Uploaded targets from card designs to developer.vuforia as Augmented Reality image targets. Imported target package into Unity, placed image
targets in scene + organised and renamed accordingly (old planet targets are now for the questions, new targets became parents of the digital
content present on the prototype planet cards).
20/07 1.5HRS Saved Illustrator files of card designs to A4 PDF in CMYK and printed onto matte paper. Cut out and glued onto (Magic: The Gathering) cards.
46/51

olivia meredith - CoNTiNUED...
21/07 0.5HR Tested cards with basic proximity coding and discovered the new planet targets were too similar (showed different planets at different angles).
Brainstormed alternative designs.
2.5HRS Designed the GUI for the planet and question cards in Illustrator (inspired by InstantGUI, which was used for the AR prac. prototype).
22/07 1.5HRS Redesigned the planet cards so the planets’ names form a part of the target (hopefully a solution to the previous targets being too similar).
2HRS Added the new GUI to the project’s Unity file and converted to sprites. Replaced new sprites with the preexisting functionality of the buttons and
facts on the planet cards, and replaced fonts with those that are “free for commercial use”.
23/07 1HR Uploaded the new planet targets to developer.Vuforia, imported the Unity package and replaced the old targets with the new. Printed the new
cards for accurate developer testing.
0.5HR Added the GUI to the question cards in Unity and tested the new planet targets – unsuccessful.
2HRS Redesigned the planet cards and their targets so the planets’ names go straight through the circular graphics (hopefully a solution to the previ-
ous two target designs being too similar), saved out, uploaded to developer.Vuforia, imported Unity package, replaced the old targets with the
new and tested (with targets on-screen, to save paper and ink) – unsuccessful.
2HRS Redesigned the planet cards and their targets using the question cards’ targets as a template, although with squares instead of circles. Saved out,
uploaded to developer.Vuforia, imported Unity package, replaced the old targets with the new. Printed and tested. – successful!
24/07 1HR Swapped the card designs so the planets use the original circular design and the question cards use the new square design. Saved to PDF, printed,
cut and glued new planet and question cards with the finalised targets. (Asked Samuel to swap over the targets in the Unity file).
27/07 0.5HR Created card play mat (two versions: simple and combination) in Illustrator.
28/07 3HRS Making cards, preparing card play mat, dealing with merged tasks and errors caused by rushing, building out and developer testing.
5HRS Presenting our preliminary project to the public and player testing; making notes of things that need to be fixed or altered. – Open Day
29/07 2HRS Went over the requirements and marking criteria for the assignment 2 submission of our final project, including presentation and document
submission. Team meeting discussing the remaining tasks and our plan of attack.
47/51

olivia meredith - CoNTiNUED...
29/07 2.5HRS Began working on our presentation; created a powerpoint presentation with consistent design, imported information from our InDesign documen-
tation, laid out areas in need of discussion, gathered screenshots of our media exposure and experiences.
30/07 1HR Working on the application’s menu screen design.
31/07 2HRS Went over our notes from Open Day, discussed with Samuel and made changes.
01/08 2HRS Prepared weekly status report + planned completion of remaining tasks and team meetings.
02/08 4HRS Worked together with Samuel on making refinements following Open Day, tried to get question card GUI to reset when tracking was lost and
carried out some developer testing.
2HRS Worked on presentation; slides and storyboards.
03/08 4HRS Wrote tutorial information for physical cards and extended version for main menu screen within the application, made tutorial cards, designed
menu screens, coded menu screens including scrolling background and seamless audio.
2HRS Worked on presentation: used screen capture software to make a little video of the menu screens, added in GUI and finalised storyboards.
2HRS Merged menu screens into game file, resized & realigned planets to be uniform, proofread/spellchecked all GUI, and general game file clean up.
05/08 3HRS Team meeting - developer testing, resized menu screen GUI for Samsung Galaxy S8+ (13.5:9) so we could film our intro. video, confirmed prox-
imity functionality was working as desired (with correct and try again audio and visual feedback showing and hiding appropriately), confirmed
seamless audio and did the final build.
4HRS Drafted our script for the introduction video, filmed footage, consolidated and transfered files, helped Samuel with the trailer and finalised
powerpoint presentation.
06/08 1HR Prepared ourselves for the presentation (split topics between us, and discussed what needed to be said to ensure we were on the same page).
7HRS Finalised documentation, packaged up the pieces and submitted the project to be assessed.
SUBMISSION OF ASSIGNMENT 2 - PRESENTATION OF FINAL APPLICATION AND DOCUMENTATION
48/51

samuel tulloch
DATE TIMe TASK DESCRIPTION
05/07/18 3.5HRS Worked on theorycrafting for more interaction elements for our augmented reality project. Ideas like new digital cards spawning based on prox-
imity, ways to challenge the users through a quiz system and how to make that quiz system more challenging for users that want a more difficult
experience.
06/07/18 2HRS Source information about potential risks that can affect augmented reality projects. I investigated other augmented reality projects and finding
out the issues they had with their users. From this I delved into potential risks that our project shared and attempted to figure out new ways to
better our experience while eliminating those risks.
07/07/18 5HRS From the knowledge I gained about potential risk factors, I crafted information for our document based on what was relevant to our application
also adding potential risks we were already aware of.
08/07/18 3HRS Wrote a brief outline for areas in our document for Olivia to build on and refine. Purpose and scope, Product Perspective and Functions, Target
Audience and Characteristics, Assumptions, Dependencies & Constraints.
09/07/18 7HRS I wrote a detailed breakdown for each of our system features. Planet Cards, Question cards, Combining Planets and Card play mat. When
completing this I took into consideration our previous project features and how we could use them to benefit our new project.
12/07/18 1HR Wrote the system features section for the challenges (time trial) and made notes for the Group Assessment and Revision History.
15/07/18 2HRS Final team meeting – clarified functional requirements for system features for Olivia to document, as well as assisted with finishing touches
(document aesthetics and checking the criteria).
SUBMISSION OF ASSIGNMENT 1 - DESIGN SPECIFICATION
17/07/18 2HRS Went through all the information that we have given the users, then from that data created around 20 different questions ranging from easy to
difficult. After doing this Olivia and I went through and chose the best 8, making sure that each planet was an answer to a specific question.
18/07/18 3HRS Examined the information given to the users and tried to formulate similarities that could potentially be used for questions. As we didn’t need
many questions for this part, the time was mostly spent creating questions that were deemed worthy enough.
49/51

samuel tulloch - CoNTiNUED...
19/07/18 4.5HRS Went back though our project and started to set it up for the next stage of coding adding new cards and other items to the project. Went through
our code to find out what we need to change and how I am going to change it, while researching the codes needed to complete our project.
19/07/18 3HRS Went through our project moving around certain elements so that our scene was in a clean manner to make visualization easier for the days to
come. This involved moving assets around the scene with question cards away from planets. This time was also used to clean up our project as a
whole, thus making it easier to navigate.
23/07/18 5HRS During this period, I went through various amounts of different proximity code to find one that was not overly complicated that could easily be
changed and edited to best suit our project. This lead to various codes not being suitable because of their complexity, leaving me to use a simple
code based on collision. This was the easiest code as it also allows for editing in the future because of its simplicity.
24/07/18 3HRS I used this time to go through the scene and attach the codes, colliders, tags and other elements to objects where needed. During this time, I also
renamed a lot of the code and objects making it friendlier for future use.
25/07/18 2HRS This time was utilised to test the application, making sure that it was working with the AR targets and ensuring there weren’t any technical issues.
We had issues with the AR targets, so they needed to be redesigned but outside of this, the application seemed to be working as intended.
26/07/18 3HRS Went through our code and made sure that everything was ready for the next step in our project. I added new interactions to test on open day.
28/07/18 3HRS The morning of open day I fixed some issues we were having with our project. After this we spent our day at open day testing our application.
29/07/18 4HRS I spent this time fixing bugs that were present on open day.
30/07/18 3HRS During this time, I finished fixing the remainder of our issues then spent time adding sonic and aesthetic feedback.
01/08/18 3HRS I used this time to add to and clean our extra feedback mechanics, adding things like a correct noise when the player is correct.
50/51

samuel tulloch - CoNTiNUED...
02/08/18 4HRS Worked with Olivia to fix up issues from open day, also refining our content.
04/08/18 2HRS Worked on fixing technical issues we were having with our correct and try again screens not appearing.
2HRS Added to our code to implement sonic features.
2HRS Tested our application to make sure there were no more bugs.
05/08/18 3HRS Team meeting - developer testing, created the script for our trailer and bloopers footage.
3HRS Filmed our footage then used After Effects to edit the footage in a professional manner. Also recorded extra voiceovers.
06/08/18 1HR Prepared ourselves for the presentation assigned each part that we were to talk about between ourselves.
0.5HR Helped with finalising the documentation.
SUBMISSION OF ASSIGNMENT 2 - PRESENTATION OF FINAL APPLICATION AND DOCUMENTATION
51/51

Design Specification - Astro Exploration

Recommended

Recommended

More Related Content

Similar to Design Specification - Astro Exploration

Similar to Design Specification - Astro Exploration (20)

More from OliviaMeredith3

More from OliviaMeredith3 (7)

Recently uploaded

Recently uploaded (20)

Design Specification - Astro Exploration