I was a UX and user researcher on…

Remanence - 2024

Genre: Action-Adventure, Soulslike

Engine: Unreal Engine (5.2)

Platform: PC

Production period: Sept. 2023 - Dec. 2024

Team name: ToSoftware

Team size: 25 (5 engineers, 10 artists, 6 designers, and 4 sound)

Full team credits: Anthon Reid, Ryman Barnett, David Porter, Riley Durbin, Cameron Myers, Simi Randhawa, Kira Shinoda, Liz Ponkow, Levi Yang, Zeke Lacy, Benjamin Poot, Nolan Lovelace, Ben Tuttle, Vasiliki Makris, Roberto Velasquez, Skylar Isaacs, Eric Park, Dylan Simpson, Blake Tran, Vasilisa Shcherbakova, Isaac Mitchell, Austin Clark, Santi Soza, Tyler Radocaj, and Caleb Sheffield.

Developed over the course of three semesters at DigiPen, Remanence is a first-person melee action game which I directed and worked as a designer on.

User Research: Achieving design goals, one test at a time.

As the Creative Director on Remanence, I took responsibility for the design team’s entire user research workflow, spanning research goal identification, testing methodology, data aggregation, and presentation.

With logistical help from other team members, we were able to execute on all of our testing plans with a rapid turnaround from beginning to end. This didn’t just boost confidence in our project; it also gave us the ability to make well-informed decisions about the direction of the project, sometimes within only a few days of a question being asked, or a new problem arising.

Above all else, I learned a unified lesson from both my experiences in user research and creative direction:

Ideation is a valuable tool, but truly good design is tempered through exposure to others’ perspectives and interactions, whether those be within the team or from external users.

So how did I improve elements of our design using user research?

1 - The problem:

With Remanence, we often struggled with degenerate playstyles, i.e. player behavior patterns that broke our intended experience. These included strategies like:

  • “Kiting”: running away from enemies while mana passively recharged, allowing constant long-range poke attacks with zero risk of damage to the player.

  • Button-mashing: spamming the attack button while ignoring other combat mechanics, beating enemies via overwhelming damage output.

Numerical tweaks to the combat often just shifted the problem back-and-forth between these two states, wasting dev labor and the team’s precious time. The problem demanded a more complex solution, but said solution was hotly debated within the team.

3 - Taking action:

With logistical help from another designer, I put into action a new testing plan that would inform design and development decisions for the majority of our production cycle:

  1. When potential targets for testing were identified, they were passed along to each department’s director.

  2. During weekly director meetings, said targets were shared and prioritized hierarchically.

  3. Weekly work began with setting up test builds, often using a dedicated control environment or “test level”, modified to suit that week’s research purpose.

  4. Throughout the week, playtests would be run (sometimes utilizing A-B testing across purpose-built build versions) to gather data on the team’s research questions.

  5. At the end of the week, testing data was coded and organized into internal research documents so that it could be shared at the start of the next team-wide meeting. These documents were standardized into templates with instructions, establishing a shared understanding of how data was recorded and presented, and even enabling other team members to conduct their own tests using my methodology.

This didn’t just address the issue of fixing degenerate playstyles exclusively; it served as a highly adaptable approach for all future design issues we encountered.

2 - Narrowing a solution:

Through unstructured playtesting, we learned that our combat system was flawed at a fundamental level, but said approach to testing didn’t help clarify what needed to change. On top of that, when members of the team would debate possible solutions, we rarely had specific data on the crux of said argument. From here, I started to formulate a new approach: a testing methodology which…

  • Allowed for comparative analysis of different controlled variables.

  • Targeted specific design & development concerns from within the team.

  • Standardized data collection so that multiple team members could run valid playtests.

  • Enabled significantly quicker iteration cycles (<1 week), where applicable.

4 - Tangible outcomes:

In regards to the example issue of degenerate playstyles, I had some interesting research outcomes that managed to permanently alter the combat direction of Remanence in the span of only a few weeks:

  • In testing a prototype of enemy “lunge”/”dive” behaviors built by my enemy designer, I found that their inclusion balanced the act of punishing “kiting” players with brief respite opportunities. Considering our healing consumable would slow the player’s movement and lock them in a short animation, giving the player some agency in creating said safety windows was very important for combat flow.

  • In testing an “inversion” of a traditional mana system (the player begins combat at 0% mana instead of 100%, only gaining mana via parrying enemy attacks), I discovered an interesting resource-management relationship between defensive behavior and offensive behavior; when players were offered more damage output and more unique abilities for taking a parry-focused approach to defense, they tended to willingly choose this playstyle of their own volition, despite the difficulty involved.

Together, these two revelations radically altered my perspective on the combat system which I had designed, leading to a design revision that emphasized trading risk (parrying multiple attacks in rapid succession) for reward (increasingly strong sword damage, higher ability frequency) and enabling greater agency in how players spend their mana in any manner of combat encounter contexts.

Want to learn more about my combat design philosophy and the final system used in Remanence? Check out the game design page linked here.