Comportement SYSTÉMATIQUE à chaque création de jeu (admin compris), pas
une formalité réservée à l'inscription : /onboarding (routes/onboarding/)
devient le point d'entrée unique — 4 cartes retournables (survol =
explication au dos), défilement horizontal animé vers le nom du jeu. Un
admin y repasse à volonté (pas de project_slug dédié, jamais bloqué/
redirigé vers un projet précédent) ; un compte "user" n'en a plus qu'un
créé d'office (routes/auth/register_2fa.py), guidé ici à la place.
- db/games/game_type_catalog.py : catalogue des 4 types (Quiz/
Embranchement-escape game/RPG/Créer mon jeu de A à Z), _meta['onboarding_type']
décide du "kind" du premier écran créé et si le tableau de bord complet
reste accessible.
- routes/games/game_dashboard.py, templates/game_dashboard_simple.html :
un type restreint (quiz/embranchement/rpg) voit désormais SON tableau
de bord (même route que "custom"), rendu en version simplifiée — juste
ses écrans en cartes avec un aperçu RÉEL du contenu (scène mise à
l'échelle par container query CSS, adaptée à la largeur réelle de la
carte). "+ Ajouter un écran" n'y propose pas de choix de type : imposé
par le projet (routes/screens/screens_new.py), verrouillé aussi côté
serveur.
- core/auth_guard.py : plus de blocage de game_dashboard par type — la
restriction se fait au rendu, pas à l'accès à la route.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Remplace le rangement plat projects/<slug>/ par une vraie arborescence
par compte créateur, sans toucher aux routes existantes (aucune ne
déclare de "/" dans son <slug> : le chemin composé "propriétaire_projet"
reste un détail interne à db/, décodé par db/games/project_slug.py, seul
fichier à modifier si la convention change un jour).
- db/game_dir.py, create_game.py, delete_game.py, list_games.py,
move_game.py : résolvent/construisent ce chemin composé. Bénéfice
direct : deux comptes différents peuvent chacun avoir un projet nommé
pareil sans collision (l'unicité ne se vérifie plus que par dossier
propriétaire). move_game.py renomme désormais le dossier PROPRIÉTAIRE
entier (changement d'email), prêt pour un futur multi-projet.
- scripts/migrate_flat_project_slugs.py : migration des projets déjà
créés sous l'ancien rangement plat (simulation par défaut, --apply
pour exécuter).
- routes/auth/profile.py, tests/conftest.py : suppression de compte/jeu
de test via db.delete_game (nettoie aussi le dossier propriétaire
devenu vide) plutôt qu'un shutil.rmtree direct du seul dossier projet.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dernier lot de la fonctionnalité (voir 449c36fd et a27d08c6) : les
sprites eux-mêmes, générés une fois par scripts/generate_animal_sprite_manifest.py
depuis les packs sources CraftPix (assets/characters/, non committés —
licence perso, voir .gitignore — gardés en local pour régénérer si besoin).
- static/characters/animals/manifest.json : catalogue déclaratif (14
familles, 15 variantes de couleur chacune, poses/animations
disponibles par famille) lu par screens/labels/animal_sprite_library.py
au démarrage pour construire ADMIN_SPRITE_LIBRARY.
- static/characters/animals/<famille>/<variante>/ : les frames PNG de
chaque pose, réencodées à une taille raisonnable pour le web (les
canevas sources CraftPix sont surdimensionnés, ~788×504 px).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Pas un bug moteur cette fois : le moteur ne fige JAMAIS de couleur de
texte par défaut à la création d'un élément (voir
default_style_for_widget.py) — un titre/texte fraîchement posé retombe
donc sur le texte SOMBRE par défaut de Bulma, pensé pour un fond clair.
Mon script de démo ne posait jamais explicitement de couleur de texte sur
les titres/paragraphes à l'intérieur des boîtes de dialogue (fond sombre
volontaire) : le texte y était donc quasi invisible, ce qui donnait
l'impression trompeuse que "la boîte de dialogue est assombrie" — alors
que seul son texte, invisible par défaut sur fond sombre, l'était (la
boîte elle-même a bien sa couleur opaque demandée, #20263a/#1f3a24/
#2a2440, sans aucun voile supplémentaire dessus).
Ajout de la couleur de texte manquante (#f5f6fa) sur chaque titre/texte
posé dans une boîte de dialogue. Valeur volontairement différente de la
suggestion par défaut du panneau (#e8eaf0) : save_element_controls.py
ignore délibérément un réglage renvoyé identique à sa valeur par défaut
tant qu'il n'a jamais été personnalisé (même logique anti-figeage que
default_style_for_widget.py) — envoyer #e8eaf0 tel quel n'aurait donc eu
AUCUN effet, silencieusement (piège rencontré et documenté dans le script).
Jeu de démo régénéré (supprimé puis reconstruit) avec le correctif.
129 tests toujours au vert (script indépendant, aucun changement moteur).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Les trois mécanismes de guidage du joueur discutés (boîte de dialogue en
popup, réaction à un clic, mise en évidence d'un élément à cliquer)
existent DÉJÀ dans le moteur (voir README, section "Survol, séquences
temporisées, surbrillance, overlay, verrouillage") : widget "Superposition
/ boîte de dialogue", action "Modifier un élément → Surbrillance", et
déclencheur "affichage" combiné à l'action "Attendre" pour un message qui
arrive tout seul après quelques secondes. Rien à coder côté moteur.
scripts/build_demo_dialogues.py construit, via les VRAIES routes Flask
(mêmes routes qu'utilise le navigateur), un jeu de démo persistant
("Demo Dialogues Surbrillance") avec deux écrans :
- "Tutoriel" : dialogue de bienvenue à l'ouverture de l'écran -> son
bouton OK ferme le dialogue et met un autre bouton en surbrillance ->
cliquer ce bouton l'éteint, le désactive (verrouillage anti-reclic) et
ouvre un dialogue "Bravo" en réaction, fermable à son tour.
- "Message différé" : un dialogue "mentor" apparaît tout seul 3 secondes
après l'affichage de l'écran (affichage -> attendre -> visibilité),
sans aucune action du joueur.
Vérifié via /runtime-payload (nombre de nœuds/arêtes attendu sur les deux
écrans) et /play (overlay + surbrillance + attente bien exposés côté
rendu). 128 tests toujours au vert (script indépendant, aucun changement
moteur).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
