Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : AMOS - Faites vos jeux (Pac-Rev)
(Article écrit par Stéphane Schreiber et extrait d'Amiga News Tech - novembre 1990)
|
|
Après avoir abordé la théorie essentielle de la programmation d'un jeu,
nous allons passer à la pratique en construisant pour commencer un clone de Pac-Man, baptisé d'un doux nom aux consonances
érotiques Pac-Rev.
Aujourd'hui : Pac-Rev
Le principe du jeu est simple et connu de tous : un gentil personnage, le Pac-Rev, doit manger toutes les
pastilles d'un labyrinthe. Il est poursuivi par deux méchants qui essaient de le manger lui aussi, d'où
la cocasserie de la situation et l'intérêt du jeu. Notre gentil Pac-Rev est aidé dans sa quête par quelques
super-pastilles qui lui permettent de dévorer à son tour les monstres, durant un temps toutefois limité.
Avant que de se lancer tête baissée dans la programmation du jeu, il va vous falloir exercer vos talents de
graphiste pour dessiner les sprites et icônes nécessaires. Ce ne sera pas bien long, il n'en faut qu'une vingtaine
et tous ont la même taille, soit 16 pixels sur 16. Reportez-vous pour plus de détails aux petits schémas que
notre vénéré rédacteur en chef vous a concoctés.
Les deux croquis
J'ai essayé dans ce jeu d'obéir à la fois aux règles de l'optimisation et à celles de la structuration d'un programme.
Toutefois, pour des raisons de mise en page dans le journal, les bouts de routines se répétant ont été "compressés",
c'est-à-dire présentés de manière moins structurée. Il n'en reste pas moins que vous vous retrouvez avec quelque
400 lignes de programme à saisir... Bonne chance ! Avis aux fainéants de tous poils (surtout dans la main) :
vous pourrez bientôt vous procurer ce jeu, ainsi que les suivants réalisés dans cette rubrique), sur les disquettes ANT
que nous sommes en train de préparer. Cela vous évitera à la fois les crampes au petit doigt et les fautes de frappe,
et vous donnera qui plus est la possibilité d'admirer le talent graphique de l'ami Yves Huitric. Fin de l'auto-publicité,
retour aux choses sérieuses.
De l'utilité des variables
Toujours dans le but de ne pas monopoliser toute la place au sein de Commodore Revue, les tests nécessaires au
déplacement de chaque personnage - et qui seront détaillés plus loin - sont effectués par les mêmes procédures,
qu'il s'agisse du Pac-Rev ou des monstres. Ceci nous oblige donc à avoir une zone de données identique pour chacun
d'entre eux, à savoir des tableaux dimensionnés en début de listing, dont la signification est la suivante :
- TAB_X() et TAB_Y() contiennent les coordonnées-tableau des personnages. En effet, il est nécessaire
de savoir à chaque instant où il se trouve pour pouvoir décider de son déplacement et, dans le cas du Pac-Rev,
s'il a mangé une pastille ou non.
- SCR_X() et SCR_Y() contiennent les coordonnées-écran des BOB. Ces variables n'étaient pas réellement
nécessaires, mais il est plus rapide de les stocker ainsi plutôt que de les calculer à chaque fois d'après des
formules compliquées. Et n'oubliez pas que la rapidité est primordiale, surtout dans ce genre de jeux.
- BDIR() indique la direction dans laquelle se déplace actuellement le BOB. Les valeurs possibles sont 1 = haut,
2 = bas, 4 = gauche et 8 = droite.
- VITESSE() : donne la vitesse, en pixels, de déplacement. Les valeurs possibles sont 1 = escargrotesque, 2 = lent,
4 = moyen, 8 = rapide et 16 = injouable (seuls les diviseurs de 16 sont autorisés, puisque, rappelons-le,
une case du jeu mesure 16 pixels sur 16).
- Enfin VAR1(), VAR2() et VAR3() sont des variables de calcul utilisées uniquement par les monstres,
pour décider du chemin qu'il doivent suivre lorsqu'ils pourchassent le Pac-Rev (voir plus bas).
Le dessin du tableau
C'est la procédure "DESSINE_TABLEAU" qui se charge de devinez quoi ? De dessiner le tableau à l'écran, oui.
Afin de permettre un maximum de versalité, le tableau du jeu est codé sous forme de données, donc librement
modifiable par vous-même (voir au label "TABLEAU1:").
Notez au passage que comme on pense à tout et surtout à vous, la disquette citée plus haut contiendra également
un éditeur de tableaux approprié. Mais dans l'immédiat, il vous sera possible de délirer comme bon vous semble
lorsque vous saurez que d'une part, le tableau fait obligatoirement 14 cases de large sur 15 de haut, ceci pour
des raisons de "mise en écran" et que d'autre part, chaque chiffre de donnée correspond à une case du tableau.
Il s'agit d'un numéro d'icône à afficher, agrémenté d'une indication quant à la présence éventuelle d'une pastille
sur la case concernée. Le bit 7 du numéro indique une pastille "normale" et le bit 8, une super-pastille.
Pour simplifier :
- Numéro de $1 à $A = case sans pastille.
- Numéro de $41 à $4A = case avec une pastille "normale".
- Numéro de $81 à $8A = case avec une super-pastille.
C'est de l'hexadécimal. Le "A" correspond donc à 10.
On déduit de tout ça que le nombre de pastilles est entièrement variable et ne dépend que de votre volonté. Il est
stocké dans la variable "PNB_PASTILLES", qui est initialisée dans la procédure.
On calcule les coordonnées-écran de l'icône à afficher - et par extension, de tous les objets graphiques, BOB
compris - par les formules suivantes :
x_écran = 8 + (16'(x_tableau) - 1)
y_écran = 8 + (16'(y_tableau) - 1)
|
Ces formules découlent du fait que les coordonnées-tableau sont comprises entre 1 et 14 (1 et 15 pour la hauteur)
et non 0 et 13 (d'où la soustraction de 1), que chaque icône fait 16 pixels sur 16 (d'où la multiplication par 16)
et que tout le tableau est "décalé" de 8 pixels par rapport aux bords de l'écran, ceci pour des raisons d'esthétique
(d'où l'addition de 8). Reportez-vous au deuxième croquis, tout deviendra plus clair.
Let the game begin
On en arrive a la gestion du jeu proprement dit. Après avoir réinitialisé les variables citées plus haut pour être
sûr que tout démarre dans les bonnes conditions, on attend l'appui sur une touche ou sur le bouton de feu de la manette,
puis c'est parti, on entre dans la "boucle principale" (Cf. listing).
Comme vous pouvez le constater, cette boucle est très courte ; elle accomplit néanmoins tout le travail nécessaire :
affichage des trois BOB à leurs coordonnées respectives, détection des collisions éventuelles (AMOS a tout ce qu'il
faut pour ça), déplacement des trois personnages et test si le Pac-Rev a mangé une super-pastille, auquel cas le drapeau
"SUPER" est mis, indiquant qu'en cas de rencontre avec un monstre, c'est ce dernier qui meurt et non le joueur. Le plus
gros du travail est cependant réalisé par quatre procédures judicieusement nommées DEPLACE_PACREV, DEPLACE_MONSTRE,
TEST_DIR et MOVE_IT, procédures que nous allons détailler sans plus tarder.
DEPLACE_PACREV
DEPLACE_PACREV se charge, on s'en serait douté, du déplacement de notre gentil héros. Elle teste pour cela la manette
et le clavier, et actualise éventuellement la variable BDIR() après s'être assurée que la direction demandée était
permise (Cf. procédure TEST_DIR).
MOVE_IT
La procédure MOVE_IT, quant à elle, déplace à l'écran le BOB dont le numéro lui est passé en paramètre, tout simplement
en additionnant sa vitesse VITESSE() à ses coordonnées-écran SCR_X() et SCR_Y(). Elle vérifie également si le BOB
en question a ou non "changé" de case à l'intérieur du tableau. Ce test s'effectue de manière fort simple : si la
nouvelle coordonnée-écran (après addition, donc) est strictement divisible par 16, c'est que le passage d'une case à l'autre
est terminé, on peut donc tester si le BOB change de direction ou non. Dans la pratique, cela se traduit par "tant que
l'on n'est pas complètement sur une case du tableau, on ne peut pas changer de direction". Ceci évite qu'un BOB
ne se trouve à cheval sur deux cas, ou pire, sur un mur.
TEST_DIR
On en arrive maintenant à TEST_DIR, qui se charge de vérifier si la direction demandée est possible ou non. Pour ce
faire, il faut savoir sur quelle case le BOB se trouve et quelles sont celles qui l'entourent. Prenons un exemple
tout bête (suivez avec le premier croquis sous les yeux) : le Pac-Rev se trouve sur une case numéro 2. Cette case l'empêche
d'aller vers le haut. Si le joueur désire aller à gauche, il faut que la case à gauche de celle sur laquelle il se
trouve ne comporte pas de mur à droite, donc qu'elle porte un numéro différent de 3, 5, 6, 7, 8 et 9. De même, s'il
désire aller en bas, il ne faut pas que la case de dessous comporte de mur en haut, donc qu'elle porte un numéro différent
de 2, 4, 6, 7, 8, 9 et 10. Compris ?
Si je t'attrape, je te mords
J'avais gardé le plus difficile pour la fin : la procédure DEPLACE_ MONSTRE. Il s'agit ici de pourchasser le Pac-Rev tout
en évitant de rester coincé dans un cul-de-sac. Si le premier but est facile à atteindre, le second l'est beaucoup moins
(j'en sais quelque chose). En fait, trois cas sont à dissocier :
1. En début de jeu ou après s'être fait manger, le monstre sort de sa "maison". C'est le cas le plus simple,
il ne prend que six lignes de programme (suivez sur le listing, quoi !).
2. En cours de jeu, la direction à prendre est indiquée par deux variables (H et V pour ne pas les nommer) qui
sont respectivement le résultat des soustractions des coordonnées X et Y des monstres de celles du Pac-Rev. Ainsi, si
H est négatif, le monstre se trouve à gauche du Pac-Rev, il doit donc aller vers la droite pour le rattraper.
Une fois cette direction théorique déterminée, deux possibilités sont à envisager : soit il est possible d'y aller,
auquel cas on y va gaiement, soit le chemin est bloqué, et on rentre dans le troisième cas possible.
3. Arrivé ici, il faut d'abord se souvenir de l'endroit où on désirait se rendre. C'est le rôle de la variable
VAR1(), qui mémorise la direction visée.
Ensuite, et pour éviter que le monstre ne reste bloqué quelque part, il faut se souvenir quel chemin il a déjà emprunté.
Plus concrètement : s'il allait vers la gauche, il faut éviter qu'il ne retourne vers la droite, sinon il rentrerait dans
une boucle sans fin, puisque revenu au second cas, la variable H lui dirait de retourner illico vers la gauche en direction
du Pac-Rev. La variable VAR2() se charge de cette mémorisation.
Enfin, on considère que le monstre peut reprendre sa course vers le Pac-Rev lorsqu'il a changé deux fois d'axe. Ainsi,
s'il était bloqué à gauche (donc sur l'axe horizontal), on attend qu'il soit d'abord monté ou descendu (donc sur
l'axe vertical) puis reparti à gauche (à nouveau sur l'axe horizontal) pour revenir dans le second cas, celui du
déplacement "libre". C'est la variable VAR3() qui se charge de comptabiliser le nombre de changements d'axe.
Une dernière remarque en passant : lorsque le Pac-Rev a mangé une super-pastille, les monstres n'essaient plus de le
rattraper mais au contraire le fuient. Cet effet est obtenu en testant le drapeau "SUPER" (positionné plus haut, souvenez-vous) :
s'il est mis, les valeurs de H et de V sont inversées (changées de signe). Ainsi, tout se passe exactement de la même manière,
mais à l'envers.
Conclusion
Voilà, c'est tout pour notre Pac-Rev du mois. Il y a évidemment bon nombre d'améliorations à y apporter, par exemple plus
de monstres, des super-pastilles "dédiées" à un monstre particulier (le Pac-Rev ne pourrait manger que celui-là),
des tableaux supplémentaires, etc. Tout cela est laissé à votre entière perspicacité.
|
