Gamecodeur - Les coulisses

Nouvelle vidéo pour changer un peu : https://youtu.be/KEsJWnhaHrk

Un de mes membres fidèle et bosseur m'a envoyé un petit hommage en vidéo et ... en C# ! Je voulais le partager avec vous : https://school.gamecodeur.fr/blog/il-me-rend-hommage-avec-un-programme Merci à lui <3.

Comment on apprenait à programmer avant Unity Avant l'avènement d'Unity et des autres moteurs de jeu modernes, apprendre à programmer était un parcours bien différent. Loin des interfaces intuitives et des bibliothèques de ressources préfabriquées, l'apprentissage de la programmation se concentrait d'abord sur les fondamentaux. D'abord : apprendre les fondamentaux L'apprentissage de la programmation commence par les bases, indépendamment de la thématique du jeu vidéo. On ne parle pas de manipuler des assets ou d'assembler des éléments, mais de comprendre les concepts fondamentaux de la programmation : variables, boucles, conditions, fonctions, structures de données, modularité/objets, etc. Ces concepts sont la colonne vertébrale de tout langage de programmation. C'est les 5 fondamentaux dont je vous parle souvent ! 👉Aujourd'hui, on fait souvent l'impasse sur les fondamentaux, pensant qu'un jeu c'est avant tout le moteur et les graphismes. Erreur fatale. Les langages simples comme point de départ Un excellent point de départ pour les débutants est d'apprendre un langage simple comme Lua. Lua est un langage de script léger et facile à apprendre. Il permet de comprendre les bases sans la complexité additionnelle des langages plus robustes comme C# ou C++. Note : En plus avec Love2D, il permet de créer des jeux vidéo et même de devenir millionnaire (Balatro est réalisé en Lua avec Love2D). 👉 Aujourd'hui beaucoup se lancent directement sur C# car ils veulent "faire du Unity". Ce qui précipitent la plupart des débutants vers l'abandon. Et quand je regarde des tutos Unity sur Youtube je suis parfois atterré par le niveau faible en programmation avec des algos bancales... Pourtant je ne suis pas moi même un scientifique du code ! L'époque des consoles et des compilateurs Dans les années 80 et 90, les développeurs de jeux apprenaient souvent à programmer sur des consoles de développement ou des ordinateurs personnels, en utilisant des compilateurs pour traduire leur code en programmes exécutables. Le processus était beaucoup plus manuel, nécessitant une compréhension profonde de l'architecture du matériel et du fonctionnement des systèmes d'exploitation. 👉Aujourd'hui, hélas on n'a que faire du matériel, de la mémoire... C'est pourtant hyper utile pour "comprendre" comment fonctionne un programme à l'intérieur. Compétence super utile ensuite pour l'optimisation, le raisonnement, etc. L'importance de la résolution de problèmes Les développeurs de l'époque étaient des solveurs de problèmes avant tout. Ils devaient optimiser leur code pour que les jeux fonctionnent sur des systèmes avec des ressources limitées. Cela leur apprenait non seulement à coder, mais aussi à penser de manière algorithmique et efficace.Title 👉Aujourd'hui, les apprentis programmeurs font tout pour éviter les difficultés et pensent que tomber sur un bug est un problème, alors que c'est une formidable opportunité de faire progresser son raisonnement ! Si tu veux apprendre... N'oublie pas que j'ai un guide gratuit : https://school.gamecodeur.fr/le-kit-de-demarrage-du-programmeur-de-jeux-video-avec-lua-et-love2d-la-methode-simple-pour-apprendre-a-programmer-et-creer-un-premier-jeu-video

Mais pour créer un jeu unique et fonctionnel, il faut une compréhension approfondie de la programmation. Mon conseil : apprenez à programmer pour de vrai. Et ne le faite pas "dans un moteur". Ce serait vous rajouter 50 couches de difficultés en plus du code. Alors que coder ce n'est pas quelque chose de très complexe. Le problème c'est que les approches modernes font tout pour vous protéger. Pour vous brosser dans le sens du poil. Et vous faire croire que vous codez...

Croire qu'on code un jeu ? Je suis tombé sur ce commentaire (en anglais à la base) sur une vidéo Youtube consacrée à Unity : "Je viens de commencer à créer mon premier jeu. Je me suis amusé avec Unity pendant environ les cinq premiers jours juste pour apprendre des choses, et ces deux derniers jours, j'ai créé un contrôleur à la première personne avec des animations et une attaque ainsi qu'un terrain. J'essaie de faire un jeu sombre en poly basique, mais ça semble être beaucoup à gérer pour ma première semaine. Est-ce que ce serait mieux pour moi d'apprendre autre chose ou devrais-je continuer à essayer d'ajouter un système de santé / des ennemis ?" Maintenant analysons ce qui se passe ici : Cette personne annonce donc commencer son premier jeu après avoir passé "5 jours à s'amuser avec Unity". Bien entendu, vous comprendrez qu'il est impossible de se lancer dans la conception d'un véritable jeu vidéo en Unity après seulement 5 jours à "s'amuser". Encore une victime des évangélistes de chez Unity, colportant depuis des années l'idée que c'est un logiciel permettant de concevoir des jeux sans programmer. J'y reviendrai plus tard. On continue avec : "ces deux derniers jours, j'ai créé un contrôleur à la première personne avec des animations et une attaque ainsi qu'un terrain" Ce qu'il faut comprendre ici, c'est que ces éléments (le contrôleur à la première personne, les animations et le terrain) sont des éléments préfabriqués disponibles dans Unity. Cela signifie qu'ils sont déjà codés et prêts à être utilisés. Il n'a donc rien créé mais juste assemblé. Il "croit" qu'il code un jeu mais hélas, lorsqu'il se confrontera à la réalité il risque fort d'abandonner en croyant qu'il n'est pas fait pour ça. Et c'est justement ce que je ne lui souhaite pas. Il se pose d'ailleurs une bonne question juste après : "J'essaie de faire un jeu sombre en poly basique, mais ça semble être beaucoup à gérer pour ma première semaine. Est-ce que ce serait mieux pour moi d'apprendre autre chose ou devrais-je continuer à essayer d'ajouter un système de santé / des ennemis ?" Si je devais être sarcastique, je répondrais que non seulement c'est beaucoup pour une première semaine, mais même pour une première année ! Comme beaucoup de débutants, il confond aspect graphique et complexité. Ce n'est pas parce que son jeu sera en low poly (utilisant peu de polygones pour les modèles 3D) qu'il sera simple à programmer. Il n'y a aucune différence de complexité entre un jeu en low poly et un jeu classique, à part pour l'infographiste... La complexité de création d'un jeu vidéo n'est pas dans son aspect visuel. Par exemple, quand il va ajouter des ennemis, que va t'il se passer ? Il va vouloir leur donner vie. Et là c'est le drame. Il n'y a pas un menu "Ajouter comportement à un ennemi" dans Unity. Unity n'est pas un éditeur de jeu, c'est un MOTEUR. Pour programmer le comportement d'ennemis, il faut programmer. Il faut une machine à état par exemple. C'est un concept simple, mais qu'on ne peut pas créer avec la souris. Il faut la créer en C#. Et C# est un langage complexe. Ajoutez à cela l'architecture de Unity. La première fois qu'on se retrouve devant du code issu de Unity, on déchante. <MonoBehaviour> ?? GetComponent<RigidBody> ?? Ce sont d'autres programmeurs qui ont codé tout cela, avec leur propre raisonnement. Et il va vous falloir aussi intégrer LEUR raisonnement pour comprendre comment programmer avec Unity. La réalité est donc que la courbe de difficulté d'apprentissage de Unity est exponentielle. Très facile au début (quand on s'amuse). Et hyper complexe quand on commence à ouvrir l'éditeur de code... Loin de moi l'idée de vous décourager de programmer avec Unity. Je veux simplement rappeler que même avec des outils puissants comme Unity, la programmation devient rapidement indispensable pour aller au-delà des bases. Les tutoriels et les démonstrations simplifient souvent le processus, donnant l'impression que tout est facile.

J'ai des questions pour toi... Quelles sont les probabilités que ton prototype de jeu soit bon ? Quelles sont les probabilités que ton jeu ai du succès ? Quelles sont les probabilités que tu réussissent à devenir programmeur de jeux vidéo ? Quelles sont les probabilités que tu finisses par comprendre ce concept important que tu as du mal à appréhender ? Maintenant, quelles sont les probabilités de faire 2x6 aux dés ? Si tu lances les dés une seule fois, très peu, voire quasiment aucune... C'est 2,78 %, soit environ 3 chances sur 100. Mais si tu lances les dés 100 fois ? Alors tes probabilités passent de à 94 % !! C'est le pouvoir de la répétition. Comme avec les dés, plus tu pratiques, expérimentes, et répètes, plus tes chances de réussir augmentent. Ce principe s'applique à tout dans la vie, y compris dans tes efforts pour développer des jeux, maîtriser la programmation, ou apprendre un concept complexe. Pense à ça : Amélioration continue : Chaque tentative t'offre une occasion d'apprendre et de t'améliorer. Même si tu n'obtiens pas immédiatement les résultats escomptés, chaque répétition t'apporte plus près de ton objectif. Résilience : Ne te décourage pas après quelques échecs. Les grands succès sont souvent précédés de nombreuses tentatives infructueuses. La répétition forge la résilience, une qualité indispensable à tout créateur ou innovateur. Maîtrise : On dit souvent qu'il faut 10 000 heures de pratique pour maîtriser une compétence. Commence par les petites étapes, répète-les, et avance progressivement. Confiance : Plus tu te retrouves confronté souvent à des défis, plus tu te sens à l'aise pour les relever. La répétition non seulement améliore tes compétences mais renforce également ta confiance en tes capacités. Alors, que faire maintenant ? Commence petit. Décompose tes grands objectifs en petites étapes. Répète ces petites étapes régulièrement. Évalue tes progrès et ajuste ta méthode si nécessaire. La clé est de rester constant et de ne pas abandonner. C'est en persévérant que tu augmenteras significativement tes chances de succès, tout comme tes chances de lancer 2x6 aux dés augmentent à chaque lancer... Bon code et reste libre !

Comment programmer sans recopier ? Quand on débutes, on copie du code. Mauvaise idée ? Non c'est plutôt une bonne chose. A condition de savoir comment le faire. Car cela pose un problème assez rapidement. On se retrouve incapable de coder seul. Dès qu'on se retrouve devant une page blanche c'est le drame. Par où commencer ? Comment faire ceci ou cela ? Il faut adapter la méthode. Passé les premiers apprentissages puérils où on copie bêtement... Il faut se mettre à copier "différemment". De manière à pouvoir ensuite "coder de tête". En utilisant son imagination. Le principe est assez simple. Petit à petit, au lieu de recopier directement voilà ce que tu vas faire. Tu vas regarder le code en question, par exemple quelques lignes.. Et tu vas t'efforcer de le comprendre. Ensuite tu le cache. Et là tu essayes de recoder ce que tu as compris. Tu vois la différence ? Coder ce que tu as compris Et pas ce que tu as lu. Je te préviens. Au début tu vas galérer. Tu vas avoir besoin de regarder le code car tu seras bloqué. Tu peux t'amuser à noter combien de fois tu as eu besoin de regarder. Pour mesurer ta progression. Il faut accepter de galérer. C'est comme ça qu'on apprend. En imposant à son cerveau des petits efforts au delà de ses capacités. Ce qui va l'obliger à se renforcer. Mais le jeu en vaut la chandelle. (cette expression est très ringarde, j'ai vraiment écrit ça ?) Et toi ? Est-ce que tu galères ? Est-ce que tu as besoin de copier ?

Je viens de me laisser tenter par un jeu mobile. Ça fait longtemps que je n'avais pas joué peut-être un an ou deux. Dice Dreams. Résultat, j'ai joué 3 minutes et j'ai désinstallé. Franchement ça devient ringard ces systèmes de jeu. Des effets visuels à n'en plus finir qui te prennent pour un gamin de 3 ans. WOW! BRAVO! BLING BLING! Alors que je n'ai rien fait à part toucher l'écran. Le gameplay complètement pipoté parce que le résultat du dé bien sûr au bout de deux fois me sort un jackpot. Sans moi.

Pince mi et pince moi sont sur un bateau... Non, je plaisante. On connait déjà la réponse. Mais l'idée est la même. Celle de comparer 2 personnes, ayant le même objectif. Et de deviner le résultat. Tu joue avec moi ? Disons que nous avons deux passionnés de programmation de jeux vidéo. Souhaitant apprendre à coder, ou bien progresser en code, comme toi. Le premier va coder 10 heures chaque dimanche. Le deuxième va coder 1 heure chaque jour, du lundi au vendredi. Lequel des deux va apprendre le plus vite ? Si tu fais le calcul, le 2e va pratiquer 2 fois moins que le 1er chaque semaine. Quelle est ta réponse ? 10h le dimanche en une fois ? 5h en 5 fois ? Voici la réponse, tu l'avais peut-être. C'est le 2e qui va progresser le plus. Car c'est la nuit qu'on apprend, au repos, pendant son sommeil. Donc le nombre de fois que l'on va pratiquer est plus important que la durée. Et la différence est énorme. Tu as la méthode maintenant. Pratique 1h par jour, ou même 30 minutes. Chaque jour tu progressera un peu. D'ailleurs je suis curieux de savoir quel est ton rythme ? Bon code et reste libre ! A demain. RAPPEL : Je bosse sur une nouvelle formation/ Elle t'apprendra à programmer une structure de jeu réutilisable en C# avec Raylib. Tu peux la découvrir en détail et t'y préinscrire ici si elle te plait, je t'enverrai un code promo lors de sa sortie dans un mois : 👉 La révolution Raylib : Crée ton framework de jeu réutilisable en C# https://school.gamecodeur.fr/la-revolution-raylib-cree-ton-framework-reutilisable

Rien de tel que de se remettre à un rpg (papier) pendant ses vacances.

La maison avance. Je suis impatient d'y produire mes formations !

J'espère que tu vas bien et que tu commences ta semaine motivé comme jamais. Si tu manques de motivations tu peux aller piocher dans mes conseils quotidiens ici : https://school.gamecodeur.fr/blog Ou sur la catégorie Développement Personnel de ma chaîne Youtube : https://www.youtube.com/playlist?list=PLQdCqBDDZ3h2RDcxEzxBZjK594niGqU0_ Pourquoi est-ce que je te donne de quoi te mettre sous la dent ? Parce que cette semaine, je serai en vacances. J'ai choisi de ne pas écrire des mails d'avance comme il est coutume de faire. Du coup, pas de mail jusqu'à lundi prochain. Savoir faire des pause et profiter de sa famille c'est aussi important. Je te souhaite une super semaine ! Bon code et reste libre !

Au passage... Je bosse sur une grande formation pour t'apprendre à programmer une structure de jeu complète et réutilisable. Elle arrive dans quelques semaines. Tu peux la découvrir en détail et t'y préinscrire ici si elle te plait : 👉 La révolution Raylib : Crée ton framework de jeu réutilisable en C# https://school.gamecodeur.fr/la-revolution-raylib-cree-ton-framework-reutilisable

Aujourd'hui j'ai un truc incroyable à te partager. Lors du dernier ADDON auquel j'ai participé, j'ai assisté à une des meilleures conférences du moment. Il s'agissait de celle de Thomas Altenburger. Tu le connais peut-être de réputation puisque c'est le programmeur du génial ScourgeBringer. Dans cette conférence il partage sa vision du game feel. Il s'agit des sensations que ressent le joueur quand il joue. Non seulement il le fait avec beaucoup d'humour... Mais ses conseils sont ENORMES et il donne énormément de techniques et montre plein d'exemples qui vont changer ta vision du jeu vidéo. C'est à voir absolument si tu veux transformer l'expérience de tes joueurs ! C'est là et ça s'appelle "Recettes de game feel fondant et croquant par l'exemple" : https://www.youtube.com/watch?v=8qdV6aKW7vM

Je rejoute dans la formation la création d'un volet de debug (activable à la compilation + par une touche), capable d'ingérer toutes les valeurs que l'on souhaite.

Imagine... Tu as une super idée de jeu vidéo. Et dans ce projet, tu as une autre super idée. Un système de combats différent, dont tu penses être le petit truc en plus qui va te permettre de sortir du lot. Tu te lances alors dans le développement de ton jeu : Structure (ton framework) Menu et interface Graphismes Musiques Narratif ... ERREUR MONUMENTALE ! Commence par démontrer que ton idée est bonne ! Cela changera tout pour toi, en particulier ta vision globale du jeu. Cela pourra avoir un énorme impact sur ton projet. Voire te convaincre de tout changer car ton idée n'est pas bonne. Ou tout miser sur cette idée car au final elle défonce tout ! On parle de "Proof of concept". Un proof of concept, ou "preuve de concept", est une version préliminaire qui démontre la faisabilité d'une idée spécifique. L'idée est simple : au lieu de travailler sur tous les aspects du jeu en même temps, tu dois isoler ce qui fait l'essence de ton jeu. Demande-toi : "Quelle est l'expérience centrale que je veux offrir aux joueurs ? Qu'est-ce qui rend mon jeu unique et intéressant ?" Et concentre toi sur ça. Au lieu de développer tout le jeu tout de suite, tu vas te concentrer sur cette idée clé. Ce proof of concept sera une sorte de prototype d'un moment précis du gameplay de ton jeu. Tu vas te concentrer sur les éléments suivants : Les mécaniques de combat : comment les personnages attaquent, défendent, utilisent des compétences spéciales, etc. L'interactivité : comment le joueur interagit avec les éléments de combat. Le feedback visuel et sonore : comment le jeu répond aux actions du joueur avec des effets visuels et sonores. Cela te permet de valider ton concept avant de t'engager dans le développement complet du jeu. Tu pourras ainsi identifier les points forts et les faiblesses de ton idée, et apporter des améliorations si nécessaire. Ce n'est pas tout. Créer un proof of concept te donne aussi une base solide pour présenter ton projet à des partenaires potentiels, des investisseurs ou des membres d'équipe. Ils pourront voir concrètement ce que tu proposes et comprendre la valeur de ton idée. Bon code et reste libre !

Au programme : GameState transversal : Partagez des informations et des fonctions de manière transversale, accessibles depuis n'importe où dans votre jeu. Gestionnaire de scènes intégré : Gérez facilement les différentes scènes de votre jeu grâce à un gestionnaire de scènes intégré. Système de scènes évolué : Profitez d'un système de scènes complet avec toutes les étapes : création, prise de focus (show), mise à jour, disparition (hide), et destruction. Structure de jeu complète : Créez des jeux complets avec menu, options (volume sonore, full screen), gameplay, et un système pour créer des listes de boutons facilement. Ajout rapide de scènes : Ajoutez une nouvelle scène à votre jeu en quelques secondes. Classe Sprite : Facilitez l'affichage et la gestion de la position des éléments de jeu avec une classe Sprite intégrée. Exemple de scène de jeu : Apprenez rapidement avec un exemple de scène de jeu incluant un compte à rebours, une liste de sprites et une fonction de pause. Système de paramètres de jeu : Sauvegardez et restaurez des textes et des valeurs dans un répertoire spécifique de l'OS (roaming) avec notre système de paramètres de jeu. Exemples de programmation C# et Raylib : Profitez de nombreux exemples réutilisables de concepts de programmation C# et Raylib : héritage avec fonctions abstraites ou virtuelles, pattern du singleton, GUI simple (bouton et case à cocher) avec survol et clic, sauvegarde en JSON, centrage de texte, animation de texte, exceptions, dictionnaires, compte à rebours, pause dans le gameplay. Exemple de musique de fond et d'effet sonore.

Un système de scène hyper facile à utiliser. On peut créer une nouvelle scène en 2 mn.

Une scène de jeu avec compte à rebours et pause.