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. NicknEmart

    NicknEmart

    Joined:
    Sep 9, 2019
    Posts:
    46
    I know this doesn't have very high priority on the todo list, but I have a few suggestions about the controls.
    I think, referring to the keyboard control scheme, that we could assign the camera movement to the mouse, so we could use the left mouse button as the attack button. During action moments the player might want to move the camera for better visibility while also being able to attack without having to change the finger position on the keyboard. As for the jump, we could simply assign it to the spacebar.

    Also I presume the game will need a button to start a dialogue (I don't know if that's included in the "spacial action" category or not), but in that case the player will probabily not be surrounded by enemies so it could just be assigned to a normal, easy-to-find button as Enter (or we could make the spacebar/south button contextual and making it start a dialogue if close to a character and jump in all the other situations, but I don't really know about this, maybe it will just be more confusing)
     
    spooneystone likes this.
  2. UniDongwon

    UniDongwon

    Joined:
    Jul 24, 2020
    Posts:
    3
    I totally agree with this!
     
  3. DaSerialGenius

    DaSerialGenius

    Joined:
    Jun 27, 2017
    Posts:
    17
    This would be a great default system, and to add to it I'd also like to work on abstracting it in such a way that the player can work with whatever control scheme they prefer. If I get the chance that is. Although I feel like the idea for the gameplay is still a bit vague in that we dont know what game feel we are going for :p
     
  4. farhangulkhan29

    farhangulkhan29

    Joined:
    Sep 3, 2020
    Posts:
    5
    upload_2020-10-3_2-52-31.png
    This seems like a strange choice, I have never played a game using this control scheme. How about we use mouse for orbiting?
     
    EssentialAsa and spooneystone like this.
  5. Megatank58

    Megatank58

    Joined:
    Jul 20, 2020
    Posts:
    44
    The game will have a control remapping system so there is probably not much to think about as players will be able change the settings according to their preferences,however there will probably be default controls once the game starts (as far as i have read)
     
  6. ballfun69

    ballfun69

    Joined:
    Jan 3, 2020
    Posts:
    8
    I tried the game with the current control shame (WASD and TFGH) which is really a strange choice of not using the mouse (and cause discomfort really easily) and I would vote on camera control with the mouse for keyboard input. If for some reason we would prefer to use the keyboard I would propose remapping to the arrow key instead
     
  7. w4ssup

    w4ssup

    Joined:
    Feb 16, 2016
    Posts:
    34
    Why is there not a card deck for this request yet? I hate how the current control is, I would like it if we can add an option to switch from precise (mouse) camera control and manual (keyboard) camera control.
     
  8. Megatank58

    Megatank58

    Joined:
    Jul 20, 2020
    Posts:
    44
    Everything right now is Subject to change and is completely for testing purposes only (as far as I've read) the input system, settings system and control remapping system is still being made as well.
     
    cirocontinisio likes this.
  9. farhangulkhan29

    farhangulkhan29

    Joined:
    Sep 3, 2020
    Posts:
    5
  10. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
  11. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Sorry I haven't replied in a while. In our original idea, the game is either for joypad, or for keyboard.
    Adding mouse for camera makes sense, but... what if we have 3 buttons? Jump, attack, interact, maybe a fourth? How would you handle that then? Q and E on the keyboard, for slow actions?
     
  12. Megatank58

    Megatank58

    Joined:
    Jul 20, 2020
    Posts:
    44
    Q,E,F,R are some common keys for attack actions
     
    cirocontinisio likes this.
  13. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Yeah, makes sense. So basically we're looking at:
    - Complete set of controls on Gamepad
    - Complete set of controls on keyboard (could be good for accessibility)
    or
    - Most controls on keyboard and some on the mouse (camera, main attack)?

    And the player can choose between the three? Could it be?
     
  14. shuttle127

    shuttle127

    Joined:
    Oct 1, 2020
    Posts:
    183
    Based on what you said in the Dialogue and Narrative thread on the rating, the fewer total buttons the better. Coz it'd be nice if my 4-year old could play it, right?
     
  15. Megatank58

    Megatank58

    Joined:
    Jul 20, 2020
    Posts:
    44
    I think (as a gamer) the main controls such as running or fighting are better on keyboard but some actions like shooting guns are easier on mouse ,looking around or aiming are better on the mouse as well, as mouse is quite easy to handle,i think we should have a vote on this maybe?
     
  16. Neonage

    Neonage

    Joined:
    May 22, 2020
    Posts:
    288
    Btw, I'd encourage to use InputActionReference instead of auto-generated class.
    It's super clean, not requires manager and easy to remap at runtime
    upload_2020-10-6_17-14-31.png

    upload_2020-10-6_17-14-50.png
     
    kirbygc00 and julien-f like this.
  17. H3LL51nG

    H3LL51nG

    Joined:
    Oct 6, 2020
    Posts:
    4
    Here are my suggestion on player movement,
    1. Use W and S to move forward and backward respectively.
    2. Use A and D to rotate character left/right. The character doesn't move just rotates. This eliminates the need to use mouse to control camera. Also this will ensure that players dont feel any difference in the movement between desktop and consoles.
    3. Using S moves character back but doesn't turn it around. We can use a separate key to instantly turn the character 180 deg along with the camera(Like in God of War).

    Note:- If our character involves aiming and throwing projectiles at enemy or picking up/interacting with objects using mouse then fixing camera movement to mouse does make sense. In that case the above points may not be ideal and we would have to map the camera movement and aiming to the right D-pad in joystick which means we will be using conventional TPS movement system.
     
  18. Megatank58

    Megatank58

    Joined:
    Jul 20, 2020
    Posts:
    44
    I would highly suggest to play the game if you haven't already as some controls are already setted up
     
  19. H3LL51nG

    H3LL51nG

    Joined:
    Oct 6, 2020
    Posts:
    4
    @Megatank58
    I did play the game. I just gave suggestions for an alternate approach. Was not aware that the controls were finalized. I went through the code strictly for educational purposes and want to know whether there were any particular reasons for going with inbuilt character controller and not the rigidbody based movement. Was it so because there was simply no requirement for it or does it have anything to do with performance(avoiding navmeshes, agents, dependence on physics etc)?

    Thanks in advance.
     
  20. Zold2012

    Zold2012

    Joined:
    Feb 4, 2014
    Posts:
    67
    It'd be neat to be able to switch between controller types, for instance, I like using a Switch Pro controller but the axis and button mappings are different from XInput controllers
     
  21. Zak_Ipatov

    Zak_Ipatov

    Joined:
    Jul 21, 2014
    Posts:
    4
    @cirocontinisio
    I'd like to start with the "conrol remapping system" ticket (didn't want to start a new thread, topic is the same).
    Without rush while architectural decisions about controls scheme are discussed.
     
  22. Megatank58

    Megatank58

    Joined:
    Jul 20, 2020
    Posts:
    44
    there's a control remapping system thead.
     
  23. Zak_Ipatov

    Zak_Ipatov

    Joined:
    Jul 21, 2014
    Posts:
    4
    Megatank58 likes this.
  24. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
  25. GordonArber

    GordonArber

    Joined:
    Jan 2, 2016
    Posts:
    22
    The control card doesn't make mention of using the mouse to point and click on menu items at all, only WASD/Arrows/Enter/Esc.

    I find menu systems a lot snappier if they allow for mouse controls. Is there a specific reason we don't want to have that feature?
     
    Last edited: Oct 20, 2020
  26. RunninglVlan

    RunninglVlan

    Joined:
    Nov 6, 2018
    Posts:
    191
    Hi, I've looked at current InputActions, InputReader and have a couple of questions/suggestions.
    1. Why are UnityActions used instead of C# Actions and why aren't they marked as events? Without event keyword anyone can call these actions.
    2. Right now one ControlScheme is used for both Keyboard and Gamepad. Wouldn't it be better to split it in two schemes, one for Keyboard/Mouse and another for Gamepad? If game will have In-Game Hints (e.g., in Tutorial) what control it will show for, e.g., Attack, Action - X (Gamepad) or LMB (Keyboard/Mouse)? As I understand it will be difficult to do with only one scheme.
    3. Suggestion: Instead of this
      Code (CSharp):
      1. if (attackEvent != null
      2.    && context.phase == InputActionPhase.Started)
      3.    attackEvent.Invoke();
      more readable could be this (I would also add curly braces around one-liner, but it's code style):
      Code (CSharp):
      1. if (context.started)
      2.    attackEvent?.Invoke();
     
    Last edited: Oct 23, 2020
    kirbygc00 likes this.
  27. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Just because it's complicating things. We can have a menu that doesn't support mouse, but we can't have the opposite (one only for mouse), because some players might be playing with a gamepad.
    Let's think about it... for now, let's try to make one for keyboard/gamepad that works as a first step!
     
    GordonArber likes this.
  28. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Good point about the event keyword. Feel free to make a PR correcting that if you want, or I'll add it next time I have a chance. As for why they're UnityActions, just a matter of habit.
    Originally the idea was to never use a mouse, only keyboard and gamepad at the same time so you didn't have to switch controls at any time. Now people have asked to orbit the camera and perform some actions through the mouse, so we might have to make this change...
    I generally don't find these super shortened syntaxes more readable, they are shorter, yes, but compact several conditions together so as you're trying to debug or understand other people's code, your brain has to do the extra work. Just a matter of personal opinion...
     
  29. GordonArber

    GordonArber

    Joined:
    Jan 2, 2016
    Posts:
    22
    I totally understand and respect if this is the way we are going to take it. In my opinion, however, is if we are developing for steam, mouse controls for menu UI is important.

    UI systems are a nightmare to navigate with just keyboards. In 2018 steam had 90 million monthly users (Fenlon, 2019) and 30 million of them registered a gamepad (Mott, 2018). If those numbers can be compared and they carry over these past 2 years, then we are alienating 2/3 of steam users.

    References

    Fenlon, W. (2019, January 14). Steam now has 90 million monthly users. Retrieved October 27, 2020, from https://www.pcgamer.com/steam-now-has-90-million-monthly-users

    Mott, N. (2018, September 26). Valve Breaks Down Controller Usage Among PC Gamers. Retrieved October 27, 2020, from https://www.tomshardware.com/news/valve-pc-controller-usage-statistics,37853.html
     
    Last edited: Oct 29, 2020
    cirocontinisio and RunninglVlan like this.
  30. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Thanks for looking into it :) I'm very aware we can't make the game controller-only, we would not only alienate players but impede the same developers to test it, or for example test it on the go (like in a train or something).

    I think they are if not made for keyboard/pad. Many PC-first games are (understandably) made mouse-first, and as a result they feel awkward when navigated with a gamepad. I'm looking at you, Darkest Dungeon :D (and at the Switch port).

    But there are literally thousands of games out for consoles that are thought first for gamepad or d-pad, and they work pretty fine. Same for all the PC game which require a gamepad to be played (usually console ports).

    Actually one note: I don't think anyone would use the keyboard here, because if we enable the mouse you are either going to use the gamepad (if you have one) or switch directly to the mouse pointer and forget about the keyboard. Am I right in assuming so?
    So I think in the end, a good compromise is to build something that can be navigated comfortably with a pad, and it will work for mouse too.
     
    Amel-Unity likes this.
  31. DSivtsov

    DSivtsov

    Joined:
    Feb 20, 2019
    Posts:
    152
    If compare the keyboard+mouse similar to gamepad:
    It have button (many not only two or three) and Ability to move axes by linear movement
    w/o mouse keyboard not very comfort.
    And I agree the game must be comfort for any style of management.
    And don't forget that the most part of time gamer spend in game, not in menu (but sometimes working in menu may be annoying - it isn't a good, but may be a comprise for Beta Version)

    More readable? Are you joking? When the shortage was a more readable? It's only short text and to narrow the circle of people, who can use it (or use it quickly).

    I fully agree ...
    The first variant I understand fly by eyes, the second I must to think.
    And the main - in "code" it will be same. In this case (and many others) very often the shortened code haven't e any pros, but more error-prone - it's a big cons. (we don't talk here about classic ++ and += and so on)
     
    Last edited: Oct 30, 2020
  32. qqqqqym

    qqqqqym

    Joined:
    May 9, 2020
    Posts:
    3
    This open project is really great, why did I just notice it today!:p
    I downloaded the game resources and experienced it, I have a little suggestion for this.
    I think this should belong to the control module: when pig jumps, the angle of view will follow the jump. But as a third-person game, isn't this uncomfortable? o_O I think this method will cause trouble to the player when pig jumps over obstacles. And I think we should modify the CinemachineVirtualCamera follow method so that the angle of view will not follow up when the pig jumps.If my suggestion can play a little role, I will feel very honored.
    I would like to witness the great birth, cheers!
     
    kirbygc00 and cirocontinisio like this.
  33. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    I'm not too sure what do you mean by this?

    Also, you know what we should do, really? Implement a circular shadow, projected downwards, which gives a feedback for the jump. You can see it in many platformers, including Yooka-Laylee for instance (00:23). How does that sound?

    In any case, this game won't have need for suuuper precise platforming.
     
    qqqqqym likes this.
  34. qqqqqym

    qqqqqym

    Joined:
    May 9, 2020
    Posts:
    3
    • Thanks for your reply! Please excuse my ignorance, I didn't really understand your work. I have watched the video you recommended carefully and it looks really cool. From the perspective of an experiencer, I feel that the current jump feedback makes me a little uncomfortable, especially when I press the space bar hard (maybe it is shaking too much? ). This is just my personal feeling, I hope we can get better and better.
     
    cirocontinisio likes this.
  35. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    No need to excuse yourself :)
    And you are right, we definitely need to work on the jump.
     
    qqqqqym likes this.
  36. RunninglVlan

    RunninglVlan

    Joined:
    Nov 6, 2018
    Posts:
    191
    I think @qqqqqym means this:
     
  37. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    Hi,

    I haven't taken a look at the source code for the input system for this project yet... but I do think the preferred way to check for actions is to check the `performed` phase, not the `started` phase. from my understanding of the docs: https://docs.unity3d.com/Packages/c...html#started-performed-and-canceled-callbacks

    started means that an input has been detected, but has not been processed/interpreted. performed is when an input has successfully been processed and is ready for use. Also, all the examples show calbacks using the `performed` phase. Not sure if this will cause bugs or issues, but I will submit a PR to switch to the performed context tonight just in case.

    EDIT: Ah, a little more reading and i found: https://docs.unity3d.com/Packages/c...ld-for-04-seconds-before-triggering-an-action

    so a functional difference between the started and performed phase would be: certain interactions (such as hold, tap, etc..) require a key to be actuated for x amount of time before 'performing' the action. just check for start fires off the business logic before it should actually be executed.
     
    Last edited: Nov 2, 2020
    Amel-Unity and cirocontinisio like this.
  38. qqqqqym

    qqqqqym

    Joined:
    May 9, 2020
    Posts:
    3
    • Thanks a lot, bro. I watched the videos Ciro recommended, and the jump with a little feedback was also good (Sorry, I might be too picky:oops:). Maybe we can make the feedback a little smoother. Hope gets better, cheers!
     
  39. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    That's a great find, @kirbygc00, great that you spotted it.

    Maybe we can use the vertical damping on the Cinemachine virtual camera to do that?

    EDIT: I just tried and it's a good solution. We could even modulate it for the different heights of the camera by assigning a different damping to the 3 circles on the FreeLook camera.
     
    kirbygc00 and Amel-Unity like this.
  40. WagnerGFX

    WagnerGFX

    Joined:
    Aug 26, 2013
    Posts:
    28
    Reading the Controls card I noticed there is no specific button for the game menus. Will the pause also function as the menu button or will there be another button?

    Reviving the camera controls matter: a good idea is to keep an alternative camera control on the arrow keys instead of just mouse or, even worse, the TFGH keys. It's a great accessibility feature, it's easy to implement with the new input system and way more comfortable to use than the initial idea.

    The next questions are probably closer to UI and advanced controls for the future, but I will let them here so we can keep that in mind for control decisions:
    • Will there be multiple big menu options like inventory, equip, quest, etc or will everything be simplified in a single screen?
    • Will there be multiple buttons to activate each menu? In this case, will it be interesting to implement a radial menu for easy access to these options? (with the most recent example being Genshin Impact)
    I don't think the game will be complex enough to need this type of menu, but is a great example in case we need it.
     
  41. RunninglVlan

    RunninglVlan

    Joined:
    Nov 6, 2018
    Posts:
    191
    @WagnerGFX, could you provide video or some other reference of this radial menu in Genshin Impact? I've searched but couldn't find this menu.
     
  42. WagnerGFX

    WagnerGFX

    Joined:
    Aug 26, 2013
    Posts:
    28
    I play the game on PC, so I don't know if this menu exists in any other platform.

    I couldn't find any video on it, but here are two images for reference. To see this menu hold TAB on keyboard or the LB on the controller.

    Since our game is waaaaay more simple than G.I. it might be better to directly use the controller directional buttons to open the menus. Like the smaller menu on the second screenshot.
     
    RunninglVlan likes this.
  43. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Good point, I've added the Y (top) button on the gamepad and the E key on the keyboard for that. How does it sound?

    I also updated other details in that card. How does it look now?

    And also, is somebody going to implement the camera movement on the mouse?? :D
    https://open.codecks.io/unity-open-project-1/decks/15/card/17g-implement-camera-rotation-with-mouse
    Also: with right mouse button modifier, or at all times?
     
  44. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    I can take a crack at this tonight if no-one else has this covered, should be a pretty small lift :).

    I think the requirements are:
    1. when the player moves:
      • camera eases it's position to behind the character's shoulder
    2. when player stands still:
      • camera stays focusing wherever it is currently pointing towards
    3. when player holds RMB they will be able to 'override' this default behaviour and control the camera directly
      • camera x-axis focus will follow the mouse position until RMB is let go
      • camera y-axis will not change
      • Once RMB is let go, camera focus stays at the last mouse + RMB position (???)
    I think 1 and 2 are already implemented... so it's just #3
    Does this sound correct @cirocontinisio ?
     
    Last edited: Nov 4, 2020
  45. BassDrop_

    BassDrop_

    Joined:
    Mar 24, 2017
    Posts:
    1
    Let me know if you are going to try to do it because i want to give it a shoot myself. :)
     
  46. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    Haha yeah, i will make a branch tonnight! just wanted to make sure i had the requirements before hacking away

    But if you'd really like to do this I can cede it over to you :)
    Also, you are definitely free to make a branch and try this out as well!
     
    Last edited: Nov 5, 2020
  47. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    After digging into our current system, i feel like we should have different control schemes for mouse + keyboard vs game pad. We currently have them bundled together.

    Makes it hard for example, to handle mouse + keyboard specific logic (such as the camera movement) since it's all bundled in there with the gamepad stuff. I also see unity take this approach with their sample projects + code.

    How do other folk feel? Can I put in a PR to split them up?
     
  48. kirbygc00

    kirbygc00

    Joined:
    Apr 4, 2016
    Posts:
    50
    Hi @RunninglVlan,

    I definitely agree with points 2 & 3. It seems like Point 1 was already addressed as well.

    One additional thing- instead of all these null checks we could initialize all events to an empty delegate :)
     
    RunninglVlan likes this.
  49. WagnerGFX

    WagnerGFX

    Joined:
    Aug 26, 2013
    Posts:
    28
    On the gamepad, I think Y for the inventory is not a bad idea, many games implement this way, but if some important action appear later this button might need to change to SELECT or inside the pause menu.
    Depending on future usability tests it might be easier to move menus like inventory and map to the d-pad.

    On the Keyboard, I don't think using E for menus (specially the inventory) is a good idea. These keys are too close to the WASD, could be pressed by mistake and additional actions might need the keys close to the movement.

    My suggestion is to use TAB if the menus are unified, otherwise its better to follow standards with I for the inventory and M for the map.

    E or F might be better as an alternative (or even main) key for interacting. While a faraway key like Right CTRL is better for an alternative attack button, since it won't conflict with the movement hand.

    At all times seems better since moving the camera will be a constant unless we implement a very good automatic camera.
     
  50. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Yes, I also think that the mouse cursor should be hidden during gameplay, otherwise it seems like it serves a purpose. For now the RMB is used as a modifier, but I think we should remove it.

    In any case I think if played with mouse/keyboard then the right hand will always be on the mouse, so LMB is attack, RMB something else, and we can't use Right Ctrl.

    Aaaaaaah, the pleasures of PC controls!! :rolleyes: