Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at id.unity.com during this transition time.

    It's still possible to reply to existing private message conversations during the migration, but any new replies you post will be missing after the main migration is complete. We'll do our best to migrate these messages in a follow-up step.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.


    Read our full announcement for more information and let us know if you have any questions.

Official Controls

Discussion in 'Open Projects' started by NicknEmart, Sep 30, 2020.

  1. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
  2. WagnerGFX

    WagnerGFX

    Joined:
    Aug 26, 2013
    Posts:
    28
    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 :D
     
    cirocontinisio likes this.
  3. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Ah, yes, we can do that. My only worry with providing all of these alternate keys is that then you need to have them all on screen as button prompts? Otherwise how would the player know what they do.

    But I guess this is not a menu control, it's for the gameplay, so you'd only see it in the controls screen.
     
  4. WagnerGFX

    WagnerGFX

    Joined:
    Aug 26, 2013
    Posts:
    28
    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.
     
  5. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    What do you mean? That players would switch control configuration in the settings menu, between something like "Only Keyboard" and "Mouse & Keyboard"?
     
  6. WagnerGFX

    WagnerGFX

    Joined:
    Aug 26, 2013
    Posts:
    28
    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"
     
  7. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    cirocontinisio and WagnerGFX like this.
  8. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    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?
     
    Last edited: Nov 13, 2020
    WagnerGFX likes this.
  9. WagnerGFX

    WagnerGFX

    Joined:
    Aug 26, 2013
    Posts:
    28
    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?
     
    kirbygc00 and NicknEmart like this.
  10. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    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
     
    Last edited: Nov 13, 2020
  11. WagnerGFX

    WagnerGFX

    Joined:
    Aug 26, 2013
    Posts:
    28
    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:
     
  12. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    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!
     
    WagnerGFX likes this.
  13. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    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.
     
    Last edited: Nov 14, 2020
  14. piraente

    piraente

    Joined:
    Oct 19, 2019
    Posts:
    10
    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.
     
    kirbygc00 likes this.
  15. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    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 o_O
     
    Last edited: Nov 15, 2020
  16. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    @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
     
  17. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Hey all. Some news related to controls:

    - We finally have the ability to run! The Pig can now move at almost double the speed, and I implemented a BlendTree in the Animator with a new run animation clip.
    - The run is activated with a gamepad just by tilting the stick to its maximum extension. So it's a full analogic movement.
    - On the keyboard, since we don't have analogic input, speed is enabled by holding Shift (either left or right).
    The magnitude of the input vector from WASD and arrow keys is capped at 0.6 speed, but, when holding Shift it's set to 1, so the character runs at full speed.

    upload_2020-12-18_20-47-10.png

    - I've reworked the camera speed to feel nicer, but also to offer a camera that doesn't feel too fast if using the mouse, and doesn't feel too slow if using the joystick.

    upload_2020-12-18_20-48-1.png

    - The joystick's right stick has a Processor for cameraMovement, meaning that if you have an older controller (like me) the camera won't move randomly because the stick reports values like 0.05 by mistake.

    upload_2020-12-18_20-46-49.png

    Let me know how all these changes feel!

    PS:
    Not ignoring this, just been blocked with SO many other things! I'll get back on the other input stuff soon. I've left you a couple of questions in the PR too.
     
    Amel-Unity and danten66 like this.
  18. deivsky

    deivsky

    Joined:
    Nov 3, 2019
    Posts:
    87
    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!
     
  19. deivsky

    deivsky

    Joined:
    Nov 3, 2019
    Posts:
    87
    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 :(
     
  20. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Hmm, I think it makes more sense to be "hold to run". Toggle is strange, you might click it without noticing and then run all game without knowing you activated it in the first place (as a new player, I mean).

    Would it be ok to, in addition to the "hold to run", slowly build up speed so that if you keep holding a direction and never let go, in 2 seconds you reach max speed.

    Or, also, that if you hold Shift and run and don't let go of a direction, you keep going at max speed until you stop. In this sense it acts more as a "run activator", plus the ability to keep holding it.
     
  21. deivsky

    deivsky

    Joined:
    Nov 3, 2019
    Posts:
    87
    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. :oops::rolleyes:

    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. :p

    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.
     
  22. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Fair enough, I never do it unless I'm doing precision jumps. But that's actually an argument in favor of having "hold shift to run", in my opinion.