En cours:
 
 
Use Case
 

 
 
 
un joueur déplace un pion => si le pion peut se déplacer => ajout d'un mouvement, déplacement du pion => prise ou fusion éventuelles. Changement du tour de jeu.
 
 
un joueur déplace une partie d'un pion => si le pion peut se déplacer => création d'un nouveau pion sur la destination (prise ou fusion éventuelles) + effacage des cailloux qui se sont déplacés de la case "origine". Changement du tour de jeu.
 
 
un joueur annule un mouvement => lecture du dernier mouvement, effacage des pions se trouvant sur "origine" et "destination", replacement des pions qui s'y trouvaient.
 
 
le joueur sauve une partie => transcription des mouvements dans un fichier.
 
 
le joueur abandonne => sauvegarde éventuelle de la partie, remise à zéro des mouvements
 
charger une partie => lecture du fichier de sauvegarde et effectuage des déplacement séquentiellement => création des MOUVEMENTS
 
 
déplacement impossible si:

• obstacle sur le chemin
• mise en échec de son dernier roi à cause du déplacement
• fusion impossible
• fusion avec le dernier roi (=> plus de roi présent après la fusion)

 
 
 
 
*************************************************************
 
Youp tout le monde,
 
 
Je voudrais faire un chty jeu, mais voilà, je ne suis pas très doué... et je voudrais apprendre à programmer "comme il faut".
 
Alors je me dis que si je "construis" mon jeu ici, les Grosses Brutes que vous êtes pourriez me corriger.
 
 
 
Je précise que ce n'est pas un travail pour l'école et que je ne vous demande surtout pas de me pondre du code.  
 
En fait, je voudrais juste savoir si ma façon de concevoir et de coder le programme est correcte.
Bien entendu, je ne serais pas contre un conseil concernant un algo ou autre
 
 
Mais je n'en suis pas encore au code puisque je n'ai que les règles du jeu:  
 
 
 
 
Jeu : Cheago
 
 
 
les règles du jeu viennent d'une revue sur le Jeu de GO via un copain.
 
En gros, c'est un jeu d'échecs qui se joue sur un plateau de GO.
 

Plateau :
 

 
 
les pièces:
 
Une pièce est un ensemble de cailloux qui se trouvent sur la même case.
 
 

Déplacements:
 
Une pièce peut se déplacer dans une direction s'il possède un caillou indiquant cette position.
 
 
 exemple: la pièce en A5 ne peut se déplacer qu'en A4
 
 
 
Une pièce se déplace normalement d'une case
 
Si un pion possède un "caillou central", il peut se déplacer d'un nombre quelconque de cases.
 
 exemple:  
             

• la pièce en A6 est une Tour

• la pièce en B6 est un Fou

• la pièce en C6 est un Roi

• la pièce en D6 est une Dame  

• la pièce en A5 est un pion  

 
On peut déplacer une partie d'un pion MAIS il faut qu'on ait toujours un Roi à la fin de son tour.
 
 exemple: on pourrait ne déplacer que le caillou en haut à droite de B6 en C5 (cfr. fusion)
 
 

Fusions:
 
Des pions de la même couleur peuvent fusionner (uniquement s'ils n'ont pas de cailloux communs).
 
 exemple: la pièce en B6 peut se déplacer en A5 ou en C5
 
 
 
Prises:
 
la pièce se déplaçant sur la pièce adverse "prend" ce pion.
 
 
 
 
Le but du jeu est de mettre le Roi adverse MAT.
 
 
*****************************************************************************
 
 
 
Choix du langage
 
Alors pour le langage, j'ai choisis le C++ avec SDL.
 
Pourquoi le C++ ? parce que je connais un peu puis parce que ça à l'air de ne pas être un trop mauvais choix pour faire un jeu.
 
 
Pourquoi SDL ? parce que c'était SDL ou ALLEGRO et que SDL "serait" plus polivalent (moins orienté uniquement jeu).
 
 
 
Objectifs:
 
faire le jeu.
 
faire un mode réseau.
 
faire une intelligence artificielle.
 
 
 
 
Alors GO, c'est parti...
 
 
 
Je me donne une semaine pour modéliser un peu le bidule (j'suis un peu lent ).
 
 
 
ps: si vous avez des remarques, n'hésitez pas

SDL moins orienté jeu? Oui, c'est vrai... mais puisque tu veux faire un jeu, justement!
 
Au fait, tu y as déja joué a ton jeu? ( sur plateau, je veux dire )

yop,
 
 
ben je voudrais pouvoir faire d'autres "types" de programme par la suite, d'où le choix de SDL.
 
sinon j'ai joué à mon jeu sur une version en VB que j'ai faite, parce que c'est vite fait en VB et surtout que sur plateau c'est très chiant à jouer.
C'est là : http://belgibique.be/downloads/Cheego.zip (programmé à la va vite comme un porc que je suis )

bon je pense qu'il me faudra deux classes:
 
 
PLATEAU

• tableau 6x6 de caractères (b = piece blanche; r = roi blanc, n = piece noire, K = roi noir, "" = case inoccupée)
• nombre de roi noir
• nombre de roi blanc
• tour de jeu (au tour de blanc ou de noir de jouer)

 
methodes:

• changer valeur d'une case du tableau
• lire "nombre de rois noirs"
• lire "nombre de rois blancs"
• changer valeur "nombre de roi noir"
• changer valeur "nombre de roi blanc"
• dire si trajet libre d'un point A à un point B (pour déplacer un pion)
• dire qui occupe une case
• changer le tour de jeu
• afficher

 
 
PIECE

• tableau 3x3 (1: case occupée par un caillou, 0 sinon)
• nombre représentant la piece: 1 et 0 du tableau mis bout à bout et transformé en décimal (permettra avec un XOR d'une autre piece de savoir si elle est fusionnable)
• nombre de cailloux
• position

 
 
méthodes:

• création nouvelle piece
• detecter si la piece est un roi
• deplacement "complet"
• deplacement "partiel" (tous les cailloux ne sont pas déplacés)
• fusion
• mourir
• modification tableau (pour fusion et déplacement partiel)
• modification nombre représentant la piece
• lire nombre de cailloux
• modifier nombre de cailloux
• afficher

• convertir "nombre binaire" en décimal
• convertir décimal en "nombre binaire" (000101001)
• extraire le nombre de 1 d'un "nombre binaire"
• extraire le nombre de 1 d'un décimal.

 
Déplacement de A à B:
 
A.nombre1:B avec nombre1 correspondant aux pierres qu'on veut déplacer (nombre "binaire" )
 
ex: B1.000000001:C2 => déplacement du caillou inférieur droit de B1 en C2
 
 
 
faut que je réfléchie un peu (du verber réfléchier) pour voir si je n'ai rien oublié...

Pourquoi le plateau ne serait pas un tableau 6x6 de pièces ?
Si la case est vide, c'est qu'il n'y a pas de pièce sur la case.

 
je ne comprends pas la question.
 
le plateau est  

Désolé, je croyais que les classes n'étaient pas fixées    
 
Je proposais un plateau de ce style :
piece* plateau[6][6];
 
Avec des NULL aux cases vides. Sinon un pointeur sur la pièce qui occupe la case.

Vous pouvez pas faire un diagramme de classes qu'on y voit quelque chose

bah pour le moment, y a pas grand chose à voir

 
 
yop ca a l'air pas mal vu comme ca
 
 
 
alors:
 
PLATEAU

• tableau 6x6 pointeurs vers PION
• nombre de roi noir
• nombre de roi blanc
• tour de jeu (au tour de blanc ou de noir de jouer)

 
methodes:

• changer valeur d'une case du tableau (pointeur)
• lire "nombre de rois noirs"
• lire "nombre de rois blancs"
• changer valeur "nombre de roi noir"
• changer valeur "nombre de roi blanc"
• dire si trajet libre d'un point A à un point B (pour déplacer un pion)
• changer le tour de jeu
• afficher
• désafficher

 
 
PIECE

• couleur
• tableau 3x3 (1: case occupée par un caillou, 0 sinon)
• nombre représentant la piece: 1 et 0 du tableau mis bout à bout et transformé en décimal (permettra avec un XOR d'une autre piece de savoir si elle est fusionnable)
• nombre de cailloux
• position

 
 
méthodes:

• création nouvelle piece
• detecter si la piece est un roi
• deplacement "complet"
• deplacement "partiel" (tous les cailloux ne sont pas déplacés)
• fusion
• mourir
• modification tableau (pour fusion et déplacement partiel)
• modification nombre représentant la piece
• lire nombre de cailloux
• modifier nombre de cailloux
• afficher
• désafficher

• convertir "nombre binaire" en décimal
• convertir décimal en "nombre binaire" (000101001)
• extraire le nombre de 1 d'un "nombre binaire"
• extraire le nombre de 1 d'un décimal.

 
ben en fait, je sais pas trop comment je dois faire ca
 
 
je veux bien faire deux rectangles et mettre mes classes dedans... mais après ???
 
c'est en partie pour ca que j'ai fait ce topic: pour qu'on puisse un peu m'orienter

C'est sympa comme jeu. Ca ressemble aux échecs. Mais le coup des fusions ça permet de faire évoluer une pièce en en sacrifiant une autre....
 
 
Sinon dans ta classe "PIECE" :
- A quoi sert le nombre de cailloux de la pièce ? Si j'ai bien compris les règles, il ne sert à rien. Juste est important de savoir où sont placés les cailloux dans la pièce pour pouvoir la déplacer.
 
- Est-ce utile d'avoir le tableau 3x3 et un nombre construit à partir de ce même tableau ? (Ca fait redondance: A chaque fois qu'il faudra modifier une information, il faudra aussitôt modifier l'autre pour qu'elle corresponde)

ben le nombre de cailloux sert à savoir si on déplace toute la pièce ou uniquement une partie.
 
si le nombre de cailloux déplacés = nombre de cailloux de la pièce => toute la pièce se déplace
 
sinon, il faudra "enlever" les cailloux qu'on veut déplacer et recréer une pièce sur la case "destination" (déplacement partiel).
 
 
pour le tableau et le nombre, c'est vrai que ca fait un peu redondance, mais je pensais que le tableau serait plus facile à remplir.
Et si j'ai une fonction qui génère le nombre à partir du tableau, il suffira que je l'appelle à chaque fois que je modifie le tableau... ce nombre me permettant de savoir facilement si des pions sont "fusionnables".
 
maintenant, je pourrais aussi faire une fonction pour savoir si deux pions sont fusionnables. Donc je me dis que t'as raison
 
donc j'enlève le "nombre spécial" et je fais une fonction "boolean fusionnable()"...  
 
 
 
merci pour tes conseils en tout cas monsieur
 
 
EDIT: je vais mettre les classes dans le premier post, comme ca se sera plus clair je pense...

Me souvenais plus qu'on peut scinder une pièce en 2. Ca ne va pas être évident de programmer la partie "intelligence artificielle"

vi mais ce sera pour plus tard ca...
 
 
par contre, maintenant, je ne sais pas trop ce que je dois faire...
 
je dois faire un diagramme comme kadreg l'a dit ou je commence à programmer ou quoi ?  
 
enfin pour bien faire les choses...

diagramme, comme ca au moins on verra quelquechose.

mais je mets quoi dans le diagramme ?
 
deux rectangles avec les classes c'est tout ?

par rapport au besoin que t'as exprimé lors de ton premier post , je te conseille une disposition comme suit
 
une classe jeu :
   avec au moins une classe ( ou structure à toi de voir )PLATEAU
   ici je parle de structure mais en fait c'est juste pour signaler qu'il est interessant de coder ton jeu en prevoyant une capacité à enregistrer l'etat de la partie à l'instant t ( pour l'intelligenc artificielle, ou les comm reseau )
 
la classe PLATEAU
    comme on l'a définie
 
la classe PIECE
    idem, auquel je rajouterait sans doute un identifiant , permettant ainsi de retarcer facilement le parcourt d'une priece, le pointeur c'est bien mais ca fait pas tout.  
A toi de décider qui donnera l'identifiant , le jeu , le plateau , le joueur ca depend de qui construira la piece, je ne connai pas les regles de GO
Au vue des possibilités de fusion etc , des classes pieces spécialisées sont à creuser
 
le conseil que je te donnerai et de se focaliser sur l'aspect délégation au sein de ton jeu :  
qui organise la partie au début ?
comment s'interfaceront les evts ?  
comment les evts seront t'ils délégués ?
 
partir d'une (super??)classe  jeu , et un moyen de débrousailler otut en pensant à l'IA future , les joueurs n'interagiront pas avec un seul plateau , mais avec le jeu , le jeu pourrait définir les regles ( dans le sens , qui joue , quelle sont les pieces accessibles pour ce joueur )
 
et le plateau srait plus un ensemble de regles pour tes mouvements de pieces ... cette piece peu bouger comme ca ( a toi de voir pour la spe de la classe piece ) , celle ci non ? position possible .. etc  
 
 
voila , ceci n'est que mon avis

en fait, je comptais "stocker" la partie dans un fichier en mettant tous les déplacements effectués.
 
mais c'est vrai que j'ai oublié de dire comment les garder en mémoire pendant le jeu...
 
je devrais aussi garder l'état "précédent" pour pouvoir faire un undo d'un mouvement.
 
 
pour ce qui est des déplacements possibles ou non, je pensais laisser les méthodes "déplacement" des pions gérer ca.
 
 
 
pour ta classe jeu, je vais y réfléchir... j'ai un peu la tête dans le cul la

 
Au lieu de garder l'état, fait une classe mouvement avec la pièce impliquée, l'origine et la destination (+ infos complémentaires), gérées en file. Tu auras un undo/redo pas cher

yop, si c'est pas cher, je prends
 
 
PLATEAU

• tableau 6x6 pointeurs vers PION
• nombre de roi noir
• nombre de roi blanc
• tour de jeu (au tour de blanc ou de noir de jouer)

 
methodes:

• changer valeur d'une case du tableau (pointeur)
• lire "nombre de rois noirs"
• lire "nombre de rois blancs"
• changer valeur "nombre de roi noir"
• changer valeur "nombre de roi blanc"
• dire si trajet libre d'un point A à un point B (pour déplacer un pion)
• changer le tour de jeu
• afficher
• désafficher

 
 
PIECE

• couleur
• tableau 3x3 (1: case occupée par un caillou, 0 sinon)
• nombre de cailloux
• position

 
 
méthodes:

• création nouvelle piece
• detecter si la piece est un roi
• deplacement "complet"
• deplacement "partiel" (tous les cailloux ne sont pas déplacés)
• fusion
• mourir
• modification tableau (pour fusion et déplacement partiel)
• détection fusionnabilité
• lire nombre de cailloux
• modifier nombre de cailloux
• afficher
• désafficher

• convertir "nombre binaire" en décimal
• convertir décimal en "nombre binaire" (000101001)
• extraire le nombre de 1 d'un "nombre binaire"
• extraire le nombre de 1 d'un décimal.

 
MOUVEMENTS
 

• origine
• destination
• tableau piece origine ou équivalent
• tableau piece destination ou équivalent
• mouvement suivant
• mouvement précédent
• couleur origine
• couleur destination

 
methodes:
 

• créer mouvement
• supprimer mouvement

Pas cher pas cher... c'est vite dit
 
Imaginons je fusionne deux pièces pendant un mouvement. Que se passe-t-il ?
Une des 2 pièces est désallouée pour vider la mémoire ? (Il n'y a plus de case qui pointera sur elle vu qu'elle n'est plus dans le jeu)
L'autre pièce est modifiée pour intégrer les cailloux de l'autre pièce.
=> pas de pb
 
Je clique "UNDO"
 
Si pour ton mouvement tu as stocké la case de départ, la case d'arrivée et l'id de la pièce, tu as une chance sur 2 pour avoir l'id de la pièce qui est restée en jeu. Tu ne sais pas qu'il y avait une fusion, ni combien de cailloux ont fusionné pour chaque pièce
 
C'pas évident

C'est pas bon comme j'ai fait la classe mouvement ?
 
si je garde la structure des pions après chaque mouvement ca doit être bon non ?

bon j'ai essayé de faire un premier pitit shémas... mais j'ai pas l'impression qu'il soit bon
 

 
je sais pas trop comment je dois faire interagir le tout

un joueur déplace un pion => si le pion peut se déplacer => ajout d'un mouvement, déplacement du pion => prise ou fusion éventuelles. Changement du tour de jeu.
 
 
un joueur déplace une partie d'un pion => si le pion peut se déplacer => création d'un nouveau pion sur la destination (prise ou fusion éventuelles) + effacage des cailloux qui se sont déplacés de la case "origine". Changement du tour de jeu.
 
 
un joueur annule un mouvement => lecture du dernier mouvement, effacage des pions se trouvant sur "origine" et "destination", replacement des pions qui s'y trouvaient.
 
 
le joueur sauve une partie => transcription des mouvements dans un fichier.
 
 
le joueur abandonne => sauvegarde éventuelle de la partie, remise à zéro des mouvements
 
charger une partie => lecture du fichier de sauvegarde et effectuage des déplacement séquentiellement => création des MOUVEMENTS
 
 
déplacement impossible si:

• obstacle sur le chemin
• mise en échec de son dernier roi à cause du déplacement
• fusion impossible
• fusion avec le dernier roi (=> plus de roi présent après la fusion)

j'ai peut-être trouvé un meilleur diagramme (USE CASE)
 

 
 
en fait, je me rends compte que j'aurais dû commencer par ca...  
 
je vais essayer de le retravailler un peu... sans penser à mes classes...
 
J'ai pas du tout l'impression de faire les choses à l'envers

tu vois moi j'essaierai de modeliser tes regles du jeu sous forme d'arbre , etc , de jouer un peu avec les arbres  
 
dans le genre, on commence la partie , et que ton 'moteur' soit capable de construire les actions, en fonction de ce que tu sais faire

je comprends pas trop ce que tu veux dire.  
 
Enfin ce que je crois comprendre, c'est que je devrais dire:
 
le joueur fait une action, que se passe-t-il ensuite => plusieurs possibilités => je construis un arbre petit à petit comme ca...
 
Mon schémas fait plus ou moins ça non ?
 
 
par contre, j'ai pas du tout compris la fin. Comment faire pour que mon "moteur" construise les actions en fonction de cet "arbre" et comment décrire les règles dans l'arbre...
 
enfin je ne vois pas trop...
 
 
 
Comme j'avais retrouvé un pitit cours d'UML que j'avais eu, je me suis dit que j'allais me baser dessus...
 
Mais tu pourrais un peu m'expliquer ton point de vue parce que j'ai pas très bien compris

si j'ai posté ca, c'est pour metre l'accent sur l'aspect générique d'un choix possible, d'une action de la part d'un joueur.  
 
Moi le seul fait d'être rigoureux de cette façon m'a permit de'évacuer des problèmes : ici chaque action d'un joueur
serait une structure.
 
Le fait d'avoir un seul type de doonnées est un bon critères pour les arbres, ca facilite la com réseau, la gestion de l'IA, etc.
 
pour construire lesrègles au fur & à mesur , un petit automate te ferait ca , que ca soit à base de switch , ou basé sur des graphes non définis qu'importe.
 
la répartition en package est surement une bonne étape pour voir ca, & ce n'est qu'une suggestion.

euh, je ne comprends toujours pas très bien...
 
tu peux donner un exemple de structure qui serait une action d'un joueur. c'est pas très clair pour moi  
 
 
Sinon pour la partie réseau, suffit d'envoyer le déplacement (origine.cailloux:destination) et c'est bon non ?
 
Pour l'IA, je ne sais pas du tout comment faire mais ca ne suffit pas d'avoir la situation sur le plateau ?
 
 
 
 
sinon, j'ai essayé de définir la liste des actions possibles d'un joueur
 
 
Actions Joueur
 
démarrage du jeu

• commencer une partie à 1 joueur
• commencer une partie à 2 joueurs
• initier une partie réseau
• rejoindre une partie réseau
• regarder une partie réseau
• charger une partie

en cours de partie

• déplacer un pion
• déplacer un morceau de pion
• annuler un déplacement
• demander que l'adversaire annule un déplacement (réseau)

"fin" de partie

• sauver la partie
• arrêter la partie
• abandonner la partie
• perdre
• gagner

(

• être coupé (réseau))
• continuer une partie

 
 
 
ps: argh... j'ai pas l'habitude de réfléchier avant de programmer... c'est dur...