L’expérience d'il y a deux ans m'avait plus, j'ai donc re-signé pour une journée de mentorat à la game jam de l'école de mademoiselle fille (un hackaton orienté jeux vidéos, ouverts aux élèves de 11 à 17 ans). Tout comme il y a deux ans, j'ai trouvé des équipes de jeunes hyper motivés, avec de belles idées, et certainement un poil trop d'ambition par rapport à leurs moyens, mais ça fait partie du jeu.
J'ai donc vu un Balatro-light en Python avec des dessins extraordinaires, un jeu de plate-formes en Godot codé en 6 heures, avec sons, animations, et petits sprites de pizza à attraper, ou encore une course pour sauver des chatons robots dans un univers 3D avec Unity.
Pour me préparer, j'avais décidé de coder le même mini jeu 3 fois avec pyGame, Godot et Unity3D, et de voir ce qu'il en était. Bien m'en a pris, car cela m'a permis d'être à peu près au point quand on m'a demandé de l'aide. Je vous parle un peu des 3 approches, avec la nimage traditionnelle.

pygame
Ce que je voyais au début comme une simple couche Python au dessus de la SDL est en fait plutôt complet, et rudement facile à utiliser. En particulier, j´admire la fonction pygame.sprite.groupcollide qui permet de faire de la collision de sprite au pixel près. C'est propre, ça marche, en 200 lignes on peut faire quelque chose d'honorable.
Godot
Très pro et léché, Godot m'a surpris - Il est vraiment possible de faire de belles choses simplement, l'approche par scènes fonctionne très bien, et l'éditeur de GDScript est pratique, avec une auto-complétion particulièrement bien fichue. De plus, il n'a pas trop changé dernièrement, les infos et tutos que l'on glane à droite à gauche sont généralement à jour
Unity3D
C'est le mastodonte - C'est plus lourd, plus lent à démarrer, et il tente très vite de te convaincre d'obtenir, voire d'acheter, tout un tas de plug-ins et de prefabs.
Je trouve la partie code moins bien intégrée. En particulier, ce choix de ne pas fournir d'éditeur de texte et de laisser l'utilisateur avec son éditeur par défaut, si elle est certainement pratique pour les utilisateurs avancés, n'est absolument pas ce dont j'ai besoin en tant que codeur débonnaire et dilettante - Mon bon vieux Emacs me fait à peu près la coloration syntaxique et l'indentation, mais pour avoir un bel environnent C# intégré, il m'aurait fallu mettre bien plus d'efforts dans l'installation de language servers et autres.
En revanche, l'approche par composants que l'on ajoute à chaque nœud du graphe, et la manière de référencer les objets du jeu dans les scripts via du glisser déposer dans l'interface est particulièrement élégante à mon sens.
Et maintenant ?
Je tente de garder le cap, et mon mini-jeu a suffisamment intéressé la plus jeune pour qu'on décide elle et moi de construire quelque chose avec ses dessins et mon code. Alors j'hésite - Insister avec le Python, ce qui me sera certainement utile pour le boulot? Pousser avec Godot avec l'idée que ce sera plus pertinent pour des projets plus ambitieux ? Revenir à mes premières amours et tout faire en C++ + SDL ? Passer au Rust ?

# Autres options
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Pourquoi pas du bon vieux C pour une vieille console ou un core libretro ?
Outre le charme, tu gagnes des fonctions super chiantes à implémenter (gestion des manettes, remapping des inputs, savestates, capture vidéo, scaling shaders…) grâce à RetroArch ou autres émulateurs.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: Autres options
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
Godot ne fait pas tout ça ?
"La première sécurité est la liberté"
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.