Open
Conversation
…des and allow specification of gameModeID for game requests, including "any" to leave the choice to the opponent
…alongside server changes to accomodate independent challenge state per game mode
Open
…r rooms only for now)
This was
linked to
issues
Feb 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Going to self-review over the next days a bit and make changes/cleanup as necessary but overall this should work.
Overview
Allowing 2p time attack online posed some challenges for UI that directly affected how the internals would change.
The primary goal for a design was to keep all players in the same lobby to maximize discoverability.
From that goal the question emerged how players pick the game mode they want to play with each other.
This could be decided either on room creation (not allowing mode changes) or within the room (allowing mode changes).
Ultimately the character select is still a bit of a pain and I estimated it to be more difficult to make a workable UI for it, due to the need of players to agree on a game mode change and the resulting higher need for visibility. That is something that I think is more suitable when tackling the general arrangement of character select again (e.g. for portrait on Android).
So I opted for a lobby-side decision instead, if players want to switch modes, they have to recreate the room.
Challenging UI
I did not want to put any significant limitations on the decision players have to make when challenging. That means a challenger should be able to challenge another player to either VS, Time Attack or any of them.
Likewise, a challenged player should be able to pick their preference when challenged to both but also be able to send a counter challenge for a game mode they have not received a challenge for yet:
If A challenges B to VS, then B should be able to challenge A to Time Attack.
This demanded a submenu, so a submenu it was. I fiddled a bit with the options here and ended up replacing the regular
Menuwith aScrollMenu. That was not strictly necessary (which I only realized later) but it does ease the handling of elements when reconstructing things like the cursor position on lobby updates because there are no extra MenuItem elements sitting inbetween that have to be navigated into.For visibility I added a simple line element. That is because the room labels can get quite wide, so the submenu was forced to be on the right and it could be difficult to discern which player the submenu originated from otherwise.
Challenger side:


Challenged side:
There were also some simple symbols added as shown in the screenshot above. Quickly made them myself, can replay them later if we find them ugly.
Checkbox not checked: No incoming or outgoing challenge for this game mode
Checkbox checked: I am challenging for that game mode
Crossed Swords: I have been challenged to that game mode
I think this is universal enough that people will just get how it works without more explanation.
Networking
The desired UI changes necessitated network changes in turn. Given that time attack challenges would always go unanswered cross client but still cause a ping, I decided that this could be a breaking change. This will need some closer monitoring on the migration and some testing on the beta server.
The state is reasonably simple, instead of storing if a player has been challenged, it now stores the game mode the challenge was issued for.
While at it, I also figured it would be nice if players could retract their challenges after missclicks. Currently this requires players to disconnect from the server so the respective function was changed from a "challenge" that implies truthiness to an update of challenge status (true or false for the respective game mode), so that we still only have one message for this.
TODO 1: Scour for traces of the old function / protocol usage and remove them on both server and client side.TODO 2: Bump NetworkProtocol version to mark the breaking change.New lobby data
Rooms were already having varying game modes ever since the 1p online feature shipped and it would be nice to tell this apart in lobby.
Lobby data was still terribly outdated with explicit playerA, playerB assignments so I doubled down on breaking changes here.
Instead of listing unpaired players, the server now only sends a list of rooms by roomNumber and a list of players by publicId.
Each player also has the roomNumber (if in a room) and each room has the list of publicIds for players inside: Both players and spectators.
I also added some more information that allows the client to display basic information about the room, like the win counts and how long an in-progress game has been running by sending the timestamp of the start time.
And which game mode the room has of course. The client uses the latter to display symbols that indicate the room type:
TODO 1: The server should send its server time to the client on login so that the client can use the delta to its own time to calculate this ingame time correctly regardless of the machine's time setting)still need to properly testTODO 2: Remove old lobbyData functions / references from NetClientTODO 3: Optionally look into making the current overlay for the extra room information to look less bad
Deployment
The idea would be to have a transition period in which the beta release stream has the main 2p vs online server replaced with the beta server. That would imply that cross-release play is not possible which means this transition period should be as brief as possible (1-2 days) before shipping to the main server.
This would involve a temporary branch that only changes the related client code and informs players in the main menu about the limitation to cross-release play.
Issues handled