4.1 KiB
Étape 0 — Prototype technique
But : prouver que la chaîne technique fonctionne avant d'investir dans le design, et trancher entre deux socles : PWA (moteur en WebAssembly) ou Android natif.
Règle : chaque sous-étape se termine par une démonstration que le développeur peut lancer lui-même avec une commande make.
0a. Le moteur en ligne de commande
Objectif : interroger le moteur GNU Backgammon sur une position, depuis le PC.
À faire :
- Récupérer les sources du moteur (choisir entre gnubg, gnubg-nn ou le moteur extrait par CBG ; justifier le choix dans un ADR,
docs/adr/). - Définir une interface C minimale du moteur (
engine/include/engine.h, identifiants en anglais : ADR 0007), indépendante de toute interface graphique :- initialiser le moteur (charger réseaux, base de fin de partie, table d'équité de match) ;
- lister les coups légaux pour une position et des dés ;
- donner le meilleur coup et le classement des coups avec leur équité, pour un niveau d'évaluation donné ;
- donner la décision de videau (pas de double, double/prend, double/passe, avec équités) ;
- évaluer une position (probabilités de gain, gammon, backgammon). Les positions entrent et sortent au format GNU Position ID + Match ID.
- Écrire
engine-cli, un petit programme qui expose ces fonctions en ligne de commande, avec une sortie JSON. - Générer un jeu de positions de référence (au moins 30 : ouvertures, contact, course, sortie, décisions de videau) avec le GNU Backgammon de bureau dans Docker, et stocker les résultats attendus dans
tests/reference/. make testcompareengine-cliaux références (même meilleur coup, équités à une tolérance près, à fixer).
Démo : make engine && ./build/engine-cli bestmove <position_id> <match_id> 31 affiche le meilleur coup en JSON ; make test passe.
0b. Le test WebAssembly (décisif)
Objectif : savoir si le moteur tourne assez vite et léger dans le navigateur du téléphone.
À faire :
- Compiler le même moteur et la même interface C en WebAssembly avec Emscripten (dans Docker).
- Charger le moteur dans un Web Worker (jamais sur le fil d'affichage).
- Page HTML minimale : un champ Position ID, des dés, un bouton « meilleur coup », l'affichage du résultat et du temps de calcul.
- Rejouer les positions de référence dans le navigateur : les résultats doivent concorder avec 0a.
make deploy-websert la page sur le réseau local pour l'ouvrir depuis le Fairphone 4.make bench(ou une page de mesure) produit un petit rapport : temps par coup selon le niveau d'évaluation, taille téléchargée, mémoire utilisée.
Critères de réussite (à ajuster après mesure) :
| Mesure sur le Fairphone 4 | Seuil |
|---|---|
| Meilleur coup, niveau rapide (0-ply GNU) | moins de 0,3 s |
| Meilleur coup, niveau fort (2-ply GNU) | moins de 3 s |
| Décision de videau, niveau fort | moins de 3 s |
| Taille totale à télécharger (wasm + données, compressé) | moins de 40 Mo |
| Résultats identiques aux références de 0a | 100 % |
Démo : la page ouverte sur le Fairphone donne le meilleur coup d'une position de référence, avec le temps de calcul affiché.
0c. Android natif (seulement si 0b échoue)
Objectif : la même démonstration en application Android.
À faire :
- Compiler le moteur pour arm64 avec le NDK (dans Docker), en s'appuyant sur la configuration de CBG.
- Application Android minimale, construite en ligne de commande (Gradle sans Android Studio,
-j2, démon Gradle limité en mémoire). - Même écran de test et mêmes mesures qu'en 0b.
make deployinstalle l'APK sur le Fairphone via adb.
0d. Plateau minimal et décision
- Sur le socle retenu, un plateau minimal : une partie complète jouable contre le moteur, coups et videau décidés par le moteur, dés tirés par l'app.
- Rédiger un ADR (
docs/adr/) : socle retenu (PWA ou Android natif), mesures obtenues, raisons, risques restants.
Critère de fin de l'étape 0 : une partie complète jouée sur le Fairphone 4, moins de 2 s par coup de l'IA en niveau standard, tous les tests au vert.