Closed Beta Feedback
Controller UI
Movement: Controller movement felt fairly natural. Though it wasn’t as fluid as experienced in Path of Exile with regard to turning for aiming, it was still enough to aim relatively precisely. Moving back and forth or up and down did not produce any frame halting or shifting effects.
User Note: PoE’s controller turning appears to utilize the full 360° arc, while D2R has some subtle, but still noticeable “steps”. They’re fine grained enough to be perfectly usable, but making use of every last degree instead of what appears to be degree arcs, no matter how small they may be, would create a superbly fluid experience with movement.
Button Binding Pane: For UI reasons, the controller button binding requires going into the options window. While standard fare, there is an bit of a problem that can get very annoying. The controller controls pane is found as a sub-pane alongside the skill tree panes. This requires not only shifting via LB/RB (L1/R1 on PS controllers) to the skill tree section, but then also using LT/RT (L2/R2) to select the controller sub-pane. Ideally, for both simplicity and ease of use, this subpane should be moved into its own primary pane accessible without having to be alongside something that has nothing to do with controls.
User Note: Simplicity is best here. Control bindings should always be in their own easily accessible section, not in a subsection, and especially not in a subsection alongside other items that have nothing to do with controls. Having to mix shoulder button and trigger button use to navigate is confusing and should be avoided whenever possible.
Button Binding (Actual Buttons): L2, L3, and R3 cannot be bound to anything currently due to pre-assigned functionality. This is expected since L2 shifts between skill bind rows just like it does on Path of Exile. However, a way to bind LB/RB (L1/R1) to at least the belt slots (and preferrably anything else) would be greatly appreciated.
This would allow us to have health and mana potions available at the tip of our fingers instead of having to take our thumb off of the left analogue stick to use them. It would also simplify it internally for players (i.e. how they perceive it in their head) by lessening the two remaining belt slots to just two opposing directions on the D-Pad. It is much easier to remember D-Pad L and D-Pad R for two slots than it is to remember which slot is U/L/R/D. This also then allows two of the D-Pad buttons to be set to functions used less often, such as show/hide item nameplates and toggling run/walk (to save wear and tear on L3).
User Note: Having some flexibility in binding belt slots and the more esoteric functions allows the player to work with a setup that feels tailored to their needs instead of being bound by a rigid system. Path of Exile had too many binds to allow for this, but D2R does not, and could benefit from the extra flexibility.
Targeting (Controller): Targeting enemies is problematic on the controller. If I’m facing an enemy in front of me, the autotarget will more often than not choose an enemy behind the one that’s closest to me. This makes melee targeting frustrating. Additionally, if we’re hit and our attack animation is stopped due to even a brief hit-lock (hit recovery), we have to release the skill button and press it again. Because this happens very frequently in the game, it also causes loss of target in most cases due to how quickly autotarget shifting occurs.
As such, a target lock bind would be immensely helpful for controller users trying to attack a specific target. This way a target isn’t lost due to having to release and re-press the skill button. Also, a fix for skills just stopping entirely upon being hit-locked would be grand. That way once the hit recovery period had ended, the skill will continue to trigger without having to release and press the button again. The combination of these two changes should alleviate most of the basic targeting issues on controller.
User Question: Button responsiveness feels lacking, almost like there is just a hair of an input delay. Is this due to the Resurrected engine being tied to the OG engine’s internal FPS cap and associated difference?
Targeting (UI): Currently we have an odd mix of monster nameplate above their head and text with no health bar up on the top center of the display. Options to enable/disable each of overhead nameplates and/or top center name would allow users to fine tune the HUD aspects to suit their desired visual preferences. Adding the health bar to the top center HUD element like we have with the KB/M UI makes sense as well.
Targeting (Visual): Currently I am unable to really visually discern any highlight around a monster when it is targeted. PoE offers this in a subtle, but still visible way. Adding this would make it so we could verify at a glance that we do indeed have the desired monster targeted. Having a more prominent highlight would also allow players the option to disable overhead nameplates if desired, as the top center display combined with targeting highlight would be sufficient to tell what you’re attacking at a glance.
Targeting (Item Pickup): Currently the X/A button is used to pick up items by default, but it also triggers skill use as well. This needs to be addressed, if possible. Wasting mana, ammo, or swinging a melee hit while trying to pick up items doesn’t work well. If this goes unchecked, then the current recommendation of setting X or A to loot pickup only will end up as the preferred way to set up for item pickup. Ultimately that is what I am likely to tell players to do - just set X/A to pickup only and sacrifice a skill bind slot to avoid this problem.
The other glaring issue here is the lack of ability to select an individual item while you’re within range to pick it up without moving your character. Path of Exile solves this by utilizing the right analogue stick to move up and down the onscreen items so you can pick and choose what you want to grab. It isn’t as fast as doing it with a mouse, but it never will be with a controller. The problem with moving your character to pick up loot is that the nameplates shift when you do so, making pickup extremely difficult and time consuming even for just a few items. When an item drops a player should be able to get to it with a minimum of hassle.
Targeting (Precision): Currently, if we want to aim an attack, we either have to be lightning fast on the analogue stick and button press, or be moving when we let off the attack. One of the things that Path of Exile had before it introduced the third set of four skill binds and whose removal actually made me stop playing entirely on console was the force stand still bind.
A force stand still bind allows a player to attack without fear of moving accidentally, and it lets ranged players aim their attacks from afar with precision. When PoE removed the FSS bind, we had to hold down a skill to aim just like we do in D2R currently. Only there is no ammo to be wasted in PoE, so it’s “less” of a problem there, except for one thing that ties into aiming in D2R: there are “breakpoints” for aiming and with the current lack of FSS + 360° / 1° aiming steps, precision aiming is impossible in D2R. If you want a good place to practice such an annoying scenario, go after Rakanishu while he’s inside the Cairn Stones or try targeting monsters behind bars in the indoors levels. Force Stand Still is an absolute necessity for precision aiming and wasting as few resources as possible in this game.
Vendors: We currently have dual functionality for buttons while on vendor screens. That has led me to do things I don’t necessarily want to do. It is better to have each button have a singular task. Triangle/Y should be to allow multiple use of the Tome of Identify so one doesn’t have to go back and forth holding down X to use, with Circle/B cancelling tome/scroll use. Square/X should be to vendor the item. X/A should be disabled (not do anything) when a vendor screen is opened. Multi-use via Triangle/Y should be allowed for the Tome of Identify in all instances.
User Note: I strongly recommend that Vicarious Vision’s developers load up Path of Exile on a PS5 or XSeX and play with the vendor controls. This is how it should be done for ease of use and fewer mistakes by the player.
Charsi: See PoE’s console crafting bench for best idea of options with regard to button use. No, seriously, they nailed this one. Copy it.
The XInput vs. DirectInput Schism: I ran into a user that was using a Logitech F310 wired controller that couldn’t get it to work (at least not initially). My Dual Shock 4 controller worked flawlessly, and even had proper icons (seriously, thank you for that!). As the Logitech F series has a switch on the back to allow for choosing XInput or DirectInput modes, I suggested to the user that he flip the switch to the opposite position and try again. I didn’t hear back, but assume he got it working by doing so.
So right now we know DirectInput works because my DS4 controller worked without any additional means such as Steam’s wrapper or DS4Windows. But I find it puzzling that XInput controllers weren’t working as they were supposed to. Is only DirectInput being used for D2R? If so, XInput needs to be put in too. Usually it’s the opposite where XInput is there but DirectInput requires third party means to work.
User Question: Is your input method solely DirectInput, or are you using SDL + controller database file for controller configurations? If the latter, Logitech’s controllers need to be put in. If the former, consider putting both input modes in and letting the user toggle between them to suit their controller.
Final Thoughs on Controller Support: You have seen me mention Path of Exile here multiple times. That is not a coincidence. Having played the console version extensively, I know just how fluid and responsive it is, and how well it is designed. I understand why developers might take slight at being compared to other developers, but they aren’t making the game for themselves, they’re making it for the players, and getting this aspect right the first time saves a lot of hours spent fixing something that didn’t need to be broken in the first place.
If an idea is well implemented somewhere else, don’t hesitate to copy it. GGG got accessibility (mostly) right with their console controller setup. The only thing they bungled was removing force stand still as an option, and leaving the aiming while holding skill buttons down subject to actual breakpoints when turning that weren’t present in the previous iteration of turning while the FSS bind was held down. You have a chance to one-up them here. Don’t miss out on it.
Keyboard and Mouse UI
Responsiveness: The mouse feels smooth and clicking appears relatively precise. There does feel like there is an input delay with skills though when repeatedly pressing the mouse button (required due to the aforementioned issue with controllers and hit recovery causing a button hold to stop working). Firing arrows was not responsive like it is in D2/LoD-C. I tested this out by launching the classic version and doing the same things, and every time the classic version consistently fired off my arrows whereas D2R failed to do so a not so insignificant amount of the time.
Skill Binds (RMB): The current UI does its best to mirror what the classic version’s UI functionality was, but there is an issue where bindings are not separately saved for each weapon swap. This leads to a scenario like a ranged weapon like the Javelin having a throw binding in for the RMB on weapon swap 1 (WS1) and a melee/bow weapon having a non-throw binding, and swapping between them forces the throw binding to not reappear when switching back to the swap with the thrown weapon.
Easy way to test this: Equip javelin/shield in WS1, set binds to attack and throw respectively for LMB/RMB. Have WS2 use sword and any skill or tome/scroll binding. Starting with WS1 you’ll see throw on RMB. Swapping to WS2 gives you the skill/tome binding. Swapping back to WS1 retains the WS2 RMB binding if it is a tome/scroll binding or it reverts to basic attack mirroring the LMB if WS2’s RMB was a skill binding. The original did not act like this that I can see and in the heat of battle leads to some very unfortunate circumstances.
Skill Binds (LMB): Right now almost nothing can be bound to the LMB other than basic attack, throw, and tome/scroll. Users are asking to be allowed to put whatever they want on there and have it remembered separately for each weapon swap.
NPCs/Dialogue Options: The current “dialogue options” box that pops up when clicking on an NPC is tiny. The text inside is easily barely half the size of the NPC’s nameplate text. I have a lot of trouble clicking the choice I want without drastically slowing my wrist down on a mere 1080p display. On a 4k display this would be so tiny I probably couldn’t even do it properly. This needs its size increased significantly, both for readability and physical clickability/accessibility. It’s smaller than the original in screen area, and this should not be the case.
Item Nameplates: Item nameplates appear to have a higher strata than monsters or even the player’s own character. This leads to both becoming hidden behind items on the ground, and in cases of lots of scattered items, causing issues with aiming. It was a small but irksome issue in the classic version, but is very irritating here in D2R. This happens in both controller and KB/M UI mide, but is more problematic in KB/M mode due to fewer places available to click on. The high strata interferes with clicking even when using the force stand still (shift) key.
Stat and Skill Available Buttons: In the classic game and in the alpha, the KB/M UI has space for these two buttons that pop up whenever you level up. Currently the D2R Resurrected KB/M UI does not. Why? This is one of the UI elements Diablo 3 players have been trying to get rid of ever since paragon levels were introduced. Please don’t bring that into D2R. Not when you have enough space to include them in the UI bar.
Skill Bar: While it is good that there is an option to keep the origina look and feel of the classic UI layout, once you have played with the controller and suddenly have access to multiple skills at a whim without having to swap keybinds via whatever you set for that function, it’s really, really hard to justify keeping this very archaic setup as the only option for KB/M users.
Many of them, myself included, are asking for a second option for KB/M, which is to mimic the Diablo 3 style skill bar. You’ve got room for it on widescreen displays, so this isn’t impossible to make. And it would alleviate or minimize one of the biggest problems with KB/M use, which is RSI. Having a set of keys you can have skills bound do in addition to LMB/RMB makes builds feel more fluid and alive. Having to hit a function key (or whatever you configured for this in Resurrected mode) to swap skills is an ancient design that has not aged well at all.
Yes, there is a mousewheel next/previous skill option, but this would work so much better and would likely greatly reduce the complaints that players can’t bind anything but the most basic of options to the LMB since it would open up keyboard keys for skills. This would also allow players, should they choose to do so, use one of those Orbweaver type gamepads for their skills while using the mouse in the other hand. That’s a whole lot of flexibility there!
It is important for those reading to understand that we’re asking for this as an option, not as the defacto UI that replaces the OG UI layout. We want the OG layout to remain as an option as well. And it makes a lot of sense to give this to KB/M users because it puts them on par with ease of use for multiple skill builds relative to controller users, and for D3 players coming into D2 it gives them an option that doesn’t feel conceptually claustrophobic.
Force Move Key: KB/M users are asking, and rightly so given the sheer number of mobs that can surround you combined with items on the ground, to have a force move keybind. The reasoning should be fairly easy to figure out. D3 made this addition and it works wonderfully. This is a rather large QoL for KB/M users.
Final Thoughts on KB/M UI: This mode had to have the least done to it. Unfortunately some things were done and are very unwelcome (lack of binding saving on weapon swaps, A/S buttons now out in combat area and not on UI bar). Thankfully that can be fixed relatively easily. And all things said, choices means flexibility. As we’re talking control choices and not ginormous passive tree (*cough* Path of Exile *cough*), this shouldn’t be controversial in the least, especially if the OG setup remains an option.
Miscellaneous
Projectile Visibility: I only worked with the Amazon this time around, but there appear to be at least some deficiencies with projectile visibility. Arrows in particular are virtually impossible to see even at a lowly 1080p. I don’t know if it’s because they’re too thin or just not shaded right, but they’re eye gougingly difficult to make out.
From what I can visually ascertain, it appears that all bow wielding monsters and players are using the bolt projectiles rather than the arrow projectiles. This lead to me constantly wondering what in the world was picking off my life, as you can be sniped from offscreen by ranged monsters. In the classic version I can see arrows and bolts clearly. Not so here. Can you spot the arrow in these screenshots? I can’t.
Netcode: It is very apparent that the netcode wasn’t changed from the original. Everything that rubberbands you in the classic version does so here as well. Hug a corner too tightly? Snap! Try to get around monsters and thought you got through? Nope. SNAP! Back you go, and usually either dead or with some life lost.
This is one thing that should be ripped right out of Diablo 3 and put into D2R. D3 had rubberbanding issues galore when it started out, but no longer does outside of niche circumstances such as purposely rounding a small object tightly. But D2R gets you rubberbanded on an all too frequent basis. This one is very likely to make or break the online portion of the game for a lot of players. It’s been over twenty years, and netcode has improved since the game was first released. The modern client shouldn’t be having these issues, especially not as frequently as they occur.
Character Design: I haven’t had a chance to really look at the Assassin up close since she doens’t move when moused over in the beta client, but the Amazon still looks like a man. She’s much less Schwarzenegger, but she still looks like a 20 year old man. If not for the ever so slight bulge in her chest armor I’d think she was a man. It isn’t so much the “hardened” face as it is the squared jawline. If you can narrow the chin it will actually look like a woman while still retaining the hardened look of the rest of her face, arms, and legs. As it is now, one could easily mistake this for a clichéd depiction of a Roman gladiator.
Looting: Controller users are going to have a massive disadvantage in a FFA loot scenario, even moreso than slower KB/M users. It’s a virtual guarantee that controller users won’t get much of any loot at all in a public game. As such, an instanced loot option needs to be added to created games so that everyone has a fair and equal chance at loot. Having a mode where you’re almost guaranteed to not get loot means that mode will be disfavored even by those that need it most.
Game Engines: There appears to be a notable input delay and or shifting going on when changing directions via the mouse. There is also significant performance degredation for many users when rain is present or for ultrawide users, black bars on the side. Whatever the case, it appears that running both engines simultaneously so we can switch between them on the fly is wasting a lot of resources.
There should be three options available to the user in the game to remedy this: Dual Graphics, Classic, and Resurrected. This way players can use Dual Graphics mode to determine which mode they prefer to play in, and then the ability to select that mode, permanently keeping the other mode from running unless selected manually or Dual Graphics is re-enabled.
While having both engines running together is a neat technical feat and/or tech demo, it is absolutely detrimental for resource usage. Allowing one to shut off the mode they aren’t using then frees up resources, and could potentially allow more systems to play the game without problems.
Feature Requests
Windows Key: Some keyboards have a switch that lets gamers disable the Windows key so they don’t accidentally exit the game at an inopportune time. Most don’t, however, so an in-game feature that disables that key would be grand as an option. This allows you to avoid unwanted Windows Key presses that get you killed (or worse, cause loss of controller input, which can and does happen sometimes when the game loses focus).
Focus Lock: This is a big one, especially for players with disabilities that prevent easy fixing of problems when a game loses focus. As mentioned above, when the game is no longer in focus, sometimes controller input is lost until the game client is restarted, and the same for mouse acceleration curves that are app specific (e.g., profiles in Logitech G software). Normally you would use exclusive fullscreen mode for this, but DirectX 12 does not have this mode. So what we’re asking for here is a way to lock focus on the game app so some random skype message, system tray message, Windows Defender deciding it needs your attention message, etc. doesn’t cause the game to lose focus.
An example of the consequences of Microsoft so thoughtfully removing exclusive fullscreen as an option is when Star Ocean 4 loses focus for any reason at all. Once that game loses focus, you permanently lose controller input until you exit the game and restart. You are also reduced to partial mouse support. As that game has a never ending dungeon for endgame purposes that has no save points, you could lose hours of work for no good reason. I know - I’ve had it happen to me three times now in that game.
So any way to lock focus (and disable CMD-TAB at the same time) as an option would be super appreciated. Nothing says screw you like the game losing focus while you’re sitting back with a controller and suddenly lose the ability to move at all and get killed, especially at higher levels where the EXP loss is very pronounced in D2R.
Closing Thoughts
My time spent with the game was less about content and more about core functionality. As such, you have seen almost nothing said about drop rates or anything else that is content related. Being as that was not going to be change other than the addition of the three shared stash tabs, I focused entirely on control and accessibility.
There are good options in the game already, but a bit more and some polish to go along with it and things will be where they need to be. Right now I’d say the controller mode is roughly 60% ready and the KB/M mode about 70%, the remainder of the latter being lack of a D3 style skill bar as an option.
I enjoyed testing the client and was pleased that controller support was well enough along to do a little playing. It isn’t quite up to snuff with targeting or moving items easily within the stash/personal inventory, but it’s a far cry better than what World of Warcraft currently has for controller configuration.
