Coucou tout le monde,

Je vais enclencher un wip pour vous parler du moteur de jeu Godot et d'un projet que j'ai commencé il y a quelques mois. Dans ce wip, je vais juste "raconter ma vie" et en même temps, j'ai envie de vous faire découvrir le moteur.

Un petit prologue:

J'ai pratiqué le BGE, de manière intense, et ce dans les alentour de 2016 (un peu plus tôt genre 2014 ? Je ne me souvient plus). J'ai tout de suite compris que sans connaissances en python, j'irai pas bien loin. Je me souvient que je me débrouillai plus ou moins bien avec le Batch pour Windows et le Bash chez Linux (très peu) mais sans plus car c'était plus à l'école qu’ailleurs...

Du coup j'avais dû apprendre le python, en plus des autres compétences requises pour la 3D, l'animation, la création de texture, etc.

Donc, je reviens à Godot:

Celui qui exploites encore le BGE/upBGE ne sera pas dépaysé (sur la technique) en passant sur Godot. Cela dit, on semble vendre Godot comme "facile", "accessible"... je ne dirai pas ça personnellement. C'est pas plus facile qu'Unity ou l'UE4 (maintenant le 5 ?). Il y a des tutos "prise en main" sur le site officiel, mais ça s’arrête à ce terme: il sera nécessaire de chercher l'information ailleurs pour aller plus loin. Pour l'adepte qui découvre le logiciel, ce qui est dommage, c'est qu'on le guide d'office sur la programmation, donc ce dernier risque d'être perdu, au départ. Il y a bien un système en brique logique (ou système nodal) mais on ne le vend pas aussi bien que la programmation, peut-être est-ce réservé aux ateliers pour enfants, et encore ? Bref, programmation = plus de liberté, 'faut pas se le cacher.

GDScript = python (enfin, dans la façon de coder, le BGE pour ça, c'était plus "pur python")
C# = C# (c-sharp pour la prononciation), les exploitants d'Unity connaissent.

Ce qui est bien cependant, c'est que l'on peut télécharger des exemples "jouable" et analyser le contenu mais sans aides si pas de commentaires dans les lignes de code...

Donc, vu que j'ai déjà des notions de base, l'adaptation n'a pas été très difficile mais j'ai voulu rester prudent, j'ai estimés commencer par un projet 2D "simple" et j'ai choisi de faire un STR (stratégie temps réel). J'ai ressortit du grenier mon tout premier jeu pc, un jeu Canadien, j'avais même acheté le deuxième quelques années plus tard, plus moderne.

À l'époque, on était à la mode Command & Conquer (si je ne dis pas de bêtises).

Et donc, c'est ce concept que je souhaites reproduire. Je ne compte pas aller trop loin non plus, juste le minimum, à savoir, le bulldozer, le camion-benne, le camion-citerne, la jeep, le tanker, le char d'assaut et les bâtiments pour la génération des ressources et unités.

J'en raconterai plus plus tard.

Screenshot de l'interface et mon travail.

Tout comme dans le BGE, il est nécessaire d'organiser son travail, ses blends et ses scripts. Godot permet d'organiser cela sans le quitter. Par contre, sur Godot, on parle en noeud, pas vraiment en objets. C'est-à-dire que, dans un premier temps, il faut un noeud principal, tout le reste devra se mettre dans celui-ci, que ce soit de la même scène ou non (comme le HUD, par exemple).

Ce concept est assez compliqué à appréhender au début mais en pratiquant, l'organisation vient naturellement, cela dépend de l'individu et de sa vision des choses. Vu que mon projet concerne de la 2D et que je désires générer aléatoirement une carte, je dois pour cela mettre un noeud "tilemap 2D".

Comme je l'ai dis plus haut, ce sont des noeuds, pas des objets et donc les scripts s'attachent et s'organisent sur le noeud qui le concerne. Par exemple, le script sur mon noeud "tilemap" se charge de générer le terrain de jeu et à placer mon point de départ, soit le quartier général et un bulldozer.

Le script de la camera gère la camera, du noeud "camera2D", pour le déplacer et le contraindre à des évènements bien précis que j'exposerai plus tard.

Chose importante dans Godot: la manière de positionner les noeuds aura un impact sur la visibilité de ceux-ci, je m'expliques: j'ai deux noeuds "simples", "BuildingObj" et "unitObj", qui doivent contenir respectivement les bâtiments et les unités. J'aurai très bien pu mettre directement ceux-ci en tant qu'enfants, juste après "showpoint" mais en fonction de la génération de chacun, il y aurai des problèmes à long terme, comme une unité qui se cacherai derrière un bâtiment.

Or, l'unité doit être visible, en tout circonstance, donc on dessine le bâtiment d'abord, puis l'unité par dessus. En fait, c'est comme si on posait une feuille transparente sur une feuille blanche. Faire l'inverse cacherai l'un d'entre eux.

Hello Redstar,

sympa de mettre en lumière godot via ce wip.
C'est un très bon moteur qui fonctionne super bien.

A noter le support AR et VR avec les plugins oculus, openvr , openxr et openhmd.

Pour moi la seule limitation (due à l'open-source qui ne prend pas en charge les formats propriétaires) , c'est le format de prise en charge des vidéos :
seulement .webm et .ogv .
C'est très limitant,relou et chronophage lors d'ateliers/workshops par exemple de devoir convertir avant importation toutes les vidéos .mp4 sorties des cameras 360°. C'est pour moi, le seul point noir comparé à Unity.


J'ai une question sur l' organisation de ton travail :
Il y a-t-il une raison particulière à ce que ton root node soit un node TileMap ?

Bon wip, hâte de voir la suite
Bon blend

Salut WinZs,

C'est bon à savoir pour la partie VR ! webm et ogv concerne que la VR ou n'importe quel vidéo ?

Par exemple, une vidéo d'introduction à l'ouverture du jeu ?

Citation :

Dans l'état actuel, oui, car je dois souvent aller chercher des informations du Tilemap pour les autres scripts des noeuds enfants. Par exemple, récupérer les coordonnées X & Y du monde converti en pixel.

Donc ça me semblait judicieux de le mettre en root, ça reste un node2D mais en tant que varient après tout.

---------------

Bien que j'ai mis en place la base, je dois configurer celle-ci. Afin de pouvoir générer une carte, je dois lui indiquer les "tuiles" comme matière première. Vu que je me concentre sur la mécanique d'abord, je n'ai pas pensé utile de faire des textures élaborées, ça viendra après.

Au départ, j'avais réalisé un code qui prenait aléatoirement un point, le définissais comme une tuile de terre puis je faisais faire un second passage pour créer des îles (ou des continents si ces même "îles" se touchent) et un troisième passage pour ajouter des "ilots" de rocher sur la terre.

Ça faisait le travail, mais ça me posait problème, car dans le jeu original, j'avais un concept à conserver: que le monde est rond, c'est-à-dire que si je vais à l'extrême gauche, je dois voir ce qui se trouve à droite. Or, mon générateur, si je collais une copie de l'original à côté, ça n'était pas du tout raccordé !

Il fallait que je trouve une solution, que j'expliquerai dans un prochain post.

Re,
Citation :

C'est l'importation global de vidéo dans le moteur.

En soit, mouliner une vidéo dans le bon format pour la prod d'une appli ce n'est pas gênant ; quand on le sait dès le début, c'est un pré-requis : ok.
Mais dans mon cas, ce qui est très très gênant : c'est quand je fais des ateliers/workshops en VR/360° sur une après-midi (3 heures en gros) et qu'il faut passer 1 heure à ré-exporter chaque vidéo que les participants ont été tournées juste avant, c'est juste impossible à gérer dans le temps imparti .
Du coup (à mon grand regret, car je milite pour l'opensource au possible) dans des ateliers/workshops 360° :
..ben, j' utilise Unity car il prend direct les fichers .mp4 quoi..


Merci de ta réponse sur le node TileMap (inherit 2D). C'est la 1ère fois que je voyais un node tileMap en root donc je me demandais juste si tu avais une raison bien particulière quoi.

bon blend

Ah, c'est embêtant...

As-tu tenté cette solution ? Sinon, essaies un peu ? Tu m'en dira des nouvelles.

Coucou, intéressant cette expérience en cours avec Godot. C'est une bonne chose que tu sois passé à autre chose après la disparition du BGE, tu pourras continuer tranquillement à réaliser des projets dans de bonnes conditions.

Pour la vidéo, est-ce qu'un NativeScript ne pourrait pas permettre de lire des vidéos au format voulu dans Godot ? Rien n'existe encore pour ça dans la communauté ?

Je prends un exemple. Au taf, on a eu besoin de streamer de la vidéo capturée depuis un PC vers un "écran" dans Unity. Or, on a rien trouvé dans Unity pour encoder de la vidéo (a priori, il peut décoder/lire mais pas encoder/compresser). Alors, j'ai compilé le projet libvpx de Google (open source) et j'ai fait une DLL wrapper en C/C++ pour avoir un minimum de fonctions qui font tout le travail d'encodage et décodage. Ensuite, j'ai fait un binding en C# de ma DLL pour appeler le code C/C++ depuis Unity. Et bingo : Unity était capable d'encoder et décoder le flux vidéo grâce à ma DLL native.

Le problème que pose cette solution, c'est qu'elle exige de savoir non seulement compiler un projet existant (type libx264), de savoir cross-compiler pour différentes architectures CPU si on veut une solution multiplateforme (x64, aarch64, ...) et de savoir développer en C pour faire un wrapper et minimiser le travail de binding.
Beaucoup de conditions qui ne sont pas à la portée de tous, malheureusement. C'est pourquoi il aurait été intéressant qu'une solution clé en main soit disponible pour Godot mais je n'ai rien trouvé à ce sujet...

Hello !
Citation :
Oui, invoquer une commande system pour lancer une appli tierce fonctionne très bien.
D'ailleurs je fais ça entre autres sur des scripts python ( os.system() ) sur des raspberry pour contrôler des vidéos avec omxplayer en récupérant les infos de sensors branchés sur les gpio.

Mais dans mon cas de vidéos360°/VR, c'est inutile. Photos et vidéos 360° peuvent être comme des "map hdri" (ou textures vidéos mapées sur des sphères) dans l'univers 3D avec autres objets 3D, interactions, boutons, controles de lectures de vidéos, etc.. : un moteur 3D quoi. Donc toujours dans mon cas lancer la vidéo dans un autre lecteur ne sert à rien, je perds "l'interactivité" du moteur.

Très intéressant ton message Bibi09 ! merci !
Cela demande pas mal de taff effectivement
Mais je garde ta soluce au chaud le jour où..

J'arrête de polluer ton topic Redstar avec mes histoires de vidéo dans godot et attend une démo jouable de ton projet avec impatience.


bon blend

Citation :

J'espère que ce sera le cas .

Citation :

Il y a bien "VideoStreamGDNative" dans la documention qui pointe vers ce git, ça semble être un dépendance qui permet de, mais je peux pas l'affirmer.

Citation :

Tu ne pollues pas, si je peux aider à résoudre ton problème, ça peut me faire plaisir .

-----------------------

La solution, je l'avais trouvée, c'était l'outil nommé "OpenSimplexNoise". Cet outil permet de générer une image type nuage (comme on ferait dans gimp), dans lequel on peut régler les paramètres de taille, l'octave, la période, l'éparpillement et le "lacunarity" (mais je ne comprends pas ses effets, qui ressemblent à l'éparpillement).

Un petit code ici.

Afin de le rendre "raccordable", je devais le spécifier, puis "bloquer" l'objet (ou la variable).

Ensuite, il me suffisait de calquer les tuiles selon la plage 0 à 1 d'un des canaux couleur (R,G,B) afin d'avoir quelque chose de plus réaliste. Ensuite faire des "clones" des tuiles du terrain généré et les disposer sur le pourtour.

Voici un exemple de ce que ça donne. Le cadre rouge signifie mon terrain central, ce qui est autour sont les clones de ce terrain.

J'ai encore un peu du mal à maitriser cet outil car rarement, ça me génère des toutes petites îles et ça me provoque des erreurs pour placer les points de ressources terrestre.

Le prochain post, je vous parlerai de l'élaboration des unités et bâtiments et du déplacement Astar.

Bonjour tout le monde,

Donc, la configuration d'une unité:

Tout comme se fut le cas avec le bge, il faut configurer des composant de bases qui constituent l'unité, comme la collision, l'image, l’interaction avec la souris et d'autre choses propre à l'unité.

Et, cette fois-ci, j'ai choisi un noeud 2D classique, j'ai pas besoin de plus car pas de physique (attraction, je parles) nécessaire.

La boite de sélection, c'est pour indiquer quelle unité sera sélectionnée ou non, le sprite animé, c'est pour changer l'image au moment ou l'unité dois tourner avant d'avancer, comme dans l'oeuvre original. L'encadré bleu ciel, c'est ce qui définit la zone de collision, on peut choisir un carré, ou une ellipse, ça dépends ce dont on a besoin. Dans mon cas, j'ai besoin d'un système de collision qui réagira au cadre se sélection que je dessinerai, afin de sélectionner plusieurs unités. Enfin, les deux timers, c'est pour gérer l'intervalle entre la transition d'image et une action.

Tout comme le bge, on peut créer des signaux à la différence que ça fonctionne comme la connexion des actionneurs (actuators) pour générer une action pour le script. Autrement dit, quand je définis un temps x, quand il est écoulé, un signal est envoyé au script pour faire ce que contient le signal (sur BGE, delays = x -> controller en mode script).

Enfin, je définis un groupe sur mon noeud principal pour utilisation ultérieur, je fais pareil sur mon noeud "area". Si j'ai besoin de déplacer mon unité entièrement, ce sera ce groupe là que j’appellerai. Si je dois interagir avec l'unité, ce sera l'autre groupe assigné à mon "area" que j’appellerai.

J’envisagerai de rajouter un second groupe quelque part, afin de filtrer le type d'unité que je veux garder.

Je précise que, dans le noeud "animated sprite", on peut changer la sprite si je génère autre chose qu'un bulldozer. Je précise aussi que le dessin que j'ai réalisé n'est pas définitif, c'est juste pour différencier la seconde unité que j'intégrerai. Il faudra que je fasse de jolies textures quand tout sera au point.