search

Double-Fine-Game-Club / bad-golf-community-edition

A community developed version of Patrick Hackett's Bad Golf Amnesia Fortnight pitch!
Other
52 stars 38 forks source link

Reorganize input handling #251

Open osse101 opened 10 years ago

osse101 commented 10 years ago

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

Cheeseness commented 10 years ago

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.

drewaburden commented 10 years ago

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. http://pastebin.com/BVHRyz1j

osse101 commented 10 years ago

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: -using mouse for menus is covered by the click handlers we have on menu options -text chat can be an exception that takes in all key inputs

and some smaller points: -InputManager.Setup needs to check if it is already setup -camera zoom is no longer supported and brake is not yet implemented -Some more actions we have are: Honk, OpenChatTextBox (and send), Reset (respawn).

Make it happen.

drewaburden commented 10 years ago

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? Just for a start: https://docs.google.com/document/d/1E6lEjabYMc69hy7ZSHH7M3ANUAZ2zw5VfW6QYeXBX38/edit?usp=sharing

Cheeseness commented 10 years ago

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.

Cheeseness commented 10 years ago

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.

drewaburden commented 10 years ago

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.

Cheeseness commented 10 years ago

At any rate, the sort of system you're proposing would make implementing keyboard controls for that trivial anyway ^_^

osse101 commented 10 years ago

Added a line for controlling emotion. Currently, pressing w makes you happy and s makes you anger face.

Cheeseness commented 10 years ago

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).

osse101 commented 10 years ago

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.

drewaburden commented 10 years ago

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.

drewaburden commented 10 years ago

Also, would you rather have a OnGUIAccept/OnGUICancel events, or would you rather have OnGUIAction(Action.ACCEPT)?

Similarly for GUI navigation (OnGUIUp/OnGUIDown/OnGUILeft/OnGUIRight or OnGUINavigation(Direction.UP))?

RyanMorash commented 10 years ago

The InControl docs suggest to query 'InputManager.MenuWasPressed'. On Apr 30, 2014 8:19 PM, "Drew Burden" notifications@github.com wrote:

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.

— Reply to this email directly or view it on GitHubhttps://github.com/Double-Fine-Game-Club/bad-golf-community-edition/issues/251#issuecomment-41867345 .

drewaburden commented 10 years ago

It seems as if that doesn't exist, even though the documentation does indeed say otherwise. image

osse101 commented 10 years ago

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?

OnGUIAccept/OnGUICancel is the style I would like...let scripts subscribe only to the events they need.

drewaburden commented 10 years ago

Ah, okay, that seems to work. I haven't tested its functionality yet, but it at least compiles now.