Official Controls

I meant that as a secondary key for accessibility for some players who can't use the mouse. But it's not as important since we will have a screen to rebind the default controls, if I remember correctly.

Reminds me of Kerbal Space Program. It has so many keys that my keyboard feels like a spaceship

 

This could become a huge issue if we add button prompts during gameplay, in that case the system would not know which to show when dealing with secondary keys.

Instead, it might be better to have the control setting allow any mouse input to be replaceable by the keyboard and vice-versa, including the mouse axis for the camera movement.

This would be the most flexible while avoiding any future issues with visual prompts.

 

I was considering we will have a menu to rebind the default keys. Will that be the case?

Considering that, my suggestion was to have the option to individually change the 4 directions of the mouse so they can be set to any key (like the arrow keys). I mentioned all this because many games don't have any alternative to the mouse movement.

If we will not have a menu for that and all controls we are deciding now will be unchangeable after release, then it's better to have that simple option to switch between "Keyboard Only" and "Mouse & Keyboard"

 

Hi all,

I just wanted post here that I've started a feature branch for menu controls. I had a quick chat with Ciro over in the UI / Wireframing thread about the requirements which you can check here: https://forum.unity.com/threads/ui-wireframing.987606/#post-6503155.

(goes on for a few posts)

 

Hey guys,

Update on the menu controls. The navigation and confirm / cancel is working great. However, I'm not seeing a good solution for getting the pointer enter / exit for each button in the UI.

The unity friendly solution would be something like hooking into the OnPointerEnter callback and using that to set the currently 'selected' UI element. In this case we would need to implement IPointerEnterHandler on each gameobject we want to receive messages from (headache for authoring and also error prone). Definitely not 'difficult' from a technical perspective, though.

For now I'd like some feedback on how people feel about this. Worth the extra complexity/lift to implement mouse over selection logic? Current implementation:

Green is highlighted, blue is selected.

As you can see, the mouse movement does not set the "selected" state on UI elements.

Edit:

So I coded up the other implementation, where mouse also sets selected state on Interactable elements:

works fine but you have to 'tag' each interactable element with a monobehaviour to register it as an event receiver. Any prefs, folks?

 

The second implementation seem to give a better feeling since having a single type of selection makes the UI behavior clear.

Is it possible to add an option in the component menu to create this button? With the "tag" and fully working?

 

Yeah, we could do that. Another option would be to override the `menuitem` button to use this implementation.

Also, is the 'highlight' behaviour something we want? How should it function? I don't know if I heard anyone mention it as a requirement. As far as I know we should only be tracking the 'selection'. @cirocontinisio @auxterlibre @piraente @ChemaDmk

 

It could give a problem if anyone needs the default button. On the other hand no one might see the custom button buried among many other options.

The requirements for menu interaction are in this post at the UI Wireframing thread:

 

Works for me.

Yeah, I see those, but they do not mention highlighting. It's not a big deal, but wondering if it was an oversight or intentional. I guess I will jump submit the second iteration and see if anyone has feedback at that point. Thanks for your thoughts, though!

 

PR: https://github.com/UnityTechnologies/open-project-1/pull/188

I noticed an issue: mouse clicks activate the currently selected UI element (even if the mouse is not over it). If any one wants to take a shot at debugging this I would definitely welcome it, but it seems tough. May circle back next week or something, but I'm calling it done for now.

EDIT: found a fix, we good.

 

I'm not sure how I feel about the second option. As a webdev it just feels weird.

How exactly will this work with tabs?
Do we want to directly switch the tab on key/controller press or just select it and then press a confirm key?
On the other hand, this is a great thing for the item grid, because the item hovered over should always be the selected.
(to display the item information)

Just a general question, is it common to support mouse, keyboard and controller in the menu? (some opinions would be great too, I never thought about this before)
I only know mouse and controller OR keyboard and controller.
When I play a keyboard heavy game, I always use the keyboard and otherwise only the mouse.

 

Hmmm. I do not know 100% without trying to implement... I think we would simply update the selection manager on tab change (e.g. null out old references and set selected to be the first element in the new tab).

Yes, I'd also like some reference for this. What I've seen for cross-platform UI controls is generally the 'destiny' model which I posted in the wireframe thread where there is a unified mouse/keyboard/gamepad input handling. However, like Ciro pointed out, the UX for gamepad and keyboard is not as nice if we go with that. Just happy to help out tbh, whatever the decision ends up being

Anyways, I think the system is bug free and meets the requirements ciro laid out... but we may need to refactor later on, either due to new UI use cases or UX improvements.

Not proud of the code to get this thing working! haha

 

@cirocontinisio submitted a fix PR last night. would it help if i continued development of the menu input system to handle tab views? e.g. build a tab view system and update menu selection/controls. wondering what is next on the priority list

 

Hey all! I was making some changes to the character Transition Table and opened this PR. That PR aimed to fix issues particularly with sliding, but soon I realized some changes had to be made to the code. I made a lot of changes so instead of pushing them directly to that PR, I opened a new PR pointing to it. Anyway, maybe I got a little carried away and decided to also make changes to the way mid-air movement is handled. That probably has to do with controls so I thought people following this thread would be interested. If you are, please go and test, review, and tell me your thoughts!

 

On a different note, can we make this a toggle, or make it work the other way around, hold shift to walk? My pinkie hurts

 

Well, I'm going to use the same example to both contradict one of your points and agree with another.

In Skyrim PC, you have "hold to walk", so you run by default.

Again in Skyrim PC, you also have Toggle, so if you toggle, it'll be "hold to run", and the default becomes to walk. Now, admittedly, as a new player, I did happen to accidentally toggle them, and then it was really hard for me to find the way to revert it.

With that said though, I do think that "hold to walk" makes more sense. I could be wrong but I feel like you're thinking about it in terms of sprinting, then I would agree that "hold to sprint" makes more sense. But right now it's actually "hold to move at the actual speed", and that feels a little unfair to keyboard users (and their pinkies!). Just think about how often you don't tilt the stick all the way on a controller.

Well, that would be possible if we implement acceleration for grounded movement.

I like this idea too, I'd make it as a toggle per run cycle, if that makes sense. So that if you want to keep moving but slow down, you press it again; but then as you said it resets whenever you stop.