Charlotte de Brabant - UX Designer
In Cache-Cache, two players have to cooperate in order to find various characters hidden within a colorful diorama. With a twist: each player has their own screen, and doesn't have access to what their partner sees!
Each player sees a diorama "mirroring" the other player's. One has a winter landscape, while the other sees a summer scenery.
Role
Team
Tools
Duration
UX Designer
7 people
Excel
Adobe XD
Google Forms
Pen & Paper
2,5 months
Game system
In the proposed experience, there are two dioramas: one depicting winter, the other one depicting summer.
Whenever players click on an object, they trigger an animation. IF the object they clicked on is a character, the game will consider it as "found" and it will move to the moon at the center of the screen.
Players can also move some objects via a drag'n'drop, as well as trade those same objects by putting them in the moon. The moon will then transfer the object from one player to the other.
Challenges
Cache-Cache is a cooperative puzzle game: a fundamental aspect for a successful experience is to maximise communication between players.
To better identify the best direction to follow, we established the target audience for Cache-Cache:
Players who like to explore and interact with the game environment, as well as interact with other players.
We didn't specificically limit our target audience's age, because we wanted Cache-Cache to appeal to children as well as adults, to maybe let parents and children enjoy the game together.
To this end, we decided to limit the in-game text to a minimum, to avoid creating reading or language barriers for the players.
Bartle's taxonomy for Cache-Cache players
Design process & sprints organization
I wanted the players to understand by themselves, by communinating, that they were playing on dioramas that are separate, although linked.
The intent was to provoke a positive emotion, a sense of awe that can occur when we understand something by ourselves for the first time. Various playtests ensured that the methods we'd chosen to that end worked, and let us refine them.
We decided to begin with a tutorial so players could understand that they were playing a co-op game. I wanted the tutorial to be clear enough not to need text.
To cover all the possibilities, I nonetheless planned to include text to help players who would take too much time to pass this step, and avoid anyone getting stuck.
The box helps explain to players that they play together despite the separate screens, since they must necessarily open it together.
Document made to facilitate the understanding of the way the tutorial works.
Thus was born "the box".
We created multiple elements so players would be able to make the connection between what they see and what the game asks of them. For an example, if a player rotates the diorama, it will also rotate for the other player.
Trees are another example: a tree with leaves that opens like a box for the player on the summer side, and a bare tree for the player on the winter side.
It constitutes one of the game's first puzzles: a character can be seen jumping from leafy tree to leafy tree when the player clicks on it.
The goal is to make the character jump on a bare tree to interrupt its jumps. There are two possibilities: the summer side player can send the tree to the players with bare trees, or the winter side player can give one of their trees to their partner.
Sending a tree from one diorama to another
The central element we used to help players understand that they're evolving on different dioramas is the ferris wheel.
Imposing and available on the summer side, it is difficult to miss. The player can click on the pods to make them swing, but nothing more.
On the winter side, instead of the ferris wheel, the player sees a simple button on which they can click, but nothing seems to happen on their side if they do so.
That button sets the ferris wheel in motion, necessarily resulting in surprise and communication between players, always resulting in players understanding the way the game works during playtests.
Playtests
Once the design challenges were established, I began to design a test protocol during the first sprint.
The desired prototype included a working puzzle, along with the necessarily 3D models intergrated into the prototype.
I started by isolating 3 main topics:
-
Is the puzzle understood?
-
Do the players communicate to solve the puzzle?
-
Are the "mirrored" interactions understood?
I gathered 3 elements for this protocol:
-
observing testers' actions
-
a survey
-
an individual interview
The survey includes questions to identify the player's position - and to be able to link the pairs of players - and different Likert scales.
Given what I sought to determine was communication, a difficult element to assess, I doubled some questions to minimize the risks of misinterpretation.
Example of the answers during the first playtest (8 participants). We notice a definite lack of comprehension.
To carry out the tests, I recruited a second observer to accompany me because of the nature of Cache-Cache: the two players facing each other, it would've been difficult for me to observe them both at the same time.
I could easily recruit testers among students. It is inevitably a biased population:
-
Testers know particularly well the rules of video games, and could be less bothered by some elements despite their lack of clarity
-
As professionals of the industry, their expectations can differ from the general public
But not without its strenghts:
-
The testers are already familiar with each other, not hindering communication further (unlike independently recruited players), making the test situation closer to a real situation
-
They know the exercice and are less likely not to dare criticize the prototype
I carried out multiple user testing sessions throughout the project following that same pattern, in order to bring answers to the new questions that would arise with the progress of the project and the resolution of old problems.
After interpreting the playtests results, I compile them into a powerpoint I present to the team, along with the changes and solutions I recommend to resolve the problems I identified. We were able to iterate and better the prototype throughout the project.
Visualisation of progress
During one of the playtests, I encountered two obstacles:
-
Players didn't understand when they'd solved a puzzle
-
Players didn't know where they were in terms of game progression
I then proposed the following solutions:
-
Add clearer success feedbacks: sound jingle an dvisual animation
-
Put all "found" characters on the moon to let the players follow their progression in a diegetic and consistent manner, without hindering the diorama's legibility
During the projects final presentation, I stayed to hold our booth and observe players majority of the time. I could see a lot of smiles, cries of exclamations and laughs, especially when players would understand how the game works.
I also noticed different obstacles certain groups of players would stumble upon, like the last puzzle being too difficult, or even a lack of understanding of the transfer mechanic.
For the vast majority of players, the issue stayed marginal, thanks to the cooperative nature of the project: as long as one player understood what to do, they would guide their partner to progress together.
However, I was able to identify remaining flaws in this "finished" project. Although I couldn't improve the project anymore at this point, I still found this experience useful and learned information I could use for future projects.
Accessibility
Because of the project's technicity - we wanted the game to be playable via network - and the short production time, I was limited in what accessibility measures I could implement. For those reasons, I had to make choices that would ask for few resources.
The first element I advocated for was accessibility for colorblind people. Given an important part of Cache-Cache's initial appeal resides in its colorful environment, I didn't want to add a filter to change the game's colors, as I felt we would risk losing that visual harmony. I preferred to opt for a more direct and universal solution: each object has a distinct form and cannot be mistaken for another one, even while playing in grayscale.
As I dislike informing the player through only one element - like color - that choice, far from being an obstacle, allows a better clarity for all plyaers. It also doesn't ask the team for more work, as it is directly implemented in the game and doesn't necessitate to implement an option via a menu.
To ensure I was on the right path, I began by testing myself through filters to emulate different types of colorblindness, to try and see whether each and every object was easy to distinguish. I used tools like Webaim's contrast checker along with some colorblindness simulators.
After this step, I enlisted the help of a colorblind classmate to confirm that the game was playable for his type of colorblindless.
We'd considered adding some patterns to objects if needed, but it wasn't necessary.
Another accessibility aspect I wanted to include was to only ask for simple interactions. My goal was to limit the available actions in order to make the game accessible to the largest amount of people, even in its default version, without any option.
While this decision while made in part due to the project's constraints - our limited time and resources wouldn't allow us to implement actual options - I also see those constraints as a way to avoid scattering ourselves during the design process.
The game proposes two actions, made for the mouse:
-
a simple left click to interact with an object
-
a drag'n'drop to move an object
Drag'n'drop of a tree
Limiting the number of possible interactions makes it easier to reach different audiences:
-
Younger generations are more familiar with smartphones than with computers, and can find using a mouse difficult
-
A lot of old people have a limited knowledge of computers
-
People with a variety of motor problems (tendonitis, limited range of movement, pain, etc.) will encounter less obstacles
-
Porting the game for mobile devices becomes easier
An issue remains however: while the drag'n'drop can be easily understood by children, it can still remain an obstacle for part of the population.
I thus designed two options to replace that interaction:
-
If, for a "movable" object, the player uses the right click instead of the left click, the object will be "magnetized" to the mouse and will follow the cursor's movement. I designed that system with the idea of helping players who experience pain or have a low range of motion (to avoid asking them to seek an icon every time). Implementing this option natively also eases remapping with external tools like joy2key.
-
For people who can move the cursor but can only use one input (like with some alternative controllers), I also proposed a clickable icon that would magnetize objects when activated.