Cette page présente les différentes étapes de la création d'un nœud Joueur pour le DindoMoteur.

La première étape est d'avoir un simple joueur contrôlable ainsi qu'une plate-forme sur lequel celui-ci puisse se mouvoir.

Normalement, nous pourrions supposer que cette plate-forme est l'objet d'un autre article du wiki, mais il ne fait pas sens d'avoir un joueur sans environnement pour l'intégrer, nous mettons donc en place un environnement rudimentaire pour tester celui-ci.

Dans un premier temps, je créé deux répertoire dans src/ : Joueur/ et Niveau/ .

Je remarque que dans l'exemple Platformer, il y a un répertoire Platform/ dédié aux plate-formes. Nous verrons en temps voulu si c'est pertinent, commençons simplement pour l'instant.

Avant toute logique de déplacement et de collision, je souhaite simplement que ces deux objets soient affichés à l'écran. J'utilise donc Inkscape pour créer deux sprites qui leurs correspondent.

En raison de l'unité de référence que nous avons choisi, la plate-forme de test fera 512 x 64 pixels.

Pour l'instant, je créerai un dossier assets/Dev/ qui contiendra les ressources temporaires liées au développement.

Voici les deux sprites utilisés pour l'instant :

Une fois les sprites réalisés, je crée donc les scènes associées :

• pour le Joueur, un Kinematic Body 2D (ce choix est discuté à la section suivante).
• pour la plate-forme, un Static Body 2D .

De manière intuitive, chacun d'entre eux aura un nœud Sprite et une Collision Shape 2D de la bonne taille.

Ensuite, je les ajoute au nœud Main en les instanciant. Ils ne bougent pas, mais ils apparaissent à l'écran ! À noter : dans le futur, ceux-ci seront plutôt instanciés à l'intérieur d'un nœud “niveau”.

Après quelques recherches, nous sommes arrivés à plusieurs conclusions concernant le système de collisions liées au Joueur.

C'est un nœud KinematicBody2D qui sera le plus pertinent pour celui-ci. Il existe de nombreux articles sur la différence entre les KinematicBody et les RigidBody qui rentrent en détail sur les différences de ceux-ci, et insistent sur le fait qu'un personnage jouable est plus facilement géré via le KinematicBody en raison du contrôle fin qu'il est possible de lui donner sans avoir à contrebalancer l'intégration automatique des forces physiques sur le nœud.

Si vous n'êtes pas familier avec les corps physiques de Godot, voici l'article dédié.

Voici la documentation du système de collision que nous utilisons.

Nous allons utiliser la méthode move_and_slide_with_snap() afin de déplacer le joueur, ce qui est très pratique et facile à faire. Comparée à la méthode move_and_slide(), celle-ci permet d'accrocher automatiquement la hitbox du joueur à la hitbox de l’environnement avec laquelle il est en contact, même si son déplacement l'amène à traverser celle-ci. Il n'y a donc pas à corriger sa position 'à la main'.

La méthode move_and_slide() est une méthode très pratique dans le cas d'un clone de Super Mario Bros 3, ou d'un jeu en vue de dessus comme The Binding Of Isaac. Elle permet d'indiquer le déplacement du Joueur, à l'aide d'un Vecteur 2D, et s'occupe automatiquement de faire glisser le Joueur contre la hitbox de l'environnement. Si un vecteur définissant l'orientation du sol lui est attribué, elle permet de différencier les murs, contre lesquels le joueur va glisser, et le sol, contre lequel la vélocité de déplacement est remise systématiquement à zéro, et empêche donc de glisser.

Je pensais en premier lieu que cela ne permettait pas d'implémenter certaines fonctionnalités traditionnelles des metroidvania récents, comme le saut mural. En effet, move_and_slide() est pensée pour ne proposer que la détection du sol, et n'est donc pas sensée faire la différence entre le plafond et le mur. Heureusement, les développeurs ont ajouté deux fonctions spécifiques pour ces cas particuliers : is_on_wall() et is_on_ceiling().

Le cas échéant, c'est la méthode move_and_collide() que nous aurions utilisée. Lorsque cette méthode est appelée avec la vélocité du joueur en argument, celle-ci renvoie un objet KinematicCollision2D, qui contient différentes informations à propos de la collision, notamment le vecteur de déplacement absorbé par l'objet en collision. En analysant cet objet, il devient possible de déduire l'orientation de la hitbox que le personnage vient de toucher, et donc de différencier le sol, les murs, le plafond ou encore certaines pentes. Il est ainsi possible d'implémenter soi-même la réponse à la collision de manière fine.

Dans les versions précédente de Godot, le PlatFormer n'utilisait pas de système d'héritage pour mutualiser l'attraction terrestre entre le joueur et les ennemis. C'est maintenant le cas, et le script Player hérite d'Actor, qui lui-même de Kinematic Body 2D. Nous comprenons l'intérêt de ce système, même si les scripts en deviennent moins intuitifs.

Nous allons mettre en place un système similaire, en créant un répertoire src/Personnage/ et un script Personnage.gd .

[EN CONSTRUCTION]