UTILISATION DE JEUX DE SIMULATION EN
DIDACTIQUE DE L'INFORMATIQUE ET EN
ANIMATION
G.
GAUTIER
Association Nationale Sciences Techniques
Jeunesse Ris Orangis
INtll-Cléll formation
jeu de aimulation, didactique, informatique, animation,
R"u.é
Les animateurs en informatique de l'Aasociation Nationale Sciencea Techniquea Jeunesse ont développé à partir de 1979 pour dea préadoleacenta de 13 à 15 ans une aérie de jeux de simulation visant la compréhenaion du fonctionnement interne d'un micro-ordinateur.D'abord utilisée en camps de vacances, les jeux originels ont évolué en même tempe que leurs objectifs. Certaines versions ont été utilisées en formation d'adultes (enseignants, animateurs).
Ce texte tente de retracer cette évolution, da pointer les intérêts de l'outil didactique "jeu de simulation", sinsi que ses limites en termes de projet pédagogique et de niveau de descriptioa.
Abatract
Computer science teachera and educators of the National Sciencea and Technica Youth Association have developped since 1979 for 13-15 youngstera aome simulation games aimed to the understanding of the inner way of working of computer.
First used in summer camps, the first games evolved at the aame time as their aima. Some have been ueed in adult training. (teachera, educatorsl Thia text tries to deacribe this evolution, to point out the interest of the didactic tool "aimulation geme" , as welle as its limitations in terms of "pedagogical project" and dellcrlption eoale and level.
1) Le cadre d'utilisation initial:
A parti: de 1979, les équipes d'animation des camps scientifiques de jeunes a dominante "informatique" de l'A.N.S.T.J. (1) ont inventé un certain nombre de jeux de simulation (2). Les camps sont un encharn~ment de séquences pédagogiques visant à faire aboutir à une situation de développement collectif de logiciels.
Le jeu de simulation intervenait dans cette dynamique vers le projet. Ses objectifs spécifiques correspondaient à un moment d'interventl~n particulier dans un projet pédagogique sur 21 jours.
Le présent texte ne peut rendre compte ni de l'ensemble d'Un tel camp d'été, ni de l'articulation de la séquence "jeu de simulation" au projet pédagogique dans son ensemble.(3) Il se focalisera simplement sur:
- l'évolution de ces séquences, du public visé, des objectifs
- les limites atteintes par les animateurs en termes de problèmes de "niveau de description" qui se posent par ailleurs pour toule modélisation
à usage didactique.
II)
Lee jeux de Doucyl'intérieur de l'ordinateur. Pour d'un objet technique "mécanique", on La séquence "jeu" interv~naiten tout début de camp et
objectifs suivants:
- offrir un premier contact avec comprendre le fonctionnement interne peut
répondait aux
+ ouvrir l'objet et étudier son agencement
+ observer son fonctionnement réel
+ utiliser des modèles mécaniques permettant d'accomplir plus lente-ment les actions prévues par construction
Le mode de fonctionnement d'un ordinateur, objet "électronique" par excellence, peut difficilement être saisi par un de ces trois moyens. Les animateurs ont d'abord utilisé des explicatlvl.3 verbales fournies autour d'un ordinateur ouvert pour rendre visibles ses composants.
Mais pour des jeunes de 13 à 15 ans, une carte de plastique vert couverte de chemins de cuivre et de petites bottes de bakélite noire était quasiment plus hermétique qu'observer un fonctionnement à l'écran! (4)
l~ jeu de simulation, introduit avant cette séquence d'ouverture de la machine, voulait créer des "représentations d'accueil" - au sens proposé par A. GIORDAN - en partie connues des animateurs.
Les personnages du jeu ont donc été choisis en parfaite homothétie avec ce que l'on allait par la suite voir sur une carte micro chaque joueur représente un composant. G. DOWEK (5) caractérise ce type de jeu comme homogène, c'est à dire où les objets représentés par les joueurs ressortent tous du même niveau de description, en l'occurence, le matériel ( quincai llerie, "hardware"). Les animateurs voulaient aussi :
- eouder un groupe nouvellement constitué: la séquence du jeu est active corporellement, c'est une des premières du camp de vacances, et les jeunes s'y retrouvent dans une tâche qui les implique collectiVement, qui demande des interactions fortes entre eux. Le groupe se constitue au cours du jeu. C'est aussi une première vision de l'activité informatique alternative des le début à celle d'un travail assis isolément devant un
clavier, avec peu d'interactions sociales entre enfants, mais beaucoup entre programmeurs et ordinateur.
- faire Apprendre
à
créer des séquences pédagogiques à la demande : Plus tard, en formation d'éducateurs (enseignants, animateurs) ce type de séquence "jeu" sra utilisé syatématiquement comme "débloqueur" decr~ativité, c'est. dire qu'apr~s une phase initiale de démonstration de
quelques jeux,il sera demanrlé aux stagiaires de concevoir de telles séquences en réponse à des problèmes conceptuels précis, pour un public précis, en alternative à des séquences de forme "cours formel".
III) Haxipuce et Orditable : deux niveaux séparés de description
MAXIPUCE, le premier jeu développé à DOUCY, était quasiment une copie humaine du schéma interne d'un micro-ordinateur". Il allai t jusqu'à figurer les tampons internes du micro-processeur (totalement transparents à l'utilisateur) par des chaises: MAXIPUCE couvrait à la fois finement chaque élèment, et simultanément tous les él~ments matériels, de l'intérieur du micro-processeur aux périphériques (écran, clavier) en passant par la distinction bus d'adresses et bus da données.
A côté, l'équipe utilisait un jeu de table, ORDITABLE, 'lui se situait de
mani~re flagr'onte à un niveau de description "plus élev~" : l'interaction entre un interpréteur BASIC, les périphérlques entrée-sortie, et l'utilisateur, au moyen d'un bus unique.
IV) Le "jeu de la puce" du ca.p 13/15 ans de CHATEL 1983 :
les au bus sur les machine nombres) Les joueurs représentent :
Une version moins exhaustive a été utilisée par l'équipe de Juillet 1983. Nous partirons de cette version pour entrer un peu dans les détails de son
fonctionnement et de
l'évolution qu'elle subit.
- le processeur: il déchiffre les instructions du programme,
lequel est réputé déja en mémoire au début du jeu (6) et ordonne toutes les opérations de lecture et d'écriture en mémoire ou périphériques. Il incarne aussi la puissance de traitement de la (concrètement, avec le programme utilisé, il additionne des (schéma ~)
- le bus il se promène entre les autres composants pour, selon ordres du micro-processeur :
+ lire en mémoire données et instructions + écrire en mémoire (données)
+ porter. l'écran textes et données. afficher
+ chercher au clavier les données tapées par l'utilisateur. Cette version ne distingue pas "bus adresses" et "bus de données". - la
papier
mémoire Incarnée par un joueur qui se tient devant un tableau ou mieux, un tableau effaçable, elle est divisée en mémoire
de de
données et mémoire de programme. Elle stocke ce que le bus lui amène et lui délivre des copies des "cases mémoires" demandées. Cette version ne distingue pas "case mémoire" de "variable", puisque les cases Bont en fait adressées par des noms (la case A, B etc ... ) Ceci nous met au niveau assembleur symbolique, comme le lecteur pourra peut-être le penser en lisant le programme.
Le programme 1) ECRIRE A L'ECRAN "TAPE UN NOMBRE AU CLAVIER"
2) ALLER CHERCHER UN Nul-lI:JRE AU CLAVIER ET LE METTRE DANS LA CASE-MEMOIRE
liA"
3) ECRIRE A L'ECRAN "~NCORE UN SVP !"
4) ALLER CHERCHER UN NOMBRE AU CLAVIER ET LE METTRE DANS LA CASE-MEMOIRE liB"
5) ADDITIONNER LES CONTENUS DE "A" ET DE "B" ET METTRE LE CONTENU DANS LA CASE-MEMOIRE
"c"
6) ECHIHE A L'ECRAN "LE RF'SlILTAT EST"
7) ALLER CHERCHER LE CONTENU DE
"c"
ET L'AFFICHER AL' ECRANLes animateurs ont commencé à éxécuter eux-mêmes (7) le programme ci-dessus, et, peu à peu, se sont fait remplacer par des préados.
V) Détails de fonctionnement et problèmea de niveau de description Exécutons une séquence d'instructions, par exemple
5) ADDITIONNER LES CONTENUS DE "A" ET DE "B" ET METTRE LE CONTENU DANS LA CASE-MEMOIRE
"c"
6) ECRIRE A L'ECRAN "LE RESULTAT EST" mp bus mém bus mp mp mp bus (.
..
) mp bus : écrn: bus mpBus, va chercher et ramène-moi le contenu de la case mémoire A (il va à la mémoire)
Mémoire, il me faudrait le contenu de la case A En voici une copie
(il retourne au microprocesseur) Voici le contenu de la case A
Bus, va chercher et ramène-moi le contenu de la case-mémoil'" B (calcule A+ B et donne un papier avec le résultat au bus) Bus, va en mémoire et dis-lui de noter ceci dans la case C
Bus, va chercher en mémùire le texte de l'instruction numéro 6 (va à la mémOire) Donne moi le texte de l'instruction numéro 6 Bus, va dire à l'écran d'afficher ce texte
(va à l'écran) Ecran voici un texte à afficher (écrit au tableau: "LE RESULTAT EST")
(retourne au microprocesseur)
Bus, va en mémoire et ramène moi le texte de l'instruction numéro 1
(et ainsi de suite) Il était
différents
t "ès tentant d'utiliser ce jeu pour décrire en détail les types d'ordres d'un langage, en complexifiant progressivement
les programmes. Les objectifs ont ainsi progressivement évolué, passant du matériel au logiciel. En introduisant des ordres tels qu~ :
SI A PLUS GRAND QUE B STOPPER LE PROGRAMME SINON EXECUTER L'INSTRUCTION par exemple, on peut faire vivre aux stagiaires des déroulements de programmes leur permettant d'élaborer eux-mêmes une typologie réelle des ordres de la plupart des langages algorithmiques. A ce moment, l'homogénéité du jeu (un joueur
=
un élément mat~riel) se modifie en même temps que le niveau de description du Jeu. Lors que l'on recherche une nouvelle homogénéité (un joueur =un "élément logiciel") on remplace le couple central du jeu :micro-processeur - assembleur par un couple :
interpréteur de langage évolué - program.e à éxécuter
certes bien plus abstrait, et inobservabvle sur un ordinateur "éventré". D'autres jeux sont ensuite nés, visant à expliquer le déroulement d'un programme en langage procédural, et spécialement de procédures récursives, c'est a dire qui s'appellent elles-mêmes. Pour aider à comprendre le déroulement d'une telle procédure, est venue l'id ée de fai re incarnerr par un joueur non plus la procédure elle-même, mais le processUII.
Pour expliquer la différence, prenons l'exemple cla~~ique de la procédure qui cJlcule la factorielle d'un nombre N de manière récursive.
POUR rACTORIELLE DE N
SI N VAUT 1 RENDRE COMME RESULTAT 1
SINON RENDRE COMME RESULTAT N MULTIPLIE PAR rACTORIELLE DE N - 1
nN
Le résultat de la demande: FACTORIELLE 3 est obtenu par l'éxécution de 3 processus éxécutant tous les
3
le code de la procédure FACTORIELLE : le processus de calcul de factorielle 3 fait appel au processus de calcul de factorielle 2 qui lui-même appelle factorielle 1. Le résultat estcalculé au fur et à mesuree de
fi:
1 \ ' \ ~la "remontée" vers le demandeur
\I(
6-.;r
FR-Z-T]]
ini tial . (l'utilisateur. ex té-;'J \
t"CT
~1
1l'ocr 2 0rieur) a l'aide des resultats '7 tj
f'
~
'
intermédiaires (schéma). I<;i, \
?\_j
'~'V
~chaque processus est incarne ~
par un joueur différent; ceci
permet la distinction entre A ~
procédure et processus comme L /' .l- ~ - / •,J8~t
entre code et éxécution
ùr,
ISQ,lfU' Iro'\>fro«~~vb i:.~(\~ Mfr1E ( 0 Le problème de niveau de description est apparu dès les premiers jeux de simulation avec le problème de l'écho-écran: si un nombre est tapé au clavier, il se trouve automatiquement porté à l'écran ~ar le système d'''écho''. Pourtant, ce mécanisme d'icho n'est pas explicitement commandê par le programme, le microprocesseur ne dit pas au bus: "va chercher un nombre au clavier, porte le à l'écran au passage, et ramène-le moi".
ordinateur réel, il fait spontanément l'écho du claviel', ce qui déclanche immanquablement les protestations des autres joueurs.
Ceci a finalement mené à abandonner l'homogénéité matérielle de certains jeux, et à sub~Lituer au couple microprocesseur 1 bus le couple interpréteur / esclave, l'esclave étant bien un programme de service, de "niveau" inférieur à l'interpréteur en termes de modèle en couches, et qui se charge de la "basse-besogne" style l'écho-écran. VI) ConclusiOll
Dans ce type de modélisation comme ailleurs, se pose l'éternel problème de négocier entre les impératifs d'être exhaustif et être compréhensible. donc de choisir un niveau de description pertinent, pour l'échelle de description, l'effet de loupe sur tel ou tel fonctionnement, et le choix des élèmenta incarnés par les joueurs.
Cette négociation délical~ est à la fois tributaire de l'objet à
modéliser et des objectifs pédagogiques prioritires.
G. GAUTIER
NOTES
(1) Association Nationale Sciences Techniques Jeunesse - 17 Av. Gambetta, 91130 RIS-ORANGIS
(2) cf "Camps Micro-informatique à Doucy-Tarentaise" D. de MEESTER et A. POLlET - doc. ANSTJ, 1981
(3) pour une description plus large, cf pédagogiques pour préadolescents et début de
à
dominante informatique, Ste AFFRIQUE d'i .. ;'ormatique, Univ. Paris VIII, 1985"Propositions de logiciels réa- lisation - Uh camp d'été 1984" G. GAUTIER, maitrise
(4) problème bien sur assez différent pour l'usage de ce type de séquences en formation d'adultes, même si le jeu de rôle y a été aussi utilisé. (5) G. DüWEK, "Jeux de rôle homogènes et jeux de rôle hétérogènes", in MICROBE, revue du secteur informatique de l'ANSTJ. Décembre 1986
(6) certaines versions ont inclus un lecteur de disquettes en mémoire vive le contenu d'un fichier - pour simplifier nous n'entrons pas dans ce détail des opérations.
qui transférait l'explication,
(7) A Ste AFr'RIQUE, un an plus tard, ce jeu sera lJ1,éparé en un sous-groupe par une dizaine de participants qui le présenteront ensuite aux autres cet le "auto-animation" v isant à faciH te r psychologiquemen t la compréhension - ce qui est expliqué par un copain est a priori moins compliqué que ce qui est expliqué par un animateur.
