Playtest 1

Overview:

Playtest 1 was the first opportunity I had to test out the first playable version of Those Left Behind by players outside of my group. This followed the completion of the fourth prototype of the game which you can find out more about HERE. This prototype covered the basic foundations, with a simple core game loop, initial start to the UI systems and a very basic fail state system that is tied to the food consumption. As the lead technical designer, it was my goal to observe how well these systems faced under numerous playthroughs. My main questions I set out to answer were; Was the resource loop functional? Does the UI make sense and is intuitive? Would players understand how to play without hand-holding?

I had worked extremely hard not only learning to code by also actually coding and implementing the click and drop mechanic, implementing a weekly resource loop, and tying all of this back to the visual elements like the button and day and week displays. Unfortunately, this playtest would prove that this wasn’t enough and I should’ve taken a step back from developing to see what the real issues could’ve been.

Technical system notes:

Click and Drop mechanic:

Preparation:

• The current character assignment system primarily relied on Unitys’s drag event interfaces such as the IBeginDragHandler, IDragHandler, IEndDragHandler. This ensured that the players were able to move the characters into the camps. One of the major oversites from only focusing on ensuring this worked was that there were no visual indications that you could even pick up the characters.

Reflection:

• When it came round to it, the playtesters attempted to drag and drop the actual empty placeholders, character icons, and once they figured out they were able to pick the characters up they still didn’t know where to “drop” the characters. This was when I sighed in disbelief at the fact that I overlooked this small but critical feature. I should’ve added something like an outline or an instructions on what to do but, because I was play testing it myself and knew what I had to do i didnt stop and think about what a new player would think.

End Day Logic and Resource Consumption:

Preparation:

• Each time the player presses the End Day button 4 food resources were deducted in the attempt to simulate a real life experience. If food dropped below 0 the player fails and they have to restart from the start of the week.

Reflection:

• Another major oversight happened as most players didn’t even realise their food resources were depleting at all and were getting confused as to why they were constantly failing. Even once they were told about the food resource consumption they didn’t even know how to obtain the food resource as there were no clear visual indications on what camp produced food. This goes back to the same issue of there being no visual reminders or even introductions as to what to do.

Bug / Issue notes:

My group recorded all bugs and issues on a sheet, these included smaller issues to game breaking bugs. The main issues were:

• Click and drop bugs – Players would try and drop the characters in the camps but in some areas they would just snap back to their original position (Mainly caused by hierarchy conflicts)
• Fail State – Each time the player would fail and restart the resource count on the UI wouldnt update and would take pressing End Day to reset this. (Need to make sure the UI is being updated alongside the restart method)
• Scaling issues on Itch.io – Character icons shrunk each time the player pressed end day or clicked to reset their location. This was very confusing as this bug wasnt happening in the Unity editor, as such we playtested through Unity.

Team Communication:

As the lead technical developer, I made sure I was responsible for setting up each playtest on my macbook. By doing it this way it let me both troubleshoot and change things in real time. As my attention was focused on this Rosie and Anna documented the bugs and wrote survey questions for each playtester to answer (This can be found HERE).

As a team we realised we lacked a proper tutorial or any form of onboarding. As such Sophie suggested temporarily physically writing some instructions for the time being and in future iteration implement a tutorial system. We want to make sure players are able to play this game without any of the developers intervention. 

My takeaways as a developer:

• Technical functionality does not equal player understanding
  • Players didn’t understand both how to play or progress due to lack of visual feedback
• UI must help guide players through weekly requirements
  • Weekly tasks requirements to do be readily displayed in an intuitive manor 
• Fail states are necessary but requires explanations as to why they fail
  • Failure is important however, without explanation as to why they failed it leaves players both confused and agitated 
• Build in a modular way to be more reactive
  • After watching players play the game I noticed how rigid the UI structure was. I need to write simpler, cleaner code with less hard coded values and allow for more live updates based on players interactions

Looking forward:

After this first tough playtest it woke me up to what the actual priorities are. Instead of looking at things from a development perspective and focusing on making everything polished and adding all these new and smooth mechanics I need to focus on visual clarity and UI onboarding. Whilst im being all negative, there were still some good parts as it showed the strengths in our core game pillars and game loop.