Feedback and Improvements 16/02-2017

This monday we had a pre-alpha playtest and my week has been based on the feedback we were given. Since there were many suggestions regarding improving the game, I have no large task to focus around but more and smaller ones.

What we could gather from the feedback was that controlling two characters was not confusing and people enjoyed it, a lack of instructions made it confusing, especially since the projectile fired travels from the “aim” to the player. Allow me to explain, in our game, you play as a girl trapped in a nightmare where the fear of going to school haunts her. In this nightmare, she seeks comfort from her teddy bear called Teddy. To emphasize that the teddy serves as her comfort, we made it so that Teddy fires a projectile towards the player and damages any enemy caught in between them, this also allows for more strategized play and positioning. We were asked if it would make more sense to just have it reversed, but we have our reasons and we take the criticism as that we have failed to communicate the bond that they share.

In order to resolve this issue, we added a tether between the player and Teddy. Our hope is that with additional effects communicate to the player how their bond works, perhaps with particles that travel along the tether from the point of fire, Teddy, towards the player. However we also got points of improvement with how we communicate damage taken by the player or enemies, which we currently had none. We knew that it was missing but hadn’t had the time to implement it yet, so we put it high on the priority list and fixed it. The effect is currently very simple, when hit by a unfriendly projectile, the player turns transparent for a moment where they are also invincible. This allows the player to safely reassess themselves and not take several points of damage in an instant. We also added a similar effect for the enemy, however they turn red and have no invincible state. The reason behind why we chose the color red was because we wanted to communicate that what you have done had an effect on the enemy that was detrimental to their cause, in affect positive for you.

Also, the playtesters thought that our health indicator was unclear and not precise in what amount of HP they currently have. In the game, we have a large bright light in the background, the brighter it is, the more health you have and when you take damage the light fades. When completely out, the player dies. The reason we went with this decision is because we wanted to get rid of  any HUD that would take the players attention away from the action, making the game more intuitive. Going back in attempt to solve this issue we found several bugs regarding how much health you have. We printed several variables to the console and playtested time and time again. What we found was that even when using a powerup to heal, you remained on the same amount of health anyway and you always had 30 less HP than intended. This looked like a serious fault somewhere in the code but was eventually resolved when we realised we had loaded the script twice on the player character, making it behave in very weird ways, like resetting the health gained by the powerup etc. That such a simple issue gave us such trouble made us feel quite silly, so we fixed it back, but that didn’t mean we were done.

For instance, when we played the game again we also found that the health indicator wasn’t really communicating well how much HP the player actually has. What is supposed to happen is that when damaged, the light starts to fade a certain amount. This amount was very noticeable the first time, but up to the fifth time, no significant change was made to the light’s brightness. We haven’t had the time to fix it just yet, but have come up with a solution that involves setting the brightness to a specific value based on the amount of HP left. Why this matters is because we can then manually compare what values we think not only has a change in brightness, but also communicates well how much HP the player currently has.

Overall, the feedback we got motivated us to take charge in implementing these small but significant improvements to the game. With them out of the way, we can continue focusing on larger tasks again, making the game involve more content that adds to the games value.aa1690531ec99989753b4c52f4b7ed1c

En reaktion på ”Feedback and Improvements 16/02-2017

  1. It is always interesting to learn about how others teams carry out their design decisions and and their reasoning behind them. Your blog post clearly explains what your team has been doing during the week and why you made the choices you have, you do not however make it clear what you personally brought to the table, which ideas were yours and so on, this is something probably worth keeping in mind. Another thing of notes is that you do not explain how these design choices were made, did you discuss them in the entire group? Or were you alone responsible for deciding upon the course of action? Lastly i would say that your explanations for the choices you made during the sprint were all very clear and concise, you accurately described the issues you encountered, the steps you took to resolve them and why you choose those specific changes and not any other options that might have conflicted with the game’s vision

    Gilla

Lämna en kommentar