M5-M7: сцены, лобби, экран игры и цикл матча

Обе сцены собраны через Code Mode, не руками.

- loader: поднимает модули, прогревает арт карт, уходит в lobby
- lobby: обе UI-ветки в одной сцене (по ARCHITECTURE.md), матч — это
  смена видимого корня, а не загрузка сцены
- GameScreen рисует текущее состояние и доводит узлы твинами, а не
  проигрывает поток событий: узел карты живёт вместе со своей картой,
  поэтому "шестёрка ушла из руки на стол" не требует отдельного случая
- один тап = ход целиком; логика вынесена в core/rules/intent.ts
  и покрыта тестами, в том числе проверкой, что она никогда не предложит
  ход, который правила отвергнут
- арт карт переехал в assets/resources: .pac — это инструкция упаковки
  на сборке, а не рантайм-ассет, и без ссылок на кадры в сборку
  не попадало ничего. Теперь все 37 спрайтов в одной текстуре 2048x2048
- клики кнопок подписываются в коде, а не через clickEvents сцены
- строки интерфейса собраны в одном файле

Сборка web-mobile проходит чисто, все ссылки в сцене проверены.
Вживую не запускалось: браузер в этом окружении не поднимает
главный цикл движка. Подробности — в docs/TECHNICAL.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
ftc
2026-09-13 11:30:28 +03:00
co-authored by Claude Opus 5
parent 2056673946
commit 4f3a26dc45
111 changed files with 8168 additions and 37 deletions
+62 -10
View File
@@ -35,13 +35,13 @@ makes the rules and the save format testable without the engine.
```
assets/
scenes/
loader.scene module init, then → lobby
lobby.scene main menu; hosts the match UI
loader.scene module init and art preload, then → lobby
lobby.scene Canvas > Background, Safe > LobbyRoot | GameRoot
prefabs/
card.prefab one playing card, face or back
...
resources/
cards/ 36 faces + back + cards.pac, loaded by path
art/
cards/ 36 faces + back, packed into cards.pac (2048²)
ui/ table surface, nine-slice panels and buttons
scripts/
core/ PURE TS — no engine imports
@@ -55,9 +55,10 @@ assets/
IStorage + MemoryStorage, CocosStorage (engine)
app/ Bootstrap, ServiceLocator, SceneRouter
ui/
lobby/ lobby screen controller
game/ match screen: hand, table, deck, animations
common/ reusable widgets, safe-area root
MainFlow.ts owns both screens and moves between them
lobby/ LobbyScreen: statistics and the New Game button
game/ GameScreen, CardView, CardLibrary
common/ Theme (layout, palette, timings), Strings
tests/
core/ vitest specs against assets/scripts/core
support/ position fixtures and the state invariant checker
@@ -119,6 +120,29 @@ sits behind `IStorage`, so all of the save logic is testable headlessly;
falls back to an in-memory store when the device refuses to persist (private
browsing, a full quota) rather than taking the game down.
## The lobby scene
Both screens live in one scene, per ARCHITECTURE.md, so starting a match is a
change of visible root rather than a scene load:
```
Canvas (1080×1920, Canvas + MainFlow)
Camera orthographic, UI_2D only, clears to table green
Background table_bg, widget-stretched
Safe cc.SafeArea — everything tappable is inside it
LobbyRoot LobbyScreen: title, statistics panel, New Game
GameRoot GameScreen + CardLibrary (inactive until a match starts)
Deck / OpponentLabel / Message / CardLayer / ActionBar / QuitButton
ResultOverlay dimmer, result panel, Back
```
`GameScreen` renders from the current `GameState` rather than replaying the
event stream — see docs/DECISIONS.md. Card nodes are pooled and stay bound to
their `Card` while it is visible, so movement is a tween to a new position.
Buttons are `@property(Button)` references subscribed in `onLoad`; the scene's
`clickEvents` lists are deliberately empty.
## Conventions
- TypeScript, 4-space indent, `PascalCase` for types, `camelCase` for members,
@@ -183,10 +207,38 @@ matching `Card.assetName` — that string is the only contract between the rules
core and the art.
Licence: the faces are LGPL-3.0 and attribution is mandatory. See
[`assets/art/cards/ATTRIBUTION.md`](../assets/art/cards/ATTRIBUTION.md), which
[`assets/resources/cards/ATTRIBUTION.md`](../assets/resources/cards/ATTRIBUTION.md), which
also explains what would have to change to drop the dependency.
### Builds
Web: `web-mobile` template. Mobile: ASTC textures per [ART.md](ART.md), PNG for
web.
A headless build, which is what CI would run:
```bash
"C:/ProgramData/cocos/editors/Creator/3.8.8/CocosCreator.exe" --project "C:/Work/fool-cardgame" --build "platform=web-mobile;debug=true;startScene=<loader.scene uuid>"
```
It writes to `build/web-mobile` in about 40 seconds. Two caveats: it starts a
second editor instance, so it competes with a running editor for
`temp/logs/project.log` and can fail with a duplicate-class error — close the
editor, or build from its Build panel. And `startScene` must be passed, or the
build has no launch scene and stops on the splash.
Mobile: ASTC textures per [ART.md](ART.md), PNG for web.
### What is and is not verified
The rules, the bot and the save format are covered by `npm test` and are
verified. The presentation layer is verified only as far as this environment
allows: the project builds clean, every component reference in the scene is
populated, and all 37 card sprites pack into one 2048² texture.
It has **not** been seen running. The browser available here falls back to a
software renderer that cannot start the Cocos main loop (`totalFrames` stays at
0), so no screenshot of the actual game was possible. To check it by eye, open
the project in Cocos Creator and press Preview, or serve `build/web-mobile` over
HTTP — it is a static folder and needs no server features:
```bash
npx http-server build/web-mobile -p 8123 -c-1
```