Input and games.

[Pekka Paalanen]

On Fri, 3 May 2013 03:51:33 -0400
Todd Showalter <todd at electronjump.com> wrote:

> On Fri, May 3, 2013 at 3:34 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> 
> > 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.
> 
>     I don't know that you need a GUI to fix it as long as you're
> willing to lay down some policy.  We could go with basic heuristics:
> 
> - if a gamepad unplugs from a specific usb port and some other gamepad
> re-plugs in the same port before any other gamepads appear, it's the
> same player
> 
> - if a gamepad unplugs from a specific usb port and then appears in
> another before any other gamepads appear, it's the same player
> 
> - otherwise, you get whatever mad order falls out of the code
> 
>     I think that covers the common case; if people start swapping
> multiple controllers around between ports, they might have to re-jack
> things to get the gamepad->player mapping they like, but that's going
> to be rare.

Sure, the heuristics can cover a lot, but there is still the mad case,
and also the initial setup (system started with 3 new gamepads hooked
up), where one may want to configure manually. The GUI is just my
reminder, that sometimes it is necessary to configure manually, and
there must be some way to do it when wanted.

Even if it's just "press the home button in one gamepad at a time, to
assing players 1 to N."

> > 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?
> 
>     Heuristics mean less work for the player and behaviour the player
> can learn to anticipate.  I say go with that.  I think the moment you
> present people with a gui plugboard and ask them to patch-cable
> controllers to player IDs, you're in a bad place.
> 
>     I could see it being an advanced option that a savvy player could
> bring up to fix things without rejacking the hardware, but the less
> technically savvy are going to have a far easier time just physically
> unplugging and replugging gamepads than they are figuring out a GUI
> they've never (or rarely) seen before.

Well, yes. But the question was not whether we should have heuristics
or a GUI. The question is, do we want the heuristics *and* the GUI in
the server or the games? The GUI is a fallback, indeed, for those who
want it, and so is also the wl_seat-player mapping setup in a game.

If we do the heuristics in the server, there is very little we have to
do in the protocol for it. Maybe just allow to have human-readable
names for wl_seats. The "press home button to assign players" would be
easy to implement. The drawback is that the server's player 1 might not
be the game's player 1, so we need some thought to make them match.

If we do the heuristics in the games, we have to think about what
meta data of the gamepads we need to transmit. You said something about
a hash of some things before. If we have just a single hash, we cannot
implement the heuristics you described above, so it will need some
thought. Also, if we want to drive things like player id lights in
gamepads, that needs to be considered in the protocol.

Maybe there could be some scheme, where we would not need to have the
wl_seat<->player mapping configurable in games after all, if one goes
with server side heuristics. There are also the things Daniel wrote
about, which link directly to what we can do.


Thanks,
pq