Machine Heart is a 2.5D Sci-fi Puzzle-Adventure Game featuring two interconnected storylines. You'll play as Avis, a defiant scientist hunted for her research, and Vox, a sentient robot who lost all his memory.
May 2022 - May 2023
UI/UX Design Lead
Usability Research Lead
Figma
Procreate
Unity
Excel
Design an interface system that is intuitive and coherent with the game experience
Develop a retro-futuristic UI art style that fits in two asethically different timelines in the game
User research of this game is conducted through though the Rapid Iterative Testing and Evaluation (RITE) method and aims to examine the general playing experience, including the intuitiveness of game control and user interface, the effectiveness of level design, and the clarity of the game narrative.
The RITE method is a fast-paced testing method that suits highly collaborative and rapidly changing projects (Medlock et al., 2018.) It suits Machine Heart’s agile development method where rapid and constant changing and updating of in-game content is to be expected. RITE study also allows the team to make changes based on the feedback of one (or a few) players and test the fix in the following participants, greatly reducing the number of playtesters requested and thus addressing our limited ability to recruit a large number of playtesters as a student-led project.
Playtest volunteers came from 3 venues: 1) Through the volunteer recruiting survey sent out by USC AGP faculty, 2) Students enrolled in the AGP class, and 3) self-sourced. We preferred playtesters who expressed interest in indie games and narrative-focused games and who have never played any build of Machine Heart before.
Playtests were conducted both in-person and remotely via Zoom. We recorded playtesters’ screens and behavior if they consented to be recorded for our internal view only. Every playtest session was facilitated by the UX research team while game designers and engineers were strongly encouraged to observe and take note.
We encouraged the playtesters to “think aloud” when playing. Players usually stated their observations, intentions, comments, feelings, and confusion during this process. If the player is not familiar with the think-aloud process, a demonstration using an example that is not related to the tested game is given before the playtest starts. During the playtest, if the player forgets to speak while playing, we would remind the player by prompting such as “Please tell me what’s going on in your mind at this moment” or “Could you state your feeling?” However, we would not answer any game-related questions or give any instructions for playing unless necessary.
Findings from the playtest are documented with a RITE-style spreadsheet. The sheet documents the details of discovered UX issues, their occurrence across playtests and their planned solutions, as well as tracks the implementation of solutions to UX issues.
Usability problems are categorized into 4 types:
The player is unable to proceed without intervention from the test moderator
The player doesn’t interact with the game in the way the designer intended but can proceed
The player can proceeds but misses certain features, cues, or instructions in the game
the player can proceed in the game but complains about certain game features
A screenshot of part of the RITE sheet. Reoccurring issues are highlighted with red to help sort problem priority.
Over the year, we have noted 328 problem reports over 261 unique issues
We have deployed solutions for 173 of the 261 unique problems. The impact ratio of the UX research is 66%.
The 88 problems with no solutions are the problems our team decided not to solve based on problem severity and project timeline. Those issues were mainly minor issues or non-recurring player complaints based on the player’s personal preference and won’t interfere with the game’s experience goal.
Examples of problems with no solution: “Player complained that he cannot walk to the rightmost part of the map when it looked like he could;” “Player complained that there’s too much dialogue.”
Although we believe that addressing such problems could help us further enhance our player experience, we could not implement fixes due to our limited team size and development time.
The gate control puzzle is a puzzle in the beginning part of the game and is implemented since the first playable build. The player needs to click to reconnect the wire to restore electricity to a control panel and then use the button on the control panel to open the gate to the next game scene.
However, our early rounds of playtests indicated that this design is not intuitive to the players. There were 3 reoccurring major problems:
Players constantly tried to drag the consumable item (crowbar) to the panel to use it
Players didn't know where to click to open the control panel.
Players didn't know they need to close the box and click the lighted red button to open the gate. They usually just exit the inspection view after connecting the wire.
Our development team started with the easier solution of changing the art. We tried revising the gate control box item art to make the crack on the box more obvious. After finding that the first solution didn’t solve any of the usability problems, the team decided to add a UI highlight on the interactable part.
After implemented this solution, players could successfully follow the steps to solve the puzzle. However, this iteration was still below satisfactory since one previous problem persisted and one new problem emerged:
Players still constantly tried to drag the consumable item to use it
Players reported that they just followed the highlight without thinking what they should do.
I have discussed the playtest results with the design team and figure out 2 possible causes of our issues.
Drag to use the item in the inventory is a standard practice in PC games
Player expected immediate responses after connecting the wire. Requiring the player to close the box and then use the gate control is very unintuitive.
With these understandings in mind, we planned our next iteration of the puzzle. One possible solution is to allow the player use item by dragging and highlighting the cursor when the player hovers over where they can interact and close the box automatically after the player reconnects the wire. We believe this solution would work, but we found amore economical solution.
After reviewing all the puzzle designs in the game, we realized that most puzzles don’t require an inventory system. Instead of building a more complicated inventory system, it was more efficient to discard the inventory system. To address the leap in the connection between connecting wire and using the gate control button, we separated the wire box from the gate control panel.
In the build with the puzzle redesign implemented, none of the previous usability issues reoccurred and we haven’t discovered any additional problems with this puzzle since then.
