The aim with this prototype was to very quickly mock-up the installing of the upgrades. While not exactly the core experience I wanted to test, but with time running out and still no evidence of prototyping and testing game products, Jordan advised me that even something small and quick like this would do the trick.
I chose flickgame due to its ease of use. I have admittedly put extremely little time into developing any programming/technical skill, and so trying to use anything more advanced than flickgame or Ink felt out of the picture. I had also considered Bitsy, but I felt the restraints that come with that engine would be too stressful to work around in the short amount of time my procrastination had left me.
While this prototype was extremely rushed and low quality and born out of some necessity and stress rather than real desire to test this mechanic, it was valuable to put down a rough idea of how I imagined this mechanic and get feedback on it. Of course theoretically I knew the importance of prototyping small gameplay sections and mechanics early in development, however experiencing it did make it much clearer to me how fundamental this process is in making sure no elements of a game get to a point of no return and end up falling short.
Playtesting & Feedback
I chose a few key questions to focus my notes around while people playtested this prototype.
Can they figure it out for themselves?
Everyone who tested was able to understand that the stand-out colours signified clickable areas. However, due to the field of view, people didn’t notice the arms being detached and replaced, so they weren’t clear on what they were actually doing. Due to the lack of context, they believed there was something broken we were fixing.
Are they curious about the wider context?
Playtesters asked what each of the buttons did and why they were pressing them. They were also curious about the rest of the robot’s body.
Did anyone get stuck? Was there anything unexpected?
There were some bugs where buttons linked to pages they shouldn’t have at certain points. This was because this prototype was quite rushed, so in copy-pasting some of the slides I did not delete the links to other pages.
Some people interpreted the check mark on the display to mean that they shouldn’t touch anything because the robot was operating well. It took some time for them to realise they still needed to interact, and some people interpreted turning the motor power off as a bad thing and tried to undo it. A lot of people got temporarily stuck trying to figure out what to do after turning it off.
The two arrows used to represent detaching the original set of arms was interpreted by some as two options with different results, despite flickgame only providing one link per colour, and the arrows were the same colour.
People were generally unclear on what parts they were looking at, with feedback wondering what buttons and such did, and observations saying the main board inside the robot’s chest looked like a bomb (fair enough, random wires and buttons everywhere on a device).
What would players like to see explored further?
I got some very valuable feedback saying that the perspective being from the outside gave a player the idea that we were playing as a separate character from the robot. While this was only supposed to test out a small mechanic, this was insightful and made me think of how the developed game could get creative with perspective/camera angles during these sections. Perhaps our character could project a diagram version of their chest onto the wall opposite and view it that way, or just have it as a HUD display sort of thing.
There was also general feedback wanting more signs/highlights to signify what the interactive areas were. I do understand this, but I do also want the experience for this mechanic in the larger game to be the player slowly building knowledge of how these systems work with as little guidance as possible – not just for a rewarding/engaging experience, but also because diegetically, our character would already know how they work and being told in a tutorial may break some immersion. If this game goes into development this will definitely be a consideration for further prototyping and testing.
Leave a Reply