Jump to content
  • Sign Up

Designing For Controllers (Feedback)

Recommended Posts

With the nascent coming of GW2 on Steam, I thought I'd offer some insight from someone who's already testing that setup.  A quick primer on myself, I've had experience with MMOs since 2004, although I've only come to GW2 around two weeks ago.  Currently I have 5 toons, all of them at or around 20 so I'm relatively new to the scene, so my experience isn't colored by years of traditionally doing it one way.


Today I'm going to share my perspective as someone who plays GW2 on mobile.  Included are thoughts and suggestions over how to improve the usability of controller based inputs, but some of these observations will be applicable to the traditional interactions.  Also included are some ux tweaks that I believe could  reduce the cognitive load of certain user interactions.  This is done with the intent to give devs more headroom in order to create content that's more taxing and stimulating at endgame.


My controller of choice is a Kishi, with a Pixel 4a attached (an adequate, but not flagship phone).  This essentially uses the same layout as an xbox controller with a custom hud.




Anyway this is all my opinion, and should only  be read in the context of trying to provide players with greater accessibility.  But fair warning, I'll admit this UI stuff is going to be pretty dry in the abstract.  Hopefully a dev might see this at some point.


Now with that out of the way...


I'd like to break this up into three sections.  Movement, Touch Focused HUDs, and Game UI.




Joysticks on controllers have a reputation for being less accurate than their desktop counterparts.  I've found this is only partly true, and highly contingent upon the game.  First person shooters and other highly tactical genres tend to fare far worse than more methodical and slower paced titles like open world RPGs, and other titles with a forgiving autoaim.


There's two types of movement that Joycons are in direct control over.  The camera, and the player character.  But while the former often suffers from a lack of precision, the latter can actually be more accurate than the on/off state a keyboard allows.


For example, ESO transitions between at least 4 states of movement depending on how far the joycon is pressed, from the simple walking animation, to jogging, running, and sprinting.  These animations are blended into one another in such a way that the player won't notice unless specifically looking for it.  Also this effect is done on both mounted and unmounted characters.


As a possible stopgap one could play the same animation at different rates, but this presents its own set of issues.  Currently there is a bug in ESO on a keyboard and mouse (instead of a controller) where one can manually toggle their mount to the walk state, but it'll play the run cycle.  This visual discrepancy is odd, but not game breaking.


GW2 on the other hand only has a walk and a sprint.  It was never designed for these intermediate stages and so when using a controller player motion feels slightly inaccurate and floaty on a subconscious level.  As a player there's an expectation that isn't being fulfilled.


Admittedly adding in new animations is not a simple fix, and is easily the problem in this letter that would require the most resources to address.  The numerous amount of skeletons made for the variety of mounts would make the effort in fixing it arguably not worth the cost.  But I strongly suspect that unmounted characters would see a benefit from this change in movement puzzles and potentially mechanically intensive encounters like fractals.


Moreover giving the player a greater amount of control over their speed would address the run-and-stop nature of characters in escort quests that frequent Tyria events.


Conversely one can mitigate some of the camera issues relatively easily by having a slight bias towards the horizontal axis, reducing the speed of vertical movement.  Making these values independent of one another grants greater precision both in list based menus, and overworld questing.




There's an obtuse piece of knowledge that isn't being conveyed to new players.  Simultaneously jumping and dodge rolling will produce a higher and longer jump.  This is an effect that shouldn't be hidden.


Controllers bring their own issue, as dodge rolling often shares the same button as jumping in an effort to streamline the user experience.  Making it a dedicated corded press (if not already done so) would simply bring the action on par to keyboards.


While this animation cancelling might have started as a bug, there are many in the community who have come to appreciate this and treat it as a feature.  I'd prefer to see it given a slight rework personally, but at the very least it should be highlighted as a legitimate input method on controllers.




Pie menus are a fantastic way of declaring states, and pulling up UI elements like windows.  However they are terrible at direct player actions like skills which require split second decisions.


What I mean by states is choosing which weapons a player might use, like a rpg or pistol; or fighting stances.  Things that effect gameplay on a strategic level instead of a tactical  one.  Typically with a long cooldown.


Drawing a menu with 4 or 12 options presents a greater cognitive load than a simple button press or an always on screen hud element.  And it's little wonder that opening one in other games will slow down or even pause the gameplay in other titles.  This obviously isn't an option here so it should be reserved for interactions for when the player can have time to read and understand both the options and their position.


If placed on the screen as a UI element, actions like viewing the inventory or looking at the map are best positioned on the side that's directly adjacent to the closest screen edge.  In other words, if you extend your right thumb to press and hold the on screen button, it's naturally going to want to pull back to the right side.  Conversely the left will go the opposite direction.  So the lesser used options like Story Journal would make the most sense in an even further extension of the digit.


So for Rangers pie menus can work with great efficacy.  They change their pets state, and the limited number of options make the muscle memory an easy thing to pick up.  And the smaller profile of an on-screen button gives a greater amount of real-estate to move an offset cursor via thumbs without accidental presses.


The other side of that are Engineers, and any other class that has a lot of directed skills one places on the ground itself.  This is the worst case scenario because unlike two simple button presses, the user needs to first move their thumb to the correct space (which doesn't have a tactile cue).  Then they need to hold, and pull to the correct side.  Lift.  Move the thumb back to aim via a joycon.  Move the thumb a third time, again to a place with no tactile feel.  Press and drag.  And lift.


This all takes a considerable amount of effort.  It's an order of magnitude slower, and while going through these motions you're likely to miss something on screen.


As I see it, there's two options which could improve this.


Option One, give the player an option to add in a slight timer to line up their shot before autofiring their selected ability.  Essentially the player could turn aimed skills into very quick channels.  350ms maybe, you'd have to do some testing to see what's comfortable.  Or in an ideal world a slider with some very stringent parameters could work just as well.


Option Two, make the keypress down, and keypress up independent actions for aimed abilities.  For those who play MOBAs this should be familiar, because I've just described quick casting.  If a player has gone through the motions of selecting a skill, it stands to reason that they have every intention of firing off said ability.  Removing the skill check of doing it twice just streamlines the process. And does so in a way that levels out the playing field between keyboards and controllers.


I am aware of Arenanet's stance on multiple key presses for single actions, but this is a case where implementation by the devs themselves could be a worthwhile change to policy under these very specific circumstances.


It seems the game already has quick casting, it just needs to be enabled under the ground targeting dropdown menu.




Let's talk keyboards for a moment.


As devs, there's no direct control over what style of keyboard a person uses.  However, in my testing I've found that since the chat window is offset to one of the corners the best utilization of space is actually a floating keyboard docked to the opposing side.


Any keyboard that's docked to the bottom is either opaque, or translucent to a degree that it's difficult to read the chat underneath.  Whereas keyboards that are transparent enough to see through makes gauging the position of individual keys inaccurate.


To be sure, typing with one thumb is slow, but it's the best bad solution since it leaves open the space to see what one types.




I've made my thoughts known about the lack of menu keybind in an earlier thread.  So I'd like to focus on some low hanging fruit.



I often toggle between the action camera and direct cursor control several hundred times a day.  In my setup there's two ways in which I can simulate a mouse move.  Using a joycon, with the left-mouse button bound to another key.  Or using the trackpad method in steam link, moving my thumb anywhere on screen to shift the mouse position relative to where it was.


Rescaling the size of commonly used buttons would be a good step to lessen the amount of time spent in menus.  For example, widening the "Compact" and "Materials to Bank" buttons would make it easier to press.  Not just for me, but likely for anyone with a physical disability.  To be clear, the UI is at the largest resolution and it still takes a bit of doing to align things up properly.


Adding a lock position option would be a welcome change.  If I've set up menus in an exact way, retaining the ability to change their position is actually a net negative.  Accidental movement is just a distraction at that point.


Also having an option to automatically close windows when a new one is brought up would be a nice way to keep things clean.  With the possible exception of previews as you often need both.


None of these are make or break, but they're just QoL changes that can enhance player immersion by reducing the amount of time spent in menus instead of playing.

Speaking of immersion, there's a relatively famous skyrim mod that comes to mind.  iHud which collectively has around 1.5 million downloads.  It'd be nice to see some of that functionality in GW2.


Essentially it's a context based version of the "display only in combat" option currently available.  So for example one could set visibility of the xp bar to only show when you've recently gained experience.  Or toggle the menu bar up top off, unless your mouse cursor was hovering over the area.


Or even fade the skill bar to mostly transparent until in combat or hovered over.  A state that's in-between full off or on.  To reduce the amount of visual noise while adventuring.


Again, being able to toggle floaters would be lovely, but I won't harp on that too much except for this one mention.  But while some of these options do exist in a limited form, the lack of customization for up and fade time are made all the more apparent on menus at their largest size.




I'm sure there's a few things I've missed, and I'll try and post an update when I get closer to endgame.  When I nail down the hud in its final form I'll send an update.  Right now is a lot of experimentation, and I wanted to get my thoughts down as I was in the middle of the process of doing it.  Granted things are bound to change between now and 80 but I'm relatively comfortable in claiming the things in this thread to hold true.


If you've made it this far I'm impressed.  Any question I'd be happy to answer.


Happy gaming.

Edited by Driftpaws.2031
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...