By Anonymous ![[us]](/mwf/flags/us.png "United States")
Date 2018-06-11 15:12
It seems that one of the biggest challenges so far with allowing gamepads and controllers to be first-class input devices has been trying to map all of the keyboard commands to a button or action on the gamepad.
I just discovered OpenClonk a couple of days ago and have had the opportunity to spend a while playing it. I've really wanted to be using my gamepad instead of the keyboard and mouse. I think that I have found a good controller layout that at least makes sense -- if there's something important to experienced players that I left off this drawing, there are still two unused buttons (A and B) that should be on every controller that could be used for additional functions. We cannot count on having the Back, Start, and Mode buttons on all gamepads. Compared to the old gamepad layout (blog post from March 2010), I think that the new layout I drew out feels more obvious and ready-to-use for players of other games that use gamepads (or console games).
Here's the drawing:
(if this image doesn't show up, you can also click here: https://imgur.com/a/7zQVwOh)
For the right analog stick, which is used for aiming and looking around in this layout, I think that a cursor should only appear when that stick has been moved from its initial position. This way, the aiming mechanics aren't obstructive when not using them. Menus can be controlled using the left analog stick or the D-pad, where the A button is used to select or "click" and the B button is used to go back to the previous screen.
I would love to hear some feedback on what could be improved in this drawing -- it's currently still a very rough draft but it makes the most sense to me.
I just discovered OpenClonk a couple of days ago and have had the opportunity to spend a while playing it. I've really wanted to be using my gamepad instead of the keyboard and mouse. I think that I have found a good controller layout that at least makes sense -- if there's something important to experienced players that I left off this drawing, there are still two unused buttons (A and B) that should be on every controller that could be used for additional functions. We cannot count on having the Back, Start, and Mode buttons on all gamepads. Compared to the old gamepad layout (blog post from March 2010), I think that the new layout I drew out feels more obvious and ready-to-use for players of other games that use gamepads (or console games).
Here's the drawing:
(if this image doesn't show up, you can also click here: https://imgur.com/a/7zQVwOh)For the right analog stick, which is used for aiming and looking around in this layout, I think that a cursor should only appear when that stick has been moved from its initial position. This way, the aiming mechanics aren't obstructive when not using them. Menus can be controlled using the left analog stick or the D-pad, where the A button is used to select or "click" and the B button is used to go back to the previous screen.
I would love to hear some feedback on what could be improved in this drawing -- it's currently still a very rough draft but it makes the most sense to me.
Hi and welcome to OpenClonk :)Thanks for the proposal. Did you look at the current state of gamepad support in the 8.1 release? I think it's already pretty similar to what you're proposing. Not sure whether it works with your Logitech controller without additional configuration, though. I'm working with an Xbox 360 controller and a Steam controller, which both appear as Xinput devices.
>We cannot count on having the Back, Start, and Mode buttons on all gamepads.
I'm aiming for Xbox controllers as the baseline, as that is the most common feature set. Players with controllers with less keys will have to reconfigure their controls. That said, these buttons are a bad fit for anything gameplay-related as they're rather hard to reach.
>For the right analog stick, which is used for aiming and looking around in this layout, I think that a cursor should only appear when that stick has been moved from its initial position.
I believe this is in the current release already, too. The cursor appears once you move the stick or you start using an item that needs aiming.
>Menus can be controlled using the left analog stick or the D-pad, where the A button is used to select or "click" and the B button is used to go back to the previous screen.
This is the biggest thing that's still missing in the release: There's no way to control in-game menus. In any case, we'll need something more sophisticated at least for the inventory menu. Otherwise, there's no way for the gamepad controls to be competitive with the mouse.
>I would love to hear some feedback on what could be improved in this drawing
You're missing some important controls: jumping (W on the keyboard), rolling (S on the keyboard), zooming (Ctrl+Scroll with keyboard/mouse - I guess this could be a chord on the controller as well). The back and start buttons could be used for scoreboard (Tab on the keyboard) and the game menu (F on the keyboard).
In the release, I think I swapped prev/next Clonk and item switching compared to your proposal. Switching items is a lot more important than switching Clonks and I think the shoulder buttons are more accessible than the D-pad.
By Anonymous
Date 2018-06-12 21:28
I finally got my gamepad working in the 8.1 release so I had time to check out the default controls to see what I liked and disliked from it. I should have waited and done that before posting what I thought was the right solution -- I didn't know that it was already decided.
I agree that it would be a bit awkward to control the menus with just a up/down/left/right/enter scheme (especially the inventory/interaction menu), but I can't think of anything better right now.
Thank you for your help and I'm really enjoying OpenClonk!
I agree that it would be a bit awkward to control the menus with just a up/down/left/right/enter scheme (especially the inventory/interaction menu), but I can't think of anything better right now.
Thank you for your help and I'm really enjoying OpenClonk!
![[se]](/mwf/flags/se.png "Sweden")
Sorry if I made a wrong impression with my post - nothing is decided yet regarding the gamepad controls. Those that are in the 8.x release are just me assigning all the controls we have to the gamepad. They weren't exactly tested a lot, so opinions on how to do them better are welcome.One part I was unsure with is how to best assign jumping. Unlike the keyboard controls, it needs to be a dedicated button, "joystick up" doesn't work. Most platformer games for console use one of the ABXY buttons. This is nice as long as running and jumping is all you do, but in OpenClonk, you frequently have to navigate the landscape while aiming a weapon or tool. With a standard gamepad grip, this means that both thumbs are on the joysticks, so there's no way to press ABXY at the same time. This is why I assigned jumping to joystick click, but I fear that this is a bit awkward to use and not very intuitive. Maybe you have a better idea on how to handle that?
Regarding the interaction menu, we have a thread on a possible redesign. It's about usability in general, but I think gamepad and keyboard controls for the menu that work better than point-and-click with the mouse are closely related to that.
![[de]](/mwf/flags/de.png "Germany")
>Unlike the keyboard controls, it needs to be a dedicated button,
Why, by the way?
With the keyboard, you can press A/D and W at the same time. This is not possible with the joystick: it can point in only one direction at once, so binding "joystick up" to jump would mean you'd always stop for the jump.
But can't you push the stick on one the diagonal (left-up) to jump and run left at the same time?
Maybe. Do you know any games that do this? I can't imagine it working very well. Jumps often have to be very precise, and you don't get that precision without a button to press.In any case, this would need special engine support to allow custom thresholds for "joystick-buttons". A pure script implementation would miss quick joystick movements if the control rate is high / the frame rate is low.
Using Up on a gamepad for jumping is luckily something that died out with the NES...For real, have you ever played a game that does it like this? It is horrible.
>Steam Controller
By the way, is using the Steam Input API possible without the game being on Steam? That'd be much cooler and support virtually every controller as opposed to xinput.
No, I don't think using Steam Input is possible for games not on Steam. XInput isn't a hard requirement as we're using SDL, it's just guaranteed to work without additional configuration. Steam would actually automate this as well even without using Steam Input...
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
