It’s been a while since out last development update, so this week we wanted to share what we’ve been working on: UI Navigation via gamepad and keyboard! For the most part, we have finished implementing UI Navigation and only have a bit left until we release our gamepad update! (We’ve also updated a couple of menus to have more animations and more intuitive layouts.) Here’s more details on what exactly we’ve been up to:
You might remember that a couple of months ago we talked about our progress in adding gamepad support to The Chaser’s Voyage, including our new control scheme for the gamepad. The implementation of those controls was a fun and relatively quick experience. But gamepad support does not end at letting the player pilot the Chaser! In order for our game to fully support gamepad use, we need the player to also be able to navigate the UI of our game with a gamepad.
As The Chaser’s Voyage was initially designed with Mouse and Keyboard in mind, we knew implementing the gamepad menu navigation wouldn’t be simple. As someone who primarily plays games using gamepads, I have had a long history of frustration at many games’ UI navigation. Implementing this feature myself gave me a much needed outlet to address all of these frustrations! Here’s some of those frustrations and other challenges we’ve met while implementing the navigation:
•Virtual Gamepad Cursor: We both have noticed a growing number of games that use a virtual cursor that is controlled via the gamepad. In implementing our menu navigation, it became clear why. If you simulate a cursor, then you don’t actually need to make the menu elements navigable, you just have the player “click” on them with a virtual mouse. I have no love for virtual cursors. They are always either clunky or imprecise and sometimes both. They always felt odd and out of place and now they just feel like the cheap alternative to properly implementing good menu navigation. However we do understand how time and money limits can cause AAA games to need to cut corners, and while cursors aren’t a perfect solution, they are an easy one. Regardless we did not want to resort to a virtual cursor for our game, and thus still had to tackle the following issues.
•Menu Wrapping: This is a feature whose absence always baffles me. Not only does making the menu navigation loop back around the screen save so much time and reduce unnecessary button presses, it also just feels right and the lack of it is immediately noticed. What’s even worse than no menu wrapping though, is bad menu wrapping. Games that have menus wrap, but only in one direction are particularly infuriating. Nothing quite compares to accidentally looping to the top of a menu, only to find you can’t loop back to the bottom and instead have to go all the way through the lengthy menu again. (And if you accidentally loop again? Agony!!) Implementing this feature was pretty trivial, especially with Unity’s UI Navigation tools. (Making me even more confused why any game would not have it.)
•Scrollbar Positioning: We don’t have many different scrollbars in The Chaser’s Voyage, but you do find one every time you’re picking up a new client. As a product of menu wrapping, the player can continually navigate down or up and continue switching between the scrollbar and the confirm client button. But when this happened the scrollbar would stay at the bottom or top of its zone. What I’ve seen other games do sometimes is that if you highlight a scrollbar from the top, the scrollbar would then jump up to the top most position, and jump to the bottom is highlighted from the bottom. This took a little bit of extra coding to pull off, but the final result is well worth it. It really ties the scrollbar to the other menu elements in a subtle manner. A second consideration was making sure that the Insignia Selection menu’s scrollbar automatically shift its position to match which insignia the player was currently highlighting. On top of that we needed the correct insignias to be highlighted when the player moved off of the scrollbar after they moved it manually.
•Button Highlights: This was thankfully already mostly accounted for by our current design of our UI, but many games do not make it obvious enough which button is being highlighted or is currently selected when using a gamepad (or even a mouse sometimes!) This was something we kept in mind from the beginning of our previous UI redesign, and Eos came up with the current (wonderful) highlight icons for buttons, and I added in the smooth animations to make them pop to life. Now all that was left in regards to button highlighting in gamepad navigation was making sure that buttons only became highlighted when they were usable. We have quite a few neat animations with our UI screens popping in and out, or fading different elements, so I needed to account for these animations where the UI buttons aren’t activated.
•Button History: When you go back a menu, you expect to be put on the button that led you to said menu. With our nestled menus, we had to keep track of what buttons led you where, and make sure to put the player back on the correct buttons when exiting a menu. This was relatively straight forward for the most part. But the next item on the list complicated this process quite a bit.
•The Back and Start Button: These two buttons were the trouble children of menu navigation for us! We have a decent amount of nestled menus and had to make sure only the most recent menu disappeared when the back button was pressed. We also had to make sure that like the UI buttons, the Back button wasn’t usable while the menus were animating in or out, as it would cause some very awkward game states. On top of that, we needed the correct previous button to be highlighted. This was easier when everything was done by clicking on UI buttons, as each button that exited a menu could point to the previous button, but the Back button can be used on any menu no matter what. So we needed to keep a more detailed history of the buttons that were pressed to get into nestled menus, and make sure that that history was cleared and used correctly. Adding in the Start button as a way to exit the pause menu (a necessity) no matter which screen you were on complicated things further. We now had to make sure multiple button history elements were cleared or risk the player being trapped in an inactive menu! (Don’t worry, we always allow the mouse and Esc key to be used, regardless of if the gamepad is in use, so the player is never locked out of the game. You know, just in case. ;D)
•Dual Stick Controls: This is a relatively small point, but it still deserves a place here due to my affection for it. Let it be known that the Nintendo Switch has absolutely spoiled me. The ability to navigate its menus using either the left OR right thumbsticks is such a wonderful improvement to UI navigation. There have been way too many times where I would try to navigate through a menu with the right thumbstick as it occasionally felt more natural, only to be reminded that almost no games do this. Why limit UI navigation to one stick when the other is unused? Some games make great use of the right stick as a way to scroll through many menus, but that is not drastically different from just having the left stick scroll instead. We decided for The Chaser’s Voyage to make the left and right sticks both navigate through the menu in the same way, just like the Switch.
That covers most of the big points of UI Navigation that gave us any sort of trouble or that I wanted to give a special spot light (dual stick controls). With UI Navigation done, the current task is now getting button remapping to work with gamepad, adjusting the options to let players switch between control schemes, and adding in some pause menus for when controllers get disconnected. We can’t wait to get this update into your hands, this has definitely been a very important feature made with lots of care!
Follow us on Twitter and join our Discord for more news and to give feedback!
