CODING ★ AVENTURES AVANT TOUT (II) ★

Aventures avant tout II (ACPC n°14)
Comme promis le mois passé, nous allons tout en douceur caresser la gestion des déplacements des jeux d'aventures. Dans cette ribrique, je vous le signale ( au fluor, bien sûr ), nous aborderons tous vos problèmes de programmation de jeux d'aventures, même ceux auxquels je n'ai pas encore pensé.

Le mois dernier, nous avons vu comment créer un plan de jeu d'aventures. Nous avons pris également comme convention que le numéro de la case dans laquelle se déplacerait le joueur porterait le nom “CASE”, et que toutes les cases du jeu (même si elles se voisinaient) ne communiqueraient pas toutes entre elles. Prenons ensemble notre souffle, car nous allons voir

FIN DE LA RECRE, AU BOULOT

Chaque case porte un numéro (tu l'as déjà dit) qui est attribué à la variable CASE. Nous allons créer pour les déplacements, un tableau que l'on appellera NSEO. Etant donné que, sur mon plan j'ai trente cases, il y aura NSEO(1), NSEO(2)... NSEC)(30). Accrochez-vous. Nous allons calculer la valeur des variables NSEO grâce à un principe fort utilisé en assembleur. Si l'accès au nord est possible, je lui ajoute 1, si l'accès au sud est possible, je lui ajoute 2, pour l'est j'ajoute 4 et enfin pour l'ouest on ajoute 8. Un petit exemple éclaircira vos petites lanternes ternes :

comment faire digérer tout cela au CPC.

PETIT RAPPEL NON ILLUSTRE

Cette rubrique ne s'adressant pas qu'aux fous de la programmation sur CPC, j'envisage donc la possibilité qu'il y ait, parmi nos lecteurs adorés, quelques-uns qui ne savent pas très bien ce qu'est un tableau. Pour les autres, cinq minutes de récré. Les tableaux sont tout simplement de bêtes variables, de types réels ou entiers avec, en prime, un indice, ce qui permet d'avoir une liste de variables portant toutes le même nom. Par exemple A(1), A(2), A(3), etc. Dans ce cas, le nom en commun étant A, il suffit de changer l'indice pour adresser une autre variable. Attention, si l'indice qui se trouve entre parenthèses est supérieur à 10 il faudra, avant d'utiliser ce tableau, déclarer la valeur maximale à atteindre (ce que l'on nomme dans notre jargon informatique “dimensionner un tableau”), à travers l'instruction Basic DIM.

La case n°19 de mon plan, qui est la “Place de Domont” a trois accès possibles (nord, sud et est). Donc NSEO(19)= 14-2+4=7. De même pour la case 10 : NSEO(10)=1+2=3. Sans vous tromper, vous calculez toutes les valeurs NSEO (même les cases qui n'existent pas, égales à 0). Si vous avez 34 cases, vous obtenez, si mes calculs sont bons, 34 valeurs qui seront stockées sous forme de DATAS et lues par une boucle FOR-NEXT. 10'

20 ' écriture et lecture des valeurs NSEO
30'
40 DATA 0,2,2,2,0,0,2,7,15.15,10,0,3,1,1
50 DATA 7,15,8,7,14,12,13,13,10,1,1,0,0,4,9
60'
70 DIM NSEO(30):RESTORE 40
80 FOR 1=1 TO 30:READ NSEO(I):NEXT I
90'

Il va de soi que la première valeur écrite dans les DATAS correspond à la case n°l, que la deuxième correspond à la case n°2 et ainsi de suite, et que le nombre de valeurs ainsi écrites est égal au nombre de colonnes qui multiplient le nombre de rangées (30 dans notre exemple).

JE PASSE, JE PASSE PAS

Je sens que vous vous demandez ce qui se prépare depuis tout à l'heure, je vous répondrai que, désormais, nous pouvons, à n'importe quel moment, savoir si le joueur peut aller dans une direction quelconque (si, si). Comment ? C'est tout simple : le joueur se trouve en case CASE, qui va de 1 à 30 ; pour cette case, il y a la valeur NSEO(CASE) qui est égale à dieu sait quoi.

  • Si NSEO(CASE) AND 1 <> 0 le nord est accessible.
  • Si NSEO(CASE) AND 2 <> 0 le sud est accessible.
  • Si NSEO(CASE) AND 4 <> 0 l'est est accessible.
  • Si NSEO(CASE) AND 8 <> 0 l'ouest est accessible.

C'est aussi simple que ça et, en plus, ça marche. Faites quelques essais pour vous en rendre compte vous-même. Prenez la valeur 14, par exemple, qui est la somme de 2+4+8, ce qui veut dire que l'on peut aller partout sauf au nord. Vérifions :

14 AND 1 = 0, ensuite 14 AND 2 = 2 et 14 AND 4 = 4, pour finir 14 AND.8 = 8. Seul le nord rend la valeur 0. Dans votre programme, vous pourrez ainsi gérer tous les déplacements. Le joueur donne l'ordre à l'ordinateur d'aller à l'ouest (nous verrons plus tard comment). Si NSEO(CASE) <> 0, il pourra le faire et, en plus, on modifiera la valeur de CASE en lui retranchant la valeur 1 (voir le mois précédent).

DIS-NOUS TOUT

Je parie que vous connaissez tous Ghosts & Goblins sur la version bor-ne d'arcade, ainsi que son adaptation sur CPC. Mais connaissez-vous sa suite, Goules & Ghosts ? Non ? Notre très cher ami, j'ai nommé l'infâme, l'horrible, le terrifiant et, n'empêche, le tout doux Frank Einstein, lui, le connaît par cœur. Il est beau, même très beau (le jeu, pas Frank). Non, je ne saute pas du coq à l'âne, mais dans ce jeu, il y a des endroits où, des fois, on passe et plus tard, ou plutôt, on ne passe pas (plus). Ça peut vous arriver également dans votre jeu d'aventures. Vous vous rappelez les barrières, les murs que l'on peut casser, ou une porte qui se ferme (ou s'ouvre me crie Lanisette... l'ami Septh), cela implique une modification éventuelle de la valeur NSEO(CASE).

Pour cela, nous utiliserons une autre opération logique M. Spoke, le. OR.

  • Pour ouvrir le nord : NSEO(CASE) = NSEO(CASE) OR 1.
  • Pour ouvrir le sud : NSEO(CASE) = NSEO(CASE) OR 2.
  • Pour ourvir l'est : NSEO(CASE) = NSEO(CASE) OR 4.
  • Pour l'ouest enfin : NSEO(CASE) = NSEO(CASE) OR 8.

Vérifions : je suis dans une case dont le nord et le sud sont bloqués, sa valeur est de 8+4, donc 12 ; je veux rendre le sud accessible, parce que le joueur a ouvert une porte qui était au sud. j'effectue un OR 2 sur NSEO(CASE) : 12 OR 2 = 14 qui correspond bien à 2+4+8 et le nord reste toujours bloqué.

ALAIN VERSE

Il serait vraiment trop injuste de pouvoir ouvrir une direction sans pour autant avoir la possibilité de la fermer. Si le mur du tunnel dans lequel j'erre s'écroule et que, par miracle, je ne mourus pas, je ne pourrai plus aller au nord d'où je venais, et le programme doit etre capable de bloquer l'accès nord.

XOR vous connaissez ? Mais non, Setph, pas le bridé en armure... Il a chaud Septh (oh qu'elle est bonne). Le XOR que l'on trouve dans le manuel à la page... euh... chais pu : c'est une opération logique qui est moins connue des Basiciens que les AND et OR et qui va nous venir en aide.

Pour fermer le nord : NSEO(CASE) = NSEO(CASE) XOR 1.

Vous voulez vraiment la suite ? OK ! Pour fermer le sud : NSEO(CASE) = NSEO(CASE) XOR 2.

Pour fermer l'est : NSEO(CASE) = NSEO(CASE) XOR 4.

C'est exactement la tactique employée, il y a de cela quelques années en Allemagne...

Pour fermer l'ouest : NSEO(CASE) = NSEO(CASE) XOR 8.

RESUMONS EN CŒUR

  • Pour la gestion des déplacements, nous utiliserons les trois opérations logiques, AND, OR et XOR.
  • Pour tester une ouverture éventuelle : NSEO(CASE) AND 1,2,4 ou 8 doit être différent de 0.
  • Pour une ouverture : NSEO(CASE) = NSEO(CASE) OR 1,2,4 ou 8.
  • Pour une fermeture : NSEO(CASE) = NSEO(CASE) XOR 1,2,4 ou 8.

Le mois prochain, tenez-vous bien, nous verrons comment écrire un analyseur de syntaxe, capable d'établir un dialogue entre le joueur et l'ordinateur. Ecrit en Basic, il vous permettra une saisie très souple, avec l'acceptation éventuelle de fautes d'orthographe. En attendant, je vous conseille de bien comprendre, malgré sa simplicité apparente, ce dont nous avons parlé ce mois-ci. Et s'il vous reste un peu de temps libre entre les courses et le ménage, vous pourrez commencer à préparer votre liste de verbes qui sera utilisée par l'analyseur de syntaxe. Notez que, dans cette suite d'articles, il y aura très souvent des petits listings ou bouts de programmes. Si vous voulez les utiliser tels quels, sauvegardez-les un par un sur une disquette, ceci afin de pouvoir les renommer, pour qu'il n'y ait pas de problèmes de saut et d'adressage (GOTO, GOSUB. RESTORE), et ensuite les reunir par des MERGE pour former votre programme principal.

Il se fait tard, le cours de mes idées vient d'être perturbé par Joe Satriani, qui est en train de faire des plans super grateux du type bliii blabla bla bla sur le walkman de Sined, qui, selon lui, est un homme qui joue avec son cœur (super propre, béton, génial)... Ce qui ne m'empêchera pas de vous dire que les meilleurs sont bel et bien Saga et Pretty Maid, sans oublier les premiers Yes et les excellents Emerson, Lake & Palmer (Ja pas d'accord : ND Sined) "mais si, Sined. c'est béton", (Septh), "ouais, c'est pas mal" (Lipfy), "ch'connais pas" (Agnès).

NDA : Snif ! Snif ! Je me sens seul dans ce monde où les goûts, comme les idées, divergent vers des galaxies distantes de milliers d'années lumière. Heureusement, il me reste la douce chaleur des paroles de mon fidèle ami Amousse : "seule compte dans ce bas monde la réalité, qui ne peut être que celle sur laquelle est basée ta vie". Voyez-vous !

POUM, A100% n°14

★ ANNÉE: 1989
★ AUTEUR: Alain Massoumipour

Page précédente : Aventures avant tout

★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser...

Lien(s):
» Coding » Aventures avant tout IV (ACPC n°16)
» Coding » Aventures avant tout V (ACPC n°17)
» Coding » Aventures avant tout VI (ACPC n°18)
» Coding » Chargement de fichiers .WIN
» Coding » Aventures avant tout (ACPC n°13)
» Coding » Aventures avant tout VII (ACPC n°19)
Je participe au site:

» Vous avez remarqué une erreur dans ce texte ?
» Aidez-nous à améliorer cette page : en nous contactant via le forum ou par email.

CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 569 millisecondes et consultée 823 fois

L'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent  du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko.