Discussion :

[xZene]

Bonjour, dans le cadre d'un exercice je dois coder le jeu d'Othello (Enfin c'est le Reversi qui est apparemment une variante). J'ai un problème lorsque je veux capturer des pions, quelques fois les pions ne sont pas capturés et d'autres fois ils sont capturés je ne sais pas trop comment.

Voici mon code pour la capture (Avec une explication en dessous):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
int capture(plateau p, int x, int y, int couleur){
  int i,j;
  p[x][y] = couleur;
  int points = 1;
  p[x][y] = couleur;
  if(p[x-1][y] != couleur){
    for(i=x-1; i > 0; i--){
      if(p[i-1][y] == couleur && p[i][y] != couleur && p[i][y] != VIDE){
	while(i < x){
	  p[i][y] = couleur;
	  if(est_coin_plateau(i,y))
	    points += 3;
	  else{
	    if(est_bord_plateau(i,y))
	      points += 2;
	    else
	      points ++;
	  }
	  i++;
	}
      }
    }
  }

Je n'ai pas mis tout le code parce que juste cette partie est pour la capture d'un pion sur la gauche et le reste suit le même schéma (Sauf pour les diagonales où j'utilise le j en plus).
Le plateau est juste une matrice[8][8]
x & y sont les coordonnées en paramètre, là où on placera le pion pour capturer les autres (Une fonction coupvalide vérifiera que cet emplacement est possible)
couleur est égal à NOIR ou BLANC qui sont juste des int (0 et 1) tout comme VIDE (qui doit être 2).
La fonction renvoie le nombre de points issus du plateau après la capture (C'est pour que l'IA choisisse la bonne option).

Comme dit précédemment, cette fonction a quelques soucis, je pense que la manière de capturer n'est pas optimale mais j'avoue ne pas trop savoir comment faire.

Egalement si quelqu'un peut m'expliquer pourquoi je ne peux pas remplacer les "if est coinplateau ..." par une fonction dans laquelle il y a ces tests (Qui me permet de rendre le code de capture un peu moins chargé).

Merci de votre aide et bonne journée !

[Sve@r]

Bonjour

Bonjour, dans le cadre d'un exercice je dois coder le jeu d'Othello

Intéressant car c'est un jeu qui ne paye pas de mine mais que j'aime beaucoup. A une époque j'ai fait partie de la FFO, je faisais des compétitions et j'ai été classé dans les 30 premiers français (enfin 30° quoi)

(Enfin c'est le Reversi qui est apparemment une variante).

Exact. dans Othello un pion posé retourne dans toutes les directions possible, dans Reversi le joueur choisit la direction dans laquelle il veut retourner.

J'ai un problème lorsque je veux capturer des pions, quelques fois les pions ne sont pas capturés et d'autres fois ils sont capturés je ne sais pas trop comment.
Voici mon code pour la capture (Avec une explication en dessous):

Alors déjà tu as deux fois l'instruction p[x][y]=couleur à deux lignes d'écart. C'est pas grave en soi mais ça montre que tu codes sans trop savoir où tu vas et donc tu as de grandes chances d'aller dans le mur. On a presque l'impression que tu réfléchis la ligne suivante au fur et à mesure que tu écris la ligne courante tandis que tu as déjà oublié la ligne précédente. Un code ça se réfléchit d'abord par un algo.
Et donc fatalement je ne pige pas trop ta logique. Par exemple pourquoi tu testes if(p[x-1][y] != couleur) spécialement ???
A partir du pion posé, et en partant du principe que le retournement est possible, c'est à dire que la ligne n'a pas de trous et qu'à l'autre bout il y a un pion de la même couleur (ce que doit normalement vérifier la fonction "coupvalide" dont tu parles), alors il suffit de boucler tant qu'on n'est pas sur une case de la même couleur que le pion posé (c'est donc qu'on est sur la case adverse) et on inverse simplement la case. Pas besoin de tous ces tests comme "estCoin()" etc car justement si au bout de la ligne il y a un coin alors le retournement n'est pas possible donc le pion ne peut pas être posé et donc la fonction n'est même pas appelée.

Egalement si quelqu'un peut m'expliquer pourquoi je ne peux pas remplacer les "if est coinplateau ..." par une fonction dans laquelle il y a ces tests (Qui me permet de rendre le code de capture un peu moins chargé).

Rien compris puisque je vois dans ton code if(est_coin_plateau(i,y)) qui montre que justement tu passes déjà par une fonction. Tu veux donc remplacer une fonction qui fait un truc par une autre qui fait le même truc ?
Accessoirement je ne vois pas pourquoi trouver un coin pendant le retournement (ce qui n'est pas possible) devrait être avantageux pour le joueur (parce que c'est ça que tu fais avec ton if(est_coin_plateau(i,y)) avec "i" qui varie).
C'est si le pion posé est dans un coin que c'est avantageux, en revanche si je pose un pion et qu'à l'autre bout de la ligne il y a un coin ben je m'en bats le steak. Certes si on est sur une ligne alors on peut se dire que la ligne devient définitive mais justement la ligne l'était déjà avant qu'on pose le pion (qui n'est donc qu'un pion de plus sur une ligne déjà connue comme étant définitive). Et si on est sur une diagonale et qu'à l'autre bout il y a un coin ben le gain n'est pas vraiment extraordinaire (on peut toujours couper une diagonale).
Tout ça pour dire que je ne vois pas pourquoi, pendant le retournement, tu évalues la force des cases retournées. Il faut séparer les actions. Un retournement c'est un retournement, rien d'autre. Et l'évaluation de la position c'est ailleurs que ça se fait (d'autant plus que l'évaluation ne se fait qu'une fois que le retournement est terminé).

[xZene]

Intéressant car c'est un jeu qui ne paye pas de mine mais que j'aime beaucoup. A une époque j'ai fait partie de la FFO, je faisais des compétitions et j'ai été classé dans les 30 premiers français (enfin 30° quoi)

Solide ! J'ai fait quelque parties en ligne et c'est un jeu plutôt amusant et qui est plus dur qu'on ne le croit.

Alors déjà tu as deux fois l'instruction p[x][y]=couleur. C'est pas grave en soi mais ça montre que tu codes sans trop savoir où tu vas et donc tu as de grandes chances de partir dans le mur.

J'ai mis 10 minutes à comprendre cette phrase avant de voir que j'avais fait une erreur de copier / coller

A partir du pion posé, et en partant du principe que le retournement est possible, c'est à dire que la ligne n'a pas de trous et qu'à l'autre bout il y a un pion de la même couleur (ce que doit normalement vérifier la fonction "coupvalide" dont tu parles), alors il suffit de boucler tant qu'on n'est pas sur une case de la même couleur que le pion posé (c'est donc qu'on est sur la case adverse) et on inverse simplement la case.

Alors le problème vient peut-être de ma fonction coupvalide... Dans le doute je te la pose, elle marche bien mais c'est possible qu'elle soit améliorable !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
int coupvalide(plateau p, int x, int y, int couleur){
  int i,j;
 
  /* On regarde si le coup est valide (Case remplie = Coup non valide) */
  if(p[x][y] != VIDE)
    return 0;
 
  if(p[x-1][y] != couleur){
    for(i=x-1; i>0; i--){
      if (p[i][y] == VIDE)
	break;
      if(p[i-1][y] == couleur && p[i][y] != couleur)
	return 1;
    }
  }
/* Test des autres directions */
 return 0;
  }

(Encore une fois je n'ai pris qu'une partie du code)

Pour ce qui est du coin_plateau il est juste là pour attribuer plus de points à un pion se trouvant dans un coin pour que dans une autre fonction (evaluation) j'attribue un nombre de points pour le plateau par rapport au nombre de pions sur l'othellier, à l'avantage de la mobilité, au nombre de pions définitif, ...J'avais fait une fonction "comptepoints" qui devait se charger de cela mais lorsque je la mettais les pions ne se retournaient pas !

[Bousk]

Cete fonction marche bien ?
Comment as-tu vérifié cela ?
Je vois une fonction qui vérifie une unique direction (l'horizontal gauche je dirais) et ne retourne pas toujours une valeur. Ce qui devrait au moins générer un warning et est une erreur.

[xZene]

Cete fonction marche bien ?
Comment as-tu vérifié cela ?
Je vois une fonction qui vérifie une unique direction (l'horizontal gauche je dirais) et ne retourne pas toujours une valeur. Ce qui devrait au moins générer un warning et est une erreur.

Puisque je test toutes les directions ça fait à peu près une soixantaine de lignes (J'aime beaucoup sauter des lignes) c'est pour ça que je n'ai mis qu'une seule direction, toutes les autres étant similaire en terme de code (Au lieu d'avoir x+1 et des x-1, etc) mais il est vrai que j'ai tout de même oublié de mettre le return 0 à la toute fin. Désolé si ce n'était pas clair ! (Je viens de modifier pour que ce soit plus compréhensible)

[Sve@r]

Solide ! J'ai fait quelque parties en ligne et c'est un jeu plutôt amusant et qui est plus dur qu'on ne le croit.

Oui. Il y a 3 phases d'apprentissage de ce jeu
1) je tente de retourner le plus de pions à chaque coup
2) je tente de gagner les bords et les coins
3) j'ai enfin compris que 1 ça marche pas et 2 c'est pas garanti (il y a même une ouverture où on donne un coin à l'adversaire au 3° coup mais malgré ça, si on joue bien, on gagne quand-même la partie) et que pour gagner il faut gérer la mobilité (nombre de coups possibles pour soi et pour son adversaire car moins il a de coups possibles plus il a de chance de devoir jouer une mauvaise case), la parité (qui doit jouer le premier dans une zone fermée pour pouvoir jouer le dernier) et enfin je sais jouer.

PS: Il y a tout de même un cas où 2 ça marche: c'est quand on réussi un béton
Un béton c'est arriver à tenir toute une région sur un bord avec exclusivement des pions à soi. L'adversaire n'ayant pas de pion lui permettant de retourner en intérieur doit fatalement jouer en bordure perdant sa mobilité ce qui l'amène à moyen terme à donner le coin associé au bord bétonné. Et là c'est l'hallali (ça donne des scores comme 59/5 ou même 64/0. Mais si le béton rate, c'est la cata (le même score mais dans l'autre sens).

Alors le problème vient peut-être de ma fonction coupvalide... Dans le doute je te la pose, elle marche bien mais c'est possible qu'elle soit améliorable !

Oui, je pense qu'on peut l'améliorer. Déjà là aussi je ne comprends pas ce premier test if(p[x-1][y] != couleur). Pourquoi considérer la première case de façon spécifique ? En programmation, plus on met de cas particulier plus ça complexifie le code. Or pour moi, dans une ligne, toutes les cases (à partir du pion posé) sont pareilles et sont à évaluer de la même façon.

Donc pour l'améliorer je pars du principe que non seulement pour pouvoir poser un pion il faut que la case soit libre, mais en plus il faut pouvoir retourner dans une direction.
Donc perso j'écrirais une fonction "isDirectionPossible()" indiquant si le retournement est possible dans la direction demandée. Puis j'écrirais la fonction "isCoupValide()" indiquant si le coup est possible en utilisant alors la fonction "isDirectionPossible() pour ça (suffit d'une direction pour que le coup soit possible).

Cela apporterait alors l'immense avantage de pouvoir réutiliser "isDirectionPossible()" au moment de retourner effectivement.
Ainsi la fonction de retournement serait "si la direction de retournement est possible alors je retourne" sans tous ces tests dont j'ai déjà parlé et qui me semblent inutiles.

Pour ce qui est du coin_plateau il est juste là pour attribuer plus de points à un pion se trouvant dans un coin pour que dans une autre fonction (evaluation) j'attribue un nombre de points pour le plateau par rapport au nombre de pions sur l'othellier, à l'avantage de la mobilité, au nombre de pions définitif,

Oui mais ce n'est pas au moment où on retourne les pions qu'on évalue la position.

...J'avais fait une fonction "comptepoints" qui devait se charger de cela mais lorsque je la mettais les pions ne se retournaient pas !

Dit-il de la façon la plus naturelle du monde. Et tu ne t'es pas dit "hum, peut-être que c'est là le signe d'un problème plus profond" ???

[xZene]

Je pense avoir saisi le truc, j'ai fait une fonction est_direction_possible:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int est_direction_possible(plateau p, int x, int y, int dir, int couleur)

dir est un int qui donnera la direction par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
if (dir == 1){
  i = x + 1;
  while (i < 8 && p[i][y] != couleur){
    if (p[i][y] == couleur)
      return 1;
    i++;
  }
}

Et je fais un return 0 tout à la fin de la fonction au cas où il n'y a pas la direction souhaitée.
Ensuite dans capture j'écris de la sorte:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
/* A droite */
  if (est_direction_possible(p, x, y, 1, couleur)){
    i = x + 1;
    while (i < 8 && p[i][y] != couleur){
      p[i][y] = couleur;
      i++;
    }
  }

Malheureusement les pions ne se font pas capturer, cela vient-il de mon code ou le problème est-il "plus profond" ?

(Je le répète, je n'ai mis que pour la direction droite mais j'ai bien évidemment écrit pour toutes les directions possibles)

[Sve@r]

Je pense avoir saisi le truc, j'ai fait une fonction est_direction_possible:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int est_direction_possible(plateau p, int x, int y, int dir, int couleur)

dir est un int qui donnera la direction par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
if (dir == 1){
  i = x + 1;
  while (i < 8 && p[i][y] != couleur){
    if (p[i][y] == couleur)
      return 1;
    i++;
  }
}

Elle me semble un peu légère. Une direction (sous-entendu de retournement) est possible si à partir d'une case X/Y, il y à n pions adverses terminés par un pion à soi (donc pas de trou au milieu ni de fin de plateau)

Donc ça donnerait

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
int est_direction_possible(plateau p, int x, int y, int dir, int couleur) {
	int trouve=0;
	switch (dir) {
		case 1: // A droite
			// Traitement des pions suivants (qui quoi qu'il arrive, ne dépasseront pas 7)
			for (unsigned short i=1; i < 8; i++) {
				// Si on atteind le bord du jeu ou une case vide, alors le retournement n'est pas possible
				if (y+i >= 8 || p[x][y+i] == VIDE) return 0;
 
				// A partir d'ici, on sait qu'on est sur une case licite (dans les limites) et contenant un pion (donc pas vide)
				// Si le pion testé est de la même couleur que le pion initial
				if (p[x][y+i] == couleur) {
					// Le retournement ne sera possible que si on a trouvé des pions adverses entre temps (et qu'on n'est pas sorti avant évidemment !!!)
					return trouve;
				}
 
				// Le pion testé n'est de la même couleur que le pion initial, la case n'est pas vide, on n'a pas dépassé les limites => il s'agit d'un pion adverse
				trouve=1;
			}
			break;
		case 2: // A gauche
			... (même principe mais là la limite du jeu sera y-i < 0)
		... (etc jusqu'à 8)
	}
 
	// Ici cas extrème (pion posé en début de direction) on a testé toute la direction quelle qu'elle soit et on n'a pas trouvé de situation qui autorise le retournement => retournement impossible
	return 0;
}

Voilà. J'ai pas testé mais ça me semble assez cohérent. Tu remarqueras qu'écrire des commentaires pendant le code aide à la réflexion. Tu remarqueras aussi qu'au lieu de tester si tout est ok, je teste si je trouve "un seul" pas ok et dans ce cas, je me fais pas chier => je quitte la fonction qui est devenue inutile.

De là, la fonction "capturerPion" pourrait-être

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
unsigned short capturer_pion(plateau p, int x, int y, int dir, int couleur) {
	// Si la direction choisie n'est pas possible on ne fait rien
	if (isDirectionPossible(plateau, x, y, dir, couleur) == 0) return 0;
 
	switch (dir) {
		case 1: // A droite
			// Traitement de tous les pions placés dans la même direction mais qui sont de la couleur opposée
			for (unsigned short i=1; p[x][y+i] != couleur; i++)
				p[x][y+i]=couleur;
			break;
		case 2: // A gauche
			... (même principe mais en utilisant y-i
		... (etc jusqu'à 8)
	}
 
	// On renvoie le nb de pions retournés
	return i;
}

Malheureusement les pions ne se font pas capturer, cela vient-il de mon code ou le problème est-il "plus profond" ?

Quelle que soit la profondeur, celle-ci reste quand-même dans ton code. Toutefois tu es en train de refondre tout le principe de ton algo. Cela nécessite donc ensuite de réadapter le reste de ton code avant d'envisager les tests...

[xZene]

Merci pour l'aide je comprends le truc, y'a juste quelque chose qui me chafouine c'est que dans l'exemple tu prends à droite mais tu fais p[x][y+i], ce n'est pas plutôt p[x+i][y] ?

[Sve@r]

Merci pour l'aide je comprends le truc, y'a juste quelque chose qui me chafouine c'est que dans l'exemple tu prends à droite mais tu fais p[x][y+i], ce n'est pas plutôt p[x+i][y] ?

Tout dépend si "x" représente une ligne ou une colonne. Généralement dans les tableaux 2D, la première dimension correspond à la position verticale et la seconde la position horizontale (après tout, une chaine (tableau 1D) ça se voit horizontalement et un tableau de chaines (tableau 2D) seront donc n chaines placées les unes sous les autres) mais ça reste bien entendu une convention et si tu bases tout un code sur le contraire, ça marchera aussi.
Comme je suis parti de cette convention, pour moi aller à droite c'est rester sur la même ligne (ne pas changer la première dimension) et juste modifier la colonne (la seconde) => p[x][y+i]. Si pour toi c'est le contraire alors soit tu changes la position des opérations comme tu l'as fait, soit tu changes juste le commentaire (ce qui aurait été plus logique et plus simple).
En fait, pour respecter à la fois les conventions de la signification des dimensions dans un tableau 2D, et à la fois les conventions mathématiques (x c'est l'horizontale et y c'est la verticale) tu aurais dû nommer ton tableau p[y][x].

[xZene]

Intéressant je ne savais pas ! En tout cas merci pour l'aide, je pense ne plus avoir besoin d'autres questions donc je ferme le topic, encore merci pour l'aide !