Case Studies | Game Design Process & Problem Solving

User Research

Building a Player Persona for a Coop experience

Context Just when I started working on Hidalgo, plans for the Coop mode were put into motion. In fact, one of my first tasks was to expand Sancho’s actions so that the second player had more actions to do. At the time I didn’t realize it, but I started thinking subconsciously about the kind of things a player that would pick Sancho as their character would like to do. I thought of them as people that enjoyed the fantasy of a strong man, capable of moving anything; so that’s what I did. I made Sancho able to pick up heavier objects that Quixote couldn’t break with his sword. But also, when I started implementing this new asset to block the player’s way and make use of Sancho’s skills, a picture started to form in my head. We knew that one of our main targets were family households that wanted to learn about Don Quixote’s adventures, so naturally I imagined a parent and their child together on their sofa playing and helping each other out by using their character’s unique skills. I imagined my Player Persona on action. However, it would still take a while for me to actually start calling it like that. Meeting my Player Persona I’ve always enjoyed going to game dev events. That’s where I took the first step to my game developer career, and I’ve always been esctatic when attending one. I will always remember the first time going to an event as one of the studios that were presenting their game. I was so nervous, but very excited. A lot of people, videogame enthusiasts that were very active in the indie sphere, came to the booth to play and share their feedbacks about the game, and I was happy to hear. However, I wasn’t satisfied. I felt like something was missing. I didn’t know what it was, until I attended a fair called Toledo Matsuri, near my hometown. This fair was anime-themed, but they had a small indie zone. It was a nice change of pace, since it wasn’t as busy as other bigger events. Plus, there was a major difference: the public. There were some indie fanatics there too. But the people that came to the indie zone were mostly either teenagers enjoying the event with their friends or families that were spending their afternoon together. And the differences in their experience compared to the proficient players that attended big and specialized events were huge. There were of course a difference in skills, having to explain more often the controls and general objectives (which were noted down as elements to improve). But also, the cooperation felt quite distinct too. While proficient players would focus on their side of the screen, unexperienced players would sometimes stop their gameplay to watch their colleague play, either to help or just to observe. This was relevant in a specific puzzle of the first chapter. This puzzle has already proven to be quite confusing to play, and it is currently on the top of my list of things to improve about chapter 1. However, there was a parent that was watching his two kids play, and instead of just turning and asking me like many players have already done, the children turned to their parent and ask him instead. So it was actually the three of them that came up with the solution on their own. That’s when I saw it: not just the family I had imagined months before, but the relationship I was actually designing for. They weren’t simply taking turns solving a puzzle. They were teaching each other, discussing ideas and enjoying the process together. A Coop Player Persona is more than two players One thing I hadn’t realized before was that a coop game doesn’t really have a single player. It has a relationship between players. Designing for a parent figure wasn’t enough. Designing for a child wasn’t enough either. What mattered was the dynamic between them: who takes initiative, who asks for help, who enjoys solving puzzles, who prefers experimenting, who gets frustrated first. My Player Persona wasn’t an individual anymore. It was a household. The key was in the player interactions with each other, not only with the game. Behaviours like constantly speaking, explain mechanics to each other, celebrating together, etc. became much more valuable than metrics like completion time or number of deaths. I even noticed that parents with little or no gaming experience rarely disengaged. Even when they weren’t holding a controller, they stayed involved: celebrating their children’s successes, helping resolve disagreements, or suggesting ideas whenever they got stuck. Some even told us they were looking forward to playing alongside them once the game was released, even if they admit they weren’t interested in gaming in general. From this point on, I made sure to have this family in mind whenever I had to design new content. We have to take into account that Hidalgo is a singleplayer-first game, so the focus wasn’t on Coop from a development standpoint. However, to work around that, I prioritized creating scenarios where both characters were needed simultaneously instead of one at a time. One example was the carpet puzzle at the beginning of Chapter 2. Instead of asking one player to wait while the other completed their task, both players had to coordinate their actions to solve the puzzle together. The goal wasn’t simply to keep both players busy. It was to spark a conversation between them by giving each character unique abilities that became meaningful when combined. This greatly impacted my decision-making, making it much easier. I could make early decisions based on how my players interact with the game, resulting in confident and more efficient decision-making in early stages of development; as well as the development of new features for existing systems like the Dynamic Camera System, which helped less experienced players focus on the elements that mattered without requiring full control of the camera. Even the narrative was influenced by

System Design

Dynamic Camera System to aid User Vision

Context At the time, I wasn’t familiar with User Experience design, but I quickly realized this was not a level design issue alone. It was about understanding player expectations, motivations and how to guide their attention through the environment without breaking the sense of exploration. At this stage of development, we were balancing the refinement of the existing demo while conceptualizing Chapter 2. At the same time, we were preparing a Kickstarter campaign, which meant that most artists and programmers were focused on marketing assets and vertical slice polishing. As a result, tasks requiring additional art or engineering support were deprioritized. Additionally, the person responsible for the original flow had recently left the project without comprehensible documentation, leaving me to reverse-engineer the intent behind several design decisions. While exploring potential solutions, I was eager to start working so I considered more radical changes such as restructuring the village layout or blocking optional paths to streamline navigation. However, these proposals were pushed back due to resource constraints and concerns about limiting player freedom. Instead, I pivoted towards low-cost solutions using existing assets to subtly guide the player. For example, I reinforced the trail of apples as breadcrumb-like visual cues and made Sancho mandatory to obtain the key that would open the village door. Research phase Playtesting showed clear improvement: players were now more likely to reach the plaza and encounter Sancho organically. However, unique and meaningful elements of the village, such as the pyre of books, were still hidden in plain sight and frequently overlooked. The core issue remained: the player’s attention was not being directed in a way that supported meaningful discovery. Around that time, I watched a video about a Spanish organization called Golden Gamers, which brings video games into daycare centers. I originally watched it because I used to work alongside one of the owners, but something in the video caught my attention. One of the main challenges they faced was camera control. Many elderly players struggled to manage both movement and camera at the same time. Their solution was to use a second controller handled by another person, who would adjust the camera based on what the elder seemed to be trying to do: focusing the view on what mattered and helping guide their actions. That was my answer: the camera. We noticed that experienced players, mostly middle-aged people that have played games before, eventually got used to it; but children, one of our main player targets, really struggled with playing with two joysticks at the same time, just like the elderly players. Instead of forcing the player through level design chokepoints, the camera itself could help frame the experience. By creating an environment where player intention was easier to anticipate, the camera could dynamically focus on elements we wanted the player to notice, without having to worry about player competence Solution The timing was ideal. During the conceptualization of Chapter 2, we had already identified the need for more flexible camera behaviour to support a puzzle sequence. To demonstrate the idea clearly, I proposed building a prototype for the creative directors. They agreed. The next day, I came up with a working prototype in Unity of a dynamic camera system capable of shifting between different types of shots depending on the emotions we wanted to convey. By adjusting camera position and rotation, the system would naturally frame points of interest such as the main path or nearby collectibles. The prototype was well received. Since the programming team was still focused on the Kickstarter campaign, I proposed implementing the system myself in Hidalgo’s Unreal project. After adapting the existing camera framework and going through several iterations, I developed a first version of the system that covered Chapter 1. The results were very positive, and after addressing feedback from the team, the system was integrated into the main development branch. Results As the system matured, it began influencing other areas of development. In Level Design, we started considering camera behaviour when shaping spaces, allowing environment layout and camera framing to work together to guide the player’s attention. This made it easier for players to notice points of interest and environmental storytelling moments without relying on explicit markers or UI guidance. The dolly camera proved particularly successful. The slight panning that followed player movement felt natural and satisfying, and it was later reinforced through level design. Long corridors with gentle curves were favored in areas where we wanted players to feel freedom and movement. Its automatic rotation was eventually integrated into the broader camera framework, helping smooth wide transitions and subtly hint at branching paths. The fixed camera became essential for highlighting key structures and creating cinematic framing. It later inspired a more advanced behaviour that could follow multiple objects using a weighting system, allowing the camera to emphasize important elements while keeping the player in view. By experimenting with Unreal’s camera parameters, we also introduced occasional lateral shots for short side-scrolling sections. Once the framework for switching camera behaviours was established, implementing new variations became significantly easier. For the Concept Art team, this also improved the workflow significantly. Because camera behaviours were now defined early, artists could anticipate how spaces would actually be framed in-game and compose environments around those viewpoints. This allowed them to shape visual focal points from the earliest stages of production. Other departments, such as programming and animation, also benefited from knowing where the player’s attention would likely be focused. This made it easier to highlight important elements, stage events more effectively, or keep technical tricks outside the player’s view. What began as an issue discovered during playtesting eventually became a system that influenced multiple departments and provided a flexible framework for the project as it continued to grow. More importantly, it marked the first time I consciously placed the player at the center of my design process. Instead of focusing only on systems or layouts, I began asking myself what players actually needed in order to experience the game the way we