Input and games.

[Pekka Paalanen]

On Thu, 2 May 2013 10:46:56 -0400
Todd Showalter <todd at electronjump.com> wrote:

> On Thu, May 2, 2013 at 5:44 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> > On Tue, 30 Apr 2013 09:14:48 -0400
> > Todd Showalter <todd at electronjump.com> wrote:
> >
...
> >>     The question is, is a gamepad an object, or is a *set* of
> >> gamepads an object?
> >
> > Both, just like a wl_pointer can be one or more physical mice.
> > Whether a wl_pointer is backed by several mice, the clients have no
> > way to know, or separate events by the physical device.
> >
> > The interfaces are abstract in that sense.
> 
>     Right.  From a game point of view, we don't want to do the
> conflated-device thing; it makes some sense to have two mice
> controlling a single pointer on a single device (the thinkpad nub
> mouse + usb mouse case), but it never makes sense to have multiple
> gamepads generating events for a single virtual gamepad.  The game
> needs to be able to tell them apart.

Indeed, that's why I proposed to put them in separate wl_seats. It
doesn't make a difference on the protocol level.

...
> > If just a gamepad goes away and later comes back, the wl_seat could
> > even stay around in between. There can also be seats without a
> > gamepad, so it is still the game's responsibility to decide which
> > wl_seats it takes as players.
> 
>     This is the icky problem for whoever handles it.  If a gamepad
> disappears and then appears again attached to a different usb port, or
> if a gamepad disappears and a different pad appears at the port where
> the old one was, is it the same wl_seat?

Yup. Whatever we do, we get it wrong for someone, so there needs to be
a GUI to fix it. But should that GUI be all games' burden, or servers'
burden...

Along with the GUI is the burden of implementing the default
heuristics, which may require platform specific information.

> > Which reminds me: maybe we should add a name string event to wl_seat
> > interface? This way a game, if need be, can list the seats by name
> > given by the user, and the user can then pick which ones are actual
> > players. (It is a standard procedure to send initial state of an
> > object right after binding/creating it.) I imagine it might be
> > useful for other apps, too.
> >
> > Unless it's enough to just pick the wl_seats that have a gamepad?
> >
> > Hmm, is this actually any better than just handing all gamepads
> > individually without any wl_seats, and let the game sort sort them
> > out? How far can we assume that a wl_seat == a player, for *every*
> > existing wl_seat? And which player is which wl_seat?
> 
>     That's why I was assuming originally that gamepads would all be
> attached to a single wl_seat and come in with pad_index values.
> However it winds up getting wrapped in protocol, what the game is
> interested in (if it cares about more than one gamepad, which it may
> not) is figuring out when those gamepads appear and disappear, how
> they map to players, and what input each player is generating.

Right.

I can summarize my question to this:

Which one is better for the end user: have device assingment to seats
heuristics and GUI in the server, and seats to players mapping GUI
in every game; or have it all in every game?

Or can or should we design the protocol to allow both ways? Even if
gamepads are in different wl_seats, the game is still free to mix and
match.

I have come to a point where I can only ask more questions, without
good suggestions.


Thanks,
pq