Date: 2026-09-05 · Status: accepted
- The presentation replays events; it computes no rule.
Game.Playreturns an ordered event list;BoardView.Presentanimates it in batches (swap → clears/hits/specials → falls/spawns → next cascade) and then hard-resyncs from the board. If an animation is ever wrong, the board is still right, and the bug is visible rather than silent. - Built-in render pipeline,
SpriteRenderers, procedural sprites. The demo ships no textures: gems, rockets, bombs, rainbows, tiles and overlays are drawn intoTexture2Ds at start-up with signed-distance functions. Zero import settings to maintain, the smallest possible WebGL payload, and any of them can be swapped for a drawn sprite without touching a view. URP would add packages and build size while contributing nothing to a flat 2D board. - The scene is generated by an editor script (
Match3 Lab → Create Demo Scene): one camera, oneGameController. The HUD is built in code with legacy UIText(no font import, no TextMesh Pro essentials). No hand-edited scene or prefab YAML lives in the repository. - Levels reach the build by a sync step, never by editing copies.
levels/*.txtin the repository root is what the CLI measures; the editor copies it intoResources/Levelson demand and before every build. - Both input backends are supported through
#if ENABLE_INPUT_SYSTEM, and the same press/drag/release logic serves mouse and touch. The event system's input module is chosen the same way. - The bot can drive the UI. "Bot: on" lets the greedy bot play the level with the same animation a player sees — the simulator's numbers become something you can watch.
- A designer who wants prettier pieces edits
SpriteFactoryor drops in sprites; the views stay as they are. - Anything that needs to look different in a cascade (a bigger burst on a rainbow, say) is a change to how an event kind animates, never a change to the rules.
- WebGL builds run from the command line:
Unity -batchmode -quit -projectPath unity -executeMethod Match3Lab.UnityEditor.Builds.WebGL.