Gamecodeur - Les coulisses
Kanalga Telegramâda oâtish
Mes formations et mes meilleurs conseils en avant premiĂšre.
Ko'proq ko'rsatish754
Obunachilar
Ma'lumot yo'q24 soatlar
+17 kunlar
+530 kunlar
Postlar arxiv
Jouer Ă Starcraft en 1998...
A la fin des années 90 est sorti Starcraft.
A cette époque, nos PC pesaient une tonne et nos écrans (cathodiques, et pas plats du tout !), pesaient le double...
Malgré cela, nous transportions nos machines chez des amis pour jouer en LAN et c'était le pied. Cette mécanique de jeu est fabuleuse.
Le défi...
Je me suis lancé le défi de programmer au moins les bases d'un RTS inspiré de Starcraft, en pur code, sans m'inspirer et sans copier du code existant.
Je te montre ça dans ma derniĂšre vidĂ©o, et je te dĂ©coupe le projet en 12 fondamentaux que tu devras maitriser pour faire la mĂȘme chose.
Allez, ON CODE !!
C'est lĂ :
https://youtu.be/6_Ik1TExLWo
IMPORTANT :
Une fois n'est pas coutume il reste quelques places pour les 2 prochaines sessions de certification "Concepteur de jeu vidéo professionnel".
C'est quoi ?
đ C'est une formation en cours du soir (2 soirs par semaine).
đ Elle dure 18 semaines environ.
đ Elle est certifiante (RNCP "Concepteur de jeux vidĂ©o").
đ Elle est finançable par France Travail (ex Pole Emploi) et Mon Compte Formation, pour ceux qui en ont la possibilitĂ©
đ Elle coĂ»te 2800 euros.
đ Pas besoin d'ĂȘtre expĂ©rimentĂ©, il faut juste les bases pour dĂ©marrer.
ATTENTION :
đșC'est en partenariat avec une vĂ©ritable Ă©cole de jeux vidĂ©o Gaming Campus du groupe Quest Education (comme ça on peut dĂ©livrer une certification pro).
đșOn ne prend que des personnes motivĂ©es !! Inutile de faire une demande si vous n'avez ni le temps, ni la motivation (genre vous n'avez jamais mĂȘme regardĂ© ce que c'Ă©tait de programmer, c'est que ça ne vous intĂ©resse pas, dĂ©solĂ©).
đșIl faut avoir du temps pour pratiquer, c'est une formation intense et exigeante : prĂ©voir 2 soirs par semaine pour les Lives, et plein d'heure en dehors pour pratiquer et suivre les cours.
đșNous sommes 2 intervenants, moi et Nicolas, et on s'appuie sur les cours de Gamecodeur, et la philosophie Gamecodeur : Autonomie, programmation, avec et sans moteur. On fait de vous des pros, c'est pas un stage pour ado.
đșPour le financement, on peut vous aider Ă monter le dossier.
Tu as envie de te lancer ?
1) Rendez-vous sur la page suivante :
https://gamingcampus.fr/pro/developpement-jeux-video.html
2) Clique sur le lien "Demande de documentation"
3) Tu seras contacté et on t'expliquera tout
đ©·
Cette semaine c'était vacances.
Reprise lundi. Avec lancement du guide RTS avant la fin du mois.
Je ne peux pas rĂ©pondre Ă tout le monde mais je tiens Ă vous tĂ©moigner ma reconnaissance, ça me touche tous ces messages que je reçois â€ïžâ€ïž
Merci pour tous vos messages en réponse à mon email de ce matin.
53 ans. Ăa fait 53% de rĂ©duction sur tout mon catalogue de formations :
https://school.gamecodeur.fr/?coupon=ANNIV53
Tout cela en 1500 lignes de code. Et enseigné en une 15e de vidéos d'une 30e de minute chacune
41. Utilisation d'outils de débogage pour corriger les erreurs dans le code.
42. Gestion des cases âwalkableâ et ânon walkableâ de la map.
43. Calcul de parcours via lâalgorithme AStar (A*) Ă©vitant les obstacles.
44. Calcul de multiples emplacements dâarrivĂ©e dâun groupe dâunitĂ©s, en prenant en compte les obstacles, autour du point choisi par le joueur.
45. Affichage des emplacements dâarrivĂ©e des unitĂ©s.
46. DĂ©placement des unitĂ©s le long du parcours prĂ©calculĂ© par lâalgorithme A*.
47. Optimisation des dĂ©placements en groupe afin de permettre quâune seule unitĂ© occupe une case Ă la fois.
48. Optimisation des dĂ©placements en cas de dĂ©placement dâun groupe dense, afin quâune unitĂ© ne reste pas bloquĂ©e.
49. Interpolation des dĂ©placements dâunitĂ©s pixel par pixel.
50. Calcul de lâorientation dâune unitĂ© en fonction de la direction de son dĂ©placement.
51. Affichage des chemins que vont empreinter les unités.
52. Limitation des blocages en cas dâabsence de chemin possible.
...
31. Détection des clics pour sélectionner des unités et interagir avec les bùtiments.
32. Sélection d'unités à l'aide d'un lasso pour regrouper plusieurs unités.
33. Affichage du lasso en temps réel, avec gestion des spécificités du systÚme de coordonnées.
34. Calcul si une unité se trouve dans la zone entourée par le lasso ou pas.
35. SĂ©lection / dĂ©selection de bĂątiments ou unitĂ©s et affichage dâun cadre de sĂ©lection.
36. Animation des unitĂ©s frame par frame, avec diffĂ©rents types dâanimations (idle, walk).
37. Calcul de quelle tuile dâun tileset afficher en fonction du type dâanimation et de la frame dans lâanimation.
38. Orientation des unités dans les 8 directions.
39. Affichage du nombre de FPS (frames par seconde).
40. Affichage dâinformations de debug Ă lâĂ©cran (mode de jeu, etc.).
21. SĂ©lection du type de bĂątiment Ă construire parmi une liste, et affichage du type et des informations Ă lâĂ©cran.
22. Gestion dâun âmode de jeuâ : play, build, etc.
23. Placement dâun bĂątiment sur une carte, Ă la souris avec indicateur de zone libre ou pas.
24. Prise en charge de la taille des bĂątiments (occupent plusieurs cases sur la map)
25. Evaluation de lâĂ©tat dâune case pour savoir si elle est libre ou pas (walkable, non occupĂ©e par une unitĂ©, un bĂątiment ou hors des limites de la map)
26. Evaluation de zones libres ou non libres pour construire un bĂątiment (ensemble de cases).
27. SystĂšme de construction de bĂątiments avec une barre de progression pour indiquer lâavancement.
28. Affichage dâun bĂątiment en fonction de sa progression de fabrication, avec calcul de la bonne frame dans le tileset des bĂątiments.
29. Production dâunitĂ©s Ă partir dâun bĂątiment.
30. Calcul dâune position libre Ă proximitĂ© dâun bĂątiment pour la production dâune unitĂ©.
11. Scaling (zoom) des pixels pour un effet pixel art.
12. Chargement et découpage de tilesets.
13. Utilisation des Quads de Love2D pour optimiser les performances.
14. Défilement de la caméra en fonction des entrées du joueur ou de la position de la souris.
15. Zoom et mise Ă lâĂ©chelle de la carte pour ajuster la vue, avec la molette de la souris.
16. Calcul de la position du scrolling pendant le zoom pour maintenir le centrage de la map sur la position de la souris.
17. Police personnalisée pour l'affichage des informations de l'interface utilisateur.
18. Chargement et utilisations de sons lors de certains évÚnements du gameplay.
19. Utilisation du clavier pour contrÎler certains éléments du jeu (raccourcis, scrolling).
20. DĂ©finitions de bĂątiments ou dâunitĂ©s par programmation, avec leurs caractĂ©ristiques.
L'atelier RTS Facile est quasi finalisé...
En prenant du recul c'est plus de 50 concepts qui y sont enseignés :
1. Conversions entre systÚmes de coordonnées (coordonnées monde, coordonnées écran).
2. Gestions de tableaux à 2 dimensions pour gérer la position des unités et des bùtiments.
3. Utilisation de références (vs valeurs).
4. Implémentation d'un algorithme de pathfinding A* pour le déplacement des unités.
5. Chargement de code avec la fonction require de Lua.
6. Utilisation de fonctions thématiques pour améliorer la lisibilité du code.
7. Utilisation de timers pour la construction progressive de bĂątiments.
8. Chargement dâune map issue de Tiled Map Editor.
9. Exploitation des informations dâune map issue de Tiled Map Editor.
10. Affichage dâune map issue de Tile Map Editor, multi-calques.
Ce WE c'est la Ludum Dare 56. Une des plus populaires gamejam au monde.
Lors des confĂ©rences auxquelles j'ai assistĂ© Ă Bordeaux la semaine derniĂšre, un des studios indĂ©pendants les plus rentables qui a pitchĂ© n'a jamais touchĂ© un moteur de prĂšs ou de loin mĂȘme avec un bĂąton. Ils codent tout en C++...
Cela leur permet pourtant de décrocher des budgets de 500000 à plus d'un million d'euros.
Il nous a mĂȘme dit qu'aujourd'hui les clients lui disaient merci et surtout on ne veux pas de Unity dans notre projet.
(Le studio c'est Pasta Games)
Différents scandales polémiques ou déceptions touchent les communautés d'utilisateurs de moteurs de jeux. Quasiment aucun moteur n'est épargné. Quel sera le suivant ?
Je suis halluciné de l'acharnement des nouvelles générations de programmeurs de jeux à vouloir absolument utiliser un moteur.
A moins de faire des jeux 3D avancés, je ne vois aucune raison d'avoir besoin d'un moteur. L'effort à fournir pour (re) apprendre à programmer leur permettrait de se libérer totalement de tout ce bordel. Avec un vrai retour aux sources. Un niveau de compétence grisant. Et une totale liberté.
Des séries sous titrées en "null" ?
Je préfÚrerais des séries sous titrées en "nil".
