Files
Forge-Engine/game_engine/flow/constants.py
T
williamandClaude Sonnet 5 b2e933f322
Build and deploy / test-python (push) Successful in 11m12s
Build and deploy / test-js (push) Successful in 53s
Build and deploy / lint-python (push) Successful in 3m56s
Build and deploy / lint-js (push) Successful in 3m1s
Build and deploy / build-and-push (push) Skipped
Build and deploy / deploy (push) Skipped
Build and deploy / sonarqube (push) Failing after 3m58s
Reorganisation game/document : renommage screens->game_engine + sous-dossiers game/ dans routes, scripts, static, templates, tests
Prepare la scission a venir entre l'editeur Jeu 2D et le futur editeur
Support de formation (voir docs/plan/PLAN.md), sans toucher a
l'architecture en couches existante :

- screens/ renomme en game_engine/ (nom clair pour le moteur du jeu 2D,
  avant l'arrivee d'un second "moteur" cote document) : ~85 imports
  corriges, contrat import-linter mis a jour, meme forme de couches.
- routes/, scripts/, static/, templates/, tests/ : tout ce qui est
  propre au jeu 2D deplace dans un sous-dossier game/ de chacun
  (routes/game/, static/game/, templates/game/, tests/game/,
  scripts/game/) ; ce qui est partage par le site (auth, onboarding,
  dashboard, uploads, db/) reste a la racine de chaque dossier. Un
  sous-dossier document/ (vide) cree dans chacun pour le futur chantier.
- styles/ volontairement inchange : les 3 fichiers sources sont
  concatenes en un seul static/style.css charge par tout le site,
  scinder leur CONTENU (editeur vs partage) serait un refactor CSS
  distinct, pas un deplacement mecanique.
- Chaine d'export SCORM (publish/build_scorm_package.py) mise a jour en
  profondeur : copie des assets, URLs d'icones relatives a
  static/style.css (qui ne bouge pas), manifeste, wrapper SCORM.
- Deux regressions d'un sweep de renommage anterieur corrigees au passage
  (screens.js/screens/scene-objects incorrectement convertis en
  game_engine.js/game_engine/scene-objects dans des commentaires).
- Effet de bord Windows decouvert et corrige : git mv + Path.write_text
  convertissent des fichiers en CRLF (core.autocrlf=true) - ~189 fichiers
  normalises en LF.
- .eslintrc.json/package.json : uniquement les chemins de glob mis a jour
  (static/game/js/...) ; la preparation eslint-plugin-unicorn du lot 7
  reste volontairement non committee (package-lock.json restaure a la
  version precedente).

Verifications : ruff, mypy --strict (391 fichiers), vulture, bandit,
lint-imports tous verts ; 591/591 tests Python, 276/276 tests JS ;
demarrage serveur + requetes HTTP manuelles confirmant que les assets
deplaces repondent en 200 au nouvel emplacement et 404 a l'ancien.

SKIP=djlint : backlog H021 (styles inline) deja documente comme dette
assumee dans CODE_QUALITY.md section 6, aucun template touche par ce
commit au-dela d'un deplacement de fichier.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-19 12:27:53 +02:00

168 lines
8.8 KiB
Python

# ---------- Logique visuelle (éditeur de flow à nœuds) ----------
#
# Remplace l'ancien système "Actions" attaché à chaque élément : toute la
# logique d'une scène (déclencheurs, conditions, actions) vit maintenant dans
# un graphe de nœuds propre à l'écran, visible dans le panneau "Logique de
# la scène" de l'éditeur (voir screen_edit.html) — un nœud Déclencheur
# ("Au clic sur X") relié à des nœuds Condition (deux sorties Vrai/Faux) et
# Action (les mêmes effets qu'avant : changer d'écran, modifier un élément,
# modifier une donnée). L'ancien système _actions reste en base pour ne rien
# casser sur les jeux déjà créés, mais n'est plus exposé dans l'éditeur ni
# utilisé par le mode jouable.
# Valeur sentinelle pour cond_row_id/target_row_id (nœud Condition/action
# "Modifier une donnée") : "la ligne de Répéteur sur laquelle on vient de
# cliquer", résolue au moment de l'exécution (window.lastClickedRowId côté
# client — voir play.html) plutôt que figée à la création du nœud. Utile
# quand le déclencheur est "Au clic" sur un Répéteur : la ligne cliquée
# n'est jamais connue à l'avance (chaque ligne du Répéteur exécute le MÊME
# graphe), donc choisir une ligne précise dans l'éditeur n'a pas de sens
# ici — -1 ne collisionne jamais avec un vrai id de ligne (toujours >= 1,
# AUTOINCREMENT SQLite).
CLICKED_ROW_ID = -1
# Phase 4 (moteur) — "la ligne qu'un nœud Action 'Ajouter une ligne'
# vient de créer" : un id de ligne n'existe qu'APRÈS l'insertion, donc
# jamais connu à la création du nœud, exactement comme CLICKED_ROW_ID
# ci-dessus. Résolue au moment de l'exécution
# (window.lastInsertedRowId, voir static/game/js/play/actions.js) — permet
# d'enchaîner "Ajouter une ligne" -> "Modifier une donnée"/condition
# ciblant cette même ligne fraîchement créée, sans avoir à inventer un
# nouveau format de payload multi-champs pour le nœud "Ajouter une
# ligne" lui-même (qui ne crée qu'une ligne VIDE).
LAST_INSERTED_ROW_ID = -3
TRIGGER_EVENTS = [
("clic", "Au clic"),
("soumission", "À la soumission"),
# 3.1 (Confort) — interactions au survol, reconstruit comme déclencheur
# de flow (au lieu d'un réglage statique dans le panneau de propriétés,
# voir universal_controls.py) : "survol" et "fin_survol" sont deux
# déclencheurs distincts et explicites (comme "Au clic"), sans effet
# implicite — un créateur qui veut qu'un texte affiché au survol
# disparaisse ensuite doit poser l'action inverse sur "Fin du survol"
# lui-même, plutôt que de compter sur un retour automatique.
("survol", "Au survol"),
("fin_survol", "Fin du survol"),
# Pas de "trigger_element_id" pour celui-ci : il concerne l'ÉCRAN entier,
# pas un élément précis (voir 1.2 dans claude/forge-engine-lacunes-boitemail.md
# côté projet Forge — "affichage piloté par la donnée"). Se déclenche
# côté jouable à chaque fois que l'écran est montré (premier affichage,
# retour en arrière, changement d'écran...) ET après toute donnée
# modifiée pendant qu'on est déjà sur cet écran — ce qui permet de
# cacher/montrer un élément selon l'état de la partie SANS qu'un clic
# explicite soit nécessaire pour le réévaluer.
("affichage", "À l'affichage de l'écran"),
# Écoute un événement personnalisé (voir game_engine/custom_events/),
# déclenché depuis N'IMPORTE QUEL autre graphe (une autre scène, un
# autre modèle) via l'action "declencher_evenement" — ni élément ni
# écran précis : trigger_custom_event_id (quel événement) est le seul
# réglage propre à ce nœud, retrouvé par un scan global de
# gameData.flows côté client (voir dispatchGameEvent() dans
# templates/game/play.html), au même titre que findTriggerNode().
("evenement", "Sur un événement personnalisé"),
# Phase 3 (moteur) — ni élément ni écran précis : trigger_key (quelle
# touche, ev.key du clavier) est le seul réglage propre à ce nœud,
# écouté UNE SEULE FOIS pour tout le jeu (voir bindKeyboardTriggers()
# dans static/game/js/play/triggers.js), même patron de scan global que
# "evenement" ci-dessus.
("clavier", "À l'appui sur une touche"),
# Mouvement continu (jeu 2D) — répond au manque signalé par
# l'utilisateur : "clavier" ci-dessus ne se déclenche qu'UNE FOIS par
# appui (keydown), insuffisant pour "maintenir une touche fait avancer
# le personnage en continu". "touche_maintenue" réutilise trigger_key
# et se déclenche À INTERVALLE RÉGULIER tant que cette touche reste
# enfoncée (voir runScreenHeldKeyTriggers() dans static/game/js/play/
# triggers.js — même patron PAR ÉCRAN que "minuteur" ci-dessous, arrêté
# dès qu'on quitte l'écran ou relâche la touche), typiquement combiné à
# une action "Modifier un objet de scène → position relative" (avance
# le personnage à chaque tick) et "Jouer une animation" (marche/course
# — voir runSpriteAnimation() dans actions.js, qui ne redémarre plus
# une animation déjà en cours plutôt que de la faire repartir de zéro à
# chaque tick). "touche_relachee" (keyup, un seul déclenchement, scan
# global comme "clavier") permet de revenir à l'animation "idle".
("touche_maintenue", "Tant qu'une touche est maintenue"),
("touche_relachee", "Au relâchement d'une touche"),
# Contrairement aux autres déclencheurs (réagissent à quelque chose),
# celui-ci fait AVANCER le jeu tout seul, à intervalle régulier —
# trigger_interval_ms (en millisecondes) est son seul réglage. Géré
# PAR ÉCRAN (voir showScreen() dans static/game/js/play/screens.js) : ne
# tourne que tant que l'écran qui le porte est affiché, jamais en
# arrière-plan sur un écran quitté.
("minuteur", "Toutes les X millisecondes"),
]
CONDITION_OPERATORS = [
("egal", "est égal à"),
("different", "est différent de"),
("superieur", "est supérieur à"),
("inferieur", "est inférieur à"),
("superieur_egal", "est supérieur ou égal à"),
("inferieur_egal", "est inférieur ou égal à"),
]
CONDITION_OPERATOR_LABELS = dict(CONDITION_OPERATORS)
FLOW_NODE_FIELDS = {
"trigger_element_id",
"trigger_event",
"cond_definition_id",
"cond_row_id",
"cond_field",
"cond_field_type",
"cond_operator",
"cond_value",
# 2.4 — conditions combinées (ET/OU) : cond_clauses est une liste JSON de
# clauses supplémentaires (en plus de la clause "historique" ci-dessus,
# qui reste la première clause) + cond_combinator ('et'/'ou') pour savoir
# comment les combiner. Absents => comportement legacy (une seule clause).
"cond_clauses",
"cond_combinator",
# Condition sur une VARIABLE GLOBALE plutôt qu'un champ d'objet — voir
# ensure_flow_schema.py pour le détail des 3 clés (cond_source vaut
# "objet" ou "variable" ; absent => "objet", comportement historique).
"cond_source",
"cond_variable",
"cond_variable_chemin",
"action_type",
"target_screen_id",
"target_element_id",
"element_property",
"element_value",
"target_definition_id",
"target_row_id",
"target_field",
"data_operation",
"data_value",
"target_variable",
# Événements personnalisés (voir game_engine/custom_events/) : quel
# événement un nœud Déclencheur écoute (trigger_event="evenement") ou
# un nœud Action déclenche (action_type="declencher_evenement") — un
# événement est une pure NOTIFICATION, sans paramètre : "déclencher"
# ne fait que signaler, jamais choisir un élément. C'est à l'ÉCOUTEUR
# (déclencheur → condition → action) de décider quoi faire ensuite,
# avec ses propres réglages habituels (target_element_id normal, pas
# de mécanisme dynamique dédié).
"trigger_custom_event_id",
"target_custom_event_id",
# Blocs de logique (voir game_engine/flow/blocks/) : à quel bloc ce nœud
# appartient. Aucun `update_flow_node` n'existe (éditer un nœud le
# recrée puis supprime l'ancien) — le client doit donc renvoyer
# block_id à chaque (ré)création, pas juste le poser une fois.
"block_id",
# Phase 3 — déclencheur clavier ("clavier") et minuteur récurrent
# ("minuteur"), voir TRIGGER_EVENTS ci-dessus.
"trigger_key",
"trigger_interval_ms",
# Phase 5 — condition de collision (cond_source="collision", aux
# côtés de "objet"/"variable") : les deux éléments dont on compare les
# rectangles — voir evaluateConditionClause() dans
# static/game/js/play/conditions.js.
"cond_element_a",
"cond_element_b",
# Fondations multi-éditeurs — jeux "jeu_2d" : équivalents de
# trigger_element_id/target_element_id pour un objet de scène (voir
# ensure_flow_schema.py).
"trigger_object_id",
"target_object_id",
}