How Ubisoft Made Prince of Persia: The Lost Crown Its Most Accessible Game Ever

Accessibility in video games has come a long way, progressing from a niche concern to an essential part of modern game design. Ubisoft’s Prince of Persia: The Lost Crown serves as a prime example of this: The game reimagines the classic franchise in a side-scrolling, Metroidvania format, offering a range of features designed to make it more approachable without diminishing the core experience. This approach challenges outdated notions that accessibility and challenge are at odds with one another, proving that thoughtful design can make games more inclusive without sacrificing depth or complexity.

To be sure, one of the game’s standout accessibility features is its Memory Shards system, which allows players to pin screenshots to the in-game map. The implementation is fantastic, and effectively solves a long-standing issue in the genre, whereby players are forced to rely on memory or written notes to track locked paths. Likewise, the team introduced extensive difficulty customization, giving players fine control over mechanics like parry timing, and ensuring that the game remains challenging while accommodating different needs. These innovations not only contributed to the game’s success, they also helped it bring home the Innovation in Accessibility award at December’s Game Awards. 

 To unpack how the team approached accessibility, we spoke with The Lost Crown’s Senior Game Designer, Rémi Boutin. We discuss how the relatively small team managed to integrate its ambitious ideas into a notoriously tricky genre, how it avoided overly hand-holding the player, and what the future of inclusive game design might look like.

First, what was the initial inspiration for you personally to focus on accessibility in gaming? How did this shape your work on Prince of Persia: The Lost Crown, and has your perspective been shaped by your experience of working on this game in any way?

Video games are an incredible medium. One that allows people to accomplish prowess, to explore incredible worlds and to experience a large palette of emotions. Everyone should have the right to experience that, there should be no barriers, no gate keeping. As designers, we want our game to reach as many people as possible, and accessibility is a part of that will. For Prince of Persia: The Lost Crown we wanted to propose a modern take on the series, and to open the Metroidvania, a genre that can sometimes be seen as elitist, to more players and so the question of accessibility came early on. It was not easy from the start because we wanted to offer a game with a lot of challenges and to keep the core pillars of our game: the thrill of exploration, the flow of combat and movements. But in the end, accessibility was a strength for us and enhanced these ingredients. And it's the lesson we learnt from this production; accessibility doesn't lower your challenge nor dilute your game essence, it's quite the opposite if you work on it from the beginning and trust the player!

The game won the Innovation in Accessibility award at this year's Game Awards. Which accessibility feature (or features) do you think were most groundbreaking?

I don't think we have a groundbreaking feature in terms of technology or complexity in design, but the Memory Shards functionality really brings something to the genre. It fixes the cognitive issue that comes with memorizing every locked path and power needed in a Metroidvania, what we call mental notes, and that can be an issue for a lot of players. It's a simple idea: pin a screenshot to the map to have a simple way to remember the connection between the map and the world, and help you remember a place you want to explore at a later point. It felt actually so obvious that we were surprised that it hadn’t been done before. But I think this simple and "natural" feature is maybe the hardest thing to create. And for us it was not only an accessibility feature, but really a core tool of the exploration. It proved to us that fixing an accessibility issue was a creative opportunity to find a new concept for everyone.

Something else that may be surprising for a game with such a focus on fight and bosses is the fact that we offered a lot of customizable difficulty parameters to the player. We aimed for a game offering quite a challenge by default, and at the release the critics and players acknowledged the difficulty. It could feel counterintuitive to let the player tweak any parameter at any time, but it's what allowed us to propose this difficulty. We wanted the player to feel a sense of achievement every time they overcome a challenge, but the difficulty is relative to everyone and so we decided to trust the players. For example, for some players the parry timing is too demanding because of a motor or cognitive disability, and just modifying this parameter allows them to still experience the challenge, and even to play the game with a very difficult enemy.  They still experience the accomplishment of defeating difficulty bosses, they still need to understand the pattern and to make deliberate moves and choices, but without this option, they would not have been able to play the game or they would have to drop the difficulty to the lowest setting.  Accessibility and challenge are not necessarily antagonistic concepts!

How did the team measure how successful the game's accessibility features were? Is it something you can easily quantify in terms of things like player satisfaction?

We relied on playtests a lot during the production and tracking at the release and during the live period. For example, as soon as we properly implemented and tutorialized the Memory Shards, we saw every playtester using it. Same with the in-game tracking: every player was using the functionality.

In terms of completion, we saw that nearly 20% of players finished the game using custom difficulty. So, one out of every five player who finished the game uses difficulty custom parameters to tweak the experience. We still have nearly half of the players completing the game in the "default" (quite difficult) preset, proving that we managed to deliver this challenging but accessible Metroidvania.

Regarding the Guided Mode, how did you strike the balance between "helpfully assistive" and "overly hand-holding"? Was this something you primarily found the answers to through player testing?

We wanted to avoid over "hand-holding", so first we decided to have the "Exploration mode" where players have to figure out where to go by themselves (like in a lot of classics from the Metroidvania genre). We also decided to let players switch between this mode and the "guided" mode any time they want. If a player is bothered to feel lost, they can activate the Guided mode, and if they think they are back on track later they can go back to the Exploration mode.

Additionally, for this Guided mode we wanted to have more than a GPS to follow. Due to the openness of our Metroidvania structure, it would have been very complicated conceptually and technically as well. We identified the friction point of players who were not used to this genre - while exploring, they wouldn’t know if a path was locked or if they were not understanding what to do or wouldn’t remember an unexplored path or know the direction of the next big objective. We decided to clearly provide visual feedback on a locked path when encountered but also to update this "locked path" to a different state "unexplored" at the moment players acquire the power to unlock them.

For the next "macro objective" displayed, we had to rely a lot on playtests and the level designers did a tremendous job to ensure that they were not too close to each other but also not confusing (for example if an objective is on the south of the map but you have to go to the north first due to the level structure, it  could create a "drunk walking" behavior to find the path that could be frustrating). At the end we think we found the right balance.

Can you elaborate on some of the challenges you faced when simplifying the Memory Shards feature from its more complex original version to its final, more simplified iteration? How did the team ensure that Memory Shards felt like a natural part of the game’s world and mechanics, rather than a disconnected tool?

As game designers, we could not refrain from trying some things that were ultimately too complex. For example, at first, you didn't take a screenshot from the whole screen, but you had to aim and choose what part of the screen you wanted to save. It was because we were prototyping other functionalities in this mode: scanning enemies, solving riddles, etc. You could even be hit and interrupted by the enemy when doing so. After a few iterations and playtest, we thought it was too convoluted. We went back to the first idea: a tool to pin the screenshot to the map and solve the problem of mental note. After a few playtests on timing, feedback and input mapping, we arrived at the Memory Shard feature’s current form that felt "natural" for the player.

To ensure it fit in the lore, we associated the feature with Fariba, a character already linked to the map, and to a "fantasy item": the Eye of the Wanderer (partly inspired by the earliest known eye prothesis, a golden eye which was found on the skeleton of a woman from 2900BC in Iran). One interesting aspect is that as Prince of Persia: The Lost Crown is a multiplatform game with cross-save, we had to limit the number of screenshots because of the save file maximum size. We pushed this constraint further by not giving the maximum screenshots to the players right from the start, but by rewarding them with Memory Shards in a chest. This allows level designers to remind players of this feature, while placing a chest with Memory Shards not far from a locked path, for example.

Were there any accessibility features that didn’t make their way into the final game, but that you're hoping to explore in future projects?

Some features were not completed nor polished enough for the release, but we used the post-launch to ship them: the multidirectional parry, the toggle of high contrast. We also listened to the community and fixed some accessibility issues, for example the feedback for the different type of attacks was not clear enough for some colorblind players so we provided an option to have bigger and clearer ones.

I think we did a good job in terms of combat but on the platforming, I think there were still some possibilities to innovate even further. We have the Platform Assist that allows players to skip a platforming section on the main path if it's too difficult, but I would have liked to experiment directly in terms of controls.

Are there any particular emerging technologies that you’re excited about applying to making games more accessible?

I'm really excited by the work done on accessible and customizable controllers. I hope our industry continues to work on that to make more games accessible, with a better support of them and maybe some way to share configuration between players of a same game. But rather than technology I think that most of the improvement in accessibility will come from design. I think that we already have a lot of unused technology that could serve accessibility and that, today more than ever, the philosophy of the legendary designer Gunpei Yokoi "lateral thinking with withered technology" could fit the accessibility field. It's what drove us on Prince of Persia: The Lost Crown, the Memory Shards were partially inspired by the photo mode you can find in games for years!

In terms of the general importance of accessibility in games, what’s something you wish more people understood? How do you think the games industry can do a better job of standardizing accessibility features into their games?

First people should understand that accessibility is important for everyone, not only people with permanent disabilities. A lot of players understand this when they have to face a temporary disability. For example: if they have a tendonitis, they will understand the interest of remapping or motor related options. And as the gaming population is getting older and older, it will become more and more important.

Secondly, people should understand that accessibility doesn't denature a game nor lower the challenge. We should trust the player. If the developers are building accessibility from the beginning of their game rather than as an afterthought, they can use it to enhance its core and even find new features that will benefit everyone.

I think the game industry is going in the right direction in accessibility and some elements should always be present by default (remapping, subtitles options, no color or sound-base only gameplay elements). That being said, we should not standardize everything either, each team should consider its game and its genre to find the best solution. For example, I saw that Avowed implemented a "dialog lore & history" to help with the cognitive issue that can come in a RPG with a huge lore that you don't always remember. I found this super smart (they refined what they did on Pentiment, a game that I greatly appreciated as well).

What best practices and takeaways do you think other devs should consider when designing accessibility into their games?

Design by default! If you don't have an accessibility issue on a feature you don't have work to do. If your health bar doesn't rely on color but just on its shape, you don't have to develop a colorblind option for example.

And to do that easily, my second tip would be to consider accessibility as soon as possible. It will also allow to have more time to iterate and playtest, and to really think about the specific accessibility issue for your type of game and potentially innovate.

Additionally, what advice would you give indie devs who want to prioritize accessibility, but with limited resources at their disposal?

Every developer should care and develop the accessibility of their feature! For example, on Prince of Persia: The Lost Crown, we were a smaller team with fewer resources. I was responsible for the accessibility while still working mainly on my game design topics: designing and implementing enemies and bosses, designing systems and their related menus, etc. So early on we decided to evangelize everyone and to break every feature into a micro task to be sure that accessibility would progress well during the development. The programmer for the damage system would do the damage option, the engineer working on rendering would work on the high contrast mode, the programmer working on the dialog system would do the text log etc... and thanks to this approach we reached a high level of quality because the developers know more than any external person the details of their feature, and by being the owner, they pushed for the extra polish.

But if you're a very small team or a solo dev, I can understand that this tip doesn't help, so I will again say to consider accessibility early on to save time and work by doing accessible design by default, and to dispatch accessibility development in small tasks during your whole development.