Files
williamandClaude Sonnet 5 9776fbc057
Build and deploy / test-python (push) Successful in 7m27s
Build and deploy / test-js (push) Successful in 1m16s
Build and deploy / build-and-push (push) Skipped
Build and deploy / deploy (push) Skipped
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

45 lines
2.3 KiB
Python

# ---------- Palette de logique réduite pour l'éditeur de scène 2D ----------
#
# Réutilise le MÊME moteur de flow (_flow_nodes/_flow_edges, flow-engine.js,
# flow-editor.js, tabs-and-blocks.js) que l'éditeur document — seule la
# palette de nœuds proposée diffère (voir décision d'architecture du plan
# "Fondations d'une plateforme multi-éditeurs"). Sous-ensembles directs de
# screens/flow/constants.py et screens/labels/action_type_labels.py : pas
# de notion de clic/soumission/survol DOM (pas d'élément HTML dans une
# scène), tout le reste est déjà générique et fonctionne tel quel sur un
# objet de scène.
from ..flow.constants import TRIGGER_EVENTS as _ALL_TRIGGER_EVENTS
_SCENE_TRIGGER_KEYS = {"affichage", "evenement", "clavier", "minuteur", "touche_maintenue", "touche_relachee"}
TRIGGER_EVENTS_2D = [(k, label) for k, label in _ALL_TRIGGER_EVENTS if k in _SCENE_TRIGGER_KEYS]
ACTION_TYPE_LABELS_2D = {
"aller_a": "Aller à un écran précis",
"ecran_suivant": "Afficher l'écran suivant",
"ecran_precedent": "Afficher l'écran précédent",
"modifier_objet_scene": "Modifier un objet de scène",
"modifier_variable": "Modifier une variable globale",
"modifier_donnee": "Modifier une donnée d'un objet",
"modifier_score": "Modifier le score",
"definir_statut_partie": "Définir le statut de la partie",
"jouer_animation_sprite": "Jouer une animation de sprites",
"jouer_son": "Jouer un son",
"declencher_evenement": "Déclencher un événement",
"attendre": "Attendre quelques secondes avant de continuer",
"rien": "Ne rien faire",
}
# Sous-palette de "modifier_objet_scene" — équivalent scène de
# ELEMENT_ACTION_PROPERTIES (screens/labels/element_action_properties.py),
# mais en pixels absolus/relatifs (pas des %) : une scène a une taille
# FIXE (voir scene_width/scene_height, ensure_schema.py), donc les
# déplacements s'expriment naturellement en pixels.
OBJECT_ACTION_PROPERTIES = [
("visibilite", "Visibilité"),
("pos_x", "Position horizontale en pixels (absolue)"),
("pos_y", "Position verticale en pixels (absolue)"),
("pos_x_relatif", "Déplacer horizontalement de... px (relatif)"),
("pos_y_relatif", "Déplacer verticalement de... px (relatif)"),
("orientation", "Orientation — sens du personnage"),
]