8 Commits

Include renames

Author	SHA1	Message	Date
william	50835a18e2	Supprime le type d'écran "document" et recentre le produit sur le jeu 2D ... Le document de cadrage produit cible des formateurs non techniques créant des serious games/quiz gamifiés — l'éditeur générique "document" (blocs de logique en nœuds, timeline d'animation, définitions d'objets/relations, templates réutilisables) est une complexité hors cible que l'effort d'ingénierie récent avait déjà abandonnée au profit du jeu_2d. - Onboarding : ne garde que le parcours "RPG" (jeu_2d), retire Quiz/Embranchement/Créer mon jeu de A à Z (tous document-only) - Suppression en bloc des modules exclusifs au document : routes/elements, routes/element_types, routes/objects, routes/legacy_actions, screens/elements, screens/element_types, screens/widgets, screens/legacy_actions, le rendu render_element_html.py et son cluster, templates/screen_edit.html, templates/game_dashboard.html, flow-editor.js/tabs-and-blocks.js/animation-timeline.js - Dashboard toujours simplifié (un seul mode possible désormais) - Tests document-only supprimés, tests de logique partagée (flow, événements personnalisés, animations) retargetés sur des écrans jeu_2d - Aucune régression jeu_2d : 299 tests passent Carte d'onboarding retravaillée : argumentaire RH non technique (liste à coche, badge "Compatible LMS"), taille et interaction de retournement ajustées.	2026-09-04 20:56:32 +02:00
williamandClaude Sonnet 5	55c6bb330b	Contrôle direct de la taille de la caméra (Largeur × Hauteur, toujours modifiable) ... Remplace le bouton conditionnel "Agrandir la caméra à la zone visible" (n'apparaissait que si un fond dépassait déjà la scène) par deux champs "Caméra (px)" TOUJOURS visibles, pré-remplis avec scene_width/ scene_height actuels — demande explicite : "l'écran de l'éditeur a une taille fixe, la caméra a la même taille, c'est tout", un réglage direct plutôt qu'une suggestion automatique liée à la taille d'un fond. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 17:28:03 +02:00
williamandClaude Sonnet 5	b9d3c46087	Bouton "📐 Agrandir la caméra à la zone visible" ... Fait de tout le "monde" affiché par l'éditeur (la taille réelle d'un "fond" plus grand que la scène nominale, voir routes/scenes/ scene_edit_view.py::world_width/world_height) la scène/caméra ELLE-MÊME — jusqu'ici scene_width/scene_height n'étaient fixées qu'à la création de l'écran, jamais modifiables ensuite. Le bouton n'apparaît que quand un fond dépasse encore la scène nominale (même condition que le repère "🎥 Champ de la caméra"), affiche la taille cible, recharge la page une fois appliqué. La caméra ne recadre alors plus rien en jeu (monde == scène == viewport, voir personnage-controller.js::forgeUpdateSceneCamera). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 17:07:24 +02:00
williamandClaude Sonnet 5	14ec76dddd	Éditeur : le canevas affiche tout le monde (fond agrandi), pas que la scène ... Suite au fix du glisser figé à (0,0) : le canevas de l'éditeur restait malgré tout limité à la scène nominale (960×540 par ex.) — la partie d'un "fond" plus grand qui dépasse restait invisible/injoignable à la souris. Le canevas affiche désormais tout le "monde" (max de la scène et de l'étendue de chaque "fond", voir routes/scenes/scene_edit_view.py), comme la caméra en jeu le fait déjà (personnage-controller.js). Nouveau repère visuel "🎥 Champ de la caméra" : un cadre en pointillés marquant où s'arrête la scène nominale à l'intérieur de ce monde agrandi (le reste est assombri), pour que l'auteur voie clairement ce que le joueur verra réellement à l'écran une fois le monde plus grand que le viewport. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-03 16:55:09 +02:00
williamandClaude Sonnet 5	d5a59bdbd8	Fusion des deux moteurs : type d'écran par écran, plus par projet ... "document" (écrans %) et "jeu_2d" (scène pixels) devient une propriété PAR ÉCRAN (_screens.kind, migration automatique idempotente dans ensure_schema.py, source = l'ancien game_type au niveau projet) plutôt qu'un choix figé pour tout le jeu — un même projet peut désormais mélanger écrans classiques et scènes 2D librement. - routes/screens/screen_edit.py : dispatch vers l'éditeur de scène selon screen["kind"] (l'écran demandé), plus game["game_type"]. - screens/payload/full_game_payload.py, templates/play.html, static/js/play/screens.js : le rendu jouable (payload, markup, bascule du mode plein-écran #playFrame) décide écran par écran, y compris en cours de partie (changer d'écran ne recharge pas la page). - screens/screens_repo/create_screen.py : nouveau paramètre kind. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-09-02 06:21:13 +02:00
williamandClaude Sonnet 5	727af55a5e	Mouvement continu, limites de scène et priorité d'animation (jeu 2D) ... Répond au manque signalé par l'utilisateur : le déclencheur "clavier" existant (keydown) ne se déclenche qu'UNE FOIS par appui, insuffisant pour "maintenir une touche fait avancer/sauter le personnage en continu". - Deux nouveaux déclencheurs (screens/flow/constants.py, screens/scenes/flow_palette.py) : "Tant qu'une touche est maintenue" (se répète ~20 fois/seconde tant que la touche reste enfoncée, runScreenHeldKeyTriggers() dans triggers.js — même patron PAR ÉCRAN que "minuteur", arrêté au changement d'écran) et "Au relâchement d'une touche" (un seul déclenchement, scan global comme "clavier"). Combinés à l'action existante "Modifier un objet de scène → Déplacer de... px (relatif)", ça permet un vrai déplacement continu. - preventDefault() sur toute touche que le jeu écoute réellement (isGameKey(), triggers.js) : Espace/Flèches font défiler la page par défaut, et Espace réactive en plus le bouton actuellement focus (souvent le bouton "Jouer" qui garde le focus après l'ouverture de l'aperçu) — ça pouvait donner l'impression qu'une touche du jeu ne faisait rien. - Le personnage pouvait sortir du cadre de la scène en se déplaçant : applyObjectProperty()/clampSceneObjectPosition() (static/js/play/actions.js) bornent maintenant toute position (absolue ou relative) à [0, scene_width/height − la taille de l'objet]. - Vitesse d'animation par défaut adaptée au nombre d'images : la valeur fixe (8 i/s) venait d'un formulaire pensé pour les cycles Kenney (8 images) — un cycle CraftPix (walk=30 images) au même 8 i/s prenait ~4 secondes, "très lent". Le choix d'une animation dans la galerie calcule maintenant une vitesse par défaut proportionnelle à son nombre d'images (flow-editor.js, animation-timeline.js). - Priorité d'animation (bug : "je ne peux pas me déplacer et sauter") : un déclencheur de déplacement (touche maintenue) redemande "marche" à chaque tick, écrasant aussitôt une animation ponctuelle ("sauter") démarrée entre-temps avant qu'elle ait pu s'afficher. runSpriteAnimation() (actions.js) laisse maintenant une animation NON BOUCLÉE en cours (même à une seule frame, ex. une pose Kenney figée) aller jusqu'au bout avant qu'une autre demande puisse l'interrompre. Nouveaux tests : static/js/play/__tests__/{actions,triggers}.test.js (idempotence + priorité d'animation, bornage aux limites de la scène, isGameKey) ; tests/test_scene_edit_view.py (persistance d'un nœud "touche_maintenue"). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-31 21:53:49 +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