Dev Diary #325 Gamepad has landed
Ahoy Ylanders!
We have been hinting for some time that we are working on gamepad support. Well, we have finally managed to do it for next Ylands update 2.3. Ylands will have full gamepad support and it should be possible to play completely without mouse and keyboard. In this programmer diary we will look what this actually entails.
[h3]Input abstraction[/h3]
First step for gamepad support was already mostly done – input abstraction using action triggers. Action trigger represents specific game action (forward movement, reload, submit…) and has bindings for individual input devices. Each frame we check currently active input device for pressed keys or buttons. Each key/button can correspond to several action triggers. This is used to construct frame input that converts this information into which action triggers are active and for how long.
Then (from individual screens or gameplay scripts) we can ask frame input if specific action trigger is activated in a way we are interested about. That could be instance we press it, release it, after tap, or after long press. If we detect this, we can consume action triggers using same binding so that next system will not react to same button. This way individual systems do not have to care if we are using keyboard or gamepad – to them it is same because of these frame input events.
[h3]Navigating the menus[/h3]
Next big step was to create new gamepad navigation system that can work with our UI. It consists of new navigation elements, sub contexts, headers and sub headers, proxies, and navigation manager itself that controls all that. Its job is to register/deregister all elements, pick best element when navigating, check what sub context are we in and more. Individual elements can be then set up in many ways to handle all our needs for given screen. That could include limited navigation space (sub context), navigation events (when we need to react to navigation to specific element), hardcoded navigation routes etc.
[h3]Control hints[/h3]
Ylands have complex controls over many game situations and UI screens. That’s why we had to create new system of visual control hints. These are universal object that contains many images and texts. Based on assigned control device and action trigger it will use all its elements to construct the hint. There are also other settings that can alter the appearance like if it should react to long presses if it should display name of action trigger and many more. So, we just need to place this universal hint to correct place, set couple parameters and connect it to script. Every time there is input device change or hint was spawned it will check if it should be displayed and toggles visibility as needed.
[h3]Updating our user interface[/h3]
Last part of gamepad support was the biggest time sink – updating all our screens and popups so they are fully usable only with gamepad.
[h3]For most screens it means these steps:[/h3]
1. Add navigation elements to all selectable things we want to be able to navigate.
2. Split areas into navigation sub contexts if necessary (for example divide main are from search field).
3. Add selection visuals for all navigable objects. For that purpose, we have universal orange selection box we can just quickly place and connect with navigation element.
4. Replace old buttons with new. They look the same, but they have control hints built in, so we don’t have to allow navigation to these buttons.
5. Add remaining control hints and helper objects that hold them (if we want some extra graphics with those hints).
6. Set up all control hints with correct action triggers, press lengths etc.
7. Check if layout of the screen is ok if we switch from keyboard to gamepad. When that happens many new objects will appear that can cause chaos. Fortunately, we can solve almost all these issues with automatic horizontal/vertical layouts that will resize individual elements for us if we set them up properly.
8. Expand the screen script with new hints and helper objects, add reactions to specific action triggers in frame input and sometimes add some custom gamepad logic if the screen is too nonstandard. Hints also needs to be refreshed on any input device change so that we know which should be active.
9. Connect all hints and helper objects with the script and hope you did not make any mistake.
Main issue is the sheer number of individual screens that are present in Ylands. Many are quite straightforward, but some are highly specialized and need lots of custom coding for gamepads or lots of control hints. For example, blueprint detail popup has 16 control hints (average is 3-5) and several sub popups it can access and many configurations how it can look.
[h3]Conclusion[/h3]
It was long work (and long diary, sorry), but we have finally reached state we can present it to you. From update 2.3 onwards you can play with gamepad only. We will continue to improve the gamepad experience and fix any bug you will send us.
In the meantime,
Stay classy!
We have been hinting for some time that we are working on gamepad support. Well, we have finally managed to do it for next Ylands update 2.3. Ylands will have full gamepad support and it should be possible to play completely without mouse and keyboard. In this programmer diary we will look what this actually entails.
[h3]Input abstraction[/h3]
First step for gamepad support was already mostly done – input abstraction using action triggers. Action trigger represents specific game action (forward movement, reload, submit…) and has bindings for individual input devices. Each frame we check currently active input device for pressed keys or buttons. Each key/button can correspond to several action triggers. This is used to construct frame input that converts this information into which action triggers are active and for how long.
Then (from individual screens or gameplay scripts) we can ask frame input if specific action trigger is activated in a way we are interested about. That could be instance we press it, release it, after tap, or after long press. If we detect this, we can consume action triggers using same binding so that next system will not react to same button. This way individual systems do not have to care if we are using keyboard or gamepad – to them it is same because of these frame input events.
[h3]Navigating the menus[/h3]
Next big step was to create new gamepad navigation system that can work with our UI. It consists of new navigation elements, sub contexts, headers and sub headers, proxies, and navigation manager itself that controls all that. Its job is to register/deregister all elements, pick best element when navigating, check what sub context are we in and more. Individual elements can be then set up in many ways to handle all our needs for given screen. That could include limited navigation space (sub context), navigation events (when we need to react to navigation to specific element), hardcoded navigation routes etc.
[h3]Control hints[/h3]
Ylands have complex controls over many game situations and UI screens. That’s why we had to create new system of visual control hints. These are universal object that contains many images and texts. Based on assigned control device and action trigger it will use all its elements to construct the hint. There are also other settings that can alter the appearance like if it should react to long presses if it should display name of action trigger and many more. So, we just need to place this universal hint to correct place, set couple parameters and connect it to script. Every time there is input device change or hint was spawned it will check if it should be displayed and toggles visibility as needed.
[h3]Updating our user interface[/h3]
Last part of gamepad support was the biggest time sink – updating all our screens and popups so they are fully usable only with gamepad.
[h3]For most screens it means these steps:[/h3]
1. Add navigation elements to all selectable things we want to be able to navigate.
2. Split areas into navigation sub contexts if necessary (for example divide main are from search field).
3. Add selection visuals for all navigable objects. For that purpose, we have universal orange selection box we can just quickly place and connect with navigation element.
4. Replace old buttons with new. They look the same, but they have control hints built in, so we don’t have to allow navigation to these buttons.
5. Add remaining control hints and helper objects that hold them (if we want some extra graphics with those hints).
6. Set up all control hints with correct action triggers, press lengths etc.
7. Check if layout of the screen is ok if we switch from keyboard to gamepad. When that happens many new objects will appear that can cause chaos. Fortunately, we can solve almost all these issues with automatic horizontal/vertical layouts that will resize individual elements for us if we set them up properly.
8. Expand the screen script with new hints and helper objects, add reactions to specific action triggers in frame input and sometimes add some custom gamepad logic if the screen is too nonstandard. Hints also needs to be refreshed on any input device change so that we know which should be active.
9. Connect all hints and helper objects with the script and hope you did not make any mistake.
Main issue is the sheer number of individual screens that are present in Ylands. Many are quite straightforward, but some are highly specialized and need lots of custom coding for gamepads or lots of control hints. For example, blueprint detail popup has 16 control hints (average is 3-5) and several sub popups it can access and many configurations how it can look.
[h3]Conclusion[/h3]
It was long work (and long diary, sorry), but we have finally reached state we can present it to you. From update 2.3 onwards you can play with gamepad only. We will continue to improve the gamepad experience and fix any bug you will send us.
In the meantime,
Stay classy!
