Règles

Préparation du Jeu

2 à 4 joueurs peuvent participer à une partie. Le plateau de jeu est composé de 60 tuiles "iceberg" qui représentent la banquise. Chacune de ces tuiles contient de 1 à 3 poissons. Au début du jeu, on construit la banquise en disposant les tuiles en 8 lignes, alternativement de 7 et 8 tuiles (la répartition du nombre de poissons sur les tuiles est aléatoire) puis les joueurs placent alternativement leurs 4 (3 à trois joueurs, 2 à quatre joueurs) pingouins sur un iceberg avec un seul poisson.

Le jeu

Chaque joueur joue un groupe de pingouin, dont le but est de boulotter le plus possible de poissons.

Le déroulement du jeu

A son tour, chaque joueur choisit un de ses pingouins. Un pingouin peut se déplacer en ligne droite dans les six directions naturelles d'autant de cases qu'il veut. Toutefois, il ne peut pas passer au dessus d'un autre pingouin ou au dessus d'un trou. En partant, il récupère la tuile sur laquelle il était et le joueur reçoit le nombre de points correspondant au nombre de poissons indiqués sur la tuile. Ainsi le nombre d'iceberg diminue à chaque tour.

Fin de la partie

Le jeu se termine quand plus aucun joueur ne peut déplacer un pingouin. A la fin du jeu, les poissons de l'iceberg sur lequel se trouvent les pingouins sont ajoutés au total des points. Le vainqueur est celui qui possède le plus de poissons. En cas d'égalité, le vainqueur est celui qui a récupéré le plus d'icebergs. En cas de nouvelle égalité il y a deux vainqueurs.

Pour plus d'information, voir http://reglesdejeux.free.fr/regles/pingv_rg.pdf

Projet informatique

En premier lieu, gardez à l'esprit que c'est un projet d'IHM. Vous devrez donc vous focaliser sur cet aspect en priorité puisque l'évaluation de votre travail reposera dessus : respectez les principes ergonomiques listés ci-après, réfléchissez aux interactions possibles, à l'aspect didactique, à l'homogénéité du style graphique, etc. Un fonctionnement parfait de l'application n'est pas demandé. Pour les mêmes raisons, on évitera de gérer la sauvegarde et la restauration d'une partie en cours ou la possibilité d'effectuer une partie multi-joueurs en réseau.

TclTk est un langage très puissant (j'espère que vous êtes à présent convaincu de cela ;-) mais il requiert une grande pratique pour en tirer le maximum. C'est pourquoi certains points du projet méritent quelques éclaircissements.

Gestion des joueurs : elle requiert une entité associée avec des paramètres pertinents, pensez y dès maintenant,

Gestion des pingouins et des hexagones : vous avez deux solutions, soit mettre en place et maintenir une structure de données personnelle parallèlement à la gestion de l'interaction utilisateur (solution classique qui requiert moins d'expérience et qui peut être une solution élégante si vous prenez la peine de l'encapsuler dans un namespace), soit utiliser uniquement la puissance du widget canvas. Dans le deuxième cas, il faut choisir avec grand soin les différents tags associés aux objets graphiques et avoir connaissance de certaines commandes du canvas :

• pour les tags, choisissez des termes uniques par élément du jeu, ajoutez éventuellement les coordonnées du repère local associé Ã l'objet, construisez si nécessaire un graphe de relations par l'insertion d'un code qui vous permette de retrouver le ou les objets associés, sachant que chaque objet a un identificateur unique, en utilisant les commandes associées aux listes (lsearch en particulier) ; par exemple, grâce au paramètre -tags \"hex i67 p154 p155 p156\" on associe l'iceberg "i67" (car l'iceberg a été étiqueté 67 par le canvas) et les poissons "p154", "p155" et "p156",
• en supposant que votre canvas se nomme .c, .c find withtag current permet de retrouver l'objet courant ; .c coords $id permet de récupérer les coordonnées définissants l'objet id sous la forme d'une liste ; .c move $id $dx $dy permet de déplacer l'objet id relativement à sa position initiale de (dx, dy) ; .c find overlapping $x1 $y1 $x2 $y2 permet de récupérer la liste des objets compris dans l'aire du rectangle défini par les points (x1, y1) et (x2, y2) ; .c delete $id permet d'effacer un objet du canvas.

Canvas : pas de fonction de rotation ; pour déformer un objet, il faut changer ses coordonnées ; ne gère par défaut que les fichiers images de type gif ou ppm/pgm (!) mais l'utilisation de la bibliothèque libtk-img comble cette lacune (package require Img) ; la création d'une pixmap se fait en deux temps : 1) chargement du fichier image par image create photo im_ping01, 2) affichage de l'image par .c create image $x $y -image im_ping01.

Divers : les calculs trigonométriques se font en radians (rappel : 1 rad = 57,295779513°) ; un hexagone est un polygone régulier à 6 côtés dont la construction peut se faire à partir de son cercle circonscrit (de rayon la longueur d'un côté de l'hexagone), l'équation paramétrique d'un cercle de centre (x0, y0) et de rayon r est donnée par : x = x0 + r cos(a), y = y0 + r sin(a).

Principes ergonomiques

Cohérence : style graphique homogène, si l'interface privilégie un certain type de widgets elle doit le faire pour toutes les facettes du jeu, les actions permettant le placement initial ne doivent pas être trop différentes des actions permettant le déplacement des pingouins durant le jeu, l'affichage et la correction des erreurs doivent toujours être traités de façon proche quelque soit le type d'erreur.

Concision : le choix du nombre de joueurs, le placement initial et la manipulation des pingouins durant le jeu doivent nécessiter le moins d'actions possible.

Retour d'informations : à toute action doit correspondre une réponse visuelle (ou sonore), une aide (si possible contextuelle) doit être mise à disposition.

Structuration des activités : toute action complexe doit être décomposée en suite d'actions simples et intuitives.

Flexibilité :

• l'aspect du plateau de jeu est modifiable,
• le nombre de tuiles et leur disposition sont modifiables,
• l'aspect des pingouins est modifiable,
• le nombre de poissons collectés par chaque joueur est visible ou non pendant le jeu,
• le nombre de poisson est totalement aléatoire pour chaque iceberg (mais compris entre 1 et 3 et avec un minimum d'iceberg à 1 poisson, fonction du nombre de pingouin),
• activation d'une variante (cf. ci-après).

Gestion des erreurs :

• gestion du placement initial (sur des icebergs d'1 poisson),
• impossibilité d'agir sur un pingouin adverse,
• prise en compte des obstacles (autres pingouins, trous, bord du plateau de jeu) dans les déplacements,
• prise en compte du choix erroné d'un hexagone de destination (opérations do/undo),

Variantes

Les pingouins arrivistes (traduction libre de "pushing penguins") : variante officieuse suggérée par l'auteur. Les règles originales s'appliquent, à l'exception que le joueur actif peut choisir entre un mouvement normal de pingouin ou le mouvement alternatif suivant :

• Situation: un de vos pingouins est voisin d'un pingouin adverse.
• Si, derrière ce pingouin adverse, il n'y a pas de bloc de glace (parce que le bloc de glace a été retiré ou parce que le pingouin adverse se trouve en bordure de l'aire de jeu), alors votre pingouin peut pousser le pingouin adverse dans l'eau et prendre sa place.
• Le pingouin adverse poussé à l'eau est retiré du jeu.
• Vous ne gagnez pas le bloc de glace que votre pingouin vient de quitter (vous ne gagnez donc aucun bloc de glace pour ce tour-ci). Ce bloc de glace que vous venez de quitter reste en place sur l'aire de jeu.

Glissade : lors du déplacement « on s'arrête quand on peut » (et non « on s'arrête quand on veut »), au premier obstacle ou au bord de la banquise.

Matériel disponible

Pour mettre ces images au format désiré, utilisez le package ImageMagick et plus particulièrement la commande convert -resize.