Feature: More than 2 Player Vs

TODO:

Technical requirements:

[ ] Assign stacks by public player id rather than an internal/temporary number
[ ] Make the server send public player id along for input messages so the client can match to the stack
[ ] Use the public player id in game setup messages

These are fairly simple and should have no adverse effects as TCP package size is up to ~1400 bytes and we have a lot of space left for our input messages. I consider this a sensible step to do early on so that match setup can start to move away from juggling temporary player numbers for anything but drawing.

[x] panel-attack/panel-game#262 Get rid of P1 and P2 as globals. Stacks should live in a dictionary array on match that is accessed by public player id. Draw order can be tracked in a separate array.

A lot of work was done for this already. Mainly still present in match setup (easy to fix), replay loading (easy to fix) and receiving inputs from the server (looks somewhat tricky).

Problematic non-coding work:

[ ] Redesign match setup screen graphically. Honestly the elephant in the room and I'm still talking about the design, not even writing the code. I have some ideas for online multiplayer as you can kind of cut down on space for other players as you only need to see their selection and not necessarily every detail of how they are selecting. But local multiplayer is a thing too. Although I wouldn't mind keeping local to 2p until development is far enough.

Minimum feature work:

[ ] Rework the network protocol for match setup. This should be a generic protocol that allows for any amount of players in a room. Meaning any and all changes, updates etc. for a player need to be contained in an array assigned to their public player id. Personally I think that a full rewrite for the match setup message protocol is in order. This needs to be accompanied by according server and client implementations that are ideally neatly encapsulated unlike the current client-side one.
[ ] Rewrite match setup based on the new protocol and design. We likely want to wait for scene-based graphics to land for that.
[ ] Come up with some design to display more than 1 stack and implement it. Doesn't need to be too fancy. Codewise this will mainly require the addition of a custom size multiplier for drawing stacks and setting sensible offsets for all the stacks on match start based on player count.

This would be a milestone assuming that side-by-side onlineplay exists by the time this is finished as it would allow people to play non-vs game modes in (online) multiplayer without having to add actual 2+ player garbage mechanics. Meaning time attack vs would be possible at least. Assuming we can find a design, I'm carefully optimistic to reach here in 2025. No promises really but I intend to make any future designs with 4P in mind so as to not create new obstacles in the way.

2+ player mechanics:

[ ] Add team selection and graphics. So we can all gang up on Ganache.
[ ] Add garbage mechanic selection. So garbage either sends to both opponents or according to some ruleset as described in the opening post of this issue. Alternatively we could do stuff like repurposing the taunt buttons to actively switch garbage target. The SFX could double purpose as the audio cue for a target switch. May require the addition of a taunt fallback to the default character or theme. Also see https://discord.com/channels/196674532491132937/1120528565964906638/1120528568624087121
[ ] Potentially scary engine work. There will be some extra work to do to ensure that a stack can verify where a piece of garbage is coming from to properly check for rollback/abort conditions. Off the top of my head this shouldn't be toooo bad as the mechanism of pushing new garbage to the target stacks garbage queue should make the general mechanism functional already. But it's rollback so you never know.

panel-attack / panel-game

Feature: More than 2 Player Vs #59