Première brique du plan "Fondations d'une plateforme multi-éditeurs" —
l'utilisateur veut un éditeur dédié aux jeux 2D/serious games (scène à
coordonnées pixel fixes, objets en couches, collision, personnages
animés), distinct de l'éditeur générique actuel, sans dupliquer ce qui
peut être partagé (comptes, objets de données, moteur de logique de
flow, hébergement/publication).
- db/games/get_game_type.py (nouveau) : "document" (défaut, éditeur
actuel) ou "jeu_2d" (nouveau), stocké dans _meta comme
is_public_played — aucune migration pour les jeux déjà créés
(retombent sur "document"). Choisi obligatoirement à la création
(templates/index.html), jamais modifiable ensuite.
- screens/scenes/ (nouveau sous-module) : table _scene_objects (une
scène = des objets en pixels fixes, pas les % fluides de
_screen_elements — indispensable pour la collision/l'animation),
CRUD complet, rendu HTML. kind="personnage" réutilise TELLE QUELLE la
structure _personnage_data et les fonctions resolve_personnage_* déjà
écrites pour le widget "personnage" de l'éditeur document (Phase 8) —
même bibliothèque Forge, même moteur d'animation, juste une autre
table de stockage.
- screens/flow/ensure_flow_schema.py : += trigger_object_id/
target_object_id (ALTER TABLE sans contrainte FK, même patron que
cond_element_a) — le moteur de logique de flow (_flow_nodes/_flow_edges,
flow-engine.js) reste EXACTEMENT le même pour les deux éditeurs, seule
la palette de nœuds change (screens/scenes/flow_palette.py, nouveau :
sous-ensemble direct des triggers/actions existants, déjà génériques).
- screens/screens_repo/ensure_schema.py : += scene_width/scene_height
sur _screens (taille de scène fixe en pixels, sans effet sur un écran
"document").
Reste à faire (prochains commits) : route + template de l'éditeur de
scène, puis le rendu en mode jouable.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ajoute deux mécanismes distincts, à la demande de l'utilisateur qui a
précisé qu'un son doit pouvoir être attaché à une SCÈNE (pas seulement
joué ponctuellement par une action de flow, comme prévu initialement) :
- Musique de fond par écran (nouveau champ background_music_url sur
_screens, ALTER TABLE nullable) : réglée dans le panneau gauche de
l'éditeur (URL ou envoi de fichier, réutilise la route d'upload
générique existante), enregistrée en AJAX au même patron que le format
d'aperçu (screen_set_aspect.py). Démarrée en boucle à l'affichage de
l'écran et arrêtée au changement d'écran (runScreenBackgroundMusic(),
appelée depuis showScreen() dans static/js/play/screens.js) — un seul
Audio actif à la fois, jamais cumulé avec une musique restée d'un écran
précédent.
- Action de flow "jouer_son" (aux côtés des actions existantes) : effet
sonore ponctuel, non bouclé, déclenchable sur n'importe quel nœud
Déclencheur. Réutilise data_value (déjà un champ texte générique sur
le nœud action, comme pour "attendre") plutôt qu'une nouvelle colonne
dédiée — fire-and-forget côté client (runActionNode), ne bloque jamais
la suite du graphe.
Les deux réutilisent le même mécanisme d'upload de fichier déjà en place
ailleurs dans l'éditeur (ex. source d'une vidéo), sans nouvelle route.
Ceci complète les 6 phases du plan d'extension du moteur (état par
joueur, hasard/maths, clavier/minuteur, ajout de ligne, position/
collision, son) : Forge Engine peut désormais couvrir des jeux bien
au-delà du narratif/puzzle/quiz (action, arcade, jeux à contrainte de
temps).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
