Input and games.

[Todd Showalter]

On Tue, Apr 30, 2013 at 5:29 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> you've provided lots of valuable information already. Unfortunately my
> input is left as hand-waving, since I cannot dedicate to designing this
> protocol myself (as in writing the XML spec).

    I'm getting set up to write code.  Someone kindly gave me a bash
script to pull down all the components, so once I get things set up
properly I'll see if I can get a patch together.

>>     That's not necessarily how games are designed, though; I know that
>> with our engine, input is represented internally as an array of
>> gamepads.  It lets us do things like feed a pad with a stack of pad
>> values to do things like demos and "replays".
>
> Alright. The remaining reasons are still significant, IMHO: this is the
> design pattern for Wayland input devices and even in general, and the
> protocol needs to move less bytes when the pad_index is effectively
> baked into the object id on the wire.

    The question is, is a gamepad an object, or is a *set* of gamepads
an object?

>>     This is I think where there's a potential problem.  Gamepads live
>> in a somewhat more chaotic world than mice and keyboards; wireless
>> ones have much shorter battery lives, and players are used to being
>> able to unplug and plug them while playing.  It's not uncommon for
>> someone to (say) play for a bit with a gamepad they don't like (maybe
>> it was on sale), unplug it, and plug in one they like better.  Or drop
>> the gamepad that ran out of batteries in the charger and pull out
>> another.
>>
>>     Players also expect to be able to add a gamepad part way through a
>> game, at least for some games.
>>
>>     So, gamepads can appear and disappear during the game's runtime,
>> and the game needs to know that is happening.  There also need to be
>> some heuristics about which gamepad is what player (or seat).
>
> So you would rather handle all that in your game, than rely on the
> display server to sort it out for you? The user would have to set up
> each game, instead of just the display server. The display server could
> also drive the player id indicators on some game controllers.

    I'd rather the display server sorted it out, honestly, I just
wasn't sure how much policy people were comfortable with pushing into
the display server.

> I can easily imagine a game controller configuration GUI for a display
> server, where you can register game controllers and assign them to
> different seats, just like you would do for keyboards and mice.

    I'd prefer something like that.  On the console side of things,
this is a problem that actually usually gets thrown to the game to
solve, and it's always a hassle.

>>     I think all gamepad input should be routed to whatever has focus
>> or whatever has grabbed input.  I don't see a scenario where it makes
>> sense to route different gamepads separately unless you're doing
>> multiuser multihead (which I assume is the point of the wl_seat
>> abstraction).
>
> A wl_seat does not relate to any specific output. Each wl_seat on a
> server simply shares all outputs with all other wl_seats.
>
> If you want to do separate sessions, that is each user has his own
> desktop, own input devices, and own outputs, then you pretty much run
> one display server for each user.
>
> wl_seats OTOH allow one to have several people collaborating on the
> same session and desktop, or just one person who needs more than one
> keyboard focus, for instance. This is one display server with several
> wl_seats.
>
> wl_seat is not really a seat in the physical sense. It may be better
> thought via input devices and input foci. One wl_seat has zero or
> one wl_keyboard, wl_pointer, etc. If you have several physical
> keyboards, they all act as one. To have two keyboards independent, they
> are assinged to different wl_seats. Then each keyboard can be typing
> into a different window at the same time.
>
> Focus is per wl_seat, and mostly per input device type. Keyboard and
> pointer have their own foci, wl_touch does not have a focus at all in
> the protocol.
>
> So for games with multiple local players on the same screen, wl_seat
> would be just a player id.
>
> Does this clarify what I was talking about?

    Ok, that makes sense.  So, from the game point of view, if each
gamepad lives in its own wl_seat, how does the game detect that new
gamepads have arrived or gone away?  I assume there are wl_seat
create/destroy events?

                                             Todd.

--
 Todd Showalter, President,
 Electron Jump Games, Inc.