Reorganize input handling #251
Comments
|
I agree that a centralised input class would make the most amount of sense. Happy with the direction you're suggesting there so long as InControl doesn't fall by the wayside. |
|
Hey, @osse101, I coded up something really rough, and wanted to see what you think. It's not functional right now, but before going that far, I'd like to make sure this is headed in the right direction. |
|
Cool stuff, I like it. Its like how I would have pictured it if I'd known about event and delegate. Looking at PlayerActionEventArgs, some of those actions will be mapped to the same button so it may need to notify that all actions corresponding to a button have been pressed. Relating to some particular cases: and some smaller points: Make it happen. |
|
All of the event args I have in there were just there for place holders, because I wasn't sure what the possible actions a player could perform were, and when he/she can or can't perform them. Can we start a list of possible actions that a player can do, bools that represent when the player can and can't perform those actions, and what keys/buttons these are default bound to? |
|
Don't forget menu navigation (which apparently works in offline mode with a game pad). We don't currently have or want the ability to walk around (as per Patrick's initial design notes, we're aiming to first get a solid game that only has driving and swinging mechanics before assessing whether or not on-foot gameplay is desirable), so inCart in your list there is redundant. We use w and s to control swing power (or x axis on the mouse which I'm hoping we'll re-implement soon), and then Space (or mouse 1) to swing at the ball rather than e (e will cancel the shot and return you to your cart). Mouse y will provide rotational control when in swing mode as well. This allows for a much faster paced gameplay than the common multi-click golf swing interface. Aside from that, the horn (q - can only happen whilst driving), being able to trigger text chat (t - can happen at any time during gameplay and should take input exclusivity. No idea how we should handle that when a keyboard isn't present) and resetting cart position (r - can only happen whilst driving) are the only things you're missing by the looks of things. |
|
Just worked through the Google doc with @drewaburden. Looking good, but it does highlight that camera rotation whilst driving is the only functionality that we have no keyboard input bindings for. |
|
We at least have the mouse movement for rotation. And I'd say it's probably unlikely that someone would be playing with only a keyboard and not a mouse. |
|
At any rate, the sort of system you're proposing would make implementing keyboard controls for that trivial anyway ^_^ |
|
Added a line for controlling emotion. Currently, pressing w makes you happy and s makes you anger face. |
I was under the impression that we were intending that that wouldn't be controllable (and would happen in response to game events (landing a ball in the rough, getting hit by another player, sinking a ball, etc). |
That does sound like a better way to handle it. |
|
It looks like InControl doesn't expose the "start" and "select" buttons, unless I'm missing something. So we'll probably need to code those ourselves. |
|
Also, would you rather have a Similarly for GUI navigation ( |
|
The InControl docs suggest to query 'InputManager.MenuWasPressed'.
|
|
It seems as if that doesn't exist, even though the documentation does indeed say otherwise. |
|
You can do `inputDevice.GetControl( InputControlType.Start ).WasPressed``. They just don't seem to have convenience things for start and select. Hopefully this is supported and there wasn't a reason for it?
|
|
Ah, okay, that seems to work. I haven't tested its functionality yet, but it at least compiles now. |
Merging offline/online scripts is being blocked by the need for online to support gamepads. ( #235)
Looking at how gamepad support is setup, there are two paradigms in place with regards to input handling. For controllers, ControllerSupport.cs is updating every tick and notifies each player when a particular button is pressed on their controller. For keyboards, each individual script has in its update function a
if( input_pressed )check. There is no reason to keep both input handling styles.I can't decide which style I prefer so I'll pick InputEventCallbacks. Either style should have a bigger InputManagement class for hiding input device type, but I think the event notify's should be done where an attached script subscribes to a particular input to be notified about.
Related to #62 and #201
The text was updated successfully, but these errors were encountered: