Closed jstuder-gh closed 9 months ago
jstuder-gh
commented
2 years ago Also as an aside, thanks Terry and Ethan for releasing the source code for this project and to your commitments to Linux as a game platform! I wish more devs would follow in your footsteps!
jstuder-gh
commented
2 years ago I added a Draft PR for with some modifications that could be made in the short term that could potentially help address some of the issues Steam Deck users will encounter.
As I stated in the PR, I'm not entirely sure that these modifications are appropriate when a wholesale rewrite of major systems (like game controller input) is set to occur in the future. But given that Steam Deck is here now, maybe it's worth it to address a short term need?
InfoTeddy
commented
2 years ago This is a huge post and should probably should be split up into smaller issues, otherwise there's too much to address at once. That being said...
The default controller layout used is:
Official Layout for VVVVVV by Terry CavanaghI'm not sure if this was intentional and applied by you, the developers, or whether this was set by Valve and their testing team.
I'm not involved with the Steam Deck SKU so I can't say; Ethan and Terry will have to answer this. But I doubt Valve would make their own layout and then say it's an "official layout" by Terry himself. They might be bad but surely they wouldn't do that.
This layout (created initially for Steam Controller???) uses Steam Input to map keyboard keys to the buttons and overrides the in-game SDL GameController mapping.
This detail was confusing for me as a user as it was not apparent that the game was not using the in-game controller mappings at first. This lead to some head-scratching moments for me as my attempts to remap controls in the in-game menu did nothing and certain actions (like Right Bumper to restart) were inaccessible given that Steam input was overriding the actual button press in-game.
If Steam Input is involved, your guess is as good as mine. I think @flibitijibibo implemented a kill switch into FNA to nuke Steam Input because of how awful it is, maybe we can do the same here?
The option to separate Interact from Enter was not intuitive to me as a user. It was unintuitive to go to the speedrunning options menu in order to activate.
The reason it's in speedrunning options is because speedrunners spam E to interact with objects as soon as they can. In previous versions, they'd use Enter, but 2.3 made it so that Enter always brought up the menu everywhere regardless of being in a cutscene or not, as an anti-softlock measure.
Though yes, this should probably be in an input menu when we rewrite the input system. The reason it was made an option in the first place (and why it's not on by default) is because Terry wanted to preserve the simplified control scheme of having only one button for interaction and bringing up the menu.
- Perhaps the Interact binding option could be hidden if the option to Separate Interact is set to false?
Maybe. We'd have to see when the input system is rewritten; as of right now the current system is not very good.
When loading up the game for the very first time (prior to a
settings.vvvfile being created), there are no controller mappings applied at all in the in-game mapping. Once thesettings.vvvfile is created and the user restarts the game, the default in-game controller bindings will be active. But that initial load for a Steam Deck user without access to keyboard (and not using the Steam input layout) will be very jarring.
This sounds like a bug, but, I'm not surprised. The current system is pretty bad and nobody really wanted to test it since it was bad.
There is no way to reset your controller binding in-game back to the default. Binding the same key to a new action will unbind the prior action, but there is no way to wholesale reset back to their defaults.
This is a known issue, and one people have kept complaining about since partial controller support was added in 2.2.
The act of binding buttons in the menu is potentially problematic on the Steam Deck. The current method has the user hit the button they wish to bind when a particular binding menu option is highlighted. However this can conflict with navigation keybindings. For instance, attempting to rebind B to Enter will not work, as the menu back navigation will occur prior to the binding taking place.
Also given that the button bound to the flip action also performs the menu accept action, there are scenarios in which the user can get themselves into a bad state. If the user binds A to the Esc/Menu action then attempts to toggle an option or enter a submenu with A, it will no longer work as expected. The escape/back menu navigation will precede the affirmative flip/accept action and the user will navigate back to the prior menu.
This is recoverable when the user has access to a keyboard as a fallback and can easily access the filesystem to delete the offending controller configuration. But on a platform like the Steam Deck this could potentially lead to scenarios that are not easily recoverable.
Not much to say here, again, it is a known issue that the current input system is horrendous.
- Should the in-game controller actions of flip/menu be separate from menu navigation actions?
Probably yes. This will have to be done with the input rewrite.
- Should the user first have to hit Menu Accept on a binding option and then press the desired button to bind (in order to allow B to be rebound in-game for instance)?
This sounds sensible. But we'd have to do the input rewrite first.
On initial load of the game the game screen was very small. Perhaps it was windowed and at a low-resolution/scaling initially? That was easily resolvable when adjusting the graphics options. Is it possible to detect via the Steam API that the current platform is Steam Deck and adjust initial graphics options accordingly?
I'm not sure what the issue is, and I don't have access to a Deck to test. But it's true that it's kind of ambiguous as to what resolution the game should start with on first load. Right now (on desktop) it seems to be 320 by 240, but I've had memories of it being, like, 640 by 480. So this will need to be addressed somehow.
As I stated in the PR, I'm not entirely sure that these modifications are appropriate when a wholesale rewrite of major systems (like game controller input) is set to occur in the future. But given that Steam Deck is here now, maybe it's worth it to address a short term need?
As I said in the PR, it probably would not be worth it. Unless Ethan wants to do a 2.3.7. But it's not going to change the cert status of the game and 2.4 is going to address that anyways.
jstuder-gh
commented
2 years ago Thanks for @InfoTeddy for the detailed response. You're right, the issue is quite long. Sorry about that. That was not my intention when I began writing it.
It's a very enjoyable experience on the Deck out of the box. I feel like VVVVVV's gameplay works really well on a portable. It's just a bit confusing at times if the user isn't aware that it's using the Steam input layout.
I'm not sure exactly what the audience of the Steam Deck is going to look like ultimately. I imagine (at least initially) that it will be users that are a bit more technically inclined and will be willing and able to workaround some of those UX issues. But I wanted to let you guys know just what issues I encountered in case you had not had the opportunity to try it out on the device.
InfoTeddy
commented
2 years ago Regarding the small screen size, I believe that's because our strategy for letterboxing and integer scaling is "set the logical render size to be 320x240 and assume that the renderer will take care of it". Desktop handles it correctly, but I'm guessing that on the Steam Deck it doesn't for whatever reason and just goes with the logical size we give, which will always be 320x240 if we are in letterbox/integer mode.
This is also similar to another issue with the game when you run it inside libTAS - if the game is letterbox/integer, the game window will always be 320x240, no matter what. I believe this is also likely due to libTAS going off of logical size and not caring about the actual resolution.
In both cases I'm not sure if either we should change, or the platform should change. In the case of libTAS I can certainly imagine sending a PR. In contrast, Valve might need more... convincing. Any thoughts here @flibitijibibo?
flibitijibibo
commented
2 years ago All things Steam Input should be ignored right now. The "official" layout is just what's set in AppAdmin, which may not have gone through any testing and many devs likely don't even know they have such a thing. I probably won't touch this until action sets are done and 2.4 is ready. FNA's nuke sadly will not work because we don't get direct access to the Deck input hardware (same story as the Steam Controller). If we had a hidapi driver in SDL we could probably bypass Steam's virtual device properly.
Aside from that, Misa covered the rest pretty well - action sets clean all this up in a single go.
Issues have been filed for the obvious non-input stuff in SteamOS 3 and it hasn't moved AFAIK... so basically everything Deck is at the bottom of the pile aside from cert-related emergencies (and I've already written elsewhere that cert might not even be worth it if they don't course correct soon, like the OS issues this also has not changed). This includes the viewport, which would be right if gamepadui respected the Tenfoot variable that was established almost 10 years ago. Once we're in RC mode again, then we'll start going through the cert checklist.
To snuff out any of the usual Deck stuff in advance: Deck users who want the best experience should focus on making action sets more accessible to all developers, including those outside of Steam (this includes focusing attention on SDL_ActionSet), and maybe lobbying to have Deck mode also set Big Picture mode so existing games do not need to check for both (after all, the strength is supposed to be in existing games, right?). Do not, under absolutely any circumstances, expect this to get any attention from anyone managing the platform, ever, without tremendously aggressive public pressure. We would love to be a targeted case study for enhancing the Deck experience and we would be in a unique position to do so entirely in the open, and with a pretty tight budget compared to other titles, but that sort of project has never been Valve's style and it never will be.
TerryCavanagh
commented
2 years ago Thank you very much for these notes, @jstuder-gh!
Just to chime in, I got a Steam Controller back when they first came out, I made the controller layout for that. Probably that did more harm than good, I'm not sure!
My plan for VVVVVV was to wait until I had my own Steam Deck before digging into this too deeply - I figure there'll be a slow rollout so it's not urgent. I'm in Q2!
flibitijibibo
commented
2 years ago I'll have to see if they tried migrating Steam Controller configs to Deck... the added touchpads/sticks/bumpers might have prevented them from doing that. (We also have to make unique layouts for all devices past present and future...)
I briefly had the hardware last year, don't have it anymore, probably won't have it in my hands again until late this year, unless they start running through devkit requests again (I got mine via a really unusual path).
Fancy2209
commented
2 years ago I'll have to see if they tried migrating Steam Controller configs to Deck... the added touchpads/sticks/bumpers might have prevented them from doing that. (We also have to make unique layouts for all devices past present and future...)
I briefly had the hardware last year, don't have it anymore, probably won't have it in my hands again until late this year, unless they start running through devkit requests again (I got mine via a really unusual path).
well Steam adapts them to any controller I have a Xbox 360 controller and it just used the Steam Controller Config while playing the game on steam, so I think it'll do that on any other Gamepad Device, inlcuding the deck
TerryCavanagh
commented
9 months ago This issue can now be closed, as it's been addressed for 2.4. We're Steam Deck verified now!
I just played through the game on the Steam Deck and it was a great experience! However there are a few little UX issues that I wanted to bring up (beyond the lack of Steam Deck controller glyphs due in 2.4).
While I'm approaching this mostly from the mindset of a user coming to the Steam Deck and looking for a console-like experience, I feel that some of the suggestions I'm making here would apply more broadly and could improve the overall UX for new users (on any PC platform) looking for a more console-like experience out of the box.
When installing the game for the first time via the Steam UI it installs:
The default controller layout used is:
I'm not sure if this was intentional and applied by you, the developers, or whether this was set by Valve and their testing team. This layout (created initially for Steam Controller???) uses Steam Input to map keyboard keys to the buttons and overrides the in-game SDL GameController mapping.
This detail was confusing for me as a user as it was not apparent that the game was not using the in-game controller mappings at first. This lead to some head-scratching moments for me as my attempts to remap controls in the in-game menu did nothing and certain actions (like Right Bumper to restart) were inaccessible given that Steam input was overriding the actual button press in-game.
Also confusing is that the Steam Input layout binds B to Space/flip. This was not bad in-game, but made for some confusion in navigating the menus as the B button would Accept rather than Go back as is standard.
I can imagine that there are quite a few Deck users who will be confused when first booting the game due to conflict due to it using this layout.
There are a few bindings that the Steam input mapping provides that I really liked that I feel would be nice to have in the in-game configuration by default. The Steam input mapping had the left "Back" button (above left thumbstick) bound to Menu and the right "Start" button (above right thumbstick) bound to Enter. By default in the in-game controller configuration, the Back and Start buttons do nothing which feels a bit odd to me as a user who has become accustomed to games using those buttons.
Other UX concerns (when not using the Steam input layout):
The option to separate Interact from Enter was not intuitive to me as a user. It was unintuitive to go to the speedrunning options menu in order to activate. I also found it a bit confusing to see the "bind interact" option in the gamepad bindings menu when the option to separate Interact from Enter is false. It led to a bit of confusion when the mapping that I had for interact had no affect in-game and I was still prompted to hit Enter.
When loading up the game for the very first time (prior to a
settings.vvvfile being created), there are no controller mappings applied at all in the in-game mapping. Once thesettings.vvvfile is created and the user restarts the game, the default in-game controller bindings will be active. But that initial load for a Steam Deck user without access to keyboard (and not using the Steam input layout) will be very jarring.There is no way to reset your controller binding in-game back to the default. Binding the same key to a new action will unbind the prior action, but there is no way to wholesale reset back to their defaults.
The act of binding buttons in the menu is potentially problematic on the Steam Deck. The current method has the user hit the button they wish to bind when a particular binding menu option is highlighted. However this can conflict with navigation keybindings. For instance, attempting to rebind B to Enter will not work, as the menu back navigation will occur prior to the binding taking place.
Also given that the button bound to the flip action also performs the menu accept action, there are scenarios in which the user can get themselves into a bad state. If the user binds A to the Esc/Menu action then attempts to toggle an option or enter a submenu with A, it will no longer work as expected. The escape/back menu navigation will precede the affirmative flip/accept action and the user will navigate back to the prior menu.
This is recoverable when the user has access to a keyboard as a fallback and can easily access the filesystem to delete the offending controller configuration. But on a platform like the Steam Deck this could potentially lead to scenarios that are not easily recoverable.
On initial load of the game the game screen was very small. Perhaps it was windowed and at a low-resolution/scaling initially? That was easily resolvable when adjusting the graphics options. Is it possible to detect via the Steam API that the current platform is Steam Deck and adjust initial graphics options accordingly?