Aller plus loin (dev)

Pour les développeurs et développeuses :

le projet se compose en réalité en différentes parties :

• le « moteur » du jeu : un ensemble d’éléments qui interagissent entre eux avec des règles plus ou moins modifiables facilement (par l’interface de Godot (variables exportées...) ou par le code)

• des « items » qui permettent d'étendre les mouvements et interaction de l'avatar (pour l'instant ils sont dépendants du moteur et n'ont pas leur propre versionnage)

• un plugin de gestion des Saves qui permet de passer d’un "niveau" à l’autre, de les sauvegarder, de gérer les sauvegardes...

• des documents pédagogique liés à des protocoles pour animer des ateliers pour des publics d’âges différents.

• un export web pour rendre accessible en ligne le résultat des ateliers (présenter l'atelier et les différents « niveaux ») ou créer un jeu complet composé de plusieurs niveaux.

Il faut donc différencier les modifications prévues et compatibles entre elles (les « niveaux» au sein d'un « jeu ») avec des changements dans le « moteur » qui peuvent créer des incompatibilités hard lock (bugs, messages d’erreurs, crash) et/ou soft lock (niveau qui ne peut plus être terminé parce que la physique a changée et donc un obstacle devient infranchissable).

Il faut bien sur que le projet Godot contienne les Items appelé dans les sauvegardes (si vous en avez créé ou modifié)

La compatibilité avec les sauvegardes est au maximum maintenue. Les incompatibilités ne se feront que dans les releases « majeures » (v0.x.0) et j'essayerais de proposer des moyens de convertir les saves d'une version à une autre.

Arborescence étrange

Beaucoup de choix qui structurent le projet sont fait pour faciliter la manipulation lors d’un atelier par une personne qui ne connaît pas forcément Godot et ne sait pas coder.

La structuration de l’arborescence des nœuds du projet permet de rendre visible dans la scene "Jeu" seulement les nœuds intéressants et faciles à modifier dans le cadre d’un atelier sur le level design et les bases du game design.

L’arborescence des fichiers reprend principalement l'arborescence dans Godot (à part les assets réutilisés à plusieurs endroits et les libs)

2D Kinematic Character Demo

Le projet est, dans l'idée, un prolongement de l’exemple 2D Kinematic Character Demo. Pour commencer à explorer le code, suivre les tutoriels associés permet de comprendre une grande partie du fonctionnement du nœud Avatar :

• Introduction à la physique
• Utiliser KinematicBody2D
• Personnage cinématique (2D)
• Vue d’ensemble du mouvement 2D

Il peut-être intéressant d’être familier avec les TileMaps, un peu avec les Signaux et savoir exporter une variable dans l’éditeur pour commencer à rajouter des modes de déplacement et interactions avec des Items.

Tilemap

Les Tilemap sont des outils très faciles à prendre en main à l’usage mais assez complexes à utiliser dans le code et surtout dans les interactions physique. Ainsi, les tuiles qui sont sensées interagir avec le joueur au delà de la simple plateforme, sont remplacée au démarrage du niveau par des scènes StaticBody2D qui comportent les éléments nécessaires à leurs bon comportement (CollusionShape2D, Sprite, LightOccluder2D, animations, lights...). à part les plateforme noires, chaque tuile correspond donc à une scène qui sera importer en lieu et place.

Items

Au maximum, les effets physiques (déplacements et intéractions) offertent par les capacités/items sont codées dans le script attaché à chaque noeud capacité/item, qui héritent tous de la class Item. Ils contiennent les variables et fonctions propre à leur fonctionnement et modifie les états et attribues du noeud Avatar. L’intéractions entre deux items (ex: sauter alors qu’on escalade un mur) est géré dans Avatar par les états d’interaction (jumping, bouncing, attacking...).

Ajouter une capacité au personnage peut être plus ou moins complexe.

• Si c’est une mécanique de déplacement qui n’intéragie pas avec d’autres, cela pourrait tenir en quelques lignes et ne nécessite que quelque connaissance de géométrie et une intuition de la physique et des vecteurs (voir Voler).
• Le besoin de prévoir une intéraction avec une autre capacité de déplacement, prévoire des bugs ou ajouter une animation demandera d’être un peu plus à laise avec Godot pour aller explorer l’objet Avatar et ses autres enfants (voir Téléporter, Escalader)
• Créer une nouvelle intéraction entre le personnage et son environement nécéssitera de créer et modifier d’autres Objets (voir Protéger, Détruire)

EditorPlugin

Pour facilité au maximum l’usage de l’interface graphique, la gestion des sauvegardes (= niveau) passe par un EditorPlugin.

Export

Je me suis surtout intéressé à l'export HTML5, pour rendre accessible en ligne une compilation de niveau (résultat d'ateliers, exemple et démo...) ou bricoler un jeu. La version exécuté depuis l'éditeur (avec le debug) n'a pas l'air si différentes des versions compilés pour les OS. La plus grande différence qu'il y a entre un projet Godot joué depuis l'éditeur et exporté, c'est la gestion des saves.

Par défaut, puisque tout est "empackagé", les fichiers json doivent être ajouté à l'export (ils vont être compilé et donc inextricablement liés avec le moteur). Avec ce réglage dans la fenêtre Exporter, onglet Ressources

Filtre pour exporter des fichers/dossiers non-ressources: save/*

Si on veut pouvoir les gérer indépendamment, il faut configurer un autre moyen que par le chemin "res://". Pour les binaires exécutables sur une machine les droits de lectures sur le disque ne semblent pas profondément différents, mais un export web nécessite des dispositions particulières : Godot ne peut pas naviguer dans les fichiers sur le serveur. Il peut lire ceux accessibles via une URL via HTTPRequest. Si on veut pouvoir modifier et surtout ajouter des niveaux sans réexporter l'intégralité du projet, il faut pouvoir lister les fichiers contenu dans un répertoire via une requête. J'ai donc bricolé le fichier export/www/saves.php qui retourne tout le contenu des fichiers json d'un répertoire save/ (mais il faut PHP d'installé sur le serveur). Ça doit être faisable avec n'importe quel langage côté serveur. Il faut penser à changer l'attribut save_server_url de Jeu avec l'url où se trouvera le "serveur de save" (ici saves.php)

Les autres paramètres du nœud Jeu peuvent être intéressant pour l'export (auto_cam ...)

La scène Menu doit être instanciée comme enfant du nœud Jeu pour permettre de passer d'une save à une autre.

Performance & moteur de rendu

Ce projet est bien sur pensé pour fonctionner au sein de fortes contraintes matérielles. PC d’écoles et de centres de loisirs, Smartphone (à tester en profondeur et adapter UI), Raspberry Pi (à tester) et Web (export jouable mais aussi édition avec web editor).

Donc le projet utilise seulement GLES2 (En termes d’API graphiques, le backend GLES2 correspond à OpenGL 2.1 sur ordinateur de bureau, OpenGL ES 2.0 sur mobile et WebGL 1.0 sur le web.).

Godot 4.0

je préfère attendre que la documentation et les exemples soit bien à jour avec la version 4.0 pour repartir du nouvel exemple de plateformeur 2D. Il semblerait qu’il y ai une refonte du KinematicBody2D et des changements avec les TileMap, l’import de Script, l’export de variable... Kinematic character 2D. Le portage vers la 4.0 est fait dans la branche godot-4.0 tout au long de la beta.

Même si les développeurs de Godot réitèrent leur intention de garder un moteur OpenGL pour le web et les petites machines.. Il faudra peut-être continuer de maintenir le projet en 3.x pour garantir le fonctionnement sur du matériel plus ancien.

Pour le moment, l'export web de projets en godot 4.0 est trop complexe (Cross Origin Isolation & SharedArrayBuffer), le tweet de Juan Linietsky va dans le sens d'attendre la 4.1. Depuis la 4.0, il faut configurer son serveur avec Cross Origin Isolation & SharedArrayBuffer pour pouvoir lancer les exports web dans le navigateur. Créer un serveur local pour tester les jeux rapidement est maintenant un peu plus complex qu'un bon vieux python -m http.server, voir cette page pour les idées de configs. Le dépot de Godot propose un script python qui semble avoir ce rôle, à vérifier et à voir comment l'utiliser (pourquoi pas faire une version de saves.php en python avec Flask pour tout rendre testable localement). Pour héberger un jeu avec le multi-thread (godot 4.0 -> 4.2.x) il faut un header http particulier, (impossible?) (difficile?) chiant à faire sur Yunohost ou Itchio par exemple. Avec la 4.3 revient l'export web en mono-thread pour éviter les soucis de COOP/COEP et voilà ! l'export web tourne sur n'importe quel serveur web depuis la 4.3 !

pistes de choses à faire

• vérifier la scene en utilisant le plugin (en cours)

• typage des variables dans la save json ? {"type":type}

• outils de migrations de save.

• BBcode dans "narrative" (bug d’alignement à droite, solution pour la 4.0)

• rajouter Item "Manger" (détruire couleur alliée), "Double saut" (comme téléportation mais vertical)

• MAJ du plugin et des editors scripts :

  • integration de l’arborescence dans fichier de save pour les prochaines versions ?
  • prévisualisation avant importation

• générer les documents pédagogiques à partir de Godot (grille de la carte, GDD)

• un EditorExportPlugin pour tester et parametrer certaines choses au moment de l'export (par exemple, remettre la scene Menu.tscn...