[Ohrrpgce] Multiple joysticks, multiplayer, and control remapping

[James Paige]

I have nothing to add to this thread other than that I think these gamepad
ideas are good, and I like the idea of making things player-oriented rather
than device oriented

Also, Hello, Simon! Nice to hear from you! :D

---
James

On Fri., Apr. 16, 2021, 9:09 p.m. Ralph Versteegen, <teeemcee at gmail.com>
wrote:

> Nice to hear that! That's a massive break from gamedev. I've been playing
> EoG for a bit. I like the ordered dithering aesthetic, although to begin
> with I thought the ladders were one-way since at the wrong distance the up
> ladders are almost invisible against a stone wall! It's a dungeon crawler
> distilled down to basics.
> I was going to say that I can't really complete the game without breaking
> out pen and paper but I JUST discovered there's a minimap if you press ESC!
>
> Getting back to controllers...
>
> I was initially quite surprised that SDL allows each player to have at
> most one joystick, because of things like the Switch Joycon and also flight
> simulator controllers (separate joystick and throttle - I actually have
> these but haven't used them for 20 years because I don't have a sound card!)
> But it turns out that SDL didn't really support Joycons until very
> recently:
> https://discourse.libsdl.org/t/simple-proper-joy-con-support/28567
>
> https://github.com/libsdl-org/SDL/commit/0f57864c9eb60807da20d793290d9f4b1a19d756
> It still doesn't merge them into a single controller, that's up to the
> application
>
> I wasn't clear, but I was suggesting letting each player have at most one
> keyboard, one joystick and one mouse.
>
> For single-player games the one-joystick-per-player is not a limitation
> because you can just use the player number to refer to controller number if
> necessary, and all the joysticks/keyboard will be coalesced so I think
> joycons will just work automatically. Throttles+joysticks however won't
> work properly unless you access them separately, because their buttons
> (arbitrarily numbered each starting from 0) would get OR'd together to
> produce the "player 0" input. I don't think we should care about supporting
> these at all, but if we did it would require shifting the button numbering
> so they don't overlap.
>
> On Sat, 17 Apr 2021 at 01:49, Simon Bradley <neworiginal at gmail.com> wrote:
>
>> I've been thinking about this sort of stuff in another context recently
>> (I just wrote my first hobby game in more than a decade, for a jam on
>> itch.io - it's here if you want to take a look:
>> https://drnefario.itch.io/eye-of-gath - I'm getting my mojo back after
>> working from home for more than a year.)
>>
>> Most of the time, for a single-player game, you want a coalesced input
>> that has maybe been abstracted to an action. You don't care whether it was
>> a d-pad up or an arrow-key up, you just want an up. And you also don't want
>> to move twice as fast if you press both.
>>
>> Even if you want to treat controllers as belonging to separate users, you
>> quite often want to be able allow a player to have more than one input
>> device, such as mouse and keyboard, or controller and touchscreen, or some
>> such. It seems to be an Xbox thing to tie user accounts to a specific
>> controller, but even there you must be able to add other non-controller
>> input sources somehow. The xbox supports usb keyboards, I think.
>>
>> Note that I did work on an AppleTV project a while ago where we did need
>> to be able to treat two controllers as a single user: the Siri Remote is
>> treated as a controller, and you have to expect someone to be using the
>> remote to launch apps while they use their game controller inside the
>> games. It's a bit of a weird edge case, though.
>>
>> Cheers,
>> Simon
>>
>> On Fri, 16 Apr 2021 at 14:05, Ralph Versteegen <teeemcee at gmail.com>
>> wrote:
>>
>>> I've been working through (especially in gfx_sdl2) gamepad bugs and
>>> unfinished features (none of which made it to github) and now I've only got
>>> handling of multiple gamepads left to improve. For better joystick
>>> numbering I'm thinking forwards to local multiplayer, remappable controls,
>>> ohrkeys joystick support, and even simple remote multiplayer via input
>>> forwarding.
>>>
>>> Currently a number of commands (keyval, keyispressed, keypress,
>>> newkeypress, joystickbutton, joystickaxis, getjoystickname,
>>> joystickbuttoncount, joystickaxiscount, joystickhatcount) take the joystick
>>> number as an extra argument. But there are lots of problems with this:
>>> -if there are multiple joysticks on the system you would have to loop
>>> through all of them to figure out which one the player is using
>>> -I added getnumjoysticks recently but it's undocumented
>>> -in gfx_sdl2 and gfx_directx joysticks can get renumbered if any are
>>> removed or even added (not possible in gfx_sdl anyway)
>>> -the joystick number is currently ignored for control keys like usekey
>>> (It's also ignored for keyboard scancodes), instead all inputs joysticks
>>> are OR'd
>>>
>>> But I used rpgbatch to scan the gamelists and there was only a single
>>> game that made use of the joystick number arg, Porosis on SS, which
>>> erroneously contains "key is pressed(key:A,true)". "joystick axis" wasn't
>>> used either (though Blood Ledger and inputtest.rpg now use it.)
>>>
>>> Further, I want to let people define additional keys to usekey, menukey,
>>> etc. (I think we could break convention and export these to the hsi as
>>> "shootkey", "runkey",  etc. for a form of consistency, since there will be
>>> little difference between builtin and additional controls.) So instead of
>>> hardcoding e.g. a charge-up action to the joy:Y button you'd define a
>>> "charge key" with some default mappings which can then be changed by either
>>> a scripted or future builtin control mapping menu.
>>>
>>> SDL2 has functions to get/set the player number for each
>>> joystick/gamepad. At most one joystick can be assigned to a player, which
>>> is a reasonable limitation. On most platforms these functions don't really
>>> do anything, but on consoles they report the actual player number and
>>> apparently some consoles have coloured LED lights to indicate which
>>> controller is each player.
>>>
>>> So it occurred to me that we should repurpose the 2nd arg to all those
>>> commands as the *player number* rather than the joystick number. Each
>>> player has at most one joystick and keyboard (and in future mice could also
>>> gain a player number arg) but note that a player might have no joystick,
>>> just a keyboard. I suggest that players are numbered from 1 up, which is
>>> less confusing, and the default player=0 (which is also used by all builtin
>>> controls) can just be all input from all control devices OR'd together so
>>> if you have multiple gamepads all existing games will just work. There
>>> could be a command to instead set a specific player as the default, e.g.
>>> for local or remote multiplayer where you want just one player to control
>>> the hero/menus.
>>>
>>> If you want to change which player a device is assigned to that might be
>>> tricky if there are no commands to enumerate joysticks, but we could have a
>>> command such as "swap player gamepads(player A, player B)"
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20210417/b4fed0e2/attachment.html>