Input and games.

[Todd Showalter]

On Fri, May 3, 2013 at 6:42 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

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

    If there's going to be a gamepad setup gui, my preference would be
for it to be a system thing rather than a game thing.  Partly because
I'm lazy/cheap and don't want to have to do themed versions of it for
every game I do, but also partly because otherwise it's something else
that someone can half-ass or get wrong.

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

    I vote do it on the server, however it winds up being done.  It
means the client is isolated from a whole bunch of things it would
otherwise need to explicitly support, and it means that things happen
consistently between games.  It also means that any bugs in the
process will be addressable without shipping a new build of the game.

                                         Todd.

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