Ma première unité configurée, il me faut maintenant la rajouter sur le terrain. Étant donné que mon unité et mon terrain sont deux scènes séparées, il fallait que je rajoutes quelques lignes de code pour l'intégrer dans ma scène principale.

Un peut comme le très buggé "libload" dans le bge... sauf qu'ici tout fonctionne bien. Et donc, au moment ou je créer une "instance" de mon unité, j'ai tout de même la possibilité de changer ses paramètre à sa création, dans le cas ou je souhaite changer son type et sa vitesse, par exemple. J'en dirai plus, plus tard...

Maintenant, je dois trouver le moyen de faire déplacer mon unité d'un point A à un point B. Suite à mon essais sur un jeu type sid meier, on m'avait parlé du système "Astar" (ou "A*").

J'étais contant de constater, dans Godot, qu'il y a un noeud A* 2D & 3D. J'ai donc utilisé, dans un premier temps, ce noeud. Au départ, j'avais un petit terrain (encadré rouge) de 96 x 96, soit 9216 tuiles. J'ai constaté que le temps de chargement entre l'avant et l'après l'ajout du système Astar était plus long. Que ne fut pas ma surprise de voir le système ne pas tenir le coup quand j'ai dû rajouter mes 8 autres paquets de 9216, pour avoir un terrain de 73728 tuiles, le temps d'attente était irréaliste ! Je ne vous cache pas que j'ai été déçu, j'ai du réécrire et adapter ce que j'avais fais sous le BGE pour ce projet-ci, et j'ai réussi ! Même que mon unité s’arrête si on pointe un terrain impraticable pour lui.

Entre temps, je programmes et configures un cadre de sélection, qui est simplement une zone texturée que je déforme grâce à la souris pour sélectionner les unités qui se trouverons sur son chemin. J'ai également rajouté le quartier général (texture logo Godot) en prenant soin de placer mon bulldozer de départ en même temps dessus.

Mon système Astar fonctionnel et opérationnel, il me faut maintenant faire en sorte que mon bulldozer remplisse ses fonctions de base, à savoir construire des bâtiments, que j'exposerai dans un prochain post.

Je vais donc parler de comment fonctionne le système de construction:

Dans la condition stricte (programmé préalablement) de sélectionner un seul bulldozer,un menu-popup apparaitra pour permettre de choisir quels bâtiments construire.

De manière dynamique, la fenêtre popup est relocalisée et légèrement décalée selon la position dudit bulldozer (en programmation). Les boutons sont rajoutés dynamiquement comme "instances" (soit provenant d'une scène séparée). Cela me permettra d'utiliser ce même popup pour faire un système de filtre s'il y a un type d'unité que je veux exclure de ma sélection (comme dans les jeux présentés dans le premier post).

Chose intéressante dans Godot, c'est que l'on peut faire en sorte d'organiser ses fenêtres, ce qui a pour conséquence que plus de cases sont rajoutées, plus la fenêtre s'adaptera, c'est-à-dire qu'elle se redimensionnera d'elle même, grâce au Vbox container. Les boutons sont rajoutés dans le "grid container", afin de les positionner correctement et proprement.

Dés que j'ai choisi le bâtiment de mon choix, la deuxième étape consiste à le placer, mais le système doit être suffisamment intelligent pour autoriser/interdire le joueur de construire là où c'est possible. un cadre séparé en "tuiles" apparait et marque les zones possibles/impossibles. Si toutes les zones ne sont pas valide, pas possible de construire.

Dans la programmation, je dois faire en sorte que là où se trouve la zone n°x, la tuile de la carte est un terrain constructible, sinon, on bloque.

Je cliques simplement sur un terrain valide, des "drapeaux" (temporairement logo Godot) apparaissent pour montrer le chantier et j’exécute le système Astar et je rajoutes les points de passage de construction pré-calculés, que je rajoutes à la fin de ma liste des points calculés par l'Astar.

Une fois le dernier point atteint, le chantier est considéré comme terminé, les drapeaux laissent place au bâtiment fini.

J'ai oublié de préciser quelque chose: dans mon cas, pour éviter de pouvoir construire un bâtiment part dessus, de réassigne les case du terrain désiré en zone infranchissable pour donner l'illusion que le bâtiment est un obstacle. Car si ce dernier venait à être détruit, il faudra alors remettre ces zones infranchissables comme avant.

Je dois maintenant programmer le contrôle de la camera: je dois d'abord vérifier que j'ai bien les contrôles normalement présent de base et si nécessaire, les rajouter/modifier. Il me faut aussi vérifier les appellations pour que cela concorde dans mes lignes de code.

Je créer un script pour la camera, je configure la vitesse de défilement et la coordination des touches clavier est c'est réglé. Le problème est maintenant le suivant: comment faire pour faire en sorte que je puisse faire le tour du monde ?

Pour cela, il faut deux éléments, trouvé après quelques jours de recherche et des soumissions de questions: un terrain raccordable et une repositionnement camera. Je demande donc à Godot, que si j’atteins un pixel particulier, ou une plage de pixel, au prorata de la résolution d'écran, de "téléporter" la camera à l'autre bout de la map à un pixel précis afin de donner l'illusion de l'on à fait le tour du monde.

De plus, il faut téléporter les unités/bâtiments de la même manière, ainsi que de recalculer les chemins Astar des unités en mouvement, pour que l'illusion soit totale. Donc là, je viens de décrire comment on fait un jeu type Sid meier. Donc dés que la camera se fait téléporter, il faut aussi envoyer des signaux à gauche et à droite, afin de faire le nécessaire pour les repositionner.

À ce stade là, mon jeu est exploitable: on peut faire le tour du monde, on peut construire des bâtiments et on peut faire voyager son bulldozer.

Mon prochain épisode, je vous expliquerai comment j'ai construis mon deuxième bâtiment, qui génère un camion benne et qui va automatiquement à la mine la plus proche. C'est là où je me suis arrêté pour le moment.

Je vais commencer à parler plus technique.

Bonjour tout le monde,

Donc, comment rajouter un deuxième bâtiment, qui permet de générer des ressources ? Premièrement, il me faut rajouter des mines dans lesquelles je pourrai aller chercher du minerai, le déposer au haut fourneau pour générer du métal. Dans un premier temps, quand le jeu démarre, il me faut rajouter sur la carte ces points stratégiques. Dans le cas des ressources, il faut qu'ils soient disposés aléatoirement mais suffisamment proche de mon point de départ. Il me faut donc établir un périmetre.

Voici la partie code.

La première partie, je me réfère à la position de mon QG, que je convertis au format de ma tilemap et je rajoutes +10/-10 pour créer mon périmetre. Ensuite, je place tout ces nouvelles coordonnées dans une liste. Je fais en sorte de générer une seule mine pour le moment puis je prends au hasard un point ou place ma mine. Si ce point est un point de type "terre" (donc valide), je vérifies que les autres cases environnante sont du même type et je rajoutes un point de validité.

Si ce point de validité atteint 9 (car 9 cases) après vérification, le terrain est valide, je peux générer la mine, sinon, je chercher un autre emplacement valide. Dans les deux cas, je supprime le point pour éviter les répétitions/chevauchements.

Ensuite, je programme l'ajout du bouton du haut-fourneau (dans un autre script). Je valides la construction du chantier (le code qui permet cela a déjà été fait pour l'habitation, donc c'est le même pour ce bâtiment-ci) et une fois que le véhicule a fait son chemin, je supprimes les drapeaux chantier et je génère le bâtiments, avec un camion-benne. Résultat en pratique.

Remarquez que je réutilises le logo de Godot (ici inversé, par dessus le bâtiment), c'est temporaire.

Dans la suite, je vous expliquerai comment j'ai automatisé le camion-benne pour qu'il fasse son travail comme un grand.

Ok, donc l'automatisation du camion benne une fois généré:

Mon système Astar est fonctionnel, il faut que je fournisse un chemin de son point de départ à la mine la plus proche.

Le code.

Pour cela, je dois initialiser la recherche de cette mine. J'ai choisi de temporiser entre l'apparition du camion et son action. La fonction qui se lance une seule fois (ready) est parfaite pour ça, je n'ai besoin que d'une "impulsion". Je configure un timer qui est lié à mon script. Quand le timer est écoulé, il doit envoyer une impulsion (signal timeout) à mon script afin de lancer la série d'action à faire.

Dans cette impulsion, je demandes à mon camion de créer une liste temporaire de toutes les mines présente sur la carte, et la distance entre le camion et chacune d'entre elles (je n'ai qu'une mine présente mais peu importe). Dans la recherche, je demandes de filtrer les "objets" ayant la propriété "mine" puis de les rajouter dans la liste.

Ensuite, quand la recherche est terminée, je demandes de choisir la mine la plus proche et je demande à faire le calcul Astar vers cette dernière. Je rajoute un pixel exprès afin que le camion arrive juste en dessous du tapis roulant de la mine (quand j'aurai réalisé la texture).

Le chemin calculé et validé,le véhicule peut se mettre en route. Tant que ce dernier n'a pas atteint le dernier point de passage (la mine), il continue sa route. Quand il arrive, et comme il n'est pas chargé en minerai, il change son statut, recherche son haut-fourneau assigné et retourne à celui-ci pour y décharger sa cargaison.

Quand il arrive à son haut-fourneau, je lui demande de se retourner, décharger sa cargaison puis recalculer le chemin vers la mine. La boucle est bouclée.

Pourquoi n'ai-je pas fais en sorte de garder en mémoire la position de la mine au lieu de recalculer ? Et bien si jamais cette mine venait à être détruite, il y aurai une incohérence visuellement, puisqu'elle n'existe plus. Donc le camion recherchera une autre mine.

Bonjour,

Je viens de terminer à peaufiner la création de la raffinerie. Cette fois, c'est un peu compliqué: le dilemme consiste à contraindre la construction de ce bâtiment uniquement sur des cases de côte dont seul 3 cases doivent être valide comme côte tandis que le reste non. Ce fut un peu difficile à trouver la bonne manière mais j'ai finalement trouvé en fonctionnant de manière méthodique: tout d'abord, dans le cas ou le joueur désire construire la raffinerie, je dois séparer le mode de vérification en conséquence.

Ensuite, je dois faire en sorte de vérifier un-par-un les cases en rajoutant une case d'eau alentour. Si cette case est sur la terre et que la case voisine est une case d'eau, je signale l'emplacement comme valide, je rajoute ce point dans une liste. Si la position n'est pas valide, on la marque en rouge, sans plus

Dans le cas ou 3 zones dans la même direction sont valide, il faut s'assurer que cela reste le cas au moment de lancer le chantier, c'est la deuxième étape.

Concrêtement, voilà ce qu'il se passe.. Ensuite,dans le cas ou rien n'est valide. Pour terminer, quand c'est valide.

Il me reste à présent à rajouter le pétrolier, qui fonctionnera exactement comme le camion-benne, à la seule différence que ce pétrolier se déplace sur l'eau et non la terre. Donc je devrai rajouter quelques lignes dans mon algorithme Astar pour filtrer dans le cas d'une unité de type pétrolier.

Yop,

Bon, problème grave: je n'arrive pas à faire générer une carte cohérente sans avoir un raccordement cohérent.

Le premier cas.

Beaucoup de tutoriels explique ce concept, il fonctionne, mais ce dernier n'est pas raccordable. Par contre, j'ai le résultat attendu.

Le deuxième cas.

Je peux exploiter la fonction raccordable, mais impossible d'avoir le même résultat que le mode sans, j'ai tout le temps des formes "sinusoïdales" ou je peux seulement obtenir des pangées (méga-continants).

Je n'ai trouvé aucun tutoriels qui traite de ce sujet à ce jour...

À noter que dans le deuxième cas, j'ai réactivé les bords alentours pour bien montrer la différence.

Si j'analyse la situation, la différence se trouve dans l'utilisation des informations: dans le premier cas, j'ai des informations de type [-1, 1]. Dans le deuxième cas, j'ai des information type RVBA [0, 0, 0, 1.0]. Parce que je demande de convertir l'image en "raccordable", le deuxième cas est considéré comme une image, et non comme des "coordonnées".

Je vois vraiment pas comment je peux m'arranger pour raccorder quelque chose comme le premier cas... Oui, je peux envisager de disposer les coins en miroir, mais ça va casser l'illusion quand on veut parcourir le monde...

Il me manque un détail, ça devrait être possible d'arranger ça ! Comment ? Là, je sais pas...

Bonjour Redstar.

J'avais ce genre de problème avec le filtre "raccorder" de gimp car il fait un dégradé de raccord beaucoup trop visible entre le bord et le centre de l'image.

Ma solution est d'appliquer le filtre "raccorder" sur une copie de l'image placée en calque supérieur, puis de gommer avec dégradé vers le transparent cette copie pour n'en garder qu'un bord, enfin quand la gomme me convient je finis en associant les deux calques.


Par rapport à ton projet je me demandais donc si tu pouvais faire le même genre de dégradé ? avec la solution 1 non raccordable au centre qui se dégrade vers la solution 2 raccordable aux bords ?

Salut sbkodama,

L'idée est bonne mais ça ne semble pas s'appliquer chez moi, car la retouche n'est pas à faire à la main et c'est aléatoire.

À moins qu'il faille mettre un algorithme bien compliqué en place pour détecter et réattribuer les cases, ce qui me semble trop compliqué.

Je vais tenter de partir sur une carte (avec un seed) fixe pour commencer.

Vas-y pour relier ça de manière cohérente...

Comment ont-ils fait sur le jeu original ? Si ils ont réussis, je dois pourvoir le faire aussi...

Voilà, j'ai enfin résolu le problème, enfin... partiellement.

J'ai généré une texture d'un nuage raccordable sur Gimp et j'ai utilisé ses données pour générer mon terrain.

Ayant comparé les deux solutions visuellement, quelque chose n'est pas logique dans le rendu dans godot: j'ai tout le temps que 3 modes de rendu.

J'ai une carte logique et relativement jolie ainsi que raccordable. Cela dit, le problème est que je dois dépendre d'une texture fixe pour générer une carte, qui n'est plus procédural du coup, ou partiellement !

Je suspectes sérieusement que la fonction raccordable dans le code source de l'Open Simplex Noise n'est pas au point.

Maintenant, je vais pouvoir continuer.