A handful of UI suggestions to the CDPR devs

[aegiskleais]

A handful of UI suggestions to the CDPR devs

Hey devs! Sorry to interrupt the development of the game, but I'm a bit of a usability buff, and I would like to provide some information regarding UI enhancements for the PC that may prove to help make the game experience more enjoyable. I hope you can find it useful.

For an interface to be as intuitive as possible, it requires the least amount of cognitive and motor loads possible. A cognitive load is when the user has to think about what needs to be done in order to complete a task, and a motor load involves the physical movements needed to achieve that through the UI (such as moving the mouse, clicking a button or pressing a key.) A good UI minimizes both cognitive and motor-based loads on the user, and to that end I have a couple suggestions.

HOME ROW
The majority of PC users have their hands on home row, where keys from 1-4 (on top) and Z-V (on bottom) are considered "prime" real estate, as they are usually all within reach of the user without the need to physically move their hand. A common issue with many UI's is that they require the user to leave home row in order to press buttons that are commonly accessed. I cite, Witcher 2's use of 'J' in order to bring up the Journal. Such an act requires not only the motor load of moving the hand away from home row, but often even requires the user to stop focusing on the screen in order to visually confirm the proper button press (remember, we cannot assume the user is playing in a well-lit condition).

My suggestion is to allow an in-depth key mapping functionality, traditionally where the player can assign a "SHIFT" button. This button allows the user to double up functionality on readily-accessible keys to the home row position. For example, you could bind a function to Q, as well as CTRL+Q (if CTRL were designated to be the "shifting" button) It would even be beneficial for you to allow mouse buttons to act as the shift, thus, users can use a thumb button on 1 hand to toggle the functionality of the keys adjacent to their left.

CONTEXT-SENSITIVE ACCEPT/CANCEL
You can reduce the amount of loads needed to perform common ACCEPT/CANCEL functionality through the ever-present support of 2 major mechanics: First, allowing the mouse's LMB to function as ACCEPT and RMB to function as CANCEL allows an easily-accessible mechanic for common confirm/reject tasks. This is preferable to requiring the user to move their mouse to the ACCEPT/CANCEL option, clicking, and returning their mouse to its original position. Also, you could create 2 additional key mappings called "ACCEPT" and "CANCEL". These bindings would be permitted to exist elsewhere (ie, other functionality could be assigned to them) as the accept/cancel-assigned buttons would only function as accept/cancel when in the context of the game presenting them that option. When not in that context, the key's functions would default back to their primary options.

SHIFT-SENSITIVE RANGE SELECTION
When incremental values need to be selected, aside from supporting an ability to drag a visual selector, key and mouse functionality should be able to be used as well. For a mouse, it is common for scroll-capable mice to increment/decrement the value (duplicating that via the keyboard with the W key, traditionally thought of as 'Up/Increment' and S key, thought of as 'Down/Decrement', but for both mouse and keyboard use, allow the user the ability to hold the SHIFT key in order to increase the increment/decrement process by a factor of 10. This will allow for quicker functionality in the event there is a large quantity the needs to be adjusted.

REMOVE THE NEED TO DRAG
In the Witcher 2, the user had to drag items to a "Drop target" in order to destroy them. This process was very slow as it required a great deal of motor load for the user. Instead, I suggest providing a feature with easy discoverability that allows the user to hold a modifier (say, ALT) while in their inventory, to quickly allow the disposition of items. This can be hinted at via the interface or an information window of the item, ever-present at the bottom. You could also use the CTRL modifier when clicking on items in order to break them into separate stacks in the event the user wants to perform actions on a set amount, but not all.

OPTIMIZE REDUNDANT TASKS
During play testing, it is a great opportunity to see what kind of interactions the player is performing most often with the UI, and to look for redundancy in them. Is the user accessing the map often? Once in the map, are they constantly looking for an indicator as to where they are? (make the indicator more obvious) Are they zooming in? (Adjust the default zoom level), do users have to sequentially go through a process to get to their task (optimize the process to be more prominent or require less effort). Even small optimizations, especially ones that are utilized often, can have a tangible positive effect on the human/computer interaction process when they are optimized.

REDUCE THE AMOUNT OF NAVIGATION NEEDED
Though we still want to reduce clutter and ensure that each area has its own dedicated "area of concern" (ie, we don't necessarily want to mix the Skill Trees area with the Journal, however a journal's quests might have related functionality on the world map), the Witcher 2 required the user to exit a navigational location and return to the game in order to bring up another. For example, if you had the map up, you had to close the map, returning you to the game, before you could then bring up the Journal. Instead, off the user a seamless way to move through the multiple areas of menu navigation. Many players may feel the TAB (and SHIFT + TAB) function as intuitive ways of moving through the menu, however to be as user-friendly as possible, you may want an option in the key bindings for "Next Tab" and "Previous Tab" to allow users to customize the buttons. Like in the aforementioned suggestion, these are context sensitive buttons, so they should be able to be mapped to multiple functions, because the tab to/fro is only contextually relevant when the user is not in the active game, but instead in the menu system.

EASE OF DIALOGUE SELECTION
Since story is such an important aspect, and dialogue selections are an integral part of the game, care must be taken to ensure that the selection process is quick, easy, and has no risk of accidental selection. Again, citing the Witcher 2, the user was required to either move their mouse to the option (with a small percentage chance the game would fail to register the hovered selection) or the user had to take their hand off home row in order to use the arrow keys (which are, despite their visual indicators, a poor selection for menu navigation). PC gamers associate the WASD keys for directions (W=Up, A=Left, S=Down, D=Right). In tandem with the aforementioned selection of allowing the mouse LMB/RMB (as well as 2 user-defined keys) for accept/cancel and a highlighted response, this should provide for an effortless and error-proof method of dialogue selection with minimal effort from the user.

COMPARISONS ON THE FLY
Another large part of games of this nature is the progression of a player's gear. As we get new gear and enhance each piece, we want to ensure that we are seeing marked progression in the expected traits of that gear. As such, quick comparison statistical differences should be provided against the currently equipped item. In the Witcher 2, there were issues where one could not compare gear they wished to purchase to the item currently equipped, requiring the user to completely exit the interaction with the merchant, re-evaluate their current gear, and then memorize the stats as they reinstantiated conversation with the merchant. To ease the cognitive load in requiring the user to remember those stats, a system that provides a clear look at what traits are better or worse would be very beneficial.

That's most of what I could think of off the top of my hat. I hope this is not taken as some random Schmoe "telling" you what to do; by no means am I; I am simply offering some suggestions that I feel would help the Witcher 3 to be the best it can (and I wouldn't be surprised, with the talent CDPR has, for you to tell me "Well, we're already doing all those things") You guys are very talented, and I know that no matter what happens, the game we get will be amazing. I hope I was able to explain myself well enough, if not, please let me know; and keep up the great work!

 

[darcler]

A long post if I even seen one :shock:
The UI is indeed of paramount importance in the case of a game where one will be spending 100+ hours. What can be accepted in a 20-hour game, or even 40-hour game, will be exhausting in a longer play.

What I might also suggest is to make all the UI elements as responsive as possible. Animated buttons, sliding menus, etc. are all fine and dandy, but when you have to wait a second or two for your journal to appear, it's a bother. Especially if you just want to quickly check on something.

Another suggestion I have is to mark not only updated journal entries, but also the specific paragraphs that were added. When I was trying to read diligently all Dandellion's musings in my journal, I often ended up rereading entries because I didn't know which paragraphs were added.

 

[Einhaender]

Many points you cover are regular keyboard control "goblins"(I say goblins because idk, some people may like 'em, some may not, so I don't want to call them issues) like the good ol' drag-to-destroy.

That said 80% if not more of your points are already covered/resolved by using a controller. Especially the TW2 comparisons.

Now I don't want to turn this into a controller vs. keyboard thing, but I think it's safe to say that these days, having a controller for gaming on PC, especially for multi-platform non-fps games, is not out of the question. Keyboard and mouse never were gaming devices and "intuitive" controls were always a point for discussion. One guy liked controls in game X, another complained he'll break his wrist. It's a huge devide and devs sure have a hard time making complex design choices work on it and remain "intuitive" and as I said, it never worked out for everyone, even with remapping. Controllers may have lesser " keys" to map, and stick accuracy is not as good as a mouse, but they also have less margin for errors and for most of us, are the most intuitive gaming device. And WASD was never good to begin with...

But as long as the game doesn't say "controller only" you have every right to ask for better controls for your choice of device you use. Especially with stuff like having to move the mouse cursor to everything in TW2, instead of simply pressing a key, like you do using a controller.

I never even tried to use the keyboard for TW2, and personally I don't know one person who did, but reading your post now it seems that using Keyboard and Mouse was quite a .....wait for it ..... drag :hai:

 

[Jupiter_on_Mars]

Hey devs! Sorry to interrupt the development of the game, but I'm a bit of a usability buff, and I would like to provide some information regarding UI enhancements for the PC that may prove to help make the game experience more enjoyable. I hope you can find it useful.

For an interface to be as intuitive as possible, it requires the least amount of cognitive and motor loads possible. A cognitive load is when the user has to think about what needs to be done in order to complete a task, and a motor load involves the physical movements needed to achieve that through the UI (such as moving the mouse, clicking a button or pressing a key.) A good UI minimizes both cognitive and motor-based loads on the user, and to that end I have a couple suggestions.

HOME ROW
The majority of PC users have their hands on home row, where keys from 1-4 (on top) and Z-V (on bottom) are considered "prime" real estate, as they are usually all within reach of the user without the need to physically move their hand. A common issue with many UI's is that they require the user to leave home row in order to press buttons that are commonly accessed. I cite, Witcher 2's use of 'J' in order to bring up the Journal. Such an act requires not only the motor load of moving the hand away from home row, but often even requires the user to stop focusing on the screen in order to visually confirm the proper button press (remember, we cannot assume the user is playing in a well-lit condition).

My suggestion is to allow an in-depth key mapping functionality, traditionally where the player can assign a "SHIFT" button. This button allows the user to double up functionality on readily-accessible keys to the home row position. For example, you could bind a function to Q, as well as CTRL+Q (if CTRL were designated to be the "shifting" button) It would even be beneficial for you to allow mouse buttons to act as the shift, thus, users can use a thumb button on 1 hand to toggle the functionality of the keys adjacent to their left.

CONTEXT-SENSITIVE ACCEPT/CANCEL
You can reduce the amount of loads needed to perform common ACCEPT/CANCEL functionality through the ever-present support of 2 major mechanics: First, allowing the mouse's LMB to function as ACCEPT and RMB to function as CANCEL allows an easily-accessible mechanic for common confirm/reject tasks. This is preferable to requiring the user to move their mouse to the ACCEPT/CANCEL option, clicking, and returning their mouse to its original position. Also, you could create 2 additional key mappings called "ACCEPT" and "CANCEL". These bindings would be permitted to exist elsewhere (ie, other functionality could be assigned to them) as the accept/cancel-assigned buttons would only function as accept/cancel when in the context of the game presenting them that option. When not in that context, the key's functions would default back to their primary options.

SHIFT-SENSITIVE RANGE SELECTION
When incremental values need to be selected, aside from supporting an ability to drag a visual selector, key and mouse functionality should be able to be used as well. For a mouse, it is common for scroll-capable mice to increment/decrement the value (duplicating that via the keyboard with the W key, traditionally thought of as 'Up/Increment' and S key, thought of as 'Down/Decrement', but for both mouse and keyboard use, allow the user the ability to hold the SHIFT key in order to increase the increment/decrement process by a factor of 10. This will allow for quicker functionality in the event there is a large quantity the needs to be adjusted.

REMOVE THE NEED TO DRAG
In the Witcher 2, the user had to drag items to a "Drop target" in order to destroy them. This process was very slow as it required a great deal of motor load for the user. Instead, I suggest providing a feature with easy discoverability that allows the user to hold a modifier (say, ALT) while in their inventory, to quickly allow the disposition of items. This can be hinted at via the interface or an information window of the item, ever-present at the bottom. You could also use the CTRL modifier when clicking on items in order to break them into separate stacks in the event the user wants to perform actions on a set amount, but not all.

OPTIMIZE REDUNDANT TASKS
During play testing, it is a great opportunity to see what kind of interactions the player is performing most often with the UI, and to look for redundancy in them. Is the user accessing the map often? Once in the map, are they constantly looking for an indicator as to where they are? (make the indicator more obvious) Are they zooming in? (Adjust the default zoom level), do users have to sequentially go through a process to get to their task (optimize the process to be more prominent or require less effort). Even small optimizations, especially ones that are utilized often, can have a tangible positive effect on the human/computer interaction process when they are optimized.

REDUCE THE AMOUNT OF NAVIGATION NEEDED
Though we still want to reduce clutter and ensure that each area has its own dedicated "area of concern" (ie, we don't necessarily want to mix the Skill Trees area with the Journal, however a journal's quests might have related functionality on the world map), the Witcher 2 required the user to exit a navigational location and return to the game in order to bring up another. For example, if you had the map up, you had to close the map, returning you to the game, before you could then bring up the Journal. Instead, off the user a seamless way to move through the multiple areas of menu navigation. Many players may feel the TAB (and SHIFT + TAB) function as intuitive ways of moving through the menu, however to be as user-friendly as possible, you may want an option in the key bindings for "Next Tab" and "Previous Tab" to allow users to customize the buttons. Like in the aforementioned suggestion, these are context sensitive buttons, so they should be able to be mapped to multiple functions, because the tab to/fro is only contextually relevant when the user is not in the active game, but instead in the menu system.

EASE OF DIALOGUE SELECTION
Since story is such an important aspect, and dialogue selections are an integral part of the game, care must be taken to ensure that the selection process is quick, easy, and has no risk of accidental selection. Again, citing the Witcher 2, the user was required to either move their mouse to the option (with a small percentage chance the game would fail to register the hovered selection) or the user had to take their hand off home row in order to use the arrow keys (which are, despite their visual indicators, a poor selection for menu navigation). PC gamers associate the WASD keys for directions (W=Up, A=Left, S=Down, D=Right). In tandem with the aforementioned selection of allowing the mouse LMB/RMB (as well as 2 user-defined keys) for accept/cancel and a highlighted response, this should provide for an effortless and error-proof method of dialogue selection with minimal effort from the user.

COMPARISONS ON THE FLY
Another large part of games of this nature is the progression of a player's gear. As we get new gear and enhance each piece, we want to ensure that we are seeing marked progression in the expected traits of that gear. As such, quick comparison statistical differences should be provided against the currently equipped item. In the Witcher 2, there were issues where one could not compare gear they wished to purchase to the item currently equipped, requiring the user to completely exit the interaction with the merchant, re-evaluate their current gear, and then memorize the stats as they reinstantiated conversation with the merchant. To ease the cognitive load in requiring the user to remember those stats, a system that provides a clear look at what traits are better or worse would be very beneficial.

That's most of what I could think of off the top of my hat. I hope this is not taken as some random Schmoe "telling" you what to do; by no means am I; I am simply offering some suggestions that I feel would help the Witcher 3 to be the best it can (and I wouldn't be surprised, with the talent CDPR has, for you to tell me "Well, we're already doing all those things") You guys are very talented, and I know that no matter what happens, the game we get will be amazing. I hope I was able to explain myself well enough, if not, please let me know; and keep up the great work!

Truly excellent post. I look forward reading more from you. @Marcin Momot, please submit the OP to the UI designer's consideration.
Agreed. TW2 UI was sometimes frustrating.

Additionally, when a sign, say, Quen, has been cast, instead of having its duration displayed via a counter, why not simply have the graphical effect - purple sparks or whatever - gradually fade out over time?.

 

[Kris_teh_pwnz]

If I were them I'd hire this dude.

 

[jerf.674]

Truly excellent points raised in the OP. I second the plea to @Marcin Momot to pass this to the UI devs.

 

[TheFawz]

Very nice detailed post going on about the benefits of having good UI. I think it's a really important part of games and can sometimes make or break the experience for me (silly I know). I really hope that's one aspect of the game that gets the attention it deserves, but even if it ends up being sub-par I think it quite safe to assume post-launch patches will resolve the major issues (like they did for previous games). There's also bound to be a couple of basic mods to customize a few things.

 

[aegiskleais]

@Einhaender
True, many problems don't exist on the controller, but this is what we call an "Input context", and (believe it or not, because I am such a person), there are MANY users who for them, a controller is simply not an option. People have preferred methods of input, such as the keyboard and mouse, an in order to produce the highest about of accessibility, we would not want to force the user into using an input method they are either not familiar with, requires an additional purchase, or that they might be against using for whatever personal reasons. They PC platform has a standard input method that is widely accepted: Keyboard & Mouse. I'm sure the amount of PCs that have a controller readily available is significantly lower. The fact that you state that you don't even know a single person who used keyboard for TW2 shows just how varied gamers can be on this platform. Believe you me, I trust your statement is right, but in the same notion, I am a player who has never known a friend of mine to use a controller on a PC game. This varied preference of input methods shows that it takes an open mind from the developer to imagine all the possibilities that exist, rather than just to hold themselves to their own personal experiences. Good points!
@Jupiter on Mars
Despite these UI shortcomings in TW2, I am currently re-re-(re?)-playing it again, with all the TW3 hype. Such a beautiful game! Memories of the games events keep coming back from me.

Spoiler

. In my last playthrough, I let Letho live at the end, cause I actually had felt sorry for the guy. Odd, I find it difficult to choose dialogue options that counter how I, myself, would actually answer the event in real life. With what we've seen from TW3, my salivation glands are going to run dry by August, lol.
@Kris_teh_pwns
I wouldn't want to work at CDPR.... (I'd want to LIVE THERE FOREVER!!! ) lol. That would be amazing to find a job with a company I respect so much, and thank you for the kind words. There's something about the HCI (Human/Computer Interaction) model that I find fascinating from a psychological standpoint. How we, as humans, interpret and interact with the interfaces we are presented with. I think one of the hard and fast rules is "There are no rules, merely guidelines." I think this stems from the fact that there are so many people out there, and we all have our own way of interpreting what we see; none of which is the wrong way.
@Fawz
To me, there are some companies who do not code platform-centric UI issues well; like Ubisoft. Ubi is a phenomenal console developer, however I feel that a lot of what they push to PC are rather shallow ports that they barely spend any time on (as I see common UI issues prevalent in older games still exist in the newer) Do you remember Skyrim? (assuming you played). It's UI was very centered around the core functionality of a gamepad, and did not transpose well to the PC. And since the menu was accessed so often during your possible 50-100+ hours of play, those small nagging UI issues really became a big problem (that, if I recall correctly, modders actually addressed rather than the company). But you raise a great point; allowing a certain level of modular code can really give the community the ability to add tweaks and modifications to suit their needs. I'm always amazed at what the modding community comes up with. Well put.

 

[Mr. Barvo]

I hope theres going to be different interfaces on PC respective consol, cuz you use mouse/keyboard and gamepad differently. With the consol UI more simplistic and the PC more advanced would be likely.
Something i don't like, as OP already stated, is when you have to move and look for example "i" for inventory. Tab would be a perfect position to enter inventory. Unlike the witcher 2 and like the witcher 1, i would like the oppertunity to switch between Inventory, journal, map and skill in the same interface, without the need to go back. Capslock is good for maps and "<" for journal maybe.

 

[Garrison72]

Wow. I'm impressed. CDPR, listen to this guy.

 

[aegiskleais]

I hope theres going to be different interfaces on PC respective consol, cuz you use mouse/keyboard and gamepad differently. With the consol UI more simplistic and the PC more advanced would be likely.
Something i don't like, as OP already stated, is when you have to move and look for example "i" for inventory. Tab would be a perfect position to enter inventory. Unlike the witcher 2 and like the witcher 1, i would like the oppertunity to switch between Inventory, journal, map and skill in the same interface, without the need to go back. Capslock is good for maps and "<" for journal maybe.

You know, Mr. Barvo, they could even go so far as to have "Adaptive UI". UI that responds to patterns. Let's say TAB brings up the Inventory screen (a feature I like as well), and from there, the PC saw that you often immediately went to another tab area, say the "Map". Well, with this feature enabled (we make it a feature so that those who don't want to use it can disable it), the game would realize this pattern and when the user hits TAB next time, it takes them to the Map by default.

This is just an example, but you see the same pattern recognition in many mobile products. The software that "guesses" your words actually will see how many times you select its recommendation based on the first couple of letters you type, and as you continue to select the intended one, it moves that up the list of recommendations so that (when in the proper context) the suggestion for that word comes up once you have typed even fewer characters. In this way, it "learns" your speech patterns and makes itself more optimized for you.

Also, we should recognize that buttons can multiple interaction modes: Click, Double Click, Click and Hold. A UI can support each of those (though Double Click is often not supported due to erroneous detection between itself and a single click). But TW2 did this with bomb throwing. When you hold (R in my case), the game entered a "throw aiming mode" and when you released, Geralt threw the bomb. That is an excellent use of a modified interaction state.

Ultimately how many times are you guys irked when something tells you "Press Button X to do action", when either (a) you've mapped that function elsewhere, thus making the information incorrect, or (b) you are using an input method that does HAVE a "ButtonX", again, invalidating the validity of the statement. What games need to do is to ensure they use the active input context, and what textual data should say is "Press the [Reload] Button". That way, the user is familiar textually with the function needed, and they are aware of the input process to achieve that action. As far as in game, the game should be smart enough to detect the input method, and then read from configuration what sequence is needed to perform it, thus displaying that directly on screen where necessary.

 

[aegiskleais]

Many users, who take the wrong steps to get to a successful result, will continue to do so and not learn what is proper. This can often be alleviated with what is known as: Discoverability Let me give an example.

Let's say that in order for a user to get to their Character Skill Screen, they press TAB to enter the menu system, and then click on the word "Skills". However, the developer expected the user to simply press the "C" button (configurable in key bindings). The reason why the user takes this long way is because, ultimately, it gets them where they want to be, so it is a successful, albeit lengthy, process.

If on the menu screen, we added button icons next to each section that had a mapping to it, the user could then "Discover" that all they need to do is press the "C" button to go directly there from the game world. Once they attempt this, they then commit this process to memory as the most optimal way to get to what they're expecting; but without that discoverability, users may use interfaces in a manner in which they weren't necessarily designed.

 

[Mr. Barvo]

yeah! But only if this adaptive UI is optional and that i can turn it of. In borderlands they have all the things in one menu, and when you press tab you get to ethier inventory, journal or map depending on what you was before. This was sometimes confusing and irritating, fortunatly it was ewasy to switch between the menus.

 

[Einhaender]

@Aegis_Kleais
When I got the notification about you mentioning me, I really hoped it was about my pun of the century! ...... ..... .... ...

Anyway, I didn't mean to imply no one uses the K+M on PC anymore. I use it regularly myself, just not for said games. I just can't stand 3D movement with keys in 3rd person anymore. But as I said with the "But as long as the game..." segment, you have every right to ask for proper controls on the "default" device for PC. I had no idea it was that bad.
Well, maybe it wasn't that bad, but obviously not polished enough and more in favor of controllers, or you wouldn't had the urge to make that post.

So I really hope you guys get better controls this time.

 

[aegiskleais]

@Mr.Barvo
Yes, I made to to mention that. You can always endear more people by making features options that can be disabled/enabled at will, rather than forced on/off. The biggest choice to make involves what the default out-of-the-box install mode should be. And that's where the 80/20 rule comes into play! In UI, you usually can't make 100% of the people happy; which is why you sometimes have to just play to the odds as best you can.
@Einhaender
Pun of the century? You sell yourself too short. That was the Pun of the Millennium!

I think what does us a disservice (but at the same time, is the reason why we have choice in the first place), is that there's no standardization of input. If keyboard were all that would be support (not advocating that, just saying), there are a lot of manufacturers who develop keyboards that are not your standard 104-key model. So, I can understand from a developer point, it's hard to properly support so many input methods, and at a certain point, you do have to say "Sorry, we can't do more."

For example, I do web development. There's a long-running angst among web developers for IE. We loathe it. But most end users, who are not concerned with web development don't really know why there is so much ire and hatred for it. To them, it's just a browser, and they expect every website to work fine it. But the reason why we don't like IE is specifically because it constantly avoids being standards compliant. When you build a site, you have to tweak, hack and modify your code just to get IE to render it as you expect. Anything which requires you to have to do more work for the same effect quickly becomes something you end up having impartial feelings towards. The end user? They expect it to just work. But the developer; they are intimately familiar with the "cost" needed in doing so. This is why a site can't be guaranteed to work in every browser (since there are over 3000, each with it's own mix of capabilities and rendering output).

I think the tough part for gamepad/keyboard support is that your code has to support those 2 distinct environments, and if another keyboard/gamepad varies enough from the basic, you either have to add another large part of code to accommodate it, extend your current input code to include it, or opt to simply not support it. The latter is easiest, but most disappointing to the user, however, you couldn't expect the developer to code for every single unique input device a user had to play the game with. Glad to hear the issues are less prevalent on gamepads though!

 

[Einhaender]

Pun of the century? You sell yourself too short. That was the Pun of the Millennium!

:victory: I knew it!

Well after reading your post I looked the Keyboard controls up on google, and I think it's safe to say that the controller was heavily favoured in TW2. The Xbox release had undoubtedly something to do with that.

I mean it's not that the issues are, as you say, "less prevalent". Many are simply not there. Changes/improvements you ask for have already been made - but for a different device.

you couldn't expect the developer to code for every single unique input device a user had to play the game with.

And that's the thing. I mean we have one game. TW1, that's keyboard only. It wasn't the best controls but heck, it's their first game, so we have lot of ground for improvement. Then, there's the second: TW2. Completely new control scheme that, (as I learned through your posts) almost completely disregarded all it's improvements and mechanics towards a whole crowd of users that use the keyboard as input device.

I can only hope that TW3 will have what you ask for, since, if not too many unique mechanics are implemented, the pad controls are already "there". So CDPR had enough time to make the keyboard relevant again.

 

[aegiskleais]

:victory: I knew it!

Well after reading your post I looked the Keyboard controls up on google, and I think it's safe to say that the controller was heavily favoured in TW2. The Xbox release had undoubtedly something to do with that.

I mean it's not that the issues are, as you say, "less prevalent". Many are simply not there. Changes/improvements you ask for have already been made - but for a different device.



And that's the thing. I mean we have one game. TW1, that's keyboard only. It wasn't the best controls but heck, it's their first game, so we have lot of ground for improvement. Then, there's the second: TW2. Completely new control scheme that, (as I learned through your posts) almost completely disregarded all it's improvements and mechanics towards a whole crowd of users that use the keyboard as input device.

I can only hope that TW3 will have what you ask for, since, if not too many unique mechanics are implemented, the pad controls are already "there". So CDPR had enough time to make the keyboard relevant again.

Well I don't mean to imply that the keyboard wasn't supported; it indeed was. But there can be steps made towards optimizing the keyboard's integration with the game; but this issue will be different for every input sources supported. They controls on keyboard were OK; I'm just hoping that a game in which I will be spending such a significant amount of time takes as many opportunities as possible to streamline the processes.

 

[Nucta.397]

Bought a controller.

All UI-related problems are gone!

 

[aegiskleais]

An additional thing I'd love to see done is to allow the player to store crafting and alchemical items in storage, but allow the game to reference them as if they were being carried when it comes to crafting. That way people can amass the large amounts of crafting items and not worry about all the weight it takes up. This is more a feature request than a UI suggestion, but, I do love that level of ease in use.

 

[Jupiter_on_Mars]

An additional thing I'd love to see done is to allow the player to store crafting and alchemical items in storage, but allow the game to reference them as if they were being carried when it comes to crafting. That way people can amass the large amounts of crafting items and not worry about all the weight it takes up. This is more a feature request than a UI suggestion, but, I do love that level of ease in use.

This I've got to disagree with. Choices and consequences. You decide what you carry with you, you prioritize and deal with the consequences.

But how did you find the UI, @Aegis_Kleais ? It's ugly as Shrek.