Playtest
Enemy feedback
When discussing the zombie enemy, most testers stated they felt the enemy worked as a good introduction but provided a challenge in hordes or when ignored, which was the design intention. As for the bats, a few players mentioned the larger health pool of the bats, which could slow down gameplay. Lowering the cooldown on the rate of fire alongside the health should allow for the bat to remain at a similar level of difficulty while speeding up the pace of gameplay. One player mentioned, “I like that you can shoot the projectiles to stop them hitting you”, and whilst the sentiment is appreciated, this is not supposed to happen. After some personal experimentation, I couldn’t seem to replicate this. What likely happened was the projectile clipped a small part of the environment or was destroyed after running out of travel time, as the player shot, causing them to believe as thought they could destroy it. Whilst the first case is difficult to convey to the player, adding a blinking effect near the end of travel time will hopefully avoid any further confusion, as seen in Figure 2.
Figure 2- Life-span blink
Figure 1 - Hay look, code
Time for the contentious spider. One tester, instead of helpfully describing their experience with the enemy, chose to use an excessive amount of profanity to convey their point, which, in all fairness, worked. Firstly though, the larger issue that went unmentioned came up when watching a few of the play testers is the spider not dropping their poison when close, this was easily fixable by adding a variable to the function that checks if the enemy is in range of the player, seen in Figure 1, allowing the spider to drop poison whilst close without requiring it to come to a complete stop. As for the other issue, the spider's poison doesn’t dissipate, which caused the general disdain of the enemy, especially in cases where “the poison will spawn in the way of an exit or entrance and leave you soft locked*”. This was half a design choice, requiring the player to constantly adapt and stay aware of the changing environment, and half a rushed job from early development. Regardless, it was clear that it had to be changed to include a lifespan, as seen in Figure 5
* softlock:
(video games) A situation where a game remains apparently playable, but further progress is impossible, typically due to a design flaw or glitch. (Wikionari, 2022)
Figure 5- Life-span blink on poision
Change log
When considering changes to be made and future playtests, players would need to know about changes, such as the poison dissipating. Whilst not necessary, I thought it would be fun to introduce a “Change Log” that would document changes in every release, helping players keep up to date with every new version and be informed about notable changes (Lacan, 2024). Following a tutorial by Coco Code (2021) helped with implementing a scrolling feature, seen in Figure 3, ensuring that the most recent changes would remain at the top and be easily viewable. During implementation, an attempt was made to have the system be dynamic, allowing easy changing. However, many issues were faced with how the game objects would scale in the scroll bar, seen in Figure 4, and after about a day of working on it, the realisation of wasting a day of development on a side idea was not the wisest use of time. And whilst this isn’t as interesting of an implementation, it’s important to note that a change log being dynamic wasn’t the smartest idea in the first place, considering the static nature of the system.
Figure 3 - Change log
Figure 4 - Bug faced with Change Log scaling
Difficult, doors,
and design intent
Whilst viewing a select few playtests, I found many players would retreat to the previous rooms or hallways in order to cower and run away from enemy’s whilst shooting them. This would often trivialise the difficulty of each room. Considering the idea of increasing speed and damage whilst raising the enemy population could incentivise a more aggressive playstyle, similar to how Doom: Eternal (2020) incentivises combat. However, this largely goes against the early design plan and personas, to invoke a more traditional game that older and lesser skilled players can enjoy. The other option would be to lock the Door behind players as they enter a room, requiring more engagement with the obstacles and enemy layout. This will require more shelter within rooms themselves, especially with ranged enemies, to ensure players don’t get overwhelmed with projectiles. This brings out a larger issue of the level design itself, specifically some rooms being too small, with adding more level elements for protection making some rooms feel overly claustrophobic. Much iteration will be needed on this idea until it feels balanced along with more feedback from the planned second playtest. However, with not much time remaining in development and much needing to be done in terms of visuals and audio to fulfil the original design brief, a solution to this will be postponed until after the main development is concluded, to see if there is spare time to fix this issue.
Other feedback
As seen in Figure 5, the feedback to responsiveness of shooting was very divisive. Many testers vented their confusion in whether they had hit an enemy. There were already plans to add a blood splatter effect and sounds during the design overall stage, which one tested specifically requested. Other then that, one player said “sometimes the hit boxes would be weird and not hit the enemy”. This issue was already knowing for a very long time, Seen in Figure 6, and an issue I’ve yet to find a fix to. The personal theory is to do with Unity ProBuilder meshes incorrectly colliding with the raycasts used to detect the hit enemy, however, further testing will be allocated later in development to not only find the problem, but a solution.
As seen in Figure 7, many players found the final boss to be difficult, however it came with some problems. Primarily, one player mentioned “It is not made very clear how to beat it”, this is further backed by some play testers needing a subtle hint to the fact you can shoot the boss. The obvious choice is to add a boss bar, however this could take a substantial amount of development time, which is unideal considering the design overall stage quickly approaching. As for now, it will be added to the Trello board and saved for a further development goal at a later date.
Figure 5 - Feedback to weapon responsiveness
Figure 6 - Raycast collision issue
