Mickael LANGLET

Catégorie : cesse-adventure

  • Devlog 2 – Cesse-Adventure Finalement du C#

    Le projet Cesse-Adventure a été initialement développé en GDScript.
    Finalement j’ai décidé de switch de de langage.

    Présentation des avantages et Inconvénients des deux langages

    GDScript

    Avantages

    • Conçu pour Godot : Intégration parfaite avec le moteur.
    • Facile à apprendre : Syntaxe simple, inspirée de Python.
    • Prototypage rapide : Idéal pour tester des idées.
    • Prêt à l’emploi : Pas de configuration supplémentaire.

    Inconvénients

    • Performances limitées : Moins adapté aux projets gourmands.
    • Langage spécifique : Peu utile en dehors de Godot.
    • Compatibilité IDE : Support limité pour des IDE externes comme Visual Studio Code ou JetBrains Rider.

    C#

    Avantages

    • Puissant et polyvalent : Idéal pour des architectures complexes.
    • Écosystème riche : Compatible avec des bibliothèques externes.
    • Performances élevées : Meilleur choix pour des projets exigeants.
    • Compatibilité IDE : Fonctionne bien avec des IDE comme Visual Studio, VS Code et Rider.

    Inconvénients

    • Apprentissage plus long : Le langage plus complexe.
    • Configuration nécessaire : Installation de Mono obligatoire.
    • Workflow légèrement moins fluide : Intégration moins native que GDScript.

    De GDScript à C#

    J’ai choisi de passer de GDScript à C# pour plusieurs raisons. Bien que GDScript soit rapide à apprendre et parfaitement intégré à Godot, j’ai ressenti certaines limites, notamment sur les aspects suivants :

    1. Architecture modulaire : Avec C#, je peux exploiter des concepts avancés comme les interfaces, les génériques et une gestion plus fine de l’architecture de mon projet, ce qui correspond parfaitement à mon approche modulaire.
    2. Compatibilité IDE : En utilisant un IDE comme Visual Studio ou JetBrains Rider, j’ai accès à des outils puissants (debugging avancé, autocomplétion, gestion des packages) qui boostent ma productivité.
    3. Réutilisation des compétences : Développer en C# me permet de transférer plus facilement mes connaissances vers d’autres moteurs (comme Unity) ou projets non liés aux jeux.

    Ce changement m’a demandé un peu d’adaptation, mais les bénéfices en termes de flexibilité et d’efficacité le rendent incontournable pour mes besoins actuels.

  • Intégration de l’Authentification OAuth avec l’API Twitch

    Aujourd’hui, je vais vous raconter comment j’ai intégré l’authentification via OAuth avec l’API Twitch dans mes applications.

    Contexte

    J’utilise l’API Twitch pour me connecter au chat Twitch et intercepter les commandes de chat. Cette API est utilisée dans deux de mes applications : CesseZeApp et Cesse-Adventure. Pour l’authentification, j’utilise OAuth 2.0.

    Pour utiliser l’API Twitch, il faut enregistrer son application. Twitch fournit alors un client ID et un client secret pour utiliser leur système d’authentification. Mon problème est que mes applications sont des clients qui se lancent directement sur un ordinateur, sans passer par un serveur tiers. Je ne peux donc pas utiliser la connexion Client Credentials d’OAuth, car cela exposerait mes identifiants à tous les utilisateurs de l’application.

    Heureusement, OAuth propose le Device Grant Flow, conçu pour ce type de cas.

    Device Grant Flow

    Voici comment ce processus fonctionne de manière simplifiée :

    1. Génération du Code de Validation : J’appelle la route /oauth2/device pour générer l’URL de validation du code.
    2. Validation dans le Navigateur : L’URL est ouverte dans le navigateur par défaut du PC.
    3. Obtention du Token : En attendant la validation du code sur la page du navigateur, la route /oauth2/token est appelée à intervalles réguliers jusqu’à l’obtention du token.
    4. Accès à l’API : Une fois le token obtenu, je peux accéder à l’API.

    Comme tout système d’authentification OAuth, un Refresh Token est fourni avec l’Access Token pour rafraîchir ce dernier avant son expiration.

    Problème avec l’API Twitch

    Cependant, selon la documentation officielle OAuth sur le Device Grant Flow, il est spécifié que la route du refresh token doit pouvoir être appelée sans avoir besoin du client secret, principe même de ce système d’authentification.

    Malheureusement, l’API d’authentification de Twitch exige un client secret pour rafraîchir l’Access Token, ce qui pose problème dans mon cas.

    En résumé, bien que le Device Grant Flow soit idéal pour mes applications, l’exigence du client secret par l’API Twitch pour le rafraîchissement des tokens complique l’intégration sécurisée de ce système.

    J’espère que Twitch pourra ajuster cette exigence à l’avenir pour mieux s’aligner avec les principes de l’authentification OAuth et offrir plus de flexibilité aux développeurs.

  • Devlog 01 – La structure de Cesse-Adventure

    Pour comprendre le contexte de ce devlog je vous invite à lire la présentation de Cesse-Adventure ici.

    Après de longues séances de brainstorming avec Céciliane et Juliette, nous avons pu nous organiser pour commencer nos tâches respectives. Céciliane n’étant pas disponible, nous avançons à deux pour l’instant.

    J’ai d’abord travaillé sur la création de la structure du code que je vais vous présenter, puis à développer le joueur et un niveau prototype qui seront présentés dans un prochain devlog.

    Présentation de l’asset de test.

    Je me suis basé sur un Asset réalisé par Vryell (lien vers l’asset), qui propose une structure de donjon de type roguelike :

    Et de modèle avec trois animations, Idle, Marcher, Attaquer, dans les 4 directions possible (Haut, Bas, gauche, droit).

    Lors de précédent poc que j’avais réalisé, il se trouvait que j’avais une modèle de personnage utilisant les traits de cet asset que j’ai décidé d’utiliser :

    Structure du projet

    Pour développer ce roguelike 2D en vue de dessus avec génération procédurale des niveaux, j’ai conçu une architecture modulaire axée sur la flexibilité et la communication efficace entre les composants. Cette approche utilise les scènes de Godot et les signaux pour garantir une interaction fluide et une maintenance simplifiée.

    Modularité

    Le projet est divisé en modules distincts, chacun responsable d’un aspect spécifique du jeu. Par exemple, nous avons des modules pour la gestion des joueurs (PlayerSystem), des ennemis (EnemiesSystem), et des niveaux. Cette séparation permet une meilleure organisation du code et facilite les tests unitaires et l’évolution des fonctionnalités.

    Orientation Objet

    Chaque entité du jeu, qu’il s’agisse du joueur, des ennemis ou des objets interactifs, est représentée par une classe dédiée. Par exemple, la classe Player gère toutes les propriétés et comportements du joueur, tandis que la classe Enemy fait de même pour les ennemis. Cette approche orientée objet me permet de réutiliser et d’étendre facilement les comportements des différentes entités du jeu.

    Utilisation des Scènes de Godot

    J’utilise également le système de scènes de Godot pour structurer les éléments du jeu. Chaque entité, comme les ennemis ou les niveaux, est définie dans une scène séparée. Cette organisation en scènes facilite la gestion des ressources et des instances dans le jeu.

    Communication par Signaux

    Pour assurer une communication efficace entre les différentes parties du jeu, j’utilise les signaux de Godot. Par exemple, le signal player_moved permet de notifier d’autres systèmes lorsque le joueur se déplace, sans créer de dépendances directes. Cette architecture orientée événement aide à maintenir un couplage faible entre les modules, améliorant ainsi la flexibilité et la maintenabilité du code.

    Conclusion

    En combinant ces principes, l’architecture peut être décrite comme une « Modular Scene-Based and Event-Driven Architecture ». Cette approche me permet de développer de manière structurée et évolutive, tout en tirant parti des puissantes fonctionnalités offertes par le moteur de jeu Godot.

    J’espère que vous avez apprécié cet aperçu de notre architecture. Si vous avez des questions ou des commentaires, n’hésitez pas à les partager ci-dessous !

    Restez à l’écoute pour plus de détails sur le développement de Cesse-Adventure !