Input and games.

[Pekka Paalanen]

On Fri, 3 May 2013 09:12:20 -0400
Todd Showalter <todd at electronjump.com> wrote:

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

Cool, I agree with that. :-)


Thanks,
pq