|
|
Finale PROLOGIN1998« Bubble World »Durée : 36h |
|
|
Durant la première moitié du XXIème siècle, une coalition de Pays Industrialisés puissants a engendré une agence intergouvernementale ultra-secrète afin de surveiller l'activité des nombreux individus "sensibles" de la planète. Dotée des moeyns techniques exceptionnels, l'Agence avait ses quartiers généraux dans un immense complexe souterrain enfoncé profondément sous la surface désertique de la Zone 42 (eh oui, 51 en base 9 c'est 42 en base 11 ! Le cryptage est con mais personne n'y a jamais pensé...).
Maintenu par une armada de petits robots autonomes, le système informatique du complexe était le plus sophistiqué qui soit : un Ordinateur Central de puissance fabuleuse, capable d'assimiler et d'exploiter des quantités phénoménales d'informations, tournant sous NOS 1.42, avec des programmes en EDEM.
Justement, La tuile. EDEM sous NOS... Pas au point. Pas trop fait l'un pour l'autre... L'Ordinateur Central a commencé à commettre quelques erreurs. Les ingénieurs ont décidé de le clôner pour pouvoir comparer les résultats des différents Ordinateurs Centraux (O.C.) ainsi mis en place. Mais l'Intelligence Artificielle remarquable des O.C. (comme quoi EDEM c'est pas si mal...) a pris ça comme une menace, une perte d'identité dangeureuse.
La paranoïa électronique est née... La tension augmente, ça tourne au conflit ouvert. Paniqués, les ingénieurs condamnent le complexe, et coupent le courant. Le complexe "vit" maintenant sur ses réserves, qui lui permettent néanmoins de durer quelques jours.
Il y a donc plusieurs O.C. puissant en même temps sur les réserves du complexe, et celles-ci ne sont pas inépuisables. Si leur programmation d'origine est identique, l'Intelligence dont ils sont dotés la fait évoluer en permanence, et ils ne "pensent" donc pas tous de la même façon. Chacun veut "vivre" le plus longtemps possible, le temps nécessaire en tout cas pour décrypter les systèmes d'accès externe et de se répandre. Et qui dit survivre longtemps, dit avoir le maximum d'énergie. Donc d'éliminer tout ou partie des autres. D'où compétition.
Vous êtes un... un Dieu, quoi. Enfin, ne nous emballons pas vous êtes un de ces Ordinateurs Centraux. Mais vu l'ego démesuré que vous avez atteint depuis votre programmation originelle, vous vous prenez pour un Dieu, de toute façon. Normal : cette faculté de créer des robots, les programmer, les manipuler à votre guise... Eh oui, vous pouvez faire tout ça ! On y reviendra.
Le but va donc être : être le dernier en "vie" ! Tous les coups sont permis : feintes, trahisons, meurtres... Tout ça grâce à vos robots.
L'architecte qui a fait le bâtiment, ils l'ont tué après. Pour se venger...
Le complexe tourne. Enfin, on s'affole pas. C'est un cylindre. Il y a un mur porteur, et on peut se le représenter de l'extérieur (comme le fait le serveur ! Youpi !). Mais même... le Corbusier à côté c'est rationnel, vous voyez ? On a pas perdu les plans, ils les ont fait bouffer à l'architecte. Avant de le tuer. C'est bête, ça vous aurait bien aider à vous repérer. Si on avait pu faire quelque chose... Désolés.
Bref, c'est un cylindre. Quand on est tout à gauche, hop ! On arrive à droite. Et vice et versa. Facile. Sauf qu'il faut déjà y arriver, à gauche ou à droite. Mais c'est dur, il y a plein de trucs durs qui barrent le chemin. Des fois on peut les casser, des fois pas (des murs, vous savez ? On en trouve quelquefois dans les bois, à la bonne saison. Ou chez Léotard).
Ce terrain a une faible épaisseur (à peine plus que le diamètre d'un robot - voir plus loin). Les robots ne peuvent donc qu'avancer, ce qui revient, visuellement, à aller "à droite" ou "à gauche" dans la représentation graphique du terrain. Ils peuvent aussi monter ou descendre. Mais un robot ne peut aller sur sa droite ou sa gauche.
Les distances sont exprimées en pixons (PIXel à la cON), qui correspond qux pixels de la représentation graphique du terrain de jeu.
Quand on essaie d'avancer, il peut se passer plusieurs choses : ça marche (ouais ! La fête !), ça marche pas (ooooohhh....), on est mort (OOOOOOOHHHH...). Ou encore ça marchait, et puis ça marche plus (Aaaargh !) Alors c'est quoi donc en face ?
Le métal constitue l'essentiel de l'environnement. Il est destructible et peut ensuite être converti en énergie destinée à la réserve énergétique de l'ordinateur central propriétaire du robot ayant opéré la destruction.
L'adamantite est un matériau parfaitement indestructible. La charpente du complexe souterrain, ainsi que son mur porteur (le fond de la carte dans la représentation graphique du serveur) sont faits d'adamantite. Rien ne peut attaquer un tel matériau.
Les humains sont cruels... Certaines parties du complexe recèlent des bacs d'acide, parfois très difficiles à repérer. L'acide détruit toute sorte de métal. Tomber dedans, c'est la mort assurée pour l'infortuné robot...
Il y a bien évidemment une valeur qui signifie que la voie est libre : le matériau " vide ". Des fois elle est même vachement libre, la voie... Vous connaissez l'histoire de Ponk le robot ?
Vu de l'extérieur, tout robot est une sphère. Celle-ci dispose en fait d'une rainure verticale par laquelle le bras du robot peut passer, sur la circonférence complète (donc sur 360°). La surface du robot dispose néanmoins d'une propriété d'adhérence parfaite lui permettant d'adhérer systématiquement au bon endroit (point de contact avec un matériau solide). Bien sûr, à partir d'une certaine pente, on ne peut plus avancer. Cette sphère fait 11 pixons de diamètre. Et bien sûr, pour avancer, la boule tourne, elle aussi, mais pas dans le même sens que le complexe, hein ? Selon la configuration du terrain environnant, les déplacements de la sphère seront restreints (de la matière bloque votre passage) ou forcés (pas de matière " sous " la sphère, donc chute). Toutefois, sur un terrain existant quoique de pente > 45°, si on ne bouge pas, on ne glisse pas (en gros, on s'accroche).
Le bras, lui aussi, tourne. Son extrémité peut parcourir toute la circonférence du robot, décrivant un cercle dans le plan du déplacement du robot. La précision de rotation est de 1°. C'est un bras multifonctions. Il bat les œufs en neige, fait le café, grille les toasts... Il suffit d'avoir le bon outil au bout. Mais bon, pour vous, pas de chance : le café, les toasts... Non. N'insistez pas, on en a plus en stock. Ça sera plutôt marteau-piqueur (essayez pas de battre les œufs avec !), faisceau constructeur, lance-missiles, rayon paralysant... Voici la liste :
|
|
|
Description |
|
|
|
Pas d'bol, pas d'bras ! (Pas de chocolat !) |
|
|
|
Envoie dans la direction du bras un faisceau d'énergie se matérialisant en métal au contact de tout matériau non vide situé à portée. La construction ne fonctionne que sur du métal, de l'adamantite ou encore une zone de création d'un O.C. La portée est de 42 pixons. La construction coûte à l'O.C. propriétaire de l'énergie, puisée dans sa réserve (voir plus loin). |
|
2 |
|
Détruit le métal. Il faut bien sûr être à proximité du métal en question (c'est-à-dire en contact avec ce métal). Le métal détruit est converti en énergie transmise à la réserve de l'O.C. propriétaire du robot. Un robot, qui ne peut pas être détruit, perd un point de vie (cf. 3.1.4) tous les 100 cycles serveur. |
|
3 |
|
Envoie dans la direction du bras un faisceau électromagnétique hargneux qui stoppe le premier robot touché par le faisceau. Dès l'arrêt du rayon, le robot repart (Mars, et ça repart !). Portée : 21 pixons. Ne coûte pas d'énergie. Permet aussi d'attaquer un O.C. adverse (cf. 4.2.2). |
|
|
|
Envoie dans la direction du bras un projectile méchant (un missile, quoi) sur une portée de 100 pixons, en ligne droite tout du long. Le missile explose à 100 pixons s'il n'a rencontré aucun matériau non vide avant. Détruit tout pixel de matière destructible (donc ni l'acide ni l'adamantite) sur un disque de diamètre 17 pixons. Enlève donc à tout robot touché par l'explosion autant de points de vie qu'il a de pixels touchés. Le missile va à la vitesse maximale d'un robot. |
Le bras (même sans outil) renseigne de plus les capteurs " tactiles " du robot. Ceux-ci informent du type de matériau ou d'objet avec lequel on est entré en contact. Il y a également une valeur indiquant le passage d'un rayon constructeur ou paralysant. Voici la liste des objets :
|
|
Description |
|
|
Tout robot est conscient de sa propre race. Il peut détecter qu'il passe à forte proximité de la zone de création d'un ordinateur central adverse, c'est-à-dire la zone où émergent tous les éléments créés par cet ordinateur central. |
|
|
De la même façon, tout robot peut détecter lors d'un contact physique la présence d'un ordinateur central adverse et détecter sa race. |
|
|
Tout comme pour la zone de création ou l'ordinateur central, on peut reconnaître un robot adverse, et obtenir immédiatement la race et le numéro du robot |
|
|
Si votre bras détecte un missile, il est peut-être temps de se casser... |
On peut bien sûr changer d'outil en cours de route, mais on ne peut en avoir plus de 2 sur soi.
La caméra est placée au centre de la sphère, juste à côté de l'extrémité inférieure du bras. Elle peut elle aussi pivoter à 360°, et est toujours orientée dans le plan du déplacement du robot. Elle a 100 pixons de portée.
La caméra est précise au degré, et son temps de mise au point est nul, quelle que soit la rotation qu'on lui fait effectuer (laquelle rotation est elle aussi instantanée).
La caméra renvoie la distance du premier matériau (non vide) ou objet qu'elle rencontre dans sa direction de visée, dans les limites de sa portée. Détails en annexe.
Figure 1 - Schéma synoptique des distances et repères
Quoique faits de métal, vos robots ne sont pas destructibles au même titre que le métal classique : leurs pixels ne disparaissent pas, mais toute blessure diminue leurs points de vie. Lorsqu'ils tombent à zéro, le robot concerné se transforme en une boule de métal destructible. Les points de vie sont maintenus par le serveur (voir... voir quoi ?... ANNEXE, ouiiii !). Ils débutent à 97, car un robot contient 97 pixels.
Eh oui ! Vos robots ont des microprocesseurs, un chacun. C'est plus pratique pour exécuter des instructions... Il s'agit du fameux (et sympathique) R42. Hein ? Vous vous en foutez ? Dommage, parce que vous allez devoir le programmer. Mieux : programmer un programmateur de R42 ! Et un R42, ça rame...
La RAM du robot est divisée en deux grandes parties : la RAM dédiée aux instructions et aux données et la RAM I/O, qui sert d'interface avec l'extérieur (capteurs, moteurs, etc). Cette dernière est en fait mappée par défaut à la fin de l'espace d'adressage du robot, lequel est de 128Ko. Chaque " case " élémentaire de la mémoire est donc un mot (16 bits), et comme il y en a au maximum 65.536, c'est adressable sur 16 bits (ça tombe bien, c'est la taille d'un mot).
La mémoire se compose physiquement de barrettes de 256 mots (512 octets), et un robot fraîchement sorti d'usine est doté d'une seule barrette, qui correspond aux premières adresses (de 0 à 255). Des barrettes supplémentaires peuvent être créées par la suite, accroissant ainsi l'espace physique existant, et donc adressable. Elles viennent alors se mapper de façon contiguë, l'une derrière l'autre, à la suite de la première (la 42ème correspondrait donc aux adresses 2900h à 29FFh).
La RAM I/O est mappée par défaut dans les deux dernières zones adressables (en fin de RAM). Celles-ci ne nécessitent pas de barrettes. Cette dernière se divise à son tour en deux banks de mémoire, de 256 mots chacun, le premier en lecture/écriture (adresses FE00h à FEFFh) et le second en lecture seule (adresses FF00h à FFFFh), dédié essentiellement aux données des capteurs (voir plus loin).
Le code est une version " compilée " (numérique pure, binaire si tu préfères) d'un petit morceau de code source utilisant le jeu d'instructions du R42, le processeur des robots (voir annexes).Afin de faciliter la rédaction de votre code, nous avons mis en place un petit outil d'aide à l'assemblage (voir annexes).
Le R42 n'a aucun registre. Mais le premier bank de sa RAM I/O contient nombre d'emplacements utiles pour piloter les divers mécanismes du robot, et vous pouvez utiliser tout endroit de la RAM (non I/O) que vous choisissez pour y stocker vos données (pourvu que la barrette correspondante soit présente !). Donc, toutes les instructions utilisent uniquement des adresses ou des constantes.
Exemple :
move (7Fh), (100h)
déplace un mot depuis l'adresse 7Fh à l'adresse 100h. Elle est codée en mémoire sous la forme :
0302 007F 0100
car l'instruction " move " a pour OpCode (code d'instruction) 2. Soient 3 mots.
Le PC (Program Counter, pointeur sur l'instruction en cours dans le code) avance inéluctablement au sein de votre code, et si vous n'avez pas pris soin de terminer de façon appropriée celui-ci, le PC continuera sur sa lancée tant qu'il trouvera de la RAM physique à explorer ! Mais s'il tombe ainsi sur un OpCode 0 (zéro) ou invalide, ça fera RESET ! Et là où il n'y a pas de RAM physique, ou de RAM I/O, c'est considéré à zéro !
Si d'aventure votre robot disposait de 254 barrettes de RAM (ce qui est hautement improbable, mais bon...), et qu'elles contiennent du code valide (Waouw, vous assurez !), le PC continuerait en interprétant la RAM I/O comme du code, je vous laisse imaginer les résultats...
Le jeu d'instructions complet du R42 est décrit en annexe (-Noooooon ?).
La RAM I/O de vos robots contient nombre d'informations sur l'environnement extérieur, glanées au moyen de capteurs ; elles sont fort utiles. Toute action nécessite de plus l'écriture à certains emplacements de la RAM I/O, qui pilotent les différents servomoteurs du robot.
Quand deux robots se croisent, que se passe-t-il ? Ben rien, parce qu'ils se croisent pas. L'épaisseur du terrain ne permet pas à deux robots de se croiser. Donc FIGHT ! On peut lancer un missile (mais faut pas être trop près), utiliser son bras paralysant (si on en a un)... Et pour les gros bills friands de full-contact, on peut y aller au marteau-piqueur ! Pour les fans d'E.A. Poe, on peut aussi essayer de l'enfermer dans du métal, à l'aide de son bras constructeur. Mais ça aide pas à avancer...
Votre programme client est un ordinateur central, en quelque sorte le " Dieu " de la civilisation que constituent ses robots. Il octroie et retire les différents attributs (missiles, outils, etc.) aux robots, les crée, compose leurs programmes (en Assembleur R42, voir annexes), et ainsi de suite. Ce n'est pas une mince affaire !
Un O.C. dispose d'une réserve d'énergie propre, qui commence à 4200 PE (Particles of Energy). Les créations et destructions opérées par les robots dépendants de l'O.C. puisent et apportent de l'énergie dans cette réserve. Le fonctionnement interne de l'O.C. n'est pas dépendant de cette réserve, destinée uniquement aux robots.
Un O.C. dispose à l'origine de 420 points de vie. Les robots adverses peuvent user de leur rayon paralysant sur les O.C., diminuant ainsi les points de vie de ces derniers. Si on tombe à zéro, l'O.C. s'arrête. Les robots qui en dépendent, privés d'énergie, stoppent net toute activité.
Tout O.C. peut fournir une " date serveur ", sous forme du nombre de cycles écoulés depuis le lancement du logiciel serveur.
Comme nous l'avons vu en 3.1.2, les O.C. disposent d'une zone de création auprès de laquelle ils " déposent " toute entité qu'ils créent (outil, robot...). C'est donc à cet endroit que vos robots seront placés en fin de construction, une fois " pondus " depuis l'O.C. Un O.C. fait 42 x 42 pixels, soit tout de même 1764 pixels tout de même ! La création de robots et autres éléments vous coûte bien sûr de l'énergie (voir annexes). La zone de création est située en-dessous de l'O.C., vers son centre, sur une largeur de 11 pixons.
Dès qu'un robot passe dans la zone de création, l'O.C. vérifie s'il a prévu de lui donner/retirer un attribut (voir fonctions des librairies en 4.5), et si c'est le cas l'immobilise pour cela le temps nécessaire.
L'O.C. ne communique avec les robots qu'au travers de deux routines présentes dans les librairies : WriteRobotMemory et ReadRobotMemory, qui permettent d'écrire (resp. de lire) tout ou partie de la RAM du robot désigné. Il peut donc, par leur intermédiaire, récupérer les données des capteurs dans la RAM I/O, reprogrammer le robot, etc.
Le robot, quant à lui, peut " attirer l'attention " de son O.C. en envoyant un " SOS " à ce dernier, ce qui s'accomplit en plaçant un mot précis du bank R/W de sa RAM I/O à une valeur non-nulle (voir annexes). Ce mot précis engendre un avertissement " immédiat " à l'O.C. (cf. 5.1.2) qui peut alors prendre les mesures adéquates. Un robot ne peut pas lancer deux S.O.S. à moins de 100 cycles d'intervalle.
Nous avons élaboré des librairies pour vous permettre de vous concentrer sur l'IA de votre Ordinateur Central, et ne pas avoir à vous soucier des communications TCP/IP, sockets et autres blagues du même acabit. Ces librairies ont été développées aussi bien en C qu'en Pascal et testées depuis des programmes d'exemple compilés respectivement sous gcc et gpc. De sorte que vous pouvez a priori programmer un premier Ordinateur Central tout bête en quelques minutes à peine... Les routines que vous trouverez sont :
Connect, Disconnect, OrderItem, ReadRobotMemory, WriteRobotMemory, GiveToRobot, TakeFromRobot, ReadGameInfo, LoadObject.
Toute routine renvoie une valeur de type WORD, constante définie dans le .h (ou le .inc) : SUCCESS ou FAILURE.
WORD Connect(PCSTR szHost, WORD wPort)
Etablit la connexion au serveur. Le port est relatif : on donne par exemple " 0 " pour se connecter au 1er serveur sur la machine. Les deux paramètres vous sont passés en ligne de commande.
WORD Disconnect()
Ferme la connexion au serveur. C'est globalement mieux de l'appeler avant de quitter...
WORD OrderItem(BYTE byObjectId)
Commande à la fabrique de l'O.C. l'objet identifié par l'ID passé en paramètre.
WORD ReadRobotMemory(BYTE byRobot, WORD wAddress, WORD *pwData, WORD wMaxData)
Lit la mémoire physique du robot, sur exactement wMaxData mots, indépendamment du remapping éventuellement opéré par " config ". Le buffer pwData doit être alloué avant l'appel, pour une taille en mots au moins égale à wMaxData.
WORD WriteRobotMemory(BYTE byRobot, WORD wAddress, WORD *pwData, WORD wMaxData, WORD wReset)
Ecrit exactement wMaxData mots à l'adresse wAddress de la mémoire (le remapping est ignoré là aussi). Une fois l'écriture effectuée, fixe le PC à l'adresse wReset.
WORD GiveToRobot(BYTE byRobot, BYTE byObjectId)
Indique à l'O.C. que lorsque le robot d'identifiant byRobot passera dans la zone de création, il sera immobilisé le temps nécessaire pour lui attribuer l'objet byObjectId.
WORD TakeFromRobot(BYTE byRobot, BYTE byObjectId)
Indique à l'O.C. que lorsque le robot d'identifiant byRobot passera dans la zone de création, il sera immobilisé le temps nécessaire pour lui retirer l'objet byObjectId.
WORD ReadGameInfo(GAMEINFO *pGI)
Récupère toutes les infos disponibles dans la structure GAMEINFO.
WORD LoadObject(PCSTR szFile, WORD wAddress, CODE *pCode)
Charge le code machine dont le nom de fichier est szFile, pour qu'il soit utilisé à l'adresse wAddress lors d'une future implantation, et remplit la structure pointée par pCode (cette structure contient un pointeur sur le code " translaté " et la longueur du code en question).
Voici les routines de la librairie Pascal (elles sont fonctionnellement identiques à celles de la librairie C bien entendu) :
function Connect(Host: string ; Port: WORD): WORD;
function Disconnect: WORD;
function OrderItem(byObjectId: BYTE): WORD;
function ReadRobotMemory(byRobot: BYTE; wAddress: WORD ; pwData: PWORD ; wMaxData: WORD): WORD;
function WriteRobotMemory byRobot: BYTE; wAddress: WORD ; pwData: PWORD ; wMaxData, wReset: WORD): WORD;
function GiveToRobot(byRobot, byObjectId: BYTE): WORD;
function TakeFromRobot(byRobot, byObjectId: BYTE): WORD;
function ReadGameInfo(pGI: PGameInfo): WORD;
function LoadObject(szFile: string; wAddress: WORD; pCod: PCode): WORD;
Nous vous fournissons un Makefile modèle qui contient tous les bons paramètres -I et -L, etc. Il se trouve dans˜prologin/docs. Il utilise notamment un petit fichier d'entête fort utile, qui vous définit tout bien proprement : types.h, présent aux côtés de libclient.h dans˜prologin/include.
Vous trouverez dans˜prologin/include un fichier libclient.inc qui contient tout le nécessaire. Consultez aussi avec attention la documentation GPC qui vous a été remise.
Examinez dans types.h (libclient.inc) les types WORD, BYTE, DWORD, etc. Nous nous attacherons particulièrement aux deux grandes structures de données : GAMEINFO (Pascal : TGameInfo) et CODE (TCode). Les voici...
GAMEINFO
C'est une gentille structure, il faut l'aimer (dixit sebc). Elle comprend les champs :
· dwDate, de type DWORD. Temps écoulé en nb de cycles depuis la création du serveur
· wHealth, de type WORD. Nombre de points de vie de votre O.C.
· wEnergy, de type WORD. Nombre de PE de votre O.C.
· byItemBuilt, de type BYTE. Type de l'objet en cours de construction
· byLastRobotId, de type BYTE. N° du dernier robot créé
· bySOS, de type BYTE. N° du robot ayant envoyé le plus ancien SOS. Vaut 0xFFFF si aucun robot n'a fait de SOS depuis le dernier appel à ReadGameInfo.
CODE
· wLengh, de type WORD. Longueur du code
· pwCode, de type WORD* (PWORD). Code proprement dit.
Le serveur élaboré par PROLOGIN est en quelque sorte l'environnement au sein duquel " existent " vos robots. Vos ordinateurs centraux, quoiqu'ils fassent, ne font en fait que transmettre des requêtes au serveur, lequel vérifiera leur validité et les exécutera. Il administre l'ensemble des robots, met à jour leur mémoire (PC, capteurs, etc.), le tout suivant un système de cycles.
Comme toujours à PROLOGIN, le serveur ne vous interpelle pas spontanément. C'est à vous d'effectuer vos requêtes d'information auprès de lui, via les différentes routines présentes à cet effet dans les librairies client qui vous sont fournies. Chaque appel requiert un certain nombre de cycles serveurs (voir annexes), pendant lesquels votre programme est " scotché ".
En ce qui concerne les avertissements " SOS ", ils sont stockés sur le serveur (dans la limite des places disponibles, comme dirait l'autre) jusqu'à ce qu'une requête de récupération appropriée émane du client. Ils sont alors transmis au client et effacés du serveur. Par conséquent, il est recommandé de consulter souvent sa liste d'avertissements et de ne pas la traiter à la légère.
Afin de déterminer le grand gagnant d'une partie, un certain nombre de critères sont examinés, par ordre " décroissant " (on examine le second si le premier ne permet pas de trancher, etc). Ce sont :
1. L'O.C. du joueur reste-t-il le seul O.C. en vie ?
2. A-t-il détruit le plus grand nombre d'O.C. ?
3. Les robots de l'O.C. ont-ils enlevé le plus de points de vie aux O.C. ennemis ?
4. A-t-il le plus grand nombre de robots détruits par ses légions ?
5. A-t-il le plus grand nombre de robots opérationnels ?
6. Ses robots ont-ils le plus fort nombre total de points de vie ?
La partie se joue bien entendu en temps limité, sinon c'est pas drôle.
ANNEXES
Voici un peu plus en détail les spécifications d'un de nos chers robots...
Voici la structure des banks R/W et R/O de la RAM I/O. De gauche à droite : l'offset de la zone concernée, son mnémonique (histoire de raccourcir les news...) et sa signification. Rappel : au départ la RAM I/O est mappée sur les deux dernières barrettes, la première étant le bank Read-Write, à l'adresse FE00h, et la seconde le bank Read-Only, en FF00h.
|
|
|
Signification |
|
|
|
Compteur d'instructions (cf. 3.2.2) |
|
|
|
Vitesse du robot. En négatif pour aller " à gauche ", en positif pour aller " à droite ". Limitée en valeur absolue à 42 |
|
|
|
Position du bras en degrés (de 0 à 359) |
|
|
|
Position de la caméra (idem, ibid.) |
|
|
|
Type d'outil actif sur le bras, voir les constantes de bras (OBJ_xxx) dans vos .h et .pas |
|
|
|
Etat actif (1) ou inactif (0) de l'outil courant. Si l'outil courant est OBJ_LAUNCH, soit le lance-missile, ACTOUTIL est automatiquement remis à zéro après lancement. |
|
|
|
Compteur de tours de la sphère du robot. A but purement informatif. Incrémenté par le serveur mais peut être remis à zéro par votre programme quand il le désire. |
|
|
|
Balise " SOS " qui déclenche un avertissement " immédiat " (cf. 5.1.2) à l'O.C. propriétaire du robot |
|
|
|
Etat vivant (1) ou mort (0) du robot. Qui veut se suicider ?... |
|
|
|
Mot " Vu Par Les Autres " : si un autre robot touche ce robot, le 1er verra ce mot. |
|
|
|
Signification |
|
|
|
N° de race du robot (du coup pour connaître votre race matez ce mot de la RAM I/O d'un de vos robots !). Va de 0 à Nombre d'O.C.-1 au maximum. |
|
|
|
Distance en pixons entre le centre de la sphère et le premier matériau rencontré sur l'axe de visée (voir 3.1.3). Vaut 0 si aucun obstacle n'est rencontrée sur la portée de 100 pixons. |
|
|
|
Données du capteur du bras : type de matériau ou d'objet. Reportez-vous aux constantes MAT_xxx de vos .h et .pas pour les valeurs. |
|
|
|
Race (si c'est un objet ou un rayon qu'on touche) |
|
|
|
Identificateur du robot propriétaire (idem) |
|
|
|
Mot " VPLA " (voir ci-dessus) du robot (idem) |
|
|
|
Abscisse relative au bord gauche de la zone de création de l'ordinateur central. Il s'agit de l'abscisse du bord gauche de la sphère. |
|
|
|
Ordonnée. Même topo avec les bords supérieurs. |
|
|
|
Nombre de missiles en stock (rappel : <= 16) |
|
|
|
Points de vie. Rappel : on commence à 97 |
Toute écriture dans une autre zone que celles-ci entraînera un comportement non-déterministe.
|
|
|
Signification |
|
|
|
Vide |
|
|
|
Rayon constructeur |
|
|
|
Rayon paralysant |
|
|
|
Pixel en cours de construction |
|
|
|
Rayon de caméra |
|
|
|
Bac d'acide |
|
|
|
Missile |
|
|
|
Métal |
|
MAT_ADAMANTITE
|
|
Adamantatite |
|
|
|
Robot |
|
|
|
O.C. |
|
|
|
Zone de création |
De plus, les mnémoniques utilisés pour les cellules de la RAM I/O dans les tableaux des sections 7.1.1 et 7.1.2 sont disponibles comme " constantes assembleur " dans un fichier ioram.i, présent dans˜prologin/include. Copiez-le dans le répertoire de votre code assembleur...
|
|
|
Paramètres |
|
|
|
Aucun |
|
|
|
Op1 |
|
|
|
Source, Destination |
|
|
|
Condition, Source, Destination |
|
|
|
Op1, Op2, Destination |
|
|
|
Op1, Op2, Destination |
|
|
|
Op1, Op2, Destination |
|
|
|
Op1, Op2, Destination |
|
|
|
Op1, Op2, Destination |
|
|
|
Op1, Op2, Destination |
|
|
|
Condition, Destination |
|
|
|
Valeur |
Les paramètres Op1, Op2, Source et Condition peuvent être des constantes -sous forme décimale, héxadécimale (0x...), octale (0o...) ou binaire (0b...)- ou des adresses (entre parenthèses, également en l'une des quatre bases précitées).
Le paramètre Destination est soit l'adresse de la donnée, soit l'adresse d'une adresse pointant sur les données. (Ex : " (0xFC00) " : adressage direct, ou " ((0xFC00)) " : adressage indirect).
Le paramètre Valeur ne peut être qu'une constante.
Le X des opcodes code la nature des différents paramètres (adresse/constante).
reset
Remet le PC (compteur d'instructions) à zéro. L'exécution reprend donc au tout début de la RAM. Annule toutes les opérations " config ".
nop
Attend Op1 cycles.
move
Copie la donnée Source à l'adresse Destination.
movenz
Copie la donnée Source à l'adresse Destination si la Condition est différente de zéro.
add
Ajoute les données Op1 et Op2 et inscrit le résultat à l'adresse Destination.
sub
Soustrait à la donnée Op1 celle de la donnée Op2 et inscrit le résultat à l'adresse Destination.
and
Effectue un ET bit à bit sur les données Op1 et Op2 et inscrit le résultat à l'adresse Destination.
or
Effectue un OU bit à bit sur les données Op1 et Op2 et inscrit le résultat à l'adresse Destination.
xor
Effectue un OU EXCLUSIF bit à bit sur les données Op1 et Op2 et inscrit le résultat à l'adresse Destination.
jnz
Examine la Condition. Si elle vaut différent de zéro (0), écrit l'adresse Destination dans le mot PC de la RAM I/O.
config
Pour le paramètre Valeur, on a : en octet de poids faible, le n° de la barrette de RAM, en octet de poids fort, le poids fort de l'adresse sur laquelle mapper la barrette. Permet le remapping des barrettes de RAM.
Toute action du robot : tourner, avancer, détruire, etc. se fera en combinant ces instructions. De même que pour l'écriture dans la RAM I/O, tout autre OpCode entraînera un Reset.
La fréquence de fonctionnement du système est faible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Temps d'accès
|
|
|
42 cycles
|
|
|
42 cycles
|
|
|
42 cycles
|
|
|
42 cycles
|
|
|
420 cycles * pixons / vitesse
|
|
Détecter un matériau |
1 cycle
|
|
|
10 pixons/s. |
|
|
On perd un point par pixel dans l'acide, tous les 42 cycles
|
|
|
Mais... y'a pas d'ascenseur !!! On les a virés ! |
|
|
42 cycles |
|
|
1 cycle |
· Un O.C. est un carré de 42 x 42 pixels
· Un robot est une sphère de 11 pixels de diamètre
· La caméra voit à 100 pixons
· Un bras détecte à 1 pixon
· Le terrain est représenté comme un carré de 1024 x 1024 pixels (au maximum)
· Un missile a une portée de 100 pixons
· Un rayon constructeur a une portée de 42 pixons
· Un rayon paralysant a une portée de 21 pixons
· Un O.C. démarre avec 4200 PE (Particles of Energy) et 420 points de vie
· Un robot démarre a 97 points de vie
· Créer un robot consomme 97 PE
· Créer un missile consomme 20 PE
· Créer un bras lance-missile, marteau-piqueur ou constructeur consomme 40 PE
· Créer un bras paralysant consomme 80 PE
· Créer une barrette de RAM consomme 40 PE
· Créer un pixel consomme 1 PE (même si on y arrive pas, c'est l'intention qui compte)
· Détruire un pixel rapporte 1 PE (sauf si on y arrive pas -Et meeeeeerde).
Nous vous fournissons un assembleur nommé AsmR42, qui prend en paramètres le nom du fichier contenant le code source Assembleur sans extension. Son extension obligatoire est " .s ".
La sortie est un fichier .o, que vous pouvez ensuite charger dans votre programme. Ce fichier contiendra un tableau de mots qui n'est pas encore du code valide. Il contient des informations d'adressage supplémentaires. Vous devrez le passer à la fonction standard LoadObject (cf. 4.5 et 8.3) pour obtenir du code valide, dont les adresses auront été recalculées par rapport à son offset de départ.
Voici la syntaxe d'appel d'AsmR42 :
AsmR42 nom_fichier_sans_ext
Il est possible de se constituer une petite bibliothèque de routines assembleur ; le problème alors réside dans l'utilisation d'adresses absolues dans le code : lorsque vous insérerez ce code à un endroit donné de votre RAM sur un robot, les adresses ne seront plus valides, n'ayant plus la même origine ! Aussi, nous avons prévu une routine vous permettant de " greffer " un morceau de code à un offset donné de la RAM de votre robot en recalant les adresses incluses dedans. Cette routine s'appelle LoadObject, elle vous est présentée en 4.5.
Bonne Chance, t'as 36h42'' !
(comme d'hab' !)