6 Commits

Include renames

Author	SHA1	Message	Date
williamandClaude Sonnet 5	5891c82c62	Commandes personnage : détection de touche au clavier + touches d'animation supplémentaires ... Deux retours utilisateur sur le panneau "Commandes" (déplacement/ animation automatiques, voir précédent commit) : - Les champs de touche (haut/bas/gauche/droite/interagir) capturent maintenant la touche au clavier (clic puis appui — event.key, même valeur que heldKeys/triggers.js) au lieu d'être tapés à la main, source d'erreurs ("Espace" vs " ", "flèche haut" vs "ArrowUp"...). - Nouvelle section "Animations supplémentaires" : un nombre illimité de touches, chacune liée à UNE pose au choix parmi celles réellement disponibles pour ce personnage (sauter, attaquer, courir...) — pas seulement les 4 touches de déplacement + interagir. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 11:50:29 +02:00
williamandClaude Sonnet 5	74f7ca396f	Déplacement/animation automatiques d'un personnage (scène 2D) ... Simplification demandée pour l'éditeur de jeu RPG : un personnage posé sur une scène 2D se déplace et s'anime TOUT SEUL avec ZQSD (+ E pour interagir) dès qu'il est posé — plus besoin de poser le moindre nœud de flow pour un mouvement de base. Le panneau "🕹️ Commandes" du personnage permet de remapper les 4 touches de déplacement et la touche d'interaction, et de bloquer un axe (horizontal/vertical seulement). Entièrement client (static/js/play/personnage-controller.js), réutilise heldKeys (triggers.js) et applyObjectProperty/clampSceneObjectPosition/ runSpriteAnimation (actions.js) — aucune logique dupliquée, et ça fonctionne aussi bien en ligne que dans l'export Web/SCORM (aucune requête serveur). "walk"/"idle"/"interact" (poses déjà présentes pour tout personnage Forge/CraftPix) sont utilisées telles quelles ; une pose absente dégrade silencieusement (déplacement sans animation) plutôt que de planter. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 11:26:37 +02:00
williamandClaude Sonnet 5	9776fbc057	Score/Progression (Phase 1.1 de la feuille de route produit) ... Concept de premier ordre, distinct du système de variables globales — préalable identifié aux futurs exports SCORM/xAPI (note de cadrage .claude/Forge_Engine_Cadrage.pdf) : ces standards ont besoin d'un signal "score"/"terminé" propre, pas d'une convention sur une variable choisie par le créateur. - db/scoring/ (même patron que db/global_vars/) : table _scoring, un score numérique + un statut (non_commence/en_cours/termine/reussi/ echoue) par joueur (voir db.PLAYER_SHARED pour l'aperçu créateur). - Deux nouvelles actions de flux, dans les deux éditeurs (document et scène) : "Modifier le score" (réutilise le vocabulaire d'opérations déjà là pour "Modifier une variable" — incrémenter/définir/etc., aucune nouvelle colonne de nœud) et "Définir le statut de la partie". - Routes créateur (routes/flow/flow_node_run_score.py, flow_node_run_status.py) + miroirs publics par joueur (routes/public_play/) — même principe que flow_node_run_variable.py. - GET /game/<slug>/scoring/<player_id> : lecture interne, pas exposée au joueur, préparée pour être consommée par le futur export Web/SCORM. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 06:23:37 +02:00
williamandClaude Sonnet 5	449c36fd5d	Bibliothèque de sprites animaux CraftPix (1/3) : catalogue, galerie, accès admin ... Premier commit d'une fonctionnalité découpée en plusieurs lots (voir le plan "Bibliothèque de sprites animaux CraftPix") : intègre 14 familles d'animaux (15 variantes de couleur chacune) comme personnages Forge sélectionnables, à côté des 6 Kenney existants — réservé au rôle admin, licence CraftPix oblige (interdiction contractuelle de rendre ces sprites utilisables par un compte "user" via l'application). - screens/labels/animal_sprite_library.py (nouveau) : charge un manifest JSON généré une fois (voir scripts/generate_animal_sprite_manifest.py, commit suivant) et construit ADMIN_SPRITE_LIBRARY, dans le même format que l'existant PUBLIC_SPRITE_LIBRARY (screens/labels/sprite_library.py, ex-SPRITE_LIBRARY, renommé pour distinguer les deux). screens.SPRITE_LIBRARY reste le catalogue FUSIONNÉ (utilisé par resolve_personnage_animations pour la résolution runtime, sans filtrage par rôle — voir le constat d'exploration : le payload de jeu et /jouer/<slug> ne vérifient déjà aucun rôle nulle part). - screens/labels/sprite_gallery.py (nouveau) : sprite_gallery_families() groupe la galerie par famille — un animal n'apparaît qu'une fois (sa variante "de base"), ses 15 couleurs se choisissent depuis le panneau de propriétés (render_variant_gallery, templates/screen_edit.html), répondant à la suggestion de l'utilisateur plutôt que d'encombrer la galerie d'ajout de 210 tuiles quasi identiques. - routes/screens/screen_edit.py, routes/scenes/scene_edit_view.py : la galerie passée au template est filtrée par rôle (PUBLIC_SPRITE_LIBRARY pour un compte "user", SPRITE_LIBRARY complet pour un admin) — même idiome que core/auth_guard.py. - core/sprite_gate.py (nouveau) + 4 routes d'écriture (element_add, element_set_personnage_data, scene_object_add, scene_object_personnage_data) : ferme la brèche d'un POST direct qui contournerait la galerie filtrée (403 si un compte non-admin tente d'assigner un personnage animal). - tests/conftest.py : nouvelles fixtures user_client/user_game (compte "user" non-admin avec un projet assigné) pour tester le filtrage par rôle de bout en bout. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 21:49:05 +02:00
williamandClaude Sonnet 5	43abfc9b93	Fix éditeur de scène 2D : décalage visuel des objets + crash Timeline ... Deux bugs remontés en test manuel sur l'éditeur de scène (Phase A, commit f0070fa) : 1. Décalage visuel à l'ajout d'un objet de scène (personnage/décor) : render_scene_object.py positionne son <img> en absolu (left/top/ width/height en px), pensé pour être un enfant DIRECT de .playScreen.playScene en mode jouable. Dans scene_edit.html, la même balise est nichée dans .canvasElementInner, lui-même déjà positionné par .canvasElement — l'image se repositionnait donc EN PLUS depuis #canvas (son ancêtre positionné le plus proche), en double du décalage déjà appliqué par le conteneur. Corrigé par une règle CSS scoped à l'éditeur (.canvasElementInner > img) qui neutralise le positionnement propre de l'image et la fait simplement remplir son conteneur. 2. "FOREIGN KEY constraint failed" à l'ajout d'un clip de Timeline sur un objet de scène : _animation_clips.element_id portait une VRAIE contrainte FK vers _screen_elements depuis la création de la table. animation-timeline.js est réutilisé TEL QUEL entre les deux éditeurs (voir le plan "Fondations d'une plateforme multi-éditeurs") et n'opère aucune distinction — pour un jeu jeu_2d, element_id désigne en réalité un id de _scene_objects, absent de _screen_elements, d'où l'échec de l'INSERT sous PRAGMA foreign_keys=ON. ensure_animation_schema reconstruit maintenant la table (une fois, migration automatique à la volée comme le reste du schéma) sans cette contrainte FK — même patron que trigger_element_id/cond_element_a dans ensure_flow_schema.py. Comme la suppression en cascade reposait jusqu'ici sur cette FK, un nettoyage manuel des clips a été ajouté à la suppression d'un élément (delete_element.py) et d'un objet de scène (delete_scene_object.py). Nouveaux tests (tests/test_scene_edit_view.py, +4 cas) : ajout d'un clip de Timeline sur un objet de scène via la route, nettoyage des clips à la suppression d'un objet de scène et d'un élément DOM. Suite complète : 312 tests passent (aucune régression). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 10:22:58 +02:00
williamandClaude Sonnet 5	f0070faced	Phase A (2/2) : éditeur de scène 2D — route, template, runtime jouable ... Deuxième et dernier commit de la Phase A du plan "Fondations d'une plateforme multi-éditeurs" (le premier, efa7d1d, posait le schéma et le CRUD des objets de scène). Ce commit branche l'éditeur et le mode jouable sur ces fondations, en réutilisant TEL QUEL tout ce qui est déjà générique côté moteur de logique. Éditeur (routes/scenes/, templates/scene_edit.html, static/js/scenes/scene-editor.js) : - routes/screens/screen_edit.py délègue à render_scene_edit() dès que game_type == "jeu_2d" — même endpoint Flask "screen_edit" pour les deux éditeurs, aucune route dupliquée. - Nouveau template scene_edit.html : canevas à taille FIXE en pixels (scene_width/scene_height) avec glisser-déposer/redimensionnement en pixels (scene-editor.js, mirror pixel de tree-panels.js), galerie personnages/décors. Les onglets "Blocs de logique"/"Timeline d'animation"/"Événements" réutilisent tels quels flow-editor.js, tabs-and-blocks.js et animation-timeline.js. - flow-editor.js : nouveau flag FLOW_TARGETS_OBJECTS (false par défaut, true dans scene_edit.html) qui fait écrire submitNodeForm() vers trigger_object_id/target_object_id au lieu de trigger_element_id/ target_element_id, plus une branche "Modifier un objet de scène" (position px, visibilité, orientation) et des gardes null partout (le DOM de scene_edit.html n'a pas tous les champs de l'éditeur document). - blocks_view.py étend l'ensemble d'ids d'éléments concernés par un bloc pour inclure aussi trigger_object_id/target_object_id. Runtime jouable (templates/play.html, static/js/play/actions.js, screens/payload/full_game_payload.py) : - full_game_payload() construit les écrans d'un jeu jeu_2d à partir de _scene_objects (render_scene_object) au lieu de _screen_elements, et récupère les animations de personnage sur les objets de scène. - play.html : #playFrame occupe tout le viewport pour une scène jeu_2d (pas de ratio fluide) ; la scène se centre via .playScreen.playScene, qui réutilise tel quel showScreen() (déjà indexé par id d'écran, pas par forme DOM) — aucun fichier "scenes.js" séparé n'a été nécessaire. - actions.js : jouer_animation_sprite retombe sur target_object_id si target_element_id est absent ; nouvelle action modifier_objet_scene avec applyObjectProperty() (positions en px, contrairement aux % de applyElementProperty()). Un bug de gabarit a été découvert et corrigé pendant la vérification : le commentaire CSS de play.html contenait littéralement "{% for %}" comme texte français, que Jinja interprétait comme une vraie balise et faisait planter le rendu — reformulé. render_scene_object() n'était en outre jamais appelé par la vue de l'éditeur (les objets de scène s'affichaient sans image) — scene_edit_view.py attache maintenant rendered_html à chaque objet avant de les passer au template. Nouveaux tests (tests/test_scene_edit_view.py, 10 cas) : dispatch document vs jeu_2d, rendu d'un personnage sélectionné, CRUD géométrie/ suppression d'objet, nœuds de flow ciblant un objet de scène (action et condition de collision), payload et page /play pour un jeu jeu_2d, présence des nouveaux helpers JS. Suite complète : 309 tests passent (299 existants + 10 nouveaux, aucune régression). node --check et node --test (13 tests JS) passent également. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 10:05:40 +02:00