Do we really need the Control Scheme section inside the ActionMap.asset?

Because I don't see the need for that.

Why would I want to create specific control schemes? This looks like extra editing for no benefit. I could even now make a ridicules mix of adding a device type keyboard with gamepad.

Why not just ditching all that and just not restrict for each action the list of source devices? If I care for a Fire action to have a gamepad source, I add it. And if not, well, then not.

 

Oh, by the way. This new system makes even a better impression than that in the Unreal Engine 4.

Last time I used UE4, it only got a list of Actions (bool) and Axis (float). UE4 stores its action map data somewhere inside a file, but it's not an actual asset for the editor. So, Unity +1.

 

It's all explained in the video on this page: https://sites.google.com/a/unity3d.com/unity-input-advisory-board/design-overview

Primary points:

• You may want to have help prompts in your game like "Press A to jump" / "Press Space to jump" that automatically switches to the correct instruction based on whether the player last touched input devices from one control scheme or another (e.g. keyboard/mouse or gamepad).
• For a local multiplayer game that supports both keyboard/mouse and gamepad, the system should know that one player only requires one gamepad OR one keyboard+mouse; not all three. Otherwise if you had 4 gamepads, one keyboard and one mouse, the system would think there's only devices to let one player play.
• Most PC games today with good input remapping functionality has the remapping divided into separate sections for gamepad/joysticks and keyboard/mouse.

I hope that clears it up!

 

Not really.

1. I thought that there is going to be some auto detection of input sources. And that it could throw some event when an input source change is detected. Then I just accessed an enum variable to read what the current source is, e.g.: keyboard/mouse, gamepad, etc.. And then change the icon set / string set used for the current input source for use in any in-game input prompts or tutorial hints.

2. I never did a local multiplayer. However, this maybe could be fixed by giving the input system a "bind input to player" mode. When the mode is entered, and the system detects any first input, then it binds that input source to a specified player index.

3. This is definitely true for the in-game GUI. A first person shooter could have its sections like Movement, Weapons, Vehicle and Social. But I don't see why I would want to create another scheme for that. If I cared to split outside the GUI layout. Then I could create another action map asset file for Movement, Weapons, Vehicle and Social sections.

And regarding auto detection of input sources. There should be at least an option to exclude specific input from auto detection to prevent accidental activation. Like touching the mouse accidently (Lock the axis. Maybe even wheel), or a gamepad's analog stick. I think a broken analog stick could also accidently trigger an input source switch.

 

Sure you can program all that yourself if you yourself keep track of which controls belong to which control scheme and that e.g. keyboard/mouse belong together in one control scheme but gamepad is separate. But we wanted this to work out of the box without complicated programming.

I'm not sure what you mean by input source here. The key thing is that you somehow need to tell the system that some input devices belong together (like keyboard/mouse) while others are separate. One way or another, if you are telling the system this, you are essentially setting up control schemes. We just have support for it directly in the ActionMap so you don't need to store or hardcode this somewhere else.

That's not what I was talking about. I mean that it usually have one "page" for configuring keyboard/mouse input and a separate "page" for configuring gamepad/joystick input.

Have you experienced problems with this when trying out the input system demo/prototype? If not, then please try it out first and let us know if it's a problem in practise.

 

Yes you are right regarding the extra code. However, this still won't change anything. The manual setup of control schemes is pointless. Read below the second quote in this post.

Are we going to be able to assign icons as well?

By input source I mean mouse/keyboard, gamepad, etc.. So I'm indeed talking about your controls schemes.

But it is quite obvious which devices belongs to which control scheme. Because a player never would use gamepad or keyboard together. Or touch and keyboard. Therefore it shouldn't require me to edit that in the editor every freaking time. Giving it obvious names like in your demo: KeyboardMouse, Gamepad, VirtualKeyboard.

Well, there might be some exotic configurations. And it's good, not to exclude them. But I would just hard code each control scheme into enums, and extend them later if needed.

Keyboard/Mouse
Gamepad
VirtualJoystick

// Are they really called sticks?
VR Headset/Sticks

// Gamepad?! Does the Occultist's Rift even matter? / troll face
VR Headset/Gamepad

Flight Stick
Wheel/Paddles
Mobile (Touch / Compass / Gyroscope)

Yes, my bad. The term "remapping" slipped out of my brain so I think now I get it. I don't see how a local multiplayer is a reason though. Because when I do a remap, I do so for a specific player index, and not for the control scheme.

I did play other games and it happened. But no, you are right. It's not that of a big problem. Though the way I imagined it wouldn't harm either. That's why I mentioned it.



To round this long post up. I think the action map setup workflow would be more optimized like this:

• I create an action map asset.
• I create a new action.
• I enter the action's name, and determine its data type: Button (pressed, held, released) or one Axis (float). Maybe two Axis would make sense, too.
• Then I add control schemes below the action. I could add a keyboard/mouse and/or a gamepad.
• If I used a One Axis data type, and added a keyboard/mouse control scheme. It will allow me to define two keys, one for each direction. A gamepad's analog stick would fit just right.

I'm skeptical regarding how the current "type" under the action's names works with those Vectors, Relative Axis, Absolutes Axis, etc.. Obviously I also want the current control scheme section on top of the action list to go anyways. I think if you just ditched both, you may even be able to finish the new input system sooner.

I started to make a new game after I ditched the last idea. But I will try to do some input implementation myself as soon as possible. Maybe I could clarify this way what really works in the end and what not.

 

I want to make a slight correction to my suggestions.

I previously suggested that devices such as a mouse and a keyboard, should be bound by default together into a predefined Control Scheme. However, instead of having to add predefined Control Schemes to each action every freaking time. They should appear for each action on their own. They could do so if you placed a list of control schemes on top of the actions list. So I just could add keyboard/mouse support, and/or gamepad, VR, mobile, etc..

I would still kick this naming of control schemes and the possibility of mixing device types. There are not that many controls schemes in the world. I don't see why we would need the feature to create our own.

Also, regarding the Control Schemes VR Heads/Sticks or VR Heads/Gamepad. Just make it VR. And if that is set, allow further check boxes for use of sticks or gamepad.

Mobile is still a good name for a scheme that includes touch, compass, gyros, GPS, etc.. Instead of being separated into pointer and sensor. There are laptops with touch. But laptops are a kind of mobile, too. A desktop computer never would have GPS, gyros, or a compass to show the direction of our apartment's refrigerator. I have to admit, though, that I don't know if there is any touch monitor for desktop. Or if that is even a good idea for video games even if this hardware exists.

 

The ones provided in the demo are just examples. Game developers often make specialized controls schemes for different specific controllers; for example one for Xbox controller and a different one for PlayStation controller because they have different conventions for which buttons are used for what.

Apart from that, the input system is designed for extensibility. A hardcoded enum with a set number of predefined control system types goes against that and is contrary to a lot of the feedback we've gotten from others.

I'm not sure what you're referring to here. Could you post a screenshot of what you're seeing?

 

Well, I'm simple with mouse/keyboard, and maybe gamepad, it seems.

Just for the sake of info. Do you have a list of usable input device combinations?

Yes I agree. But even standard controllers with numbers instead of those fancy A and X buttons of the major consoles, are still "gamepads". Every section for an action, that got set to gamepad as a source, can offer customization. You could chose a unified approach from a drop down menu. Like "Unified Button A/X/1". Or something specific, like "Xbox 360 Button A".

You are already using a custom inspector for the action maps asset file. Me thinks this should be just a matter of programming the editor to show specific options when appropriate. I understand that you may want to block an input, by switching profiles. But I thought that binding devices to player in a local game would do the same!?

Obviously I don't do VR.

The Occultist's Rift: One VR headset. One Xbox 360 gamepad.


The HTC Vive: One VR headset. And a "stick" thing pair. And I thought that the other thing is occult. :0

 

There's no such list. It's not up to us to judge what's a usable combination or not.

That's how it works if you just choose "Gamepad". There is just Action 1, Action 2, Action 3, Action 4, which corresponds to A, B, X, Y / Cross, Circle, Square, Triangle / corresponding locations for buttons on other gamepads.

But that's not sufficient. There's not always a one-to-one mapping. Different platforms can have different conventions for for which of the four buttons are used for confirm/cancel; which are used for jump, attack and similar. On top of that, the "extra" buttons like Start, Pause, Back, Share etc. are different.

The point is that different people use control schemes in different ways and we're aiming to cover a lot of different ways.

I didn't understand what point you are making about VR controllers.

 

Aside that I'm curios as a game designer myself. I don't think that there are that many combinations in the first place.

99% would use: mouse/keyboard, gamepad, touch

0.20% (Steam stats) would use: VR headset + gamepad, VR headset + sticks, VR headset + mouse/keyboard

0% because they are invisible to me just like the Illuminati. Would use: Flight stick, Car Wheel/Paddles, HoloDeck Lens

The managed side of this new input system is open source. There you already have all the extensibility you need. I haven't seen all the code. But it shouldn't be a problem to add new enums to work!? And if one wanted new devices, one would need to add to the code anyways. I don't see why one would want to bother the 99% with the obvious.

Yeah, I understand. It also isn't too much work to create a profile by hand. So I could live with this current implementation.

I don't know why you ask the last question regarding VR. But me mentioning VR was only regarding its control schemes. And it seems there is a third one with mouse/keyboard. This means also that my last thought of creating one enum for VR won't work. One would need three separate enums.

My total list of usable control schemes would be this.

keyboard/mouse
gamepad
mobile (touch, compass, gyroscope, GPS, camera (for AR))
VR Headset + gamepad
VR Headset + keyboard/mouse
VR Headset + sticks
Wheel/Paddles
Flight Stick
HoloLense
HoloLense + Gamepad

 

Since the 0% are invisible to me. Two addition: VR Headset / flight stick, VR headset / wheel/paddles.