Objectif : programmer des robots de combat, puis les jeter dans une arène.
But du jeu : après le choix du terrain qui se présente sous la forme d'une grille plane à maille régulière comportant un certain nombre d'obstacles, un programme est chargé pour chaque participant (de 2 à 6) et représenté sur le terrain par un robot ; au lancement de la partie tous les programmes s'exécutent de façon synchrone, pas à pas, et conditionnent le comportement de chaque robot ; le vainqueur est celui dont le robot est le dernier à fonctionner (il peut y avoir des ex aequo).
Un programme est constitué d'instuctions dont l'exécution coûte plus ou moins d'énergie au robot associé. Chaque joueur est donc placé devant un problème de rapport coût/efficacité. Un robot très efficace dépense une grande quantité d'énergie. Il perd donc davantage de points que ses adversaires moins performants. Il prend donc le risque d'être éliminé rapidement. A moins, bien sûr, qu'en raison même de son efficacité, il ne les élimine plus rapidement qu'il ne s'épuise. On doit donc choisir un véritable comportement pour son robot. Il y aura ceux qui poursuivent un adversaire, s'arrêtent au moment d'entrer dans la zone de repérage puis se mettent à tirer tous azimuts. D'autres au contraire adopteront un comportement de fuite systématique s'accompagnant de pose de mines dès qu'un adversaire sera à proximité. A vous de trouver le programme qui fera de votre robot le "terminator".
Cahier des charges
L'ensemble du projet doit se faire en Python objet, exclusivement à l'aide des modules fournis par défaut à l'exception notable des modules tkinter et PIL (Python Imaging Library) Il ne comportera aucune composante sonore ou réseau. L'aspect esthétique est laissé au libre choix du concepteur mais ne doit en aucun cas primé sur les fonctionnalités (il ne sera d'ailleurs pas pris en compte dans la notation).
L'application doit permettre :
- de choisir la configuration du terrain,
- de charger les programmes des robots participants,
- d'assurer le bon déroulement de la partie,
- d'avoir un rendu visuel qui rende compte de l'évolution de la partie en cours,
- de proposer une aide (générale et contextuelle).
Tous les terrains sont de dimensions 30 x 20 cases (la définition de chaque case est normalement fonction du périphérique d'affichage) et totalement clos. L'utilisateur détermine interactivement les paramètres suivants :
- les obstacles figurant sur le terrain, dont la proportion ne doit pas dépasser 20 %, par le choix d'un fichier de configuration, constitué de 20 lignes de 30 caractères ("#" pour un obstacle et "_" pour une case libre), une case d'obstacle ne doit pas avoir uniquement de voisins indirects comme ci-dessous :
- le nombre de robots, de 2 à 6, puis leur position initiale et le programme associé,
- l'énergie allouée à chaque robot, de 500 à 3000 points (ce qui conditionne la durée de la partie),
- la distance de repérage (voir instruction TT), de 2 à 6 cases (4 par défaut).
Chaque robot est associé à un programme, dont le nombre de pas varie de 5 pas minimum à 20 pas maximum. Un programme se présente sous la forme d'un fichier texte, d'extension .rbt, constitué : d'une ligne d'information préfixée du caractère ";" (spécificité du programme/robot), puis de l'instruction correspondant au "circuit de secours" (voir ci-dessous), et enfin de 5 à 20 pas d'instructions qui correspondent aux actions du robot.
Le déroulement d'une partie doit se faire à une vitesse compatible avec les capacités visuelles moyennes des individus, avec suffisamment d'informations affichées pour en comprendre l'évolution. Les aides aussi bien générales que contextuelles doivent être accessibles à tout instant. Il doit être possible de mettre une partie en pause puis d'en reprendre le fil.
Programmation des robots
Par défaut, les actions des robots vont se faire séquentiellement mais la plupart peuvent être soumises à un test. Lorsque la fin du programme est atteinte, celui-ci reprend automatiquement à la première instruction.
Voici les codes des actions que les robots peuvent effectuer :
- DD : déplacement déterministe d'une case dans une direction fournie (H : haut, B : bas, D : droite, G : gauche) si la case visée est libre sinon reste sur place. C'est une instruction importante pour les terrains dégagés.
- AL : déplacement aléatoire d'une case dans une direction donnée (H : haut, B : bas, D : droite, G : gauche) si la case visée est libre sinon reste sur place (permet de rompre des séquences de programmation conduisant au blocage).
- MI : pose d'une mine sur l'une des quatre cases voisines du robot (au hasard). C'est l'arme la plus meurtrière pour les robots adverses. Quand ils marchent sur une de vos mines, ils perdent 200 points d'énergie. En outre, le pas de leur programme au moment de l'explosion est détruit et remplacé par celui du "circuit de secours" (voir ce paragraphe). Les robots sont capables de reconnaître leurs propres mines et ne sautent pas sur elles mais celles-ci sont détruites dans tous les cas de figure.
- IN : invisibilité, c'est une contre-mesure électronique qui coûte cher en énergie, mais qui déboussole complètement les adversaires. Au moment où votre robot utilise cette instruction, les autres robots ne savent plus où il est.
- PS : instruction de poursuite, votre robot doit repérer l'adversaire le plus proche, puis se diriger d'une case vers lui. Le déplacement, s'il est possible, peut s'effectuer en diagonale, contrairement aux autres types de déplacement. Si elle n'est pas conditionnée par l'instruction de test (TT), cette instruction s'effectue quelle que soit la distance qui sépare votre robot de l'adversaire le plus proche.
- FT : instruction de fuite, comme l'instruction PS, mais le robot fuit l'adversaire le plus proche au lieu de le poursuivre,
- TT : appel de l'instruction de test, elle conditionne l'appel à des instructions déjà citées (AL, MI, IN, PS et FT) et à deux nouvelles instructions (TH, TV, voir ci-dessous). Ce test est un test de distance : il détermine si le robot adverse le plus proche est ou non situé à une distance inférieure ou égale à celle définie comme "distance de repérage". Si la réponse est oui le robot effectuera l'action correspondant à l'instruction qui suit immédiatement l'instruction TT, sinon il suivra la deuxième instruction qui suit l'instruction TT (exemple : TT MI PS, ce qui se traduit par si le robot le plus proche est à une distance inférieure ou égale à celle de repérage alors pose d'une mine sinon poursuite de ce robot).
Codes des actions pouvant être associés au mode test :
- AL, MI, IN, PS et FT (tous sauf DD et TT),
- TH : tir horizontal, à gauche ou à droite aléatoirement. Le tir est stoppé par la première cible (obstacle, robot ou mine) rencontrée. Il permet d'affaiblir vos adversaires car un robot touché perd 20 points d'énergie. Ils détruisent les mines adverses rencontrées, sans détruire les vôtres. Il est sans effet sur les obstacles.
- TV : tir vertical, en haut ou en bas aléatoirement, idem TH.
Attention, en mode séquentiel les actions sont effectuées quelle que soit la distance des adversaires, alors qu'en mode test elles sont toujours soumises au test de proximité.
Circuit de secours : votre robot perd un pas de programme en marchant sur une mine. L'instruction qu'il contenait est immédiatement remplacée par celle du "circuit de secours". L'instruction de secours est définie au tout début d'un programme, parmi les instructions suivantes : AL, MI, IN, PS ou FT.
Coût énergétique
Le tableau ci-dessous indique le coût énergétique de chaque action et de chaque avarie :
| Codes | Actions | Coûts | Dommages |
|---|---|---|---|
| DD | déplacement choisi | 5 | |
| AL | déplacement aléatoire | 1 | |
| PS | poursuite | 4 | |
| FT | fuite | 4 | |
| MI | pose d'une mine | 10 | 200 |
| TH | tir horizontal | 3 | 20 |
| TV | tir vertical | 3 | 20 |
| IN | invisibilité | 20 | |
| TT | test de proximité | 4 |
Notation
La notation de ce projet prendra en compte le respect du cahier des charges, la qualité de la programmation (robustesse, lisibilité et modularité du code) qui devra suivre le paradigme objet, ainsi que les aspects propres à une IHM que sont : cohérence, concision (limitation du nombre d'intervention de l'utilisateur), structuration des activités (décomposition d'une tâche complexe), flexibilité (application personnalisable), retour d'informations et gestion des erreurs, toutes choses qui garantissent une interface ergonomique et intuitive et qui n'apparaissent pas explicitement dans cette présentation.
