UI Planning - UQdeco2800/2022-studio-1 GitHub Wiki

To establish effective and cohesive user interfaces (UI), team 10 planned out the layout, design, and necessary functionalities early on. Before getting started on the code and deliverables of sprint 1, the UI components were mapped out by using low-fidelity wireframes. The wireframes were shared with each team in the studio to accommodate their respective interactivity with the user. After communicating with teams the wireframes were iterated upon, and ultimately informed the final output.

Wireframes Version 1

Visuals

wireframe1 1 wireframe1 2

Description

The initial low-fidelity wireframe was released early on in sprint one, which was fundamental timing for the UI team to understand the essential elements needed to make the game interactive across all pages.

Start Page: The start page was kept relatively similar to the 'Box Boy' game (the code base that was provided to be built upon) but slightly altered to fit the Atlantis Sinks theme and interactivity. Each component of the start page is addressed below...

  • Buttons: The start page button was designed to be more distinct and prominent when compared to the Box Boy's small green buttons. From a UI standpoint, larger buttons were decided upon as a bigger click area allows for faster selection times. This approach was also adopted for the settings and exit buttons. It was a decision to remove the load button as we didn't see it as a necessary button as the game itself does not to be loaded as when the game just begins upon start.
  • Layout: The layout of the UI elements was similar to that of Box Boy, whereby it is a centered-aligned hierarchal structure. More specifically, the title game logo is at the top of the structure followed by the start, settings ad exit buttons based on what would be the 'most clicked' or interacted buttons on behalf of the user.

Settings Page: The settings page was kept relatively similar to the 'Box Boy' game (the code base that was provided to be built upon) but slightly altered to fit the Atlantis Sinks theme and interactivity. Each component of the settings page is addressed below...

  • Buttons: Since the wireframe was created at the beginning of the sprint when the students were only just being exposed to the Box Boy code, the settings wireframes excluded numerous built-in settings features like the FPS Cap, Fullscreen, VSync, UI Scale and Resolution. Hence these elements are missing from the wireframes and were not considered in sprint 1's workload, and will be addressed in the future. However, in the beginning, the team considered it important to allow the user to unmute and mute any audio sounds. By nature, audio can be at times overwhelming, distracting, and intrusive when trying to concentrate. In a game environment with stimulated intensity and tasks that require concentration, we wanted to ensure the user could have a preference on the sound output to reduce interruptions and ultimately, their emotions (bothered, frustrated, or annoying emotions while trying to focus). Thus, a simple on and off button was planned for music as well as sound effects (note that sound effects weren't integrated within sprint 1, however, they were considered for future UI).
  • Layout: Once again the layout of the UI elements was similar to that of Box Boy, whereby it is centered-aligned which fitted our simplistic and straightforward design approach. The UI team wanted the game to be able simple as possible to ensure swift navigation and smooth user experiences.

Main Game Page The game page differentiated quite significantly from the 'Box Boy' game (the code base that was provided to be built upon) as the original code lacked UI elements due to the basic design and game structure itself. Each component of the main game page is addressed below...

  • Buttons: After cementing the game ideas and concepts in the first weeks of university, the UI team was able to infer what sort of information was necessary to display to the user. Buttons were highly important to linking diverse information handles like the store etc.
    • Settings Button: To facilitate easy access to settings to make changes like turning off the music a settings button was introduced onto the main game page. This way there is a shorter navigational path to access the settings page, rather than exiting the game and heading back to the start page and then opening settings via a button located there. Once again, this UI decision accommodates the user's gameplay and limits the disconnection from the game for long durations of time.
    • Store Button: The store button was crucial to linking the store team's work with the main game. Atlantis sinks has a store whereby users buy materials and goods to optimize their gameplaying, which was outside of Box Boy's scope and needed to be employed. After a discussion with team 6 (store team), we agreed to provide the button for which they would take care of the event handlers once the button was clicked. Hence, we provided the linkage to navigate to the store interface.
    • Attack Button: This button was introduced to allow the user to instigate attacks on the enemies. Therefore, this was the primary point of interactivity between the users and playing the game.
    • Inventory Button: As discussed in studios, there was a need for collecting artifacts and goods which required a place to store these objects. Although, no team was assigned this feature in sprint 1 we thought we'd implement it early on so the future team has a point to link ahead of time.
    • Return to Home (Back) Button: To allow users to return to the game page we created a return button that takes them to the last page they last visited.
  • Other Elements: Alongside the buttons, displaying information is equally important to orientate and inform the user. This included the following features...
    • Player and Crystal Health Status Bar: The primary game objective is twofold, whereby the player and crystal must be simultaneously protected and kept alive to continue gameplay. Originally we had the crystal and player operating completely separately, which meant that there is no linkage between the two entities. In this way, it is fundamental to share the user's progress and status in the game as this would affect their gameplay. Hence, the status bar was integrated to communicate to the user.
    • Coin Counter: Similarly, the number of coins available which have been earnt by the user is recorded in the progress area section so that keep up to date with what they can afford.

Feedback

After talking to each team and getting their opinions on the 'Wireframes Version 1' there were notable changes in the wireframes which resulted in 'Wireframes Version 2'(See Image Below). The following feedback was provided:

  • Two currency counters needed to be implemented, these being the coin counter and stone counter. Originally stone currency was out of scope, however, the build team wanted a currency for building. Hence, we chose to display the stone count beside the coin count. We also chose to show the actual quantity of coins instead of the status bar as it is ineffective in letting the user numerically identify their balance.
  • Remove the attack button as it is not required. After more discussion into the game strategies and working, there was no need for the attack button as it would happen based on the day and night cycle which was out of the control of the user.
  • Potentially implement day and night indicators. To help the user understand the time constraint on the game it was suggested to have a small clock feature that moves with the timing of the game. Towards the end of sprint 1, this was classified as a future task as it would need to be integrated into the nightfall and daytime clockwork which wasn't developed in this sprint.

Wireframes Version 2

wireframe2