Four systems put a mini-game in your way. Each has a defined winning ending; knowing which state ends it is the difference between playing it and passing it.
An 8×8 board of five-element cells with a walker you move by WASD. Cells clear as you pass them, and
when none are left (remainGeZiCount <= 0) the view plays its 破解 banner, closes itself, and sets
GeZiGame.m_LastGameSuccess. The quest script that opened it then asks two questions — is it finished,
and did it succeed — so a win has to go through that ending rather than around it.
Opened by script (OpenGeZiGame with a range of board ids, one picked at random), which is why the
same room can hand you a different board.
A 17×17 board against a character. The win branch lives inside the click handler: on a winning move it sets the game state to WIN, awards 棋艺 +3, increments the 侠棋 win counter, fires a stunt hook, and runs whatever the caller wanted done on a win. There is no callable "win" — the branch is inline.
A sequence of timed prompts (ArtistryButtonSlot). The run ends at its End state, which hides the
prompt and reports how many were caught; five is what the game counts as a good showing
(btn_Slot.completeCtn >= 5 decides the reward tier in ArtistryView.CompareComplete).
A set of questions with one correct answer each (PreachView). A wrong answer or a timeout ends it
immediately with failure; answering all of them ends it with success. The result goes back through a
callback to whatever opened it.
Not games at all — a bar that fills over time and completes on its own. The view's own update calls the matching completion when its timer passes its duration.