DevLog_06: Testing Feedback
Justification for testing requirements:
1. Game controls.
To test this we had to create questions about what input device the user played the game with, and their opinion of said input. We wanted to know if the control scheme needed to be changed or not, we want the controls to feel fluid and easy to play to not take away from the gameplay experience.
2. Upgrade System and did it feel impactful?
We asked testers in the survey if they thought the upgrade system was impactful and what they thought could have been improved. This is the core loop of our rogue-like gameplay, and essential to the enjoyment and replayability of the game.
3. Atmosphere/theme
Users were asked if the atmosphere felt coherent and fit with the theme of the game (Slime lab), as well as how immersed they felt in the game environment. We wanted to see if models/textures didn't feel coherent within the game world, thus breaking the immersion of the player.
4. General Feedback
The general feedback we asked consisted of:
- Aspects liked/disliked
- Bugs and if they could be recreated.
- Rating the game (Enjoyment, Would they recommend, and Engagement).
We wanted general feedback to help cover areas that we may have missed in our questions, as well as to see if the idea should be pursued further, or changed in some way.
5. Observations (Us watching players)
We watched the players as they played through the game and found a few hiccups/patterns on the first playthrough. Observing the players was useful because to cover testing aspects that weren't addressed in the form, as well as any we might not have thought of prior to testing taking place.
The survey used can be found here: https://docs.google.com/forms/d/e/1FAIpQLSdoMjBkOkRZxVuZefR7hoNS8woDkSemP9330Ju8...
Testing Observations & Solutions
- Some players were confused about where to go after defeating all of the enemies. It was not obvious enough that a door had opened to the next level and where that door actually was. It was suggested to add a spotlight near the exit door. This was a fairly common observation and we will look into methods to draw the players attention to the open door.
- Players were not sure what upgrades were supposed to do before picking them up. This evidently was a design choice to make the player learn what each upgrade did and improve the replayability of the game. It encourages players to try something new and experiment with different combinations. We had expected this feedback, and about 25% of players said they would rather to know the upgrades effects before collecting.
- Many players were not reading upgrade descriptions, you could tell that by the way they proceeded to ask questions like:
- Can I go back and read that again?
- I probably should have read that shouldn't I?
- Multiple players found the mouse too sensitive. This was an issue with the sensitivity in Unity not translating over to the WebGL build. We also noticed this on the day, and will be changing sensitivity settings before the next WebGL build.
- Only a few players found out that you could pause the game, and change volume.
- One player tried to find a way to smash things in the first level. (Not going to mention names, you know who you are.)
- The collider on baton (ranged weapon) may be too big and should probably focus on the central part of the projectile. Players had a knack for clipping the weapon into the walls/ground when firing it (even though the reticle was on the enemy).
- People don’t know shield upgrade recharges. Once players figured this out it was obvious that the shield was then abused and too strong. We will need to add this to the description, and make some balancing changes.
- UI bug when 10 of an upgrade is reached. The numbers didn't fit into the allocated space and became unreadable after hitting 10.
- Going through the "More?"door gave several players extra upgrades on some occasions.
Summary of Findings from the Online Survey
Controls
Breakdown of input controls used during testing.
We found that the majority of players used keyboard/mouse, however approximately 35% used a controller at some stage. The keyboard users encountered more issues with inputs than those with controllers.
- The heavy attack being 'E' was a complaint from one user.
- The controls had to be explained in game, particularly the heavy attack.
- Some players were aiming down for the melee attack, which is unnecessary to attack enemies.
- Sensitivity on the mouse was too high, as mentioned above in the Observations section.
We could improve understanding by adding a tutorial in the first level, with control scheme written on the walls of the level. We won't likely change the aim of the light attack, as it would require lots of changes to animation, movement, and code, as well as the entire feel of the movement and game play.
Upgrades
Overall, players were mixed on the impact of upgrades. This is due to disparity in the power of the upgrades, with some being OP while others appear to have no obvious effect. This will be fixed by balancing upgrades, as well as potential for damage numbers. We will also implement changes to the health and shield bar, so that increasing max health/shield is more visible.
Some players felt that over time they became god-like and it removed all challenge for further runs. We will add enemy scaling to help address this issue, and tie it in with our balancing of upgrades.
Difficulty
We found that around 50% of players were able to complete the first three levels on their first run, while the others generally didn't make it past the first or second level. We see this as an indication that the difficulty for the first run is scaled well, as players should be encouraged to have multiple attempts at the game. Players that completed a single run were far more likely to complete multiple runs back to back due to upgrade stacking.
General Feedback

A visual representation of player enjoyment scale

The level of engagement players felt during gameplay.
Would the players recommend to a friend?
The above three bar histograms show the overall sentiment towards the game was positive. The enjoyment was rated as 8.35/10, which is far beyond our expectations, and testers often expressed how engaged they felt during testing. During testing one player encountered sever performance issues, we were not able to identify the cause but believe his computer was the problem. Upon going through the survey it was noted they were the one who left the three on enjoyment.
Fantasy Lab Escape
Status | In development |
Authors | Josh Daniels, Streatj, Hazza2705, Spaghetti_Sauce |
Genre | Action |
More posts
- DevLog_05: Week 112 days ago
- DevLog_04: Week 1010 days ago
- DevLog_03: Week 918 days ago
- DevLog_02: Week 825 days ago
- DevLog_01: Week 739 days ago
Leave a comment
Log in with itch.io to leave a comment.