Breaking Barriers: Combat Accessibility in 'God of War Ragnarök'

[Music] thank you hi everyone welcome to Breaking barriers combat accessibility in God of War Ragnarok thanks for coming by there's a lot to get through so let's get started with an introduction and some background my name is Adam and I'm a senior combat designer at Santa Monica Studio I'm excited to speak with you today about some of the accessibility features that the team built out to reduce barriers within god of war ragnarok's combat I'll be doing a deep dive on just a handful of our accessibility features and explain how they came to be the details I'm presenting today is the result of a collaboration between combat design ux design camera design gameplay engineering and more I'm presenting their work to you let's jump right into it for those unfamiliar with the franchise God of Wars combat aims to deliver

intense character action in an approachable way despite approachability being a stated goal there are aspects of our gameplay that prove to be particularly challenging to navigate as we aim to expand accessibility we have many aspects of the game that are intentionally punishing in order to drive engagement the player must keep track of multiple threats frequently and respond in real time with well-timed defense how do we balance keeping these aspects of the game and where do we find Opportunities to make accommodations I'll share a definition of accessibility and the types of disabilities I'll be fully focusing on today so we're on the same page accessibility is the practice of avoiding unintentional barriers that prevent players with varying impairments from accessing or enjoying the game through design or bespoke accessibility features games constantly have intentional barriers like needing to defeat an enemy or solve a puzzle to progress with accessibility we want to avoid

unintentional ones the primary type of disability I'll be discussing today and how we design for them is motor disabilities those relating to control and Mobility some examples are limb amputation or tendonitis with less ability to engage with the game's controls many common actions become difficult or impossible in addition some players experience fatigue being only capable of playing for a short time let's look at why motor disabilities can be a particular issue with God of War here's an image of the control screen all the buttons on the controller are used having a lot of actions and reasons to use them is all part of what makes gameplay fun and engaging both in and out of combat but this presents significant challenges for us as developers to provide an accessibility experience how to reapproach this there's some key context to consider from early in the project that impacted how and when we approach these problems

early on while there was a push for expanded accessibility that many could be on board with conceptually like with anything there was also some healthy skepticism for a few reasons and evaluating features we generally considered these three things first is player value predicting value was initially tough many didn't know what the opportunity for improvement was or how players would benefit from some suggested features we break out player value further into volume which is how many players use it and magnitude which is to what extent does this feature transform the experience for those who use it second is cost we had a good understanding of what it takes to make a boss or an enemy but much less knowledge of what it takes to execute accessibility features this made signing up for a robust robust set of features difficult third is whether or not the feature conflicts with the design intent because of the first two features being so significant on their own exploring

features that conflict with the intended design was much less common early in the project how do we move forward from this initial uncertainty we looked at things that wouldn't conflict with the design that also had easier to understand player value to get our feet wet so to speak some examples for us were highly expanded control remapping which took a great deal of work due to the way our engine previously handled inputs and the sheer number of possible permutations things that we could semi-automate such as traversal would read the stick intent for contextual traversal that would previously require a button press these both showed value at partial implementation even though full implementation took much longer so even if full auto traversal is Out Of Reach automating Manchester's loan may be feasible as an improvement The Experience gave us an understanding of the complexity in the space and confidence that we could succeed here leading us to take on more

that leads us to the first couple features I'll discuss these are some of the trickier problems we tackled in enabling players with motor disabilities to engage with the combat while not conflicting with their design having a player controlled camera is a significant motor disability issue due to requiring the use of both sticks frequently many players impacted by these disabilities can only really operate one stick at a time because Kratos uses a strafe navigation set and is attack orientation is relative to camera forward players can't use the navigation stick to aim their melee attacks our playable character being encouraged to regularly switch back and forth between melee and ranged combat adds extra complexity to lock-on systems players may choose to use lock-on exclusively sometimes or never so we needed to solve both cases while expanding accessibility the entire combat system is designed to work with Outlook on and the player can disengage as well at will

many players decide to use it 100 percent of the time anyway that's okay so it's key it works well in as many scenarios as possible and the regular lock-on has a lot of things that are important to it working well in the system in a game where we're encouraging the player to switch back and forth between melee and ranged combat it's natural to be locked onto the enemy and then pull aim and we allow you to freely aim even while locked on to support managing fights with multiple enemies when aim is released the camera snaps back to the retained Target which you can see in this video as I encapitate incapacitate an enemy with the ax before re-engaging with the lockdown Target lock-on is helpful for players who can't use both sticks in combat but when viewed as an accessibility feature there were issues when targets die having to find a new Target is a big ask a player needed to

press R3 again an input requiring Force that's even on the right stick enemies had to be on camera to be a valid lock-on Target so if you physically cannot control a camera this is counterproductive enemies disengage lock-on in certain cases like to enforce camera control as a skill and causing lock-on to temporarily disengage presents a barrier for players with low dexterity to use ranged attacks the enemy can move out from underneath the reticle by the time they can throw their weapon there was an opportunity to expand this for players with disabilities and the goal was to keep the default lock on as is and allow players to opt in to more help which comes at a trade-off so what do we do to improve lock-on for accessibility when a Target dies we can acquire a new Target okay we continue to be locked onto the target even during aim enemies can't disengage lock-on except in rare cases like enemies going

completely above the screen we were also pushing mid-combat traversal a lot this game which reorients the camera we needed to introduce the concept of disengaging logon and then reacquiring the target afterward which would come in handy later and we need to consider those off-screen targets completely locking on to the Target introduced a problem in this video the right stick does nothing while locked on and aiming but many players play with lock on always engaged 100 of the time meaning we needed to provide access to Precision throw gameplay even with these lock-on settings enabled that's where subtarget aim flicking comes in itially we thought we'd only allow you to flick when it would guarantee a positive result a common instinct when building assists this raised a lot of questions made implementation complicated and required we made assumptions on what the player wanted to do which could prove false when we move to a more generic model this became easier to implement

because we could share data across characters more easily also important is that this granted access to experimentation nothing prevents you from trying to headshot or trip an enemy that doesn't support those hit reactions under free Aim so there's not a great reason to do so here either in addition to solving the need of reliably finding a lock-on Target we also turn a largely analog Endeavor which is precision aiming into a much less demanding activity for the player with auto Target we don't have access to free aim but we can move the stick up or down to flick to various points of interest like the creature's head for a headshot or the legs for a trip melee focused games rarely do this except on very large creatures but because of our emphasis on fun enemy hit reactions this worked very well for us and when Precision throws were mandatory in certain sequences this feature was there to help the player may not want to use lock-on due to its trade-offs or its input so

let's get into a feature that helps players who are playing without are close intimate third person camera results in enemies being off screen and scenarios they typically be visible in other games so Kratos always orients his attacks to camera forward so you can't use the navigation stick to aim at enemies some players with motor disabilities were able to either attack or control the camera but not do both at the same time in God of War 2018 we had a setting that re-centered the camera toward our Target when we successfully hit an enemy which we knew helped beginners players with a less frequent need to rotate the camera manually but we could expand this into an accessibility feature by always doing it when the attack begins so how does that work in practice here's a video of Kratos fighting some drawer this feature enabled the player can focus on attacking and defending without the need to control the camera which is a perfect fit for this type of player even if an enemy is behind Kratos the

player can simply attack to rotate around and strike if managing lock-on was cumbersome or itself posed a barrier this would be a strong alternative foreign just like with anything else in the game we also need to validate the design of our accessibility through play testing we had a consultant with a motor disability test out the combat with these camera assists and other features enabled they were lower level quad they can still use their hands to some extent but also utilize their chin to engage with controls feedback was highly positive and I'm going to share some direct quotes from that player it was hard for me to orient myself in battle in God of War 2018. the features really allowed me to overcome the combat myself it helped me try different things I wouldn't normally try when I felt comfortable in battle I could focus on using more of it let me try using a trace now

so due to not experiencing as many barriers with the controls they were able to engage more with systems like controlling the companion in combat rather than just focusing on getting through the fight this is a combat designer's dream right here we have an accessibility feature that helps the player engage with the depth that we've gone through great trouble to provide I think that's some serious player value we used information from this and other play tests with players with disabilities to inform our next steps like the next feature I'll be discussing that wraps up the camera assists and how they help a player Target and attack enemies but what about finishing enemies to go over that I'll need to discuss stun grabs when a creature stun meter gets full they become crumpled the player can initiate a stun grab that would either do damage or execute the enemy based on their current HP the input for this is R3 or holding Circle now these down grabs fulfill that Kratos

power fantasy and are also absolutely required to complete many boss fights yet they presented a barrier for those with motor disabilities due to the input being on the right half of the controller there was an accessibility opportunity here now you might think we could automate the stun grab and some on the team thought through too Kratos becomes invulnerable after inputting one and during the grab itself so why not but an unmotivated action can be really jarring with a close camera and a stun state may even be triggered by a companion acting autonomously the player intent and choice would be lost additionally we further push cases where you would want to wait to stun grab like dealing damage to the enemy in the crumpled State and then initiate a grab only when it became fatal to drive the point home here's a clip where Kratos and atreus are fighting to Drager I trip one of them and punch him into a wall which triggers this done state I then attack the other drugger while that one is crumpled before initiating

the stun grab this allows me to convert what would have been one Sun grab into two thanks in part to atreus's help we wanted to somehow capture the player's intent even with this as an accessibility feature so we very quickly moved the idea of stick intense thumb grab later named moo stick the player already needs to use the stick to move so why not use that same stick to stun grab the enemy successes with traversal assist also reinforced this idea removing that button press this gave the player access not only to Sun grabs but also the fun and depth around the Sun grabs if they want to do something else before initiating one further having this stun grab check running repeatedly while holding the stick also helped identify technical issues with the setup this Improvement led us to improve the implementation for all players

so my now we've had some of those accessibility wins and tackled those first two issues I brought up the player value was clearly demonstrated and we had more knowledge of what it took to realize these features that third thing aligning with the design intent would start to come up a lot more often even when there could be a conflict with the intended design with the opportunity to be great enough for us to explore anyway one example where the accessibility feature began to conflict with the design was the extremely popular mini boss checkpoint feature for main bosses we often use phase transitions to deliver narrative or emotional beats of fights and checkpointing afterward checkpointing in our boss fights allows us to make each phase longer and more challenging than if we required you to do it all in one go this is not the case for many bosses enemies with large amount of Health often used as an anchor in a group fight or as one-on-one challenges we had gotten feedback from our

accessibility Consultants about long-duration fights leading to fatigue and that losing progress was particularly problematic in this context so there seemed like an opportunity to improve for these players who needed it by adding a checkpoint we knew we wanted to restrict this for the highest difficulty setting because playing correctly for an extended duration is actually a design goal of that difficulty with that one stipulation we got these checkpoints working in game and they were selectable in play tests it was in the main gameplay section menu in the main gameplay section of the menu so almost every player would see it this is where problems came up the player awareness was low they turned on because sure who doesn't like checkpoints and then they play for several hours or days without realizing it was still on or when it activated I'll tell I'll share a story from one of those players in a God of War you can unload your powerful cooldown abilities to reach a threshold thought of the mini boss

respawn at full HP with all of your abilities and then just repeat the process players would constantly do this getting a checkpoint then another checkpoint then another we had a player play through the game on a higher difficulty so they wanted some more challenge but they had the checkpoints enabled they gave feedback that the mini boss was underwhelming and after checking the tapes we noticed that a money boss checkpoint was triggered trivializing the fight for them they were robbed to that challenge they were looking for and they didn't know why tuning on the minibus could have been done to address this feedback we would have harmed the design for players not using checkpoints yet the core problem of many boss checkpoint awareness would have remained we were now feeling that the setting could also be conflicting with the design intent of this difficulty not just the highest to address this problem we move this to the accessibility menu so that players would mostly find this if they were really struggling searching through setting for help

we locked this out on both higher difficulty settings instead of just the highest First Step the player should take if they're struggling against mini bosses it's turning down that difficulty with the improved messaging better location in the settings menu and locking it out on both higher difficulties the feature retained its purpose while being far less likely to deny a player of their desired challenge we also give the player a reminder that the checkpointing is enabled on each death this improves player awareness of the feature and reminds the player that can be turned off if they aren't having any trouble we've helped the player a lot with attacking and finishing off enemies as well as dealing with those mini bosses there's also the problem of Defending against incoming attacks which is net with this next feature did importantly there was a clear design and conflict here from the beginning which we've been building towards I'll quickly share some details about evades

in this video Kratos when Kratos is blue he's invulnerable and invades in God of War are split up into two parts the initial sidestep and the full roll in both States Kratos is invulnerable for some frames and then becomes vulnerable to hits there's also a directionality component here's an example where I sidestep at the right time look at hit because it was done toward the enemy some attacks require the player to evade to the side or behind or backwards not simply at the right time the player is often tasked with evading frequently with a strict timing requirement other games have accessibility features that let you become fully invulnerable during roles and in fact some team members suggested doing this for ayurveds Pumped in consideration for our design goals it's important that there's some risk and timing involved it keeps defense engaging over many hours of play in addition because of the existence of a companion in most encounters the player can earn damage without paying an

animation cost if you could stay invulnerable indefinitely you can make progress and defeat enemies this way what were our design instincts telling us now due to that conflict with our design goals our instincts were much like Kratos here the game and all of its content is carefully balanced around the existing Frame data so a change like this would be detrimental to the combat but in discussions this notion was challenged do we really know for sure that any change here would ruin the intended design how can we know that if we've never tried let's focus on the problem the timing constraint is actually an opportunity for an accessibility gain and after all the player is doing what we're asking which is to evade but they're too early if we could help the player out here even a little bit what would that look like thinking of the problem from this perspective here's what we produced with evade assist we add some more

invulnerability to both States here's a video of just the side steps slowed down for demonstration purposes this may seem subtle but keep in mind this is a game where one frame is often the difference between success and death we're giving the player several here they still need to have timing and keep directionality in mind so they're engaged with the defense but it's less strict we're able to validate this as we did with the previous features through play testing this feature is also locked on the higher difficulties in the same way that defeating a mini boss all at once is an intended part of The Challenge on the higher difficulties so too is the timing aspect of evades now I'd like to bring it all together by focusing on a post-game boss we have optional bot challenge bosses in the game like the valkyrie Queen here they represent the culmination of all of our systems and are the ultimate challenge for the player providing the experience that hardcore players and many of us as combat designers crave when we play these types of games

they have a high power level encouraging engagement with side content elsewhere in the game and to be deliberate about build choice their attack sequences are balanced around kratos's defensive abilities and their Frame data they demand control of the camera requiring players to keep up they have a high Health pool and a damage output demanding the player play correctly for a long time while making minimal mistakes at the end of it all the player must input a stun grab to finish the fight now most of those assists I just discussed are Global features so they'd be usable here would even gone out of her way to allow the enhanced camera lock on features to reacquire these bosses after they returned from going above the screen but allowing mini boss checkpoints on these on these challenge bosses was controversial some thought we shouldn't support checkpoints at all due to this direct conflict with the antenna design that journey of repeatedly failing learning and achieving Victory is a highlight moment for many players even

on the lowest difficulty and this was at risk if it was shortcut with this feature we knew players struggling at retail could internet search for help at the first time of trouble and find many boss checkpoints rather than change their play style or upgrade their armor now when the line between difficult to do difficulty tuning and accessibility became blurred so too was the path forward so we needed to consider this carefully the player might shortcut the challenge but they could also turn down the difficulty we already trust them with that decision even if these are meaningfully different in a few ways like those cooldown moves I mentioned earlier the fight's optional but narrative is delivered after these fights locking some players out of these experiences could itself be a design conflict with the narrative goals of the game players May Rob themselves of that Journey but how do we know they will enjoy it less if they selected it or needed needed it due to fatigue or any other reason and to reach the checkpoint they first

need to make progress as opposed to starting the boss with reduced Health in the first place they're only addressing the endurance part of the fight behavior and attack sequences all remain importantly the two higher difficulties already disallow it systemically we were now more sensitive than ever to accessibility gains after having seen huge wins elsewhere and if we hadn't resolved that player awareness issue as I described earlier this probably would have been off the table but we decided to allow one checkpoint on these challenge bosses which is pretty significant considering they're tuned around no checkpoints at all key to reaching this result and having a good conversation was validating the express concerns while many of our concerns remained this checkpoint would do more good for the players who truly needed it than harm to a player who didn't

in closing this was a long and difficult Journey there's certainly still room to grow and improve but we'll learn some great lessons from this experience getting early wins built confidence in many areas allowing us to push further validating the design through play testing with players and Consultants with disabilities was crucial not only to ensure we were delivering the feature to the players who needed it but also to find new opportunities the trickiest problems were when a promising feature posed a direct conflict with combat fundamentals and design goals these were challenging but often the most rewarding it was important to validate concerns and be empathetic to the arguments against possible features rather than dismissing them this kept teammates working together on the problem rather than pushing each other away at the same time it was important to challenge our design instincts and ask ourselves if we truly knew for sure that the fundamental design would fail if certain features were added

throughout this journey we became sensitive to accessibility wins making us reconsider and earnestly push toward features we wouldn't have entertained at first not only do we break barriers for the player but also each other as players as teammates and within our design thinking this made it very worthwhile okay before I wrap things up I wanted to highlight a few talks that took place earlier this week at GDC about the game's accessibility that will be viewable on the vault in the coming weeks if you want to learn more about how we validated our accessibility through play testing check out play testing God of War Ragnarok accessibility options by Sue senior user researcher at PlayStation if you want to learn more about how we designed accessibility for Low Vision players check out gottable Ragnarok designing AAA low vision game accessibility by Mila the game's ux design lead last but not least we're hiring for

what's next if what I've gone over today excites you please get in touch check out our careers page to see open positions and that's the talk thank you very much [Applause] um I believe I have three minutes for questions if people can line up at the mics on each side no questions all right then all right got the Pioneer over here let's hear it all right great talk thanks very much could you talk a little bit about um turning off accessibility options at higher difficulty levels a bit more like what the thought process behind that was right yeah so you're asking why we turned off this the the settings or

disabled them on higher difficulty settings um right so that was to protect the design intent uh on those difficulties uh we're asking the player of more and sometimes specifically what we're asking of them uh is something that the feature conflicts with we're okay with having those those help and assists on the lower difficulties because there's not a design design intent conflict um does that answer your question cheers thanks uh so for the design team what determines whether or not an accessibility feature is a toggleable option in the accessibility menu or a feature that's baked into the game itself oh um we made many improvements that didn't necessarily need like a setting to be enabled for example when I believe I believe this is true if an enemy gets done they actually make a sound I don't believe that was the case in the previous game which helps we also have

an audio queue that makes it much louder if you go into the settings but other things like there were considerations for trying to make sure that things were communicated both through audio and visual um we're like an earlier iteration would only communicate it through one and that was just kind of baked into that content um but yeah I guess it kind of depends on the specific feature I hope that answers your questions yeah totally thank you all right then seems like we're wrapped up thanks everybody [Applause] [Music]