UI Building Planning
In Sprint 2, the UI team focussed their energy on the Building Status Pop-up which displays the building's health, and level, and enables the user to sell or upgrade their building. The feature was proposed by a fellow team in the cohort and thus, wireframes were essential to ensure the output of our team matched the concepts suggested in the studio. After communicating with teams the wireframes were iterated upon, and ultimately informed the final output.
The initial low-fidelity wireframe was released early on in sprint two, which was necessary to outline what needed to be coded and produced. Hand-drawn digital sketches were produced to mock up the first concepts. The following points outline considerations of the first wireframe.
- Building Level Title: To inform the user what level their building is on, we have chosen to display 'Building Level XXX' at the top of the pop-up. It is important the user understands what level their building is on, as they may want to upgrade the building to increase defences which improves gameplay.
- Health Status Bar: Since buildings can cop damage just like the main character and crystal, we want to allow the user to see a close-up of the building's health to keep track. More specifically, if the building runs out of health then it disappears from the game which disadvantages the user. Hence, it is important for the user to understand the status of their defences/resource buildings.
- Upgrade Building Button: A user may want to upgrade their building's level to improve their defences/strength in the game as it progresses. Hence it is useful to easily upgrade a certain building by accessing the pop-up and simply clicking one button that handles the currency transaction as well as improving the building.
- Sell Building Button: A user may want to sell a building to generate money that can be spent elsewhere in the game. Therefore, a sell button was implemented to take care of the transaction in one click for the user.
Producing the wireframes stimulated design and delivery considerations our team needed to account for. This included the following:
- Building Levels: How many building levels are possible? What is feasible yet still enough for the game?
- Different Prices for Upgrading and Selling: What price are we going to sell the different levels of buildings? What amount is charged to upgrade a building between levels?
- Coding: Do we handle the upgrading/selling of the building code? Do we need to create multiple entities to accommodate for the different types of buildings?
To obtain feedback on 'Wireframes Version 1' we reached out to team 7 and team 2. Team 2 were in charge of the story-line this sprint, so we wanted to get their approval on the design and they said that our wireframes look great, but the building UI won't affect their work this sprint as they will be working on cut scenes before you start the game and some during the gameplay (eg cut scenes just before the first night cycle starts) rather than the tutorial of the game. We obtained more feedback from team 7 as they actually suggested the feature ticket in the studio session so they had ideas and concepts as to how the building UI would operate and look.
Feedback from Team 7:
- Building Levels:
