Regarde sur le forum du jeu 
Oh là là M Dark, ton projet m’a l’air mal engagé ! Je t’avais dit que programmer un jeu de stratégie était complexe, et je t’avais conseillé d’être particulièrement méthodique si tu voulais en voir le bout…
Et là, je vois que tu n’en as pas tenu compte. Evidemment, c’est toi qui décide… Malgré tout, si tu continues à te dissiper de la sorte, tu risques bien de laisser tomber dans pas longtemps !
Et Colin, qu’est-ce qu’il en pense ? Je croyais qu’il allait t’aider ?
La première chose que je t’avais conseillée, c’est de bien étudier les règles du jeu. Tu n’as pas l’air de l’avoir fait ! Tu dis que tu bloques sur le “système de combat”. Tu devrais d’abord l’analyser, le disséquer et maîtriser son fonctionnement général avant d’essayer de le reproduire dans ton programme…
Le “tour” d’un joueur dans Risk se décompose en 3 étapes ; sur la page de Règles où je t’avais envoyé, c’est écrit tout à fait explicitement :
"Les droits de celui qui joue se décomposent en trois temps :
- FORCES ARMEES
- COMBATS
- DEPLACEMENTS"
C’est écrit dans les règles, il n’y a qu’à lire… Tu l’as vu, ça ? Et tu as pris soin de bien le noter dans ton programme ? (au moins au moyen de commentaires…)
Les Forces Armées, ce sont les renforts ; mais je t’avais dit que tu pouvais éventuellement le laisser de côté au début (surtout si tu as l’intention de reproduire le système de cartes Territoires du jeu original). Dans cette première étape, tu peux te contenter d’inscrire que chaque joueur reçoit un nombre fixe d’armées à chaque début de tour. Disons entre 5 et 10 armées, l’effectif n’a pas tellement d’importance (je te conseille un petit chiffre comme 5, de cette façon les tours seront plus courts, et ton jeu sera plus commode à tester). Il doit ensuite les répartir, de la même façon qu’il l’a fait lors de l’attribution initiale des territoires.
Le deuxième temps d’un tour, ce sont les Combats proprement dit. Là aussi, il y a plusieurs phases que l’on peut distinguer. Premièrement, l’assaillant choisit son territoire attaquant (territoire à partir duquel il lance son attaque), et désigne le territoire qu’il veut envahir (le territoire défenseur) ; ça, tu peux déjà le faire… Deuxième phase, l’assaillant choisit le nombre d’armées qu’il veut (ou qu’il peut) risquer : autrement dit, il choisit combien de dés il veut lancer (1, 2 ou 3). Le défenseur, lui, si son territoire compte plus de 1 armée, peut choisir s’il se défend en force ou non (donc, s’il lance 1 ou 2 dés). Avant de t’occuper du lancer des dés, tu peux déjà travailler à mettre au point ces petites choses (ces deux premières phases me semblent très importantes, puisque ce sera sur ces deux territoires que les variables seront actives). Troisième phase, les dés. C’est vrai que c’est assez compliqué ; je n’ai tellement réfléchi comment je ferai, toutefois, là encore, il faut bien comprendre comment cela fonctionne. Le système de combat dans RISK est basé sur une double comparaison des dés : d’abord, il faut examiner le lancer de chaque joueur (Attaquant et Défenseur) séparément, de manière à pouvoir distinguer le dé le plus fort et le dé le plus faible. Ensuite, comparer les dés les plus forts de chaque joueur et leurs dés les plus faibles. Réfléchis longuement sur ce concept de double comparaison ! Arrête d’utiliser des grands mots vagues comme “système de combat”, observe le comportement des dés dans le jeu original, dissèque chaque phase, et travaille avec méthode.
Enfin, le troisième temps, qui clôt le tour d’un joueur, est le déplacement autorisé (un seul) entre deux territoires contigus.
Cette analyse-là tu aurais pu (tu aurais dû) la faire tout seul, avant de crier au “système de combat”… Il suffit de lire la Règle.
Ensuite, j’ai lu quelques autres âneries dans vos commentaires (y compris ceux postés sur ton forum, M Dark). Loustak, plus haut, parlait déjà de l’IA. Ce serait idiot de travailler sur une intelligence artificielle alors que le système de jeu n’est pas encore au point… Je t’avais conseillé de considérer que tous les joueurs seraient humains, et cela me semble nettement préférable. De toute façon ton intelligence artificielle ne fonctionnera pas si ton sytème de jeu n’est pas stable, et tu auras toutes les peines du monde à tester ton jeu… (si ton IA ne répond pas correctement, tu ne pourras pas faire plus d’un tour de jeu). Aussi, sur ton forum, j’ai lu que tu voulais faire fonctionner ton IA sur la base du hasard. Oh, mais quelle idée ! Tu imagines un jeu d’échecs où l’IA jouerait ses coups au hasard ? Même un débutant n’aurait aucune peine à gagner… Une intelligence artificielle se doit d’être un minimum intelligente… En fait (on y reviendra quand tu en seras là), si tu programmes une intelligence artificielle (à la toute fin du développement de ton jeu) il serait sans doute plus simple d’adapter ton jeu à la variante “front unique”, et de programmer l’IA de façon à ce qu’elle vise ton territoire le moins défendu (et introduire ensuite quelques subtilités…).
Réfléchis à tout cela. Bonnes vacances, M Dark !
Salut m dark pourrait tu créer un bouton ou il y a écrit lancer le dé pour ton jeux j’en est besoin pour le système de combat 
Si tu me le créer ton système de combat sera opérationnelle 
Heu, il n’a pas réussi…
Si je l’ai analysé, et j’y joue aussi chez des amis.
Eh bien j’ai mis de choisir 15 renforts, mais je vais diminuer à 5
Bah c’est pas facile, comment on peut différencier un territoire eloigné à un territoire proche?
oui ça j’ai compris, mais il faut que je fasse la phase 2 (combats) qui n’est pas facile
Je crois que loustak à fais ça, je vais regarder
Oui je vais le prévenir de ne pas faire de IA pour commencer, mais des humains.
Merci
Salut m dark j’ai réussis a faire ton système de combat 
Je le fait pour toute les ville et je te l’envoi
Whaoo Loustak Bravo
Personnellement j’ai été complètement découragé quand m_dark m’a expliqué avec précision ce qu’il attendait après j’ai fais quelque essais non concluants 
Ah M Dark, tu commences à poser les bonnes questions, c’est bien !
Comment faire donc pour qu’un territoire ne puisse attaquer que les territoires immédiatement voisins et pas les autres ? A mon avis pour faire cela, il faudra au préalable établir des connexions de territoires. C’est précisément pour cette raison que je t’ai dit que les 2 premières phases du deuxième temps d’un tour (les combats) sont importantes.
En effet, l’assaillant doit choisir le territoire à partir duquel il attaque (territoire attaquant) et le territoire qu’il veut envahir (territoire défenseur). Donc, concrètement, il doit sélectionner le territoire attaquant puis le territoire défenseur. Chacun de tes territoire est un objet indépendant. Tu peux donc établir des connexions entre ces objets, en écrivant dans ton programme que par exemple, le Territoire A ne peut attaquer que les Territoires B, C ou D. Si ton joueur sélectionne le Territoire A (territoire attaquant), tu dois programmer de manière à ce qu’il ne puisse pas sélectionner un autre territoire que B, C ou D en territoire défenseur. Ainsi, s’il choisit le territoire A, il ne pourra pas sélectionner le Territoire E, N ou W qui se situent beaucoup plus loin.
Tu fais des connexions, tu les regroupes dans une scène à part. C’est un peu fastidieux (surtout si tu as beaucoup de territoires, car tu dois le faire pour chaque territoire). Cependant, ces connexions seront définitives, une fois que tu les auras faites tu n’auras plus besoin d’y toucher.
Grâce au variable, tous se fait manuellement 
Donc c’est vachement plus long mais plus pratique exemple :
*On peut faire le système de combat en calculant a quelle position sont les unité est sur quelle territoire ainsi que son importance(nombre), ça c’est fait
*Sauvegarder les unités+les position dans des variable, a faire mais bientôt fait 
Je vous envoi tous ça dès que fini vous apercevrez que c’est pas si compliquer
Je pense avoir fini dans 1ou2 jours ça dépend si je peut accéder a mon ordi 
Un jeux de stratégie calcul tout, donc il faut tous sauvegarder, il faut donc tous mettre dans des variable différentes et non dans une seul
A oui par contre Je vais créer une nouvelle scène pour chaque territoire ça sera beaucoup plus lisible car avec 32 variable fois 4 sur une page ça fait beaucoup.
(beaucoup de variable seront présente dans ma retouche car il faut tous sauvegarder, charger et modifier, puis il faut les analyser, donc la encore on utilise énormément de variable, et c’est comme ça que j’analyse tout, un problème un arrêt cardiaque, tout et écrit dans les variable, Vive les variable )
Tu me fais peur, avec ton système de variables, Loustak, tu me fais peur…! 
Tu vas mettre des variables partout, et tu trouves que c’est plus “pratique” ? A coup sur tu te trompes ! 32 variables x 4 ? 
Comment tu trouves ça ? Et lorsque tu constateras des bugs, tu seras bien embêté pour retrouver de quelles variables ils proviennent… Il y a fatalement plus simple. Naturellement, chaque territoire étant un objet, il sera soumis à deux variables déterminantes : l’une qui indiquera le joueur auquel il appartient, et l’autre qui indiquera le nombre d’unités qui l’occupe. Ce seront 2 variables d’objet qui doivent suffire. Les autres seront des variables globales qui gèreront les phases de jeu et leur déroulement…
Mais toi, tu comptes faire reposer la possibilité d’attaquer un territoire sur une variable… Mais comment veux-tu faire ? Je suis impatient de voir ta solution ; à mon avis, ton raisonnement est tordu. Pour une raison évidente : en programmation belle et propre (propre est le contraire de sale !), une variable est une valeur qui varie. Or ici, la question de la contiguité des territoires n’est pas une notion flottante. Si le territoire A et le territoire X se trouvent à des endroits de la carte très éloignés, ils ne pourront jamais s’attaquer. Jamais, jamais, jamais. C’est donc plutôt saugrenu, voire ridicule, d’employer une variable pour gérer ce phénomène. Il est beaucoup plus judicieux, clair et conforme à la logique d’utiliser des conditions, qui ne permettent au territoire A de n’attaquer que les territoires à proximité. Si le territoire A est sélectionné, alors seuls les territoires contigus (B, C ou D par exemple) peuvent être la cible de l’attaque.
J’ai une idée pour différencier les territoires de leurs distance :
Réponse : ID
Et oui, si on associe un id à chaque territoire et qu’il est toujours le même (je sais faire) on pourra faire comme tu as dit voyageur : pas avec A B C mais 1 2 3
Heu je fait le système je vous l’envoi est vous me dite ce qui va pas
@Colin : J’en est pavé quand même pour faire ce système
Bon voila c’est pas fini il y a plein de bug mais je vous montre quand même :
toofiles.com/fr/dl/documents/rar/risk.html
Bug a corriger :
*chiffre qui ne s’affiche pas avant ou après le combat
*Système de combat aléatoire
*Impossible d’attaquer ou attaque de ville normalement impossible a attaquer
Voila
Il y a plein de bug mais en cherchant bien ils pourrait être vite corriger
j’aimerai bien tester mais tu n’as pas enregistrer en version portable ou alors tu l’as ouvert et ré-enregistrer après.
A attend je regarde,
Normalement je les juste enregistrer en .gdg mais attend je regarde…
@ Voyageur : Les variable que j’utilise me donne la position des ennemies et ou ils sont répartis sur la carte donc c’est bien plus pratique pour le moteur de combat
A oui est pour infos Je n’est fait le système de combat pour le joueur 1 mais pas pour le joueur 2.
J’ai téléchargé ton système, Loustak, et je suis en train de le regarder. Je n’ai pas encore tout compris, mais je commence vaguement à apercevoir les variables dont tu me parlais.
Pas mal, ton idée de “Socles” ; je dois avouer que je n’aurais probablement pas fait comme ça. Cependant, tu serais gentil de mettre un peu plus de commentaires dans tes événements… J’ai vu que tu as commencé à créer un embryon d’intelligence artificielle, qui place elle-même ses troupes au début. Mais, sans commentaire, j’avais cru au début que ta variable “uniteMoai” désignait dire le nombre d’unités sur Moguany en “affectation initiale”. Donc, “ai”, c’est intelligence artificielle ? Ensuite, tu pourrais expliquer dans un commentaire ce qu’est ta variable globale “no”… Et pourquoi, étant égale à 0 au début, elle prend la valeur 3 pendant les combats. Ce n’est pas une variable qui gère les tours, puisqu’il y en a déjà une.
Je n’ai pas encore eu le temps de tester si ton système de tours de jeu tient la route ou pas… (j’insiste pour dire que c’est vraiment important). Il faudra que je simplifie tes événements pour le vérifier.
C’est une mauvaise habitude, crois-moi, de négliger les commentaires dans un programme ; toi-même, tu risques de ne plus t’y retrouver, plus tard, si tu revois ton programme après l’avoir mis de côté pendant un moment.
Et pour le système de combat, j’ai vu que tu crées des variables globales, du genre “Gu_Moai”. C’est donc avec ces variables que tu comptes gérer les possibilités d’attaques autorisées par la contiguité des territoires ? En fait, le joueur ne pourrait attaquer un territoire que si la variable correspondant à ce binôme est défini… C’est bien cela ton principe ? Je vais y réfléchir encore un peu, mais je reste malgré tout convaincu qu’il est plus simple et plus clair de gérer ceci avec des conditions plutôt qu’avec des variables.
Je veux te féliciter pour ton travail, tu y as visiblement passé du temps.
Elles font vraiment ça, tes variables ? - Je vais voir…
“Plus pratique”, là non plus, ce n’est pas certain…
Il y avait plusieurs solutions j’ai en utiliser une, celle que j’ai le plus l’habitude d’utiliser.
Je rajouterais et perfectionnerait le système dès que je le pourrait.
Pour la variable unite_Moai ça veut dire qu’il y a des unités dans le territoire => moguany et que c’est occupé par l’intelligence artificielle
Mais comme tu a dû le remarquer si tu a tester quand on a fini d’attaquer les territoires ennemie on perd nos troupe, c’est normale car il faut sauvegarder leur position
Voila, et oui j’y est passer pas mal de temps