Scoring System - UQdeco2800/2021-ext-studio-1 GitHub Wiki
Overview
The feature of this game is referred to the "Scoring System", which encompasses two systems that record and display player achievements as they progress through the game. These two systems are as follows: The progress bar, and The point collection system. The progress bar will be displayed on the main game screen and will show how close the player is to completing the game. As the game progresses due to the player surviving for an increasing amount of time (aiming to survive for > 1 minute), the progress bar will continually update. For example, after 30 seconds the progress bar will display 50% completion, as 30 seconds is half (or 50%) of one minute (60 seconds). The point collection system will be a system separate to the progression system, and will display the points accumulated as the player earns points throughout the game. Currently, points can be earned in two ways: Killing enemies, and picking up coins. As the player kills enemies and picks up coins on the map, the point collection system will be updated on the screen to display the total amount of points collected at that point in time, until the game is over (by either winning or losing the game). The point collection system will also display the total amount of points collected/earned in game on the game over screen as a "final score".
Rationale
The rationale for the Scoring System was because firstly, there was a plan to implement a scoring system in sprint 2 in some form, however the team decided that the scoring system should be focused on as a separate feature in a future sprint due to the amount of work needed, as well as the fact that there were many undiscussed details and aspects relating to the scoring system with other teams, and we felt that more input/discussion was needed for how the scoring system should be implemented. Furthermore, trying to justify a scoring system based on time survived (as proposed in sprint 1) ultimately did not make much sense as there was a win condition after 1 minute, so the team felt that the scoring system could be implemented in another way, using other sources of information (i.e. enemy kills, etc).
In order to make the game more engaging, entertaining and "playable" for users, the team realised that users should be receiving feedback in relation to their performance in the game, as well as receiving recognition when players were performing well. A scoring system adds more complexity to the game, as it is currently quite basic and would not be considered "entertaining" by most users. In particular, with the use of a point collection system and the concept of a "high score", there is potential to create a leader board in future sprints with this feature, this will also add to game playability and overall engagement/entertainment.
Finally, when trying to target the anticipated emotional goals, the implementation of a scoring system would help to target several emotional goals: Pressure, where the player may use the progress bar to indicate how close they are to finishing the game. Frustration, where the player dies and is aware from the progress bar how close they were to finishing the game but ultimately failed. Accomplishment, where the progress bar reaches 100% and the game finishes, as well as the point collection system which continually updates as the player collects more points, giving the player small but continuous feelings of accomplishment because the game is providing positive feedback when the player is successfully completing these tasks. Ambition, where the player plays the game over and over again trying to better their own high score.
Inspiration
Prior to designing the scoring system elements of the progress bar, point collection system, and the +10 points visual, the team undertook research in order to get an idea of pre-existing systems/visuals and to gain some inspiration as to what they might look like. From the research the team identified a few examples, just to provide a basic understanding of the end goal.
Point Collection System
In the game below, the basic points system is seen at the top left and simply displays the integer value of the points, this is something that the team are looking to implement, however a recognisable icon next to the integer value would make the game points more personal or specialised to the theme of the game.
In the game Jetpack Joyride (as seen below), the game allows the player to collect coins as the main way of determining the quality of the game run. As seen in the top left, the game provides two statistics: The total distance travelled in the game run, and the total coins collected in the game run. The coins also feature a small coin icon next to the integer value that resembles the coins that can be collected in the game. This is again something that the team are looking to incorporate into the point collection system.
In the game Crash Bandicoot (as seen below), the game allows the player to collect apples, and the number of apples collected are displayed on the top left of the screen. Again, this game is utilising an obvious icon (the apple), as it is seen in the game as the item that should be picked up.
In the game Fallout Shelter (as seen below), the game has a monetary currency that uses bottlecaps or "caps" for short. The point system in Fallout Shelter, as seen in the top right of the screen (755), has a bottle cap with the letter c on it, signifying that the player has 755 caps of currency. This type of personalised and themed points system is exactly the type of points system the team is looking at implementing.
Progress Bar
These examples provided the team with a good basis to go off, additionally, some examples of progress bars in video games were obtained to gain a further understanding of their functionality, display, and appearance on the screen:
The first example shows how a "capturing" progress bar appears when the player is attempting to capture a certain area/objective in the game. While this type of progress bar might not be relevant to our game, as the progress bar would last for a much longer period of time, and ideally would not be placed in the centre of the screen due to this reason, these examples provided us with useful information to help us in the design, placement, and functionality processes of the progress bar.
+10 Points Visual
The game seen below has a "15 hit" visual when the player successfully hits their opponent, this visual is similar to what the team is looking to implement when the player obtains points from either killing enemies or collecting coins, without the "hit" text, as maintaining consistency across all actions, the player would not be hitting the coin to collect it, hence just the visual of the number will suffice for the purpose of this sprint.
In the game seen below, the player has received some form of boost, adding the value of +262 to e.g. their health, it is not depicted here where the 262 is referring to. This visual provides a more accurate depiction of what the +10 visual may look like, as it only contains the numerical integer and the + sign, as well as being highlighted in green, which insinuates it being beneficial to the player.
In the game Fortnite (as seen below), it can be seen that when the player causes damage to their opponent, the amount of damage (66 health) appears next to the opponents body, symbolising that the opponent has suffered 66 damage to their health. This again is similar to the visual text that the team would like to implement when displaying the +10 points for collecting coins and killing enemies.
Visual Elements of the Scoring System
Point Collection System (Main Game Visual)
As the point system is displaying on the main game screen similar to the armour and health system, as well as on the game over screen as a final score, team members brainstormed ideas for a symbol that would be used in both of these visuals. The initial design ideas are seen below:
With these initial ideas, the team came to the decision that coins made the most sense as the point collection symbol, this was because not only were there coins in the game that would be picked up to give the player points, but also because it seemed logical that in successfully defeating enemies that some sort of valuable resource be gained from this action. Furthermore, as outlined in the initial ideas coins are easily recognisable, and are often seen as point related/valuable or positively correlated.
Furthermore, some inspiration was taken from the visual below as the team was considering including a skull in the point collection visual, signifying enemy deaths and coins as point accruement avenues:
From there, the team designed some initial drafts of what the symbol might look like:
Ultimately it was decided that the visual should contain one symbol, and the team member responsible for the visual (Adriene) for the main screen collaborated with the team member responsible for the game over screen visual (Isaac) to produce more refined designs of the two preferred symbols for the system:
Finally, the team came to a consensus that it made the most logical sense to go with the coin visual, a final version of the main game point collection visual was produced:
Point Collection System (Game Over Visual)
As well as the initial drafts designed for the main game visual, the team member responsible for the game over visual also drew up some drafts of what the symbol could potentially be, all possible symbols were (including the ones drafted by the team member responsible for the main game visual), were presented to all team members for input:
The reasoning for the lightning design was that if the player were to collect power, that could apply to both pick-ups and killing enemies. killing enemies and collecting "power" makes more sense (theme wise) than collecting coins/gems. Additionally, lightning since Thor is the god of thunder, so each time he picks up or kills enemies, he would gain "power" in the form of lightning. Secondly, for the second design, an interesting concept with the "horns of Odin", relating to norse mythology, a symbol of protection. However, due to the sinister and unrecognisable nature of this second design the team ultimately decided not to go with it.
From these initial drafts, the team narrowed down the designs to two options, the lightning bolt and the coin. This was because firstly, there are coins in the game, and secondly, the lightning bolt is highly relevant to the theme of the game as it is based off Thor, the god of thunder. From there a more detailed and refined version of the two options were produced by for final consideration:
As seen with the visual for the main game, the coin was decided as the symbol to be used, and in collaboration with the team member responsible for the main game visual, a final design of the game over visual was produced:
+10 Points Visual
For the first draft, team members decided that coins would make the most sense when displaying the value derived from player actions, especially since there are coins in the game. Additionally, when killing enemies, the value derived from this action can be easily converted to coins. By using a common visual of a coin:
collecting coins = accruing +(coins) and killing enemies = accruing +(coins),
it would be a good way to convey to the player exactly what they're earning, as opposed to using a visual like a gem:
collecting coins = accruing +10 "gem" points and killing enemies = accruing +50 "gem" points.
The coin visual definitely makes more logical sense and will make more sense to the player when converting coins to points.
For the second draft, team members discussed how the visual could potentially provide more information in relation to the amount of coins/points being accrued, so integer values (i.e. +10 and +50) were added to the final visual.
Scoring System Functions
Point Collection System
// Gold board
entity.getComponent(InventoryComponent.class).setGold(0);
int gold = entity.getComponent(InventoryComponent.class).getGold();
CharSequence goldText = String.format("Gold: %d", gold);
goldLabel = new Label(goldText, skin, "large");
goldBoard = new Table();
goldBoard.top().right();
goldBoard.setFillParent(true);
goldBoard.padTop(45).padRight(172);
goldBoard.add(goldLabel).padLeft(50);
stage.addActor(goldBoard);
Stack goldCount = new Stack();
coinCollectorImage.setSize(coinWidth, coinHeight);
goldCount.add(coinCollectorImage);
goldCount.add(goldBoard);
goldCount.setSize(coinWidth, coinHeight);
//table.row();
table.add(goldCount).size(coinWidth, coinHeight).padTop(30).padLeft(-600);
stage.addActor(table);
coinCollectorImage.setSize(coinWidth, coinHeight);
goldCount.add(coinCollectorImage);
goldCount.add(goldBoard);
goldCount.setSize(coinWidth, coinHeight);
table.reset();
table.top().left();
table.setFillParent(true);
table.padTop(30f).padLeft(5f);
table.add(heartImage).size(heartSideLength).padRight(50);
table.add(armourImage).size(armourSideLength).padRight(50);
table.add(goldCount).size(coinWidth, coinHeight).padTop(30).padLeft(-600);
Point Collection Animation
Game Over Delay Function
if (health == 0) {
heartImage = new Image(ServiceLocator.getResourceService().getAsset("images/health_empty.png", Texture.class));
long currentTime = ServiceLocator.getTimeSource().getTime();
while (ServiceLocator.getTimeSource().getTime() - currentTime < 2000L) {
getEntity().getEvents().trigger("GameOver");
}
}
refreshDisplay();
}
UML
Changes to Plan
- Originally the plan for this sprint was to create two features which would encapsulate the “scoring system”, described in the design document as a combined point collection system and a progress bar. The point collection system had no changes made, however the progress bar, which displays the players progress towards winning the game (i.e. 50% completion after surviving for 30 seconds) was ultimately not implemented. This was because after collaboration with Team 4, who were implementing a game timer which displays the time left in the game before game completion (winning the game), it was deduced that the features were too similar as they both display the games main goal of surviving for 60 seconds, and the implementation of both features would risk one becoming obsolete or useless in favour of the other.
- Initially all points for killing enemies and collecting coins were valued at +10 points, however the team decided that defeating enemies should have a higher point weighting and it was decided that two separate point values would be given for the two tasks: +10 points for each coin collected, and +50 points for each enemy defeated. This was because ultimately defeating enemies is a more difficult and risky task than collecting coins and therefore should have a higher reward for doing so.
User Testing
Test Plan
Conduct a design walkthrough with participants in order to get design and functionality feedback for all implemented features so far. The game was presented to 3 users and provided a brief description of the game and the features being implemented. Users provided feedback on the game's design and functionality so that the game and its features could be improved upon in the next sprint.
Design Walkthrough Questions:
- Are the game mechanics easy to understand and carry out?
- Do the functions work as expected? If not, which functions do not?
- Where do you think design consistency has worked well or not worked well?
- Can you clearly see the results of your actions or events displayed on the screen?
- What aspects of the game can be improved?
- What system's responses can be improved?
- What is working well and what isn’t working well for you?
Results
Are the game mechanics easy to understand and carry out?
- Participants reported that without a tutorial or brief run down of the controls, they did not fully understand what the controls were, based off previous video game experience users quickly tested keyboard letters like arrows and WASD, but some participants were unsure of how to attack enemies.
- Once the mechanisms were understood, participants found the mechanics easy to understand and carry out
Do the functions work as expected? If not, which functions do not?
- Overall, the main mechanisms mainly worked as expected however participants were frustrated at the inability to move forwards and backwards to pick up coins and attack enemies as they were limited to the up and down options, or "lanes" as was initially proposed in player movement.
- Start, Settings, Tutorial, Exit, and Replay buttons work as expected
Where do you think design consistency has worked well or not worked well?
- The buttons on the game over screen, win screen and main menu are all consistent and the font/colour scheme of the buttons work well with the space theme.
- The visuals on the main menu screen and the main game screen display consistency as the space background is seen in both.
- The animation of the enemies is consistent moving across the screen however there is no consistency with the enemies and the game theme, participants commented that all the enemies looked vastly different to each other (i.e. one being a ghost and one being a dragon).
Can you clearly see the results of your actions or events displayed on the screen?
- Participants reported being able to clearly see the result of their actions through the changing of the health system however not where items are picked up.
What aspects of the game can be improved?
- Participants reported that the games visuals were very static, the spacey background featured on the main menu screen and main game screen would ideally be moving as the player is moving through space, but it is just a still image.
What system's responses can be improved?
- Animation when things are picked up or enemies are killed
- Clear feedback when weapons are picked up
What is working well and what isn’t working well for you?
- Buttons function well, enemy movement across the screen could be improved where the aren't all moving in the same direction at the same time as it causes the game to become boring and less engaging. Lack of immersion with static background images and, animation of enemies also appears choppy, not smooth.
Future Directions
From the user testing results it is clear that there are several things that need to be worked on to improve the game:
- Player immersion by changing static images to dynamic moving images (i.e. the space background theme, smoother animations of enemies, etc).
- More feedback when the player carries out tasks (i.e. weapon animation when a weapon is picked up, more clear response when coins are picked up, more clear response when an enemy is killed and the player is rewarded with coins, etc).
- A tutorial that outlines the mechanics and controls of the game prior to the commencement of the game, or as a separate button option that can be accessed via the main menu screen
- Consideration into whether controls should include left and right movement rather than just up and down movement, as this in particular confused and frustrated participants.
- Change in the design of enemies to better fit the theme of the game.