Téléchargé 7 fois
Vote des utilisateurs
2
0
Détails
Licence : GPL
Mise en ligne le 18 septembre 2016
Plate-formes :
Linux, Windows
Langue : Anglais
Référencé dans
Navigation
Jeu de Triple Yahtzee
Jeu de Triple Yahtzee
Il s'agit d'un jeu de Triple Yahtzee à plusieurs joueurs sur un même poste.
Le projet n'utilise que des composants ultra-classiques, à l'exception du composant Iphtml dont le paquetage Turbopower_Ipro est fourni avec le code source. Il a été réécrit en "tout objet" en mettant en application les notions détaillées dans les excellents tutoriels de Gilles Vasseur sur la POO (dont vous trouvez les liens ci-dessous).
Bon amusement !
Le projet n'utilise que des composants ultra-classiques, à l'exception du composant Iphtml dont le paquetage Turbopower_Ipro est fourni avec le code source. Il a été réécrit en "tout objet" en mettant en application les notions détaillées dans les excellents tutoriels de Gilles Vasseur sur la POO (dont vous trouvez les liens ci-dessous).
Bon amusement !
Nos ressources disponibles
Notions fondamentales de POO avec Free Pascal/Lazarus
Les méthodes avec Free Pascal/Lazarus (1/2)
Les méthodes avec Free Pascal/Lazarus (2/2)
Les propriétés avec Free Pascal/Lazarus
Les méthodes avec Free Pascal/Lazarus (1/2)
Les méthodes avec Free Pascal/Lazarus (2/2)
Les propriétés avec Free Pascal/Lazarus
Le jeu est à présent terminé, avec une aide et un classement persistant des meilleurs scores.
Tout retour sur d'éventuels bugs est le bienvenu !
Tout retour sur d'éventuels bugs est le bienvenu !
Toutes tes suggestions ont été incluses dans le code source.
Voici la nouvelle version (3.1.1) : http://lazarus.developpez.com/telech...Triple-Yahtzee
Ce qui me gène encore est la différence de rendu entre Linux et Windows au niveau du dimensionnement des composants : par exemple, les deux TStringGrid de la feuille de points sont exactement dimensionnées sous Linux et semblent quelque peu rétrécir dans leur cadre sous Windows. Une suggestion ?
Voici la nouvelle version (3.1.1) : http://lazarus.developpez.com/telech...Triple-Yahtzee
Ce qui me gène encore est la différence de rendu entre Linux et Windows au niveau du dimensionnement des composants : par exemple, les deux TStringGrid de la feuille de points sont exactement dimensionnées sous Linux et semblent quelque peu rétrécir dans leur cadre sous Windows. Une suggestion ?
Bonjour,
Tout d’abord, félicitations pour le travail réalisé : j’apprécie tout particulièrement ton code précis et bien documenté . Comme j’ai enfin trouvé le temps de le revoir dans son ensemble, je me permets quelques suggestions.
Compilation avec Lazarus
J’ai toujours une certaine réticence à utiliser Code Typhon, mais c’est très personnel ! Si cet EDI est très riche et adapté à ceux qui ne veulent pas s’embêter avec des bibliothèques à installer, il reste qu’il anticipe parfois un peu trop en utilisant des éléments instables ou renommés de manière arbitraire.
Ainsi, le code source fourni avec ton jeu ne compile pas avec Lazarus : les bibliothèques pl_bgrabitmap et lz_ipro sont inconnues. De plus, la version d’ipro définit automatiquement une propriété preview inconnue de la version diffusée avec Lazarus. Du coup, j’ai retravaillé ton projet afin qu’il se compile sans problème avec la version de base de Lazarus 1.6.0 pour peu qu’on lui adjoigne BGRABitmap.
Fichier common.pas
Je ne définirais pas de getters pour des propriétés simples : en effet, un getter laisse entendre qu’un traitement est effectué avant le retour de la valeur du champ (c’est par exemple le cas de Copyright). Du côté des setters, comme ils sont bien plus susceptibles d’être implémentés (par exemple pour vérifier la validité des données), les définir même sous une forme squelettique ne pose pas de problème, au contraire (ça devient une question de style).
Fichier main.pas
Partout où tu as créé dynamiquement une fiche, je remplacerais le code par un autre plus léger. Par exemple :
Non seulement on y gagne en lisibilité, mais on économise une variable locale (je suis avare en variables ).
N.B. : il n’y a pas de raison d’utiliser le paramètre Self alors que la destruction va s’opérer manuellement. D’ailleurs, Free a été omis à la fin du listing dans la méthode Partie.
Fichier feuillepoints.pas
Plutôt que de définir cinq méthodes pour savoir si oui ou non on garde la valeur des dés, je suggère d’employer la propriété Name connues de tous les descendants de TObject pour ne garder qu’une seule méthode partagée par les cinq événements OnClick :
Là, ce n’est pas une petite économie !
Enfin, pour éviter les avertissements et les conseils qui laissent croire que le code n’est pas maîtrisé (alors que ce n'est certainement pas le cas), j’aime employer {%H-} devant un paramètre non utilisé volontairement et encadrer une ligne par {$HINTS OFF} et {$HINTS ON} si nécessaire.
Finalement, vu le nombre de lignes de code, ce ne sont que des broutilles. Le vrai problème est celui-ci : ce jeu est addictif pour moi et il faut que je passe à autre chose .
Tout d’abord, félicitations pour le travail réalisé : j’apprécie tout particulièrement ton code précis et bien documenté . Comme j’ai enfin trouvé le temps de le revoir dans son ensemble, je me permets quelques suggestions.
Compilation avec Lazarus
J’ai toujours une certaine réticence à utiliser Code Typhon, mais c’est très personnel ! Si cet EDI est très riche et adapté à ceux qui ne veulent pas s’embêter avec des bibliothèques à installer, il reste qu’il anticipe parfois un peu trop en utilisant des éléments instables ou renommés de manière arbitraire.
Ainsi, le code source fourni avec ton jeu ne compile pas avec Lazarus : les bibliothèques pl_bgrabitmap et lz_ipro sont inconnues. De plus, la version d’ipro définit automatiquement une propriété preview inconnue de la version diffusée avec Lazarus. Du coup, j’ai retravaillé ton projet afin qu’il se compile sans problème avec la version de base de Lazarus 1.6.0 pour peu qu’on lui adjoigne BGRABitmap.
Fichier common.pas
Je ne définirais pas de getters pour des propriétés simples : en effet, un getter laisse entendre qu’un traitement est effectué avant le retour de la valeur du champ (c’est par exemple le cas de Copyright). Du côté des setters, comme ils sont bien plus susceptibles d’être implémentés (par exemple pour vérifier la validité des données), les définir même sous une forme squelettique ne pose pas de problème, au contraire (ça devient une question de style).
Fichier main.pas
Partout où tu as créé dynamiquement une fiche, je remplacerais le code par un autre plus léger. Par exemple :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | var //LFormInscriptions : TFormInscriptions; Li : Integer; begin (* Dialogue d'inscription des joueurs *) //LFormInscriptions := TFormInscriptions.Create(Self); //try // LFormInscriptions.ShowModal; //finally // FreeAndNil(LFormInscriptions); //end; with TFormInscriptions.Create(nil) do try ShowModal; finally Free; end; |
Non seulement on y gagne en lisibilité, mais on économise une variable locale (je suis avare en variables ).
N.B. : il n’y a pas de raison d’utiliser le paramètre Self alors que la destruction va s’opérer manuellement. D’ailleurs, Free a été omis à la fin du listing dans la méthode Partie.
Fichier feuillepoints.pas
Plutôt que de définir cinq méthodes pour savoir si oui ou non on garde la valeur des dés, je suggère d’employer la propriété Name connues de tous les descendants de TObject pour ne garder qu’une seule méthode partagée par les cinq événements OnClick :
Code : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 | procedure TFormFeuillePoints.imgDe1Click(Sender: TObject); (* Choix de garder ou relancer un dé *) var LI: Integer; begin LI := StrToInt(RightStr((Sender as TImage).Name, 1)); Des[LI].Garder := not Des[LI].Garder; end; |
Là, ce n’est pas une petite économie !
Enfin, pour éviter les avertissements et les conseils qui laissent croire que le code n’est pas maîtrisé (alors que ce n'est certainement pas le cas), j’aime employer {%H-} devant un paramètre non utilisé volontairement et encadrer une ligne par {$HINTS OFF} et {$HINTS ON} si nécessaire.
Finalement, vu le nombre de lignes de code, ce ne sont que des broutilles. Le vrai problème est celui-ci : ce jeu est addictif pour moi et il faut que je passe à autre chose .
Ah oui, au temps pour moi.
Mais il semble qu'il y ait un petit problème d'affichage. Tantôt il manque le cadre autour du mot "relancer" (voir ma capture d'écran d'hier), tantôt le fond dudeuxième dé est noir.
C'est noté.
Je ne trouve pas cela si désagréable. On pourrait améliorer le dessin des dés, mais comme ça ce n'est pas mal. Je vais regarder ton code de plus près.
Mais il semble qu'il y ait un petit problème d'affichage. Tantôt il manque le cadre autour du mot "relancer" (voir ma capture d'écran d'hier), tantôt le fond du
C'est noté.
Je ne trouve pas cela si désagréable. On pourrait améliorer le dessin des dés, mais comme ça ce n'est pas mal. Je vais regarder ton code de plus près.
Je ne sais pas à quoi tu pensais exactement mais voici ce que j'ai à te proposer, des dés faits avec BGRABitmap.
J'ai fait le fond des images en noir, parce c'était comme ça dans l'original, mais on pourrait aussi prendre comme couleur de fond la couleur de la fenêtre :
J'ai fait le fond des images en noir, parce c'était comme ça dans l'original, mais on pourrait aussi prendre comme couleur de fond la couleur de la fenêtre :
Code : | Sélectionner tout |
1 2 3 4 5 6 | bmp := TBGRABitmap.Create( Image.Picture.Bitmap.Width, Image.Picture.Bitmap.Height, //BGRABlack ColorToBGRA(ColorToRGB(clForm)) ); |
Grâce à tes bons conseils, j'aspire à m'améliorer et à grapiller sur le monstrueux retard technologique que j'ai pris (je sors tout doucement d'OWL () et des API).
Je mettrai à jour la fiche de téléchargement quand j'aurai étudié et intégré tes modifications.
Franchement, ça ne se sent pas du tout à la lecture du code que tu as produit : même les remarques que j'ai faites sont marginales, car ton code n'est ni fautif ni lent. Je le répète d'ailleurs : j'aimerais lire plus souvent un code aussi clair et documenté
Quant aux "modifications", elles n'ont rien d'impératif. Ce sont plutôt des remarques et ne pas les intégrer ne me gênerait pas. Je les vois plus comme des questions de style (cosmetics) à prendre ou à laisser...
Quant aux "modifications", elles n'ont rien d'impératif. Ce sont plutôt des remarques et ne pas les intégrer ne me gênerait pas. Je les vois plus comme des questions de style (cosmetics) à prendre ou à laisser...
Bonjour Roland,
En cliquant sur les titres des colonnes, tu choisis sur laquelle le tri doit se faire et dans quel sens.
En cliquant sur les titres des colonnes, tu choisis sur laquelle le tri doit se faire et dans quel sens.
Très beau travail.
Bizarre, avec cette nouvelle version, je n'arrive pas à choisir les dés que je veux relancer. Il manque le bouton du deuxième dé, et les autres boutons ne réagissent pas.
C'est sous Windows 10, avec l'exécutable que tu as compilé.
Une question en passant, à quoi sert le composant que tu as utilisé ?
Bizarre, avec cette nouvelle version, je n'arrive pas à choisir les dés que je veux relancer. Il manque le bouton du deuxième dé, et les autres boutons ne réagissent pas.
C'est sous Windows 10, avec l'exécutable que tu as compilé.
Une question en passant, à quoi sert le composant que tu as utilisé ?
Developpez.com décline toute responsabilité quant à l'utilisation des différents éléments téléchargés.