from typing import Any import db from ..animations.list_animation_clips import list_animation_clips from ..flow.list_flow_edges import list_flow_edges from ..flow.list_flow_nodes import list_flow_nodes from ..rendering.collision_rules import resolve_collision_rules from ..rendering.collision_settings import resolve_collision_settings from ..rendering.dialogue_box_style import resolve_dialogue_box_style from ..rendering.personnage_commands import resolve_personnage_commands from ..rendering.personnage_data import resolve_personnage_animations from ..rendering.personnage_role import resolve_personnage_role from ..rendering.quiz_box_config import resolve_quiz_box_config from ..rendering.screen_triggers import resolve_screen_triggers from ..rendering.trigger_graph import list_completable_dialogue_ids from ..scenes.list_scene_objects import list_scene_objects from ..scenes.render_scene_object import render_scene_object from ..screens_repo.list_screens import list_screens def full_game_payload(slug: str, player_id: str = db.PLAYER_SHARED) -> dict[str, Any]: """Toutes les données nécessaires au runtime JS de la page de jeu jouable (/game//play, ou le paquet Web/SCORM exporté — voir publish/build_scorm_package.py) : chaque écran avec ses éléments (HTML déjà généré, y compris les Répéteurs de données, lus en direct), le graphe de logique (nœuds + fils) de chaque écran, et un instantané des données du jeu (avec le type de chaque champ, nécessaire pour évaluer une condition correctement) — un seul aller-retour serveur, ensuite tout se joue côté client (aucune navigation ne recharge la page, sauf pour appliquer une action "modifier une donnée", qui doit passer par le serveur). player_id (état par joueur, Phase 1) : toujours PLAYER_SHARED aujourd'hui (une seule partie partagée, pour la conception comme pour un paquet exporté) — le paramètre reste générique pour tout objet/ variable per_player (voir db/global_vars/, db/rows/), qui renvoie alors la valeur propre à CE joueur.""" # Fusion des moteurs (voir screens/screens_repo/ensure_schema.py) : un # écran "jeu_2d" construit "elements" depuis _scene_objects (objets de # scène en pixels) plutôt que _screen_elements (DOM en %) — décidé # ÉCRAN PAR ÉCRAN (s["kind"]), un même jeu peut mélanger les deux ; # tout le reste de cette fonction (flows/animations/variables/data) # est déjà générique et inchangé pour les deux types d'écran. screens_ = list_screens(slug) payload_screens = [] flows = {} animations = {} for s in screens_: objects = list_scene_objects(slug, s["id"]) for o in objects: o["rendered_html"] = render_scene_object(o) # Déplacement/animation automatiques (voir # static/js/play/personnage-controller.js) : chaque # personnage porte ses touches et son rôle déjà résolus # (défauts comblés) pour que le runtime client n'ait # aucune logique de repli à dupliquer — seul un # personnage "joueur" est déplacé/suivi par la caméra. if o["kind"] == "personnage": o["personnage_commandes"] = resolve_personnage_commands(o) o["personnage_role"] = resolve_personnage_role(o) if o["kind"] in ("dialogue_box", "quiz_box", "score_widget"): # Widgets d'interface (voir "🖥️ Interface", # screens/rendering/dialogue_box_style.py) : ni # collision, ni cible/source de règle — juste leur # style, lu par static/js/play/dialogue-box-controller.js. o["dialogue_box_style"] = resolve_dialogue_box_style(o) if o["kind"] == "quiz_box": # Plein écran/minuteur/modèle (voir screens/rendering/ # quiz_box_config.py) — même convention que # dialogue_box_style ci-dessus (cohérence de contrat), # même si le JS runtime lit en pratique les data-* # déjà posés sur rendered_html. o["quiz_config"] = resolve_quiz_box_config(o) continue # Boîte de collision (voir static/js/play/conditions.js:: # elementsOverlap) : posée sur TOUT objet de scène, pas # seulement "personnage" — un décor/fond peut aussi servir # d'obstacle. o["collision"] = resolve_collision_settings(o) # Règles "à la collision/dans un périmètre -> action" (voir # "🧩 Collision", templates/scene_edit.html, et # static/js/play/collision-rules-controller.js pour leur # exécution) — jamais sur "fond" (jamais une cible), ni sur # le personnage "joueur" lui-même (ce sont TOUJOURS les # AUTRES objets qui réagissent à SA présence, jamais # l'inverse). if o["kind"] != "fond" and not (o["kind"] == "personnage" and o.get("personnage_role") == "joueur"): o["collision_rules"] = resolve_collision_rules(o) # Déclencheurs D'ÉCRAN (voir "Déclencheurs de l'écran", sans objet # requis — narration/cinématique dès l'affichage) : résolus ici # comme collision_rules ci-dessus, sous un nom distinct de la # colonne brute _screen_triggers (laissée telle quelle par ailleurs # dans `s`, comme le reste des colonnes _screens). s["screen_triggers"] = resolve_screen_triggers(s) # "La notion de caméra disparaît" quand un quiz plein écran existe # sur cet écran (demande explicite) — pas seulement le widget lui- # même : ".playScreen.playScene" (templates/play.html), dont la # taille EST la "caméra" (scene_width/scene_height) et qui reste # centré via un `transform`, casse `position:fixed` pour tout # descendant (voir static/js/play/dialogue-box-controller.js:: # forgeEscapeCameraForFullscreen). Exposé ici pour que play.html # rende directement CET écran en plein viewport, sans transform ni # taille caméra — le réglage "Caméra (px)" ne s'applique alors plus # du tout tant que ce quiz reste plein écran. s["any_quiz_box_fullscreen"] = any( o["kind"] == "quiz_box" and o.get("quiz_config", {}).get("fullscreen") for o in objects ) payload_screens.append({**s, "elements": objects}) # Le graphe de logique et les animations sont, eux, lus pour TOUS les # écrans. Animations d'un personnage (Phase 8) — résolues ici, à CHAQUE # affichage de la page de jeu (donc toujours à partir du personnage # Forge ACTUELLEMENT assigné), plutôt que figées dans le nœud de flow/ # le clip de Timeline au moment où le créateur les a configurés : sans # ça, changer le personnage Forge d'un élément dans l'éditeur laissait # ses animations déjà posées dans la logique/la Timeline continuer à # jouer les frames de l'ANCIEN personnage indéfiniment (bug signalé — # voir runActionNode()/applyAnimationClip() qui font cette résolution # à l'exécution à partir de gameData.personnage_animations plutôt que # depuis un data_value/custom_keyframes qui contiendrait des frames # déjà résolues). personnage_animations = {} for s in screens_: flows[str(s["id"])] = { "nodes": list_flow_nodes(slug, s["id"]), "edges": list_flow_edges(slug, s["id"]), } animations[str(s["id"])] = list_animation_clips(slug, s["id"]) for o in list_scene_objects(slug, s["id"]): if o["kind"] == "personnage": personnage_animations[str(o["id"])] = resolve_personnage_animations(o) definitions = db.list_definitions(slug) data = {} fields_meta = {} for d in definitions: full = db.get_definition(slug, d["id"]) full = db.assert_not_none( full, "d['id'] vient de list_definitions(slug), donc get_definition ne peut pas renvoyer None ici" ) rows = db.list_rows(slug, full, player_id) # Un champ "relation" vit dans une colonne SQL "_id", jamais # sous son nom "propre" (voir _field_column dans # filter_repeater_rows.py, la même règle) — sans ce cas particulier, # un champ relation lisait toujours une colonne inexistante et # renvoyait systématiquement None ici. Inoffensif EN LIGNE (cette # snapshot n'est jamais utilisée pour un filtre/une Donnée liée : ces # derniers requêtent la base fraîche via filter_repeater_rows.py) — # mais fatal pour le port hors ligne (export Web/SCORM), qui n'a # QUE cette snapshot, aucune base à requêter (bug signalé par un # utilisateur : un filtre sur un champ relation ne matchait jamais # rien une fois exporté, laissant "{{champ}}" affiché tel quel). cols = {} for f in full["fields"]: col = db.slugify(f["name"]).replace("-", "_") if f["type"] == "relation": col += "_id" cols[f["name"]] = col data[str(d["id"])] = [{**{fname: r.get(col) for fname, col in cols.items()}, "id": r["id"]} for r in rows] # min_value/max_value (2.2 — bornage automatique, voir # apply_data_action.py) : nécessaires ici pour que le port # client-side de l'export Web/SCORM (static/js/play/offline/, # voir le plan "port complet du runtime jouable côté navigateur") # puisse reproduire le même bornage sans aller-retour serveur — # inoffensif pour le runtime en ligne, qui ignore ces deux clés. fields_meta[str(d["id"])] = [ {"name": f["name"], "type": f["type"], "min_value": f.get("min_value"), "max_value": f.get("max_value")} for f in full["fields"] ] # Instantané des variables globales, pour qu'un nœud Condition puisse en # tester une côté CLIENT (evaluateConditionClause, templates/play.html) — # {{$var}} (Répéteur/Condition de visibilité), lui, reste résolu côté # SERVEUR au rendu (filter_repeater_rows.py) et n'a jamais eu besoin de # ça. refreshRuntimeData() récupère un payload entier (donc des # variables à jour) après toute action qui en modifie une. variables = { v["name"]: {"value": v["value"], "type": v["type"]} for v in db.list_global_variables_for_player(slug, player_id) } # id de définition -> nom de l'objet (voir filter_repeater_rows.py côté # serveur, static/js/play/offline/filter-repeater-rows.js côté port # hors ligne) : nécessaire pour résoudre une référence "{{Objet.champ}}" # (Répéteur/Donnée liée/Condition de visibilité) — data/fields_meta # ci-dessus sont déjà indexés par id, jamais par nom. definition_names = {str(d["id"]): d["name"] for d in definitions} # Déclencheurs "terminés" (voir screens/rendering/collision_rules.py:: # "dialogue".mark_completed) : GAME-WIDE, la liste des id de dialogue # que le créateur a marqués comme concluant la partie — nécessaire à # static/js/play/dialogue-box-controller.js:: # forgeSyncAllDialoguesCompletionToScorm pour savoir quand TOUS ont # été joués, sans plus aucune notion de quête. completable_dialogue_ids = list_completable_dialogue_ids(slug) return { "screens": payload_screens, "flows": flows, "animations": animations, "data": data, "fields_meta": fields_meta, "variables": variables, "personnage_animations": personnage_animations, "definition_names": definition_names, "completable_dialogue_ids": completable_dialogue_ids, }