Week 9

This week was the PROGRESS demonstration week. aahhhhhh... it was scary but overall i think the demonstration went well. The whole group contributed well to the tasks assigned to them. It took a while for me to complete the progress document but we finished it! We all decided to speak all together at the presentation. We wrote a speech and demonstrated the application as well as we could. 

This week, we discussed our part B assignment and what had to be finished to get the assignment done. We decided on the final dates for our project and what had to be done by when.  

We collected everyone tasks that had been implemented for the final application and finalised on all the changes that have been made to the initial concept. 

Changes that have been made to the initial concept 

Interactivity

From the feedback given, there are many changes that have been put in place to benefit the finial application. To properly describe the changes, we have broken the application down into a number of steps to show how the changes have occurred.

In the initial concept, we discussed how the game would open with an article of the Great Barrier Reef that describes the damaging effects of human interaction with the reef. This was done to take the user through a basic timeline of the reef; showing the effects that the Great Barrier Reef has had due to the effects of human interaction. After much thought and feedback we decided to remove the article and put in an instructions page. After receiving feedback from the paper prototype, this was changed to an interactive tutorial instead.

When the tutorial page is displayed, the user will have the option to click the “PLAY NOW” button or the option to go through the tutorial. When the user has finished the tutorial or alternatively clicked the “PLAY NOW” button, there will be a page prompting the user for their name. This has to been incorporated to make the game feel more personal for the user. A high scores leaderboard will be displayed at the end of the game. If the user scores in the top 5, their name and score will replace another’s in the leaderboard.

In the application, the game will generate a fish that can be manipulated by the user; the game will also generate many other marine species from the Great Barrier Reef that cannot be manipulated by the user. In the initial idea we did not arrange a specific number of fish species to be displayed in each level, but through the progress we have made of the application, we have decided to arrange 5 different species of marine species to be displayed in each level; meaning that there will be a total of 25 types of marine species displayed throughout the application. This was done to show the user variation between the marine species and to make sure the user doesn’t get bored with the same species of fish displayed; although the specific player-controlled fish will stay the same throughout the entire game. This was done to create an aspect of consistency throughout. In the final implementation of the application, the fish will be animated to look as though they are swimming

The game interface will show a checklist of fish species listed on the left hand side of the screen. This checklist shows the aim of the game very clearly, that is, to collect all the fish in the level. ‘Undiscovered’ fish will appear grey on the checklist, whereas ‘discovered’ fish will be shown in green, as seen in the image on the right. We decided to show the difference in this visual manner to appeal to our target audience.

We have decided against ranking fish species based on rarity throughout the application. This decision was made as it is unnecessary to the scoring functionality, as we have offered other ways for users to finish the game with varying scores.

Obstacles have been included in our final game concept. We are now only including one obstacle to be used, which will be a plastic bag. This will show the user the effects the Great Barrier Reef is suffering due to human interaction and the effects of pollution. There will no longer be any “surprises” in the game, for example a “rare” fish displayed within the interface as it makes the game overly complicated for the target market. If the player swims into an obstacle they will lose 50 points on the scoreboard. The “obstacle” was added to add variation to the scoring system and to facilitate the needs of the feedback given.

From the feedback given, the lecturer vocalized how the game did not incorporate enough Trove data throughout the game. To facilitate this, we incorporated a Star Box to be displayed within the game. The player is able to swim into the Star Box to gain 100 points on their score. The game will then pause and have a new window or tab open which displays articles and images that are related to harsh effects of human interaction on the reef. The topics we have chosen include tourism, mining, climate change, fishing and oil drilling. After viewing the content, the user is then able to return to the game and continue with their current progress.  The trove information received from the Star Box is shown below.

In the initial application, our idea was for each level to be set in a different area of the reef. For example, the first level is set at the northern part of the reef and each progressive level will be further south. The location changes were intended to inform the user of the different species that inhabit that area of the reef, as well as the difference in the issues that have affected various areas of the reef. We have decided against including this in our final concept as we found that Trove had very little reef-specific information. We have still decided to change the background image of each level; however these images will be pre-selected from Trove and will not be determined by a specific area of the reef. This decision was made so that the audience will be ‘rewarded’ with a different background image as they progress through the game.

The background images will show various corals and marine life. In our initial concept the background was designed to show the name of the coral besides where it appears; however we have decided against this as it makes the screen interface too “busy” giving it a congested feel.

When the user loses health, a protective shield will be generated to protect the fish for 3 seconds. We will show this visually in the form of a light glow surrounding the player-controlled fish for the 3 seconds that the “protective field” is used; this action is additionally used when the user returns from the Star Box page.

As mentioned previously, when a user completes a level, they will be taken to a page showing articles and images relating to each fish. If the user loses all health before successfully completing a level, the page displayed to them will only show articles and images relating to each fish they were able to collect.

Scoring System

Small changes have been made to ensure the scoring system is more efficient and encourages competition.

When the player eats a fish, they will gain 100 points. In order to encourage the educational side of the game, swimming into the Star Box will gain the user 200 points. A 50 point reduction will occur when a user contacts a larger fish, or when the user hits an obstacle. Furthermore, the game interface will no longer display a progress bar displayed on the top of the screen. Instead the user will rely solely on the points to indicate how they are progressing through the game.

Feedback From Progress Report

Before our group demonstration, our group decided on three feedback questions we would ask to our peers and tutors. The questions were constructed to get the vital feedback needed for the development of our application and too see what further changes should be made.

The questions and feedback are listed below.

Question:

Should we allow users to manipulate the Trove pages in the application by allowing them to type their own search terms? Do you think adding this would functionality would encourage the users to access more Trove content?

Response:

No, what you have provided is suitable enough, given that you have pre-selected topics that you want the user to learn about.

Question:

Do you think that having a points bonus for Star Boxes gives users enough incentive to click them?

Response:

Yes; if there is a competitive element to the game, anything with a points bonus will be quite appealing.

Question:

Do you think the articles are suitable for primary school kids or should we switch zone type to something more appealing such as pictures?

Response:

No, providing articles and images is fine.

 

Lecture

This week,  we focused decomposition/modularity which meant the 

"Real design/software problems are too big,  need to break into manageable pieces.
Modularisation is the decomposition of a product into building blocks (modules) with specified interfaces." 

To be completely honest, i didn't really understand this lecture that well but I'm trying to break it down a little to find out the really depth of it. 

So for understandings sake within designing an application, there are many problems that you may acquire within performing the code; this lecture helped us understand how to break down the problem and the easiest ways to solve it. 

What i thought:

Overall this week i was very pleased with the report and the demonstration that presented. The lecturers seemed to really enjoy the animation of the application and everything seems to flow very easily. 

This next week i will be focusing on developing the tutorial of the application.