Gamepad focus model (Re: Input and games.)

[Pekka Paalanen]

On Tue, 7 May 2013 14:04:14 -0400
Todd Showalter <todd at electronjump.com> wrote:

> On Tue, May 7, 2013 at 1:02 PM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> >>     This would work too.  The main thing is dealing well with the
> >> single player case where the player is replacing a gamepad.  This
> >> could be because:
> >>
> >> - they wandered out of RF range when they were getting a drink
> >> - they want to play the game with a different gamepad
> >> - the gamepad they were using ran out of power and is now plugged in via usb
> >> - the gamepad they were using ran out of power and is being replaced
> >> with a charged gamepad
> >> - someone tripped over the usb cord and yanked it out and then plugged
> >> it back in
> >
> > Yeah, sure, and that's all just heuristics inside the server. The
> > server needs to make sure the player id becomes what the user
> > wants, even if one wl_gamepad object is deleted and another created.
> 
>     The client needs to look at a new wl_gamepad when it shows up and
> decide whether it's a new player or an existing player who is
> reconnecting,  As long as it's easy for the client to do that, I think
> we're good.

Yes, the client just looks at the played id the server tagged the
gamepad with. No heuristics needed in the client.

> > The problem you described with PS3 should be solvable with the
> > mysterious gamepad configuration GUI I talked about before, somehow.
> 
>     Partly, though I think the default case should be that if a
> controller disappears and another (or the same one) appears, the
> assumption is it's the player that just left coming back.  The number
> of times that isn't true isn't likely to be statistically significant.

Yeah, you can just simply do that in the server heuristics. No
clients involved. And when heuristics fail, like on the PS3 for
you, there needs to be the GUI, just like we talked.

> >>     My temptation would actually be to say that when focus goes to a
> >> new application, we treat buttons that are down as if they were up;
> >> don't send a release when they are lifted.  So, if I'm holding down
> >> SELECT when focus enters the client window and then release it, press
> >> it and release it, the client sees the press and the second release,
> >> but not the initial release.
> >
> > It depends. If a gamepad enters with button A down, and then the
> > user presses button B down, is the application supposed to respond
> > to B or A+B?
> 
>     In my experience games that use gamepads don't usually use the
> gamepad buttons as modifiers; it can happen, but it's awkward to
> explain to the player and often awkward to actually perform with the
> hands.  What you get more often is some sort of lockon, where holding
> a button down makes player motion relative to a target (so you can
> circle-strafe around an opponent, for example).  In cases like this
> the focus switch is likely to have broken the player's context
> anyways.

The PS3 game I'm playing atm has the shoulder buttons as attack mode
modifiers: keep a shoulder button down, and the N/E/S/W buttons do a
different thing.

Looks like we do need initial button state sent at device enter.

We do that also for keyboard keys, or at least modifiers, where you
might equally well just say "meh, just re-press the key". Therefore
I don't think the "broke the player's context anyway" is a valid
argument.

The protocol has a native type for an array, so one might just send
an array of pressed button ids. Usually that would be empty, too.


Thanks,
pq