william
50835a18e2
Le document de cadrage produit cible des formateurs non techniques créant des serious games/quiz gamifiés — l'éditeur générique "document" (blocs de logique en nœuds, timeline d'animation, définitions d'objets/relations, templates réutilisables) est une complexité hors cible que l'effort d'ingénierie récent avait déjà abandonnée au profit du jeu_2d. - Onboarding : ne garde que le parcours "RPG" (jeu_2d), retire Quiz/Embranchement/Créer mon jeu de A à Z (tous document-only) - Suppression en bloc des modules exclusifs au document : routes/elements, routes/element_types, routes/objects, routes/legacy_actions, screens/elements, screens/element_types, screens/widgets, screens/legacy_actions, le rendu render_element_html.py et son cluster, templates/screen_edit.html, templates/game_dashboard.html, flow-editor.js/tabs-and-blocks.js/animation-timeline.js - Dashboard toujours simplifié (un seul mode possible désormais) - Tests document-only supprimés, tests de logique partagée (flow, événements personnalisés, animations) retargetés sur des écrans jeu_2d - Aucune régression jeu_2d : 299 tests passent Carte d'onboarding retravaillée : argumentaire RH non technique (liste à coche, badge "Compatible LMS"), taille et interaction de retournement ajustées.
45 lines
2.2 KiB
Python
45 lines
2.2 KiB
Python
"""
|
|
app.py — moteur Forge, point d'entrée.
|
|
|
|
Lance un serveur web local. Fonctionnalités construites pour l'instant
|
|
(le reste viendra au fur et à mesure) :
|
|
1. Créer un jeu (dossier + index.html/css/js + base de données dédiée).
|
|
2. Définir des "objets" (comme des tables de base de données, avec des
|
|
champs typés, et des relations vers d'autres objets déjà définis).
|
|
3. Le moteur lit ces définitions et génère lui-même le formulaire adapté
|
|
pour saisir des données et les enregistrer dans la vraie base SQLite.
|
|
4. CRUD complet sur les trois niveaux (jeu / objet / donnée) : renommer
|
|
et supprimer un jeu, modifier une définition d'objet (ajouter/retirer
|
|
des champs) et la supprimer, modifier et supprimer une ligne de
|
|
données — avec blocage/avertissement quand une suppression casserait
|
|
une relation existante.
|
|
"""
|
|
|
|
import threading
|
|
import webbrowser
|
|
|
|
from core.flask_app import app
|
|
from core import jinja_filters # noqa: F401 - enregistre les filtres Jinja
|
|
import routes # noqa: F401 - enregistre toutes les routes sur `app`
|
|
from core import auth_guard # noqa: F401 - enregistre la garde de connexion (après les routes)
|
|
from core import csrf # noqa: F401 - enregistre csrf_token() comme variable globale Jinja
|
|
from core import csrf_guard # noqa: F401 - enregistre la vérification du jeton CSRF
|
|
from core import recovery_codes_flash # noqa: F401 - enregistre pop_recovery_codes() comme variable globale Jinja
|
|
|
|
|
|
def _open_browser():
|
|
webbrowser.open("http://127.0.0.1:5050/")
|
|
|
|
|
|
if __name__ == "__main__":
|
|
threading.Timer(1.0, _open_browser).start()
|
|
# threaded=True : le serveur de dev Werkzeug traite UNE requête à la
|
|
# fois par défaut — un jeu 2D charge des dizaines d'images (sprites de
|
|
# personnages, fonds...) en parallèle à chaque chargement de page, et
|
|
# sans ce réglage elles se mettaient en file d'attente une par une
|
|
# (bug remonté : un Ctrl+F5, qui recharge TOUT sans cache, laissait
|
|
# l'éditeur de scène "vide" le temps que les images finissent par
|
|
# arriver l'une après l'autre — un rechargement normal, servi surtout
|
|
# depuis le cache navigateur, le cachait).
|
|
app.run(host="127.0.0.1", port=5050, debug=True, use_reloader=False, threaded=True)
|