Discussion :

[Hemir]

Bonjour,

Le projet que je dois développer porte sur un jeu de cartes (coloretto http://www.trictrac.net/jeu-de-societe/coloretto/infos si ça vous interesse).

Mon problème est que je dois gérer les diffèrent tour des joueur, j'ai pensé a creer u booléen true si c'est son tour false sinon MAIS


j'en suis au début, on peut choisir le nombre de joueur , donner un nom etc...
la les joueur doivent choisir une couleur de départ (j'ai eu la brillante idée de mettre les image des couleurs dans des boutton )

(les bouton j1,j2... était pour des test je mettrais des label avec le nom du joueur & un autre plus grand avec le nom du joueur en cours)

ce que je veux faire : le joueur 1 clique sur un l'image/bouton "rouge", on lui affecte rouge(l'image rouge.Enable=false)
on passe au joueur 2 et ainsi de suite.
ne pas pouvoir choisir 2 fois la même couleur aide, mais je ne sais pas comment affecter

:sachant qu'il y aura d'autre problematique car ces 7 carte font partie d'une pioche qu'il faudra déduire etc... #PasIZI

[egautier18]

Salut,

Je suis désolé je ne comprend pas trop le problème ?
Tu veux en fait affecter une couleur au joueur en cours ?


Il faudrait savoir comment est construit ton objet joueur.
Il faudrait qu'il est une propriété correspondant à un objet couleur.

Tu aurais du coup

Code :

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

Monjoueur1.couleur = MaCouleur;

Si tu as un peux plus de détail sur ton architecture à nous donner.

A+

[Hemir]

(oui en gros c'est ça, mais j'avais pas vu assez loin, parce qu'une couleur es en fait une carte ,qui fait partie de la pioche,
donc il faudrait peut être que je crée ma pioche en 1er.)

pour l'instant je donne a joueur un attribut premCouleur je devrais reussir.

EDIT: bah non, enfait comment je sais a quel joueur j'attribue la couleur dans mes procedure ,
rappel : chaque image est un bouton




comment faire la difference , est ce que c'est le joueur 1 , le 2 ou le 4 ??

RE-EDIT: ah bah oui celui qui a Tour = true

[jopopmk]

Salut,

pour le coup la solution ne serait-elle pas plutôt de mettre les TexBox pour les noms des joueurs sous les cartes.
Si elle est remplie un joueur est associée à la carte, sinon y'a pas de joueur.
Ensuite pour le "numéro" des joueurs je suppose que ça n'a pas tellement d'importance, y'a un tirage au sort pour déterminer l'ordre en début de partie je suppose (enfin j'en sais rien, y'a pas les règles du jeu dans le lien que tu as filé).

[ebastien]

Bonjour,
Faire une propriété Tour sur l'objet joueur n'est à mon avis pas une bonne idée au niveau de la conception. Dans l'absolu cela peut signifier que 2 joueurs pourraient avoir Tour = True et là c'est le drame.
Et puis, cela engendre une gestion fastidieuse. Je ferais plutôt un objet Game comportant la liste des joueurs et une propriété indiquant le joueur dont c'est le tour (un index de la liste ou directement un des joueurs de la liste, à voir).

[Hemir]

Salut,

pour le coup la solution ne serait-elle pas plutôt de mettre les TexBox pour les noms des joueurs sous les cartes.
Si elle est remplie un joueur est associée à la carte, sinon y'a pas de joueur.
Ensuite pour le "numéro" des joueurs je suppose que ça n'a pas tellement d'importance, y'a un tirage au sort pour déterminer l'ordre en début de partie je suppose (enfin j'en sais rien, y'a pas les règles du jeu dans le lien que tu as filé).

normalement celui qui commence c'est celui qui a le plus de couleurs sur ses vêtement, un peu compliqué a mettre en oeuvre,
pour associer la couleur je trouve que l'idée de @egautier18 est mieux, j'ai commencé a la mettre en oeuvre ça roule...
pour les no de joueur ça n'a pas d'importance je commencerai de J1 a J5 ça pose pas de probleme

Bonjour,
Faire une propriété Tour sur l'objet joueur n'est à mon avis pas une bonne idée au niveau de la conception. Dans l'absolu cela peut signifier que 2 joueurs pourraient avoir Tour = True et là c'est le drame.
Et puis, cela engendre une gestion fastidieuse. Je ferais plutôt un objet Game comportant la liste des joueurs et une propriété indiquant le joueur dont c'est le tour (un index de la liste ou directement un des joueurs de la liste, à voir).

"une gestion fastidieuse." j'ai commencé avec "tour" j'aime pas,ça m'a l'air tellement long en plus verifier lequel est vrai , ensuite faire passer au suivant ...

Je ferais plutôt un objet Game comportant la liste des joueurs et une propriété indiquant le joueur dont c'est le tour (un index de la liste ou directement un des joueurs de la liste, à voir).

je vais essayer ça

[jopopmk]

egautier18 te parles de modèle, je te parle d'interface ...
Je vais vous laisser vous amuser

[Hemir]

egautier18 te parles de modèle, je te parle d'interface ...
Je vais vous laisser vous amuser

ah je vien de piger , en gros je mets de picture box et il mettent leurs nom en dessous...
je suis pas encore pressé ou fatigué, mais sinon oui ça contourne le pb de conception que je me suis crée tout seul en mettant des bouton

quand j'e aurait marre ou bloqué je simplifierait peut être mais bon comme ça j'apprend des choses

quand il a cliqué est que c'est disabled (la grise) , magnifique & interactif !!


jveux garder mes bouton

[jopopmk]

Pour le comportement que tu recherches il te suffit de conserver dans un attribut de ta class Form une référence vers le joueur en cours (càd le dernier bouton "Jn" que tu auras cliqué).

Mais pour moi ça reste peu ergonomique. Autre possibilité, en conservant tes "joulis bouton de carte colorées" : quand tu cliques sur ta carte tu ouvres une modale pour demander le nom du joueur. Si l'utilisateur clique sur OK (avec un nom unique non null) tu fais l'association et tu grises la carte, s'il fait CANCEL tu ne fais rien. Tes instances de joueurs (je suppose que tu as fait une classe joueur) devront être mis dans une collection dynamique pour plus de facilité.

[Hemir]

Pour le comportement que tu recherches il te suffit de conserver dans un attribut de ta class Form une référence vers le joueur en cours (càd le dernier bouton "Jn" que tu auras cliqué).

Mais pour moi ça reste peu ergonomique. Autre possibilité, en conservant tes "joulis bouton de carte colorées" : quand tu cliques sur ta carte tu ouvres une modale pour demander le nom du joueur. Si l'utilisateur clique sur OK (avec un nom unique non null) tu fais l'association et tu grises la carte, s'il fait CANCEL tu ne fais rien. Tes instances de joueurs (je suppose que tu as fait une classe joueur) devront être mis dans une collection dynamique pour plus de facilité.

bonne idée pour les user, mais je dois aussi choisir un nombre de joueur entre 3 et 5 (j'etait partit comme ça, je peux changer mais faut prendre en compte un nombre de joueur variable)



"Mes instance de joueur dans une collection dynamique"

objet Game comportant la liste des joueurs

je suis partit sur ça c'est la même chose non ?

[egautier18]

Je pense que le fait de mettre un combo avec 3 et la possibilité de remplir 5 joueurs est perturbant.

En fait, tu peux enlever le combo, et laisser 5 textbox.
Tu remplis le nombre de tes textbox que tu veux (avec une condition minimum de 3) et quand tu appuis sur continuer :

- Tu ajoutes X Objets joueurs à ta liste de joueurs de ton objet Game.
- Tu vas sur ta page avec tes cartes te permettant d'attribuer tes couleurs à tes joueurs fraîchement créée.

- Sur cette page tu mets "Joueur X Merci de choisir votre couleur." (en fonction d'une règle de "qui commence le premier", que tu aura définis).
Une fois qu'il a cliqué
- Tu associes ton objet Carte/Couleur (tout dépend de comment tu gères les choses) à ton joueur X en cours.
- Tu passes aux suivants.

Je sais pas si ma vision est très clair et correspond à tes attentes.
A+

[jopopmk]

Ce que j'appelle une "collection dynamique" c'est simplement un objet du genre List<T> ou Dictionary<K, V>.
A la différence d'un "vrai" tableau il est facile d'y ajouter/supprimer des éléments sans avoir à gérer les trous.
Après que cette collection soit au niveau de ton objet Game semble tout à fait logique.

Pour ton interface j'ai encore des réticences sur les enchaînements et choix ergo, mais je vais pas non plus t'imposer ma vision.
Mais dans ce que tu cherches à faire, le fait que ce soit une collection dynamique intervient dans ton écran "accueil".
Dans ton écran "choix de la couleur" ta modale peut alors proposer une ComboBox avec la liste des joueurs.

[Hemir]

Je pense que le fait de mettre un combo avec 3 et la possibilité de remplir 5 joueurs est perturbant.

c'est dynamique les textBox du joueur 4 & 5 sont visible = false au lancement, s'il choisi 4 je lui affiche la textbox pour le joueur 4 etc...

le fait que ce soit une collection dynamique intervient dans ton écran "accueil".

je m'y colle

Dans ton écran "choix de la couleur" ta modale peut alors proposer une ComboBox avec la liste des joueurs.

la j'ai pas saisi comment ça se présenterait ?
s'il a entré les joueur dans l’accueil, "ta modale" tu entend par là la le choix des couleurs ?

- Tu ajoutes X Objets joueurs à ta liste de joueurs de ton objet Game.
- Tu vas sur ta page avec tes cartes te permettant d'attribuer tes couleurs à tes joueurs fraîchement créée.
- Sur cette page tu mets "Joueur X Merci de choisir votre couleur." (en fonction d'une règle de "qui commence le premier", que tu aura définis).
Une fois qu'il a cliqué

tout ça c'est ok

- Tu associes ton objet Carte/Couleur (tout dépend de comment tu gères les choses) à ton joueur X en cours.

j'ai pas encore fait mes objet carte/pioche
je devrais le faire avant ou bien j'essaye d’implémenter, et je leurs donne un attribut couleurs dans la classe joueur pour l'instant ?
parce que connaitre ça couleurs de départ n'est pas utile au jeux , c'est la même chose qu'une carte lambda qu'il obtiendra dans les manche.
c a d au cours du jeu on ne se souvient pas de notre carte de depart parmis toute les autres carte.


je sais pas si c'est clair...

[jopopmk]

Re,

ce que j'appelle une "modale" c'est une boîte de dialogue modale, ou fenêtre modale, ou popup modale.
En gros un autre Form qui s'affiche par-dessus ton Form principal et bloque l'accès à ce dernier tant que l'utilisateur n'a pas fait un choix.

Pour ton dernier paragraphe : oui, prévois tes modèles avant d'implémenter l'interface, ça devrait simplifier ta réflection sur les IHM.

[Hemir]

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
public partial class ChoixCouleur : Form
    {
        public ChoixCouleur(Game g)
        {
            InitializeComponent();
 
            int nbJoueur = g.ListJoueur.Count();
            MessageBox.Show(Convert.ToString(nbJoueur));
            btJ1.Text = g.ListJoueur[0].PseudoJoueur;
            btJ2.Text = g.ListJoueur[1].PseudoJoueur;
            btJ3.Text = g.ListJoueur[2].PseudoJoueur;           
        }
 
 
 
 
        #region les bouton
        private void btJ1_Click(object sender, EventArgs e)
        {
            //MessageBox.Show(jou1.PseudoJoueur + );
        }

j'ai fait ma classe Game avec ma liste , mais je tombe sur un os.
j'ai fait passer ma liste dans le constructeur de mon nouveau formulaire, mais je sais pas comment la passé a ma procédure événementielle (du bouton, celui la est un exemple mais j'en aurait besoin dans les carte je crois

[jopopmk]

Lorsque tu passes ton objet au constructeur de ton formulaire il faut que celui-ci en profite pour en conserver une référence dans une variable membre dudit formulaire. Ainsi tu pourras y avoir accès de partout dans cette classe.

Sinon, ton instance de Game étant unique pour toute ton appli, je la verrai bien en attribut membre static de ta classe la plus "haute" (genre ton Form principal de démarrage, ou carrément ta classe Program). Pour faire un truc encore plus chiadé tu pourrais même transformer ta classe Game en singleton.

[Hemir]

Lorsque tu passes ton objet au constructeur de ton formulaire il faut que celui-ci en profite pour en conserver une référence dans une variable membre dudit formulaire. Ainsi tu pourras y avoir accès de partout dans cette classe.

ça marche !!

Sinon, ton instance de Game étant unique pour toute ton appli, je la verrai bien en attribut membre static de ta classe la plus "haute" (genre ton Form principal de démarrage, ou carrément ta classe Program).

ça fait un peu plus propre mais je verrait si je change après

Pour faire un truc encore plus chiadé tu pourrais même transformer ta classe Game en singleton.

je savait pas ce qu’étais un singleton , je savait pas ce que voulait dire chiadé non plus

[si quelqu'un lis et perd le fils, j'ai fait des modif on m'a repondu donc j'ai supprimé]

[jopopmk]

Oui, un singleton est une classe comme les autres sauf qu'au lieu de passer par son constructeur tu passes par un accesseur statique, ce qui permettra d'obtenir une même instance (d'où le nom "singleton" ) partout dans ton code très facilement. Si besoin je peux te mettre un petit exemple.

Pour info une variable (ou méthode) statique est une variable (ou méthode) partagée par toutes les instances d'une même classe.

[Hemir]

Pour info une variable (ou méthode) statique est une variable (ou méthode) partagée par toutes les instances d'une même classe.

je l'savait

Oui, un singleton est une classe comme les autres sauf qu'au lieu de passer par son constructeur tu passes par un accesseur statique, ce qui permettra d'obtenir une même instance (d'où le nom "singleton" ) partout dans ton code très facilement. Si besoin je peux te mettre un petit exemple.

je veux bien un exemple, j'aime tout ce qui est trés facile

[jopopmk]

Pas de souci

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
24
25
26
27
28
29
30
31
	public class PersonneUnique {
		// attributs pour l'exmple
		public string nom;
		public int age;
		// méthode pour l'exemple
		public string Affiche() {return "de partout le gars s'appelle " + nom + " et a " + age.ToString() + " ans"; }
		// l'instance statique qu'on retrouvera de partout
		private static PersonneUnique _personne = null;
		// un constructeur qu'on n'utilise pas directement
		public PersonneUnique() {
			this.nom = "";
			this.age = 0;
		}
		// la fonction de récupération/initialisation de l'instance unique
		public static PersonneUnique GetInstance() {
			if (PersonneUnique._personne == null)
				PersonneUnique._personne = new PersonneUnique();
			return PersonneUnique._personne;
		}
	}
 
	// ...
	// n'importe où dans le code : au premier appel ça va instancier le singleton
	PersonneUnique unGars = PersonneUnique.GetInstance();
	unGars.nom = "Jean-Jeacques";
	unGars.age = 12;
 
	// ...
	// n'importe où dans le code : au deuxième appel on récupèrera l'instance initialisée plus tôt
	PersonneUnique unGars = PersonneUnique.GetInstance();
	Console.WriteLine(unGars.Affiche());