Add the score record flow to the results screen #14
+1,511
−36
Conversation
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
Players had no way to leave their name on a run, and the results web app needs a stable per-run id to look a run up later. A third button, RECORD, sits between CONTINUE and QUIT. Choosing it opens an arcade name entry, saves the run to score_records.json, then shows the id the run was filed under so the player can photograph it. New session files: Campus.cs and CampusBuildConfig.cs hold the cabinet's campus identity. The config loads from Resources and falls back to a runtime instance with a valid campus string, so a missing asset cannot write an empty campus field. A cabinet switches campus by editing one asset. ScoreRecord.cs is the JSON contract the web app reads: id, name, score, date, campus, lastPlaced. ScoreRecordFile exists only because JsonUtility cannot deserialize a top-level array; the file on disk is still a raw array. ScoreRecordStore.cs loads, appends, and saves. Ids come from the highest existing suffix rather than the record count, so deleting or hand-editing a row cannot hand out an id already printed on someone's phone. Dates and ids format with invariant culture. A missing, empty, or corrupt file reads as zero records, because a bad save must never block a player from leaving the results screen. New UI files: RecordNameEntryController.cs walks the glyph grid with Left and Right only, since the cabinet menu map has no up or down. Confirm inserts, DONE or the physical Enter key saves, and Back deletes then cancels once the name is empty. RecordConfirmController.cs shows the saved id and takes a final Continue or Quit. RecordFlowLayoutBuilder.cs builds both overlays from Style1 tokens, per results panel, so each half of a split screen owns its own overlays and its own input provider. Results screen changes: ResultScreenLayoutBuilder adds the RECORD button to the row. ResultScreenController replaces the two-way Continue/Quit flag with a three-way selection that skips Record when it is hidden, and re-spans the button row for two or three buttons. Record is gated on allowNavigation rather than a list of game modes, so it covers 1P, Player 1 in VS Bot, both players in human 2P, and battle mode, while the bot's spectator panel keeps the original two buttons. Record opens an overlay instead of leaving the scene, so it is never reported to TwoPlayerGameCoordinator as a Continue. After a save, the results buttons are re-armed before the confirm is reported, because the other player may have chosen the opposite option and the coordinator will ask for another confirm. Co-authored-by: Cursor <cursoragent@cursor.com>
Sign in
to join this conversation on GitHub.
2 participants
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.
Players had no way to leave their name on a run, and the results web app needs a stable per-run id to look a run up later.
A third button, RECORD, sits between CONTINUE and QUIT. Choosing it opens an arcade name entry, saves the run to score_records.json, then shows the id the run was filed under so the player can photograph it.
New session files:
Campus.cs and CampusBuildConfig.cs hold the cabinet's campus identity. The config loads from Resources and falls back to a runtime instance with a valid campus string, so a missing asset cannot write an empty campus field. A cabinet switches campus by editing one asset.
ScoreRecord.cs is the JSON contract the web app reads: id, name, score, date, campus, lastPlaced. ScoreRecordFile exists only because JsonUtility cannot deserialize a top-level array; the file on disk is still a raw array.
ScoreRecordStore.cs loads, appends, and saves. Ids come from the highest existing suffix rather than the record count, so deleting or hand-editing a row cannot hand out an id already printed on someone's phone. Dates and ids format with invariant culture. A missing, empty, or corrupt file reads as zero records, because a bad save must never block a player from leaving the results screen.
New UI files:
RecordNameEntryController.cs walks the glyph grid with Left and Right only, since the cabinet menu map has no up or down. Confirm inserts, DONE or the physical Enter key saves, and Back deletes then cancels once the name is empty. RecordConfirmController.cs shows the saved id and takes a final Continue or Quit. RecordFlowLayoutBuilder.cs builds both overlays from Style1 tokens, per results panel, so each half of a split screen owns its own overlays and its own input provider.
Results screen changes:
ResultScreenLayoutBuilder adds the RECORD button to the row. ResultScreenController replaces the two-way Continue/Quit flag with a three-way selection that skips Record when it is hidden, and re-spans the button row for two or three buttons.
Record is gated on allowNavigation rather than a list of game modes, so it covers 1P, Player 1 in VS Bot, both players in human 2P, and battle mode, while the bot's spectator panel keeps the original two buttons.
Record opens an overlay instead of leaving the scene, so it is never reported to TwoPlayerGameCoordinator as a Continue. After a save, the results buttons are re-armed before the confirm is reported, because the other player may have chosen the opposite option and the coordinator will ask for another confirm.