williamandClaude Sonnet 5
ee270d0286
Nouvel onglet "🧩 Collision" dans l'éditeur de scène 2D : chaque objet (hors joueur et fond) peut porter des règles "à la collision" ou "dans un périmètre (px)" déclenchant une action (quête, attaque, événement, ou interagir - qui affiche "Appuie sur [touche]" puis exécute une sous-action à l'appui, un seul niveau d'imbrication). Backend (sanitisation, route de persistance, exposition dans full_game_payload) + assistant modal en cartes empilées côté client. Ajoute le moteur d'exécution runtime (collision-rules-controller.js) : détecte l'entrée en collision/périmètre avec le joueur à chaque tick, déclenche l'action une seule fois par entrée, pur JS client sans appel serveur (fonctionne à l'identique en ligne et en export SCORM). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
207 lines
12 KiB
Python
207 lines
12 KiB
Python
import db
|
|
|
|
from ..screens_repo.list_screens import list_screens
|
|
from ..elements.list_elements import list_elements
|
|
from ..flow.list_flow_nodes import list_flow_nodes
|
|
from ..flow.list_flow_edges import list_flow_edges
|
|
from ..animations.list_animation_clips import list_animation_clips
|
|
from ..element_types.list_element_types import list_element_types
|
|
from ..element_types.load_template_tree import _load_template_tree
|
|
from ..rendering.personnage_data import resolve_personnage_animations
|
|
from ..rendering.personnage_commands import resolve_personnage_commands
|
|
from ..rendering.personnage_role import resolve_personnage_role
|
|
from ..rendering.collision_settings import resolve_collision_settings
|
|
from ..rendering.collision_rules import resolve_collision_rules
|
|
from ..scenes.list_scene_objects import list_scene_objects
|
|
from ..scenes.render_scene_object import render_scene_object
|
|
|
|
|
|
def full_game_payload(slug, player_id=db.PLAYER_SHARED):
|
|
"""Toutes les données nécessaires au runtime JS de la page de jeu jouable
|
|
(/game/<slug>/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_:
|
|
if s["kind"] == "jeu_2d":
|
|
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)
|
|
# 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)
|
|
payload_screens.append({**s, "elements": objects})
|
|
else:
|
|
elements = list_elements(slug, s["id"], enforce_visibility=True, player_id=player_id)
|
|
payload_screens.append({**s, "elements": elements})
|
|
|
|
# Le graphe de logique et les animations sont, eux, lus pour TOUS les
|
|
# écrans, écrans-modèles compris (include_templates=True) — pas
|
|
# seulement les "vrais" écrans ci-dessus. Un élément de jeu réutilisable
|
|
# (ex. "mail content") peut avoir son propre déclencheur/sa propre
|
|
# animation posée dans l'éditeur de SON écran-modèle (voir
|
|
# screen_edit.html) : sans ses entrées ici, gameData.flows/
|
|
# gameData.animations n'auraient jamais contenu cet écran-modèle côté
|
|
# client, et findTriggerNode()/collectAnimationClips() (templates/
|
|
# play.html) — pourtant déjà écrits pour les chercher — n'auraient
|
|
# jamais rien trouvé. On ne les ajoute PAS à payload_screens : un
|
|
# écran-modèle ne doit jamais être rendu comme un vrai <div
|
|
# class="playScreen"> (il n'est jamais affiché tel quel, seulement
|
|
# rechargé en direct à l'intérieur d'un élément qui l'utilise).
|
|
# 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). include_templates=True : un personnage peut vivre
|
|
# dans un écran-modèle d'élément de jeu réutilisable, comme les flows/
|
|
# animations ci-dessous.
|
|
personnage_animations = {}
|
|
for s in list_screens(slug, include_templates=True):
|
|
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"])
|
|
if s["kind"] == "jeu_2d":
|
|
for o in list_scene_objects(slug, s["id"]):
|
|
if o["kind"] == "personnage":
|
|
personnage_animations[str(o["id"])] = resolve_personnage_animations(o)
|
|
else:
|
|
for el in list_elements(slug, s["id"]):
|
|
if el.get("widget") == "personnage":
|
|
personnage_animations[str(el["id"])] = resolve_personnage_animations(el)
|
|
|
|
definitions = db.list_definitions(slug)
|
|
data = {}
|
|
fields_meta = {}
|
|
for d in definitions:
|
|
full = db.get_definition(slug, d["id"])
|
|
rows = db.list_rows(slug, full, player_id)
|
|
# Un champ "relation" vit dans une colonne SQL "<champ>_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"]
|
|
]
|
|
|
|
# element_type_id -> id de son écran-modèle : nécessaire côté client (voir
|
|
# collectAnimationClips() dans play.html) pour savoir, quand un élément de
|
|
# jeu réutilisable (ex. "mail content") est posé sur un écran, quels
|
|
# autres clips d'animation (ceux de SON PROPRE écran-modèle) doivent
|
|
# aussi être joués à l'affichage de cet écran — sans quoi une animation
|
|
# posée directement dans l'éditeur du modèle ne se jouait jamais quand le
|
|
# modèle est utilisé ailleurs.
|
|
element_types = {str(t["id"]): t["template_screen_id"] for t in list_element_types(slug)}
|
|
|
|
# Arbre complet (éléments + descendants) de l'écran-modèle de chaque
|
|
# élément de jeu réutilisable — voir screens/element_types/
|
|
# load_template_tree.py, appelée aujourd'hui à CHAQUE rendu (aperçu
|
|
# créateur ET jeu publié en ligne). Nécessaire ici pour que le port
|
|
# client-side de l'export Web/SCORM (static/js/play/offline/,
|
|
# rendu d'un exemplaire d'élément de jeu OU d'un modèle de ligne de
|
|
# Répéteur) puisse le rejouer sans base de données — inoffensif pour
|
|
# le runtime en ligne, qui l'ignore.
|
|
element_type_templates = {}
|
|
for type_id_str, template_screen_id in element_types.items():
|
|
if template_screen_id:
|
|
tree = _load_template_tree(slug, int(type_id_str))
|
|
if tree:
|
|
element_type_templates[type_id_str] = tree
|
|
|
|
# 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}
|
|
|
|
return {
|
|
"screens": payload_screens, "flows": flows, "animations": animations,
|
|
"element_types": element_types, "data": data, "fields_meta": fields_meta,
|
|
"variables": variables, "personnage_animations": personnage_animations,
|
|
"definition_names": definition_names, "element_type_templates": element_type_templates,
|
|
}
|