(2011) Conception, Realisation Et Evaluation D'un Jeu Serieux de Strategie Temps Reel Pour L'apprentissage Des Fondamentaux de La Programmation

Conception, realisation et evaluation dun jeu serieux de
strategie temps reel pour lapprentissage des

fondamentaux de la programmation
Mathieu Muratet
To cite this version:

Mathieu Muratet. Conception, realisation et evaluation dun jeu serieux de strategie temps reel
pour lapprentissage des fondamentaux de la programmation. Other [cs.OH]. Universite Paul
Sabatier - Toulouse III, 2010. French. <tel-00554287>
HAL Id: tel-00554287

https://tel.archives-ouvertes.fr/tel-00554287
Submitted on 10 Jan 2011
HAL is a multi-disciplinary open access Larchive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinee au depot et a la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publies ou non,
lished or not. The documents may come from emanant des etablissements denseignement et de
teaching and research institutions in France or recherche francais ou etrangers, des laboratoires
abroad, or from public or private research centers. publics ou prives.
!
"# " #! $
) " " ! , - , ) (
4$ 4565
$7 3 $ % +$ 8
8 $ $ +$ 8
% &
! "# $ $ % &'
( ) ** (
(+ , ( - !(* .)""(
, / 0 )**(
! $ -1 ( (*
( $ , 2 (
# # ! $, - 3 $
#' #' $ $ - - $
# '(" $ ( (*
AUTEUR : Mathieu MURATET
TITRE : Conception, ralisation et valuation dun jeu srieux de stratgie temps rel pour
lapprentissage des fondamentaux de la programmation
DIRECTEUR DE THSE : Pr. Jean-Pierre JESSEL
LIEU ET DATE DE SOUTENANCE : 2 dcembre 2010 lIRIT-UPS (Toulouse)
RSUM :
Les jeux vido font aujourdhui partie de la culture de nombreux tudiants au mme titre que
la tlvision, les films ou les livres. Or depuis quelques annes, les tudiants se dtournent
des sciences. La recherche dans le domaine de lenseignement de linformatique aborde les
problmes du recrutement et du maintien des tudiants dans les formations informatiques. Une
approche prometteuse consiste utiliser la culture vidoludique des tudiants pour les motiver
investir du temps dans la pratique de la programmation.
Dans ce cadre, les travaux prsents portent sur la conception, la ralisation et lvaluation dun
jeu srieux pour lapprentissage des fondamentaux de la programmation. Ce jeu est bas sur un
jeu de stratgie temps rel o la programmation est un moyen dinteraction. Grce au systme
Prog&Play, le jeu srieux a pu tre dploy et valu dans diffrents contextes denseignements.
MOTS-CLS : Jeux srieux, Apprentissage de la programmation, Prog&Play, Jeux de stratgie

temps rel.
DISCIPLINE ADMINISTRATIVE : Informatique
LABORATOIRE : Institut de Recherche en Informatique de Toulouse (IRIT)

Universit Paul Sabatier, Toulouse III
118 route de Narbonne
31062 Toulouse Cedex 9
!
"# " #! $
) " " ! , - , ) (
4$ 4565
$7 3 $ % +$ 8
8 $ $ +$ 8
% &
! "# $ $ % &'
( ) ** (
(+ , ( - !(* .)""(
, / 0 )**(
! $ -1 ( (*
( $ , 2 (
# # ! $, - 3 $
#' #' $ $ - - $
# '(" $ ( (*
Remerciements
Je tiens remercier les membres du jury pour avoir accept dvaluer mes travaux ainsi
que pour leurs commentaires aviss. Je remercie donc en tout premier lieu mes rapporteurs,
les professeurs Jean-Jacques Bourdin et Pascal Estraillier, ainsi que les examinatrices, Elisa-
beth Delozanne et Fabienne Viallet. toutes les deux, je tiens exprimer ma profonde recon-
naissance. Elisabeth Delozanne et sa collgue Franoise Le Calvez ont, par leur persvrance
et leur implication, particip au dploiement du jeu srieux lextrieur de lUniversit Paul
Sabatier. Fabienne Viallet par son investissement personnel ma aid rvler la composante
pdagogique de mes travaux. Cette collaboration avec Fabienne Viallet a t, pour moi, lune
des rencontres les plus enrichissantes lors de ces annes de recherche.
La ralisation de cette thse est laboutissement de mes tudes universitaires. Le point de
dpart de cette aventure commence en premire anne de Master o Patrice Torguet accepte
de mencadrer pour un Travail dtude et de Recherche. Il accepte de renouveler lexprience
lanne suivante pour mon stage de Master Recherche. La ralisation de cette thse en est la
suite logique. Pour sa confiance, sa disponibilit et son encadrement tout au long de ces annes,
je le remercie avec la plus profonde sincrit. Je remercie galement Jean-Pierre Jessel pour
mavoir accueilli dans lquipe VORTEX et fourni un cadre de travail idal pour la ralisation
de cette thse. Enfin, je remercie Monsieur Luis Farias del Cerro, directeur de lIRIT, pour
mavoir accueilli dans son laboratoire.
Je tiens galement prciser que ce travail naurait jamais pu tre ralis sans la collabo-
ration de nombreux enseignants. Je tiens donc sincrement remercier lensemble des quipes
pdagogiques qui mont fait confiance. Je remercie donc Max Chevalier et Christian Percebois
(dpartement Informatique - site Toulousain), Jrmie Guiochet et Andr Lozes (dpartement
Gnie lectrique et Informatique Industrielle - site Toulousain) et Sylvain Barreau et Emmanuel
Conchon (dpartement Services et Rseaux de Communication - site Castrais) de lIUT A de
Toulouse, mais aussi Marie-Franoise Canu et Andr Pninou du dpartement Informatique de
lIUT B de Toulouse et enfin Vronique Gaildrat, Mathias Paulin et tous les enseignants de
lUniversit Paul Sabatier qui ont particip aux exprimentations. Sans eux, je naurais jamais
pu tester le jeu dans des contextes denseignements rels et ainsi mettre en place les valua-
tions. . . merci encore.
Mes collgues et amis rencontrs au cours de ces quelques annes mont galement apports
de nombreux moment de dtente. Je remercie donc ceux qui mont accompagn tout au long de
v
cette thse, merci Jonathan Claustre, Andra Doran, Marion Dunyach, Philippe Ercolessi, Guil-
laume Gales, Mathieu Giorgino, Dorian Gomez, Olivier Gourmel, Franois Lefebvre-Albaret,
Sylvain Lemouzy, Anthony Pajot, Marie Ploquin, Samir Torki et Rodolphe Vaillant-David. Je
remercie galement ceux qui mont prcd et qui mont inspir, merci Souad El Merhebi,
Vincent Forest et Jean-Christophe Hoelt. Pour tout ce temps pass en leur compagnie, pour leur
aide, pour les grandes discussions au restaurant universitaire, pour les mmorables parties
de Magic et les folles courses de karting, je leur dis tous un grand merci. Je tiens enfin
remercier Loc Barthe, Nelly de Bonnefoy et Roger Pujado pour leur sympathie et leur bonne
humeur.
Enfin je souhaite remercier ma famille pour son soutien et le temps pass la relecture de
mes publications francophones. Je remercie tout particulirement mes parents Jol et Brigitte
Muratet. Toutefois, ma plus sincre reconnaissance est pour mon pouse, Cline. Elle a su
mpauler chaque instant et me donner la motivation suffisante pour mener bien ce projet.
Je lui ddie cette thse.
vi
Table des matires
Introduction 1
Partie I tat de lart 7
Chapitre 1 Jeux vido, jeux srieux et simulateurs 9

1.1 Gnralits sur les jeux vido . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.2 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Gnralits sur les jeux srieux . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.1 Historique et domaines dapplication . . . . . . . . . . . . . . . . 18
1.2.2 Composantes dun jeu srieux . . . . . . . . . . . . . . . . . . . . 22
1.3 Gnralits sur les simulateurs . . . . . . . . . . . . . . . . . . . . . . . . 24
1.3.1 Domaines dapplication . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Chapitre 2 Jeux de stratgie temps rel (STR) 29

2.1 Dfinition gnrale des jeux de STR fonde sur le jeu Dune 2 . . . . . . . 30
2.1.1 Rgles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1.2 Buts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.2 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3 Architectures rparties . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.1 Systmes centraliss . . . . . . . . . . . . . . . . . . . . . . . . . 36
vii
Table des matires
2.3.2 Systmes sans serveur . . . . . . . . . . . . . . . . . . . . . . . . 38

2.4 Exemples de jeux de STR code source ouvert . . . . . . . . . . . . . . . 41
2.4.1 Spring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.2 ORTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.4.3 WarZone 2100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Chapitre 3 Formation en informatique 47

3.1 Analyse du modle anglo-saxon . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.1 Dcoupage et points communs des disciplines informatiques . . . . 48
3.1.2 Analyse du Computer Science . . . . . . . . . . . . . . . . . . . . 50
3.1.3 Comparaison avec le modle franais . . . . . . . . . . . . . . . . 55
3.2 Analyse de lattractivit de la discipline informatique . . . . . . . . . . . . 56
3.2.1 Motivation et performances . . . . . . . . . . . . . . . . . . . . . 57
3.2.2 Innovations pdagogiques . . . . . . . . . . . . . . . . . . . . . . 60
Conclusion de ltat de lart 75
Partie II Contributions 77
Chapitre 4 Conception dun jeu srieux de STR pour lapprentissage de la program-

mation 79
4.1 Cadrage du jeu srieux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.1.1 Popularit des jeux de STR auprs des tudiants . . . . . . . . . . 80
4.1.2 Fonctionnement gnral du jeu srieux . . . . . . . . . . . . . . . 84
4.2 Spcification du systme Prog&Play . . . . . . . . . . . . . . . . . . . . . 86
4.2.1 Premire version . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.2.2 Seconde version . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3 Intgration de Prog&Play dans diffrents jeux de STR . . . . . . . . . . . 98
4.3.1 Intgration ORTS . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3.2 Intgration Spring . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.3.3 Intgration WarZone 2100 . . . . . . . . . . . . . . . . . . . . . 100
4.4 Conception du jeu srieux . . . . . . . . . . . . . . . . . . . . . . . . . . 102
viii
4.4.1 Premire version de Prog&Play avec ORTS . . . . . . . . . . . . . 103
4.4.2 Seconde version de Prog&Play avec Spring . . . . . . . . . . . . . 105
4.5 Portage de la partie Client de Prog&Play vers diffrents langages de
programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.5.1 Prog&Play en C/C++ . . . . . . . . . . . . . . . . . . . . . . . . 114
4.5.2 Prog&Play en Java . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.5.3 Prog&Play en Compalgo . . . . . . . . . . . . . . . . . . . . . . . 116
4.5.4 Prog&Play en OCaml . . . . . . . . . . . . . . . . . . . . . . . . 117
4.5.5 Prog&Play en Ada . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.5.6 Prog&Play en Scratch . . . . . . . . . . . . . . . . . . . . . . . . 119
Chapitre 5 valuation 123

5.1 Premire exprimentation . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.1.1 Contexte de lexprimentation . . . . . . . . . . . . . . . . . . . . 124
5.1.2 Conception du protocole dvaluation . . . . . . . . . . . . . . . . 125
5.1.3 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.2 Deuxime exprimentation . . . . . . . . . . . . . . . . . . . . . . . . . . 132
5.2.2 Intgration du jeu srieux dans la formation . . . . . . . . . . . . . 132
5.2.3 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.3 Troisime exprimentation . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.3.2 Intgration du jeu srieux dans la formation . . . . . . . . . . . . . 138
5.3.3 Conception du protocole dvaluation . . . . . . . . . . . . . . . . 140
5.3.4 Rsultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.4 Diffusion du jeu srieux . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.4.1 Premire diffusion . . . . . . . . . . . . . . . . . . . . . . . . . . 154
5.4.2 Deuxime diffusion . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.4.3 Troisime diffusion . . . . . . . . . . . . . . . . . . . . . . . . . 157
Conclusion des contributions 161
ix
Table des matires
Conclusions et perspectives 163
Partie III Annexes 175
Annexe A Dtail des interfaces de lAPI Prog&Play en langage C 177

A.1 Interface Fournisseur . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
A.1.1 Types de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . 177
A.1.2 Enttes des fonctions . . . . . . . . . . . . . . . . . . . . . . . . . 179
A.2 Interface Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
A.2.1 Types de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . 180
A.2.2 Enttes des fonctions . . . . . . . . . . . . . . . . . . . . . . . . . 180
A.3 Interface de gestion des erreurs . . . . . . . . . . . . . . . . . . . . . . . . 184
Annexe B Liste de constantes de Kernel Panic 3.8 en langage C 185
Annexe C Solution en langage C des six premires missions de la campagne 189

C.1 Mission 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
C.2 Mission 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
C.3 Mission 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
C.4 Mission 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
C.5 Mission 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
C.6 Mission 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Annexe D Interface algorithmique pour le langage C : PP_ALGO.h 195
x
Table des figures
1.1 Les Sims 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.2 Un jeu de latroncule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Premier jeu srieux : Army Battlezone. . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Americas Army. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5 Darfur is dying : un jeu srieux militant. . . . . . . . . . . . . . . . . . . . . . 20
1.6 Influence du jeu Zapitalism sur les performances des tudiants. . . . . . . . . . 21
1.7 Utilit du jeu Virtual U en fonction de lge des participants. . . . . . . . . . . 21
1.8 Exemple daffordance dans un jeu vido. . . . . . . . . . . . . . . . . . . . . . 23
1.9 Boucle perception, cognition, action en communication avec le monde virtuel. 26
1.10 Simulateurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.11 Croissance de ventes des jeux vido de 1996 2008. . . . . . . . . . . . . . . 28
2.1 Reprsentation du brouillard de guerre dans Dune 2. . . . . . . . . . . . . . 31

2.2 Perception dune situation de jeu en fonction de la prsence du brouillard de
guerre et de la prise en compte du champ de vision . . . . . . . . . . . . . 32
2.3 Influence du brouillard de guerre sur la perception de deux joueurs prenant
part une mme partie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Architecture client-serveur centralise. . . . . . . . . . . . . . . . . . . . . . . 37
2.5 Architecture pair pair distribue en communication point point. . . . . . . . 38
2.6 Situation de jeu dans Kernel Panic. . . . . . . . . . . . . . . . . . . . . . . . . 42
2.7 Hirarchie de cration des units des Systmes . . . . . . . . . . . . . . . . 42
2.8 Situation de jeu dans ORTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.9 Situation de jeu dans WarZone 2100. . . . . . . . . . . . . . . . . . . . . . . . 44
2.10 Systme de conception dunits. . . . . . . . . . . . . . . . . . . . . . . . . . 44
xi
Table des figures
3.1 Architecture modulaire des enseignements introductifs et importance des fon-

damentaux de la programmation . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2 Scratch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.3 StarLogo The Next Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4 Alice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.5 Kodu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.6 Compalgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.7 Robocode : un simulateur de batailles de robots. . . . . . . . . . . . . . . . . . 70
3.8 Colobot : un jeu srieux pour lapprentissage de la programmation. . . . . . . . 71
3.9 La RoboCup 2007 (Allemagne). . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.10 C-jump : un jeu de plateau pour dcouvrir les fondamentaux de la programmation. 73
4.1 Pourcentage de joueurs en fonction du sexe et du type de formation. . . . . . . 80

4.2 Enqute 1 : Pourcentage de joueurs en fonction du type de jeu. . . . . . . . . . 81
4.3 Enqute 2 : Rpartition de lintrt des tudiants pour les jeux indiffrents . . 82
4.4 Enqute 2 : Rpartition de lintrt des tudiants pour les jeux populaires . . 82
4.5 Enqute 3 : Les neuf catgories de jeu les plus mentionns parmi la classifica-
tion de GameSpot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.6 Enqute 3 : Les onze catgories de jeu les plus mentionns par les tudiantes
joueuses parmi la classification de GameSpot. . . . . . . . . . . . . . . . . . . 83
4.7 Interaction entre chaque joueur, leur programme et le jeu de STR. . . . . . . . 85
4.8 Prog&Play : une interface entre les langages de programmation et les moteurs
de STR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.9 Architecture fonctionnelle (version 1). . . . . . . . . . . . . . . . . . . . . . . 87
4.10 Le centre de dveloppement. . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.11 Architecture fonctionnelle (version 2). . . . . . . . . . . . . . . . . . . . . . . 92
4.12 Gestion de la mmoire partage par le Fournisseur . . . . . . . . . . . . . . 93
4.13 Cas particulier du rafrachissement ct Client . . . . . . . . . . . . . . . . 94
4.14 Diagramme de classes de lAPI Prog&Play. . . . . . . . . . . . . . . . . . . . 95
4.15 Diagramme de composants du systme Prog&Play. . . . . . . . . . . . . . . . 97
4.16 Exemple de programme en langage C fonctionnel avec plusieurs jeux de STR
intgrant le systme Prog&Play. . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.17 Grille de sudoku vide dans ORTS. . . . . . . . . . . . . . . . . . . . . . . . . 103
xii
4.18 Un vaisseau reprsentant un chiffre positionner sur la grille de sudoku. . . . . 103
4.19 Vaisseaux positionns conformment ltat initial de la grille de sudoku (avant
rsolution). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.20 Vaisseaux positionns conformment la solution de la grille de sudoku (aprs
rsolution). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.21 Exemple de briefing (Mission 1) . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.22 Exemple daffordance dans la mission 1. . . . . . . . . . . . . . . . . . . . . . 111
4.23 Composition du jeu srieux. . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.24 Graphe de dpendance de Prog&Play pour programmer en C. . . . . . . . . . . 114
4.25 Proposition dune reprsentation de lAPI Prog&Play sous une forme oriente
objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.26 Graphe de dpendances de Prog&Play pour programmer en Java. . . . . . . . . 116
4.27 Graphe de dpendances de Prog&Play pour programmer en Compalgo. . . . . 117
4.28 Graphe de dpendances de Prog&Play pour programmer en OCaml. . . . . . . 118
4.29 Graphe de dpendances de Prog&Play pour programmer en Ada. . . . . . . . . 119
4.30 Graphe de dpendances de Prog&Play pour programmer en Scratch. . . . . . . 120
4.31 Interface de Scratch modifie pour utiliser Prog&Play. . . . . . . . . . . . . . 121
5.1 Organisation temporelle de lvaluation pour la premire exprimentation. . . . 126

5.2 Comparaison des rsultats des tudiants notre valuation et lexamen dal-
gorithmique. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.3 Indice de difficult pour chaque mission. . . . . . . . . . . . . . . . . . . . . . 129
5.4 Extrait du questionnaire post exprimental en rapport avec lamusement. . . . . 130
5.5 Satisfaction moyenne des tudiants pour chaque niveau de la pyramide des be-
soins (IUT A dpartement informatique Toulouse III). . . . . . . . . . . . . . . 131
5.6 Solution de la premire mission en langage algorithmique. . . . . . . . . . . . 135
5.7 Solution de la troisime mission en langage algorithmique. . . . . . . . . . . . 135
5.8 Organisation temporelle de lvaluation pour la troisime exprimentation. . . . 141
5.9 Moyennes des notes obtenues aux valuations en fonction du groupe dtudiants. 145
5.10 Moyennes des notes obtenues aux QCM en fonction du groupe dtudiants. . . 145
soins (L1S1 IMP Toulouse III). . . . . . . . . . . . . . . . . . . . . . . . . . . 148
xiii
Table des figures
5.12 Perception des tudiants de lutilit dun jeu vido pour apprendre la program-
mation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
soins (IUT B Toulouse II). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
xiv
Introduction
1
Depuis la premire explosion des jeux vido dans les annes 80, lindustrie du jeu vido a
pris une place importante dans lconomie mondiale. En 2008 le march du jeu vido aux tats-
Unis a atteint 11,5 milliards de dollars [Ass09] et a dpass le march du cinma (10 milliards
de dollars en 2008) 1 . Les tudiants, actuellement luniversit, ont grandi avec les jeux vido.
Cette composante ludique fait partie de leur culture au mme titre que la tlvision, les films ou
les livres.
Par ailleurs, les tudiants se dtournent des disciplines scientifiques. En informatique, par
exemple, de nombreux travaux attestent que le nombre dtudiants est en chute libre et que
rgulirement 50% ou plus des tudiants ayant initialement choisi des tudes en informatique
dcident rapidement dabandonner. LUniversit Paul Sabatier subit le mme phnomne avec
une baisse de 17,6% dtudiants inscrits en premire anne de licence sur les quatre dernires
annes et une baisse de 30% en deuxime anne de licence informatique sur les sept dernires
annes.
La recherche dans le domaine de lenseignement de linformatique consacre une part impor-
tante de ses travaux aux problmes du recrutement et du maintien des tudiants dans les forma-
tions informatiques. Une approche prometteuse consiste utiliser la culture vidoludique des
tudiants pour les motiver investir du temps dans la pratique de la programmation.
Forte de ces constats, la recherche prsente dans ce mmoire sattache tudier un jeu
srieux pour lapprentissage de la programmation, le recrutement et le maintien des tudiants
dans la filire informatique. Ce travail de recherche est centr sur un type de jeu particulier :
les jeux de stratgie temps rel (STR). Comme nous le montrerons dans la suite, ce type de jeu
est bien adapt la mise en uvre dexercices de programmation et constitue donc un cadre de
conception adapt la problmatique.
Ce travail initi dans le domaine de linformatique a ncessit des comptences en didac-
tique pour aborder les problmes thoriques lis aux contenus des formations en informatique
et lapprentissage de la programmation. Ds la deuxime anne de mes recherches, jai col-
labor avec le Service Universitaire de Pdagogie (SUP) de lUniversit Paul Sabatier qui, son
tour, ma orient vers Fabienne Viallet, membre de lUnit Mixte de Recherche Education,
Formation, Travail, Savoirs (UMR EFTS). Ce partenariat ma galement permis de concevoir
le cadre dvaluation du projet pour les diffrentes exprimentations.
Dans ce contexte, ce document traite des problmatiques lies la conception et la rali-
sation dun jeu srieux centr sur les fondamentaux de la programmation et de son valuation
1. http://www.the-numbers.com/market/ accd le 27 Aot 2010.
3
en contexte rel. La prsentation des travaux sarticule donc autour de deux parties principales.
La premire sattache raliser une tude sur les jeux srieux et lapprentissage de la program-
mation. La seconde partie traite des contributions ralises au cours de ces travaux.
Ltat de lart est structur en trois chapitres qui prsentent de manire dtaille les com-
posantes relatives au cadre de recherche.
Le premier chapitre sattache positionner les jeux srieux vis--vis des jeux vido et des
simulateurs. En effet, les frontires entre ces trois types dapplications sont parfois mal dfinies.
Lobjectif de cette premire tude consiste donc comprendre les tenants et les aboutissants des
jeux srieux en vue de poser un regard critique sur lexistant.
Le cadre de recherche tant centr sur les jeux de STR, le deuxime chapitre prsente ce
type de jeux en vue den identifier les rgles et les buts. Cette prsentation sappuie sur ltude
dun jeu ayant fortement particip dfinir les bases des jeux de STR : Dune 2. Suite cette
dfinition, des exemples de jeux de STR code source ouvert, susceptibles de servir de base
la conception dun jeu srieux, sont examins.
Le troisime chapitre se consacre la prsentation de lenseignement en informatique.
Comme notre connaissance, il nexiste pas de rapport dtaill sur lenseignement de linfor-
matique en France, lanalyse du modle anglo-saxon est mis en perspective dans notre vision
du modle franais. cette occasion, ce chapitre aborde le problme de la la crise de linfor-
matique dans lenseignement et prsente quelques innovations pdagogiques qui tentent dy
rpondre.
Suite lanalyse de ces innovations pdagogiques, une approche pragmatique est envisage
pour concevoir, raliser, mettre en uvre et valuer un jeu srieux sur lapprentissage des fonda-
mentaux de la programmation. Les contributions, ralises au cours de ces travaux, sarticulent
donc autour de la conception du jeu srieux et de son valuation.
Le quatrime chapitre prsente donc la conception du jeu srieux qui sorganise autour de
deux composantes principales : le dveloppement du systme Prog&Play et son intgration
aux jeux de stratgie temps rel [MTVJ10a] [MTJV09] [MTJ09] [MTJV08b] [MTJV08a] ; et
lincorporation du savoir enseigner travers les diffrents modes de jeu [MTVJ10a] [MTJV09].
Outre ces deux points cls, ce chapitre est introduit en prambule par une srie denqutes
dont lobjectif est de vrifier la popularit des jeux de STR auprs dun chantillon dtudiants
apprenant la programmation [MTJV09] [MTJV08b]. Enfin, ce quatrime chapitre se termine en
abordant la problmatique de la portabilit du systme Prog&Play vers diffrents langages de
4
programmation. Cette compatibilit a notamment permis de faciliter la mise en place dexpri-
mentations dans diffrents contextes denseignements.
Le cinquime chapitre sattache prsenter ces valuations travers la description des con-
textes dexprimentation, des protocoles dvaluation, de ladaptation des enseignements pour
intgrer le jeu et des rsultats obtenus [MTVJ10a] [MTVJ10b] [MVTJ09] [VMD+ 10].
5
Premire partie
tat de lart
7
1
Jeux vido, jeux srieux et simulateurs
Dans le pass, les procds utiliss dans les simulateurs taient seulement disponibles pour
des systmes industriels et militaires trs onreux. Avec laugmentation des performances des
ordinateurs, les technologies se sont dmocratises jusqu investir des applications du grand
public telles que les jeux vido. Lutilisation commune de ces technologies par les simulateurs
et certains jeux vido rend la distinction de ces deux types dapplications parfois floue. Les nou-
veaux logiciels tels que les jeux srieux accentuent cette confusion. Nous allons donc prsenter
ces trois composantes pour tenter de positionner les jeux srieux vis--vis des simulateurs et
des jeux vido.
1.1 Gnralits sur les jeux vido
Mickael Zyda [Zyd05] dfinit le jeu vido comme un dfi intellectuel lanc sur un ordi-
nateur selon des rgles spcifiques. Il est ddi au divertissement ou au fait de remporter un
enjeu . Cette dfinition met en vidence deux points cls qui semblent fondamentaux pour
caractriser les jeux vido : les rgles et lenjeu.
Les rgles sont une composante fondamentale du jeu en gnral. Jean Piaget [Pia94] a dfini
une classification du jeu chez lenfant :
le jeu dexercices (0 2 ans) correspond la priode sensorimotrice. Le bb effectue des
exercices moteurs rflexes en fonction des informations perues ;
9
Chapitre 1. Jeux vido, jeux srieux et simulateurs
le jeu symbolique (2 8 ans) exerce la capacit de lenfant reprsenter une ralit non
actuelle, cest--dire limitation de ladulte travers le jeu (jeu de la poupe, de la dnette,
du bricolage) ;
le jeu de rgles (6 15 ans) marque la socialisation de lenfant. Ces jeux sont le reflet du
code social (jeux comportant des rgles).
Dans le dveloppement de lenfant, Jean Piaget introduit la rgle comme indicateur du

dernier stade du jeu. Il prcise que [. . .] sil ne demeure chez ladulte que quelques rsidus des
jeux dexercice simple [. . .] et des jeux symboliques [. . .] le jeu de rgles subsiste et se dveloppe
mme durant toute la vie (sports, cartes, checs, etc.) [Pia94, p. 149] ; le jeu vido entre donc
dans cette dernire catgorie et contribue promouvoir une communication sociale entre les
joueurs par lchange dexpriences ou de solutions acquises travers le jeu. Le mode de jeu
multijoueur favorise dautant plus cet change quil permet plusieurs joueurs dinteragir
ensemble dans le mme environnement virtuel. Alliance, coopration ou comptition mergent
pour fournir une forme de communication sociale.
Lenjeu est dfini par le dictionnaire TLFi (Trsor de la Langue Franaise informatis)
comme suit : Ce que lon peut gagner ou perdre dans nimporte quelle entreprise . La
prsence denjeu dans les jeux vido implique donc la dfinition de buts afin de dterminer
le gain ou la perte en fonction de latteinte ou non des objectifs. La stratgie mise en uvre par
le joueur pour atteindre ce but peut tre extrmement dirige (le joueur ne peut faire que trs
peu de choix) limage du jeu The House of the Dead 2 ou, linverse, des jeux comme Les
Sims 2 3 ou Grand Theft Auto IV 4 laissent le joueur presque totalement libre dans ses prises de
dcisions. Lobjectif, quant lui, nest pas toujours clairement dfini. Par exemple, Les Sims 2
pointe constamment les difficults surmonter par le joueur (fatigue, colre, salet. . . voir Fi-
gure 1.1). Lapproche qui consiste placer le joueur dans une dynamique de rsolution de prob-
lmes successifs est, semble-t-il, une motivation tout aussi grande que datteindre un succs
clairement dfini.
2. Sega, 1998
3. Electronic Arts / Maxis, 2000, http://thesims.ea.com/ accd le 26 Avril 2010.
4. Take 2 Interactive / Rockstar, 2008
10
1.1. Gnralits sur les jeux vido
F IGURE 1.1 Les Sims 2.

Le jeu pointe constamment les problmes rsoudre par le joueur.
1.1.1 Historique
Pour comprendre lvolution du jeu vido, lhistorique suivant prsente par ordre chrono-
logique quelques dates cls ayant particip lavnement du jeu vido, tant sur le plan technique
que matriel.
1952 : OXO est le premier jeu graphique fonctionnant sur un ordinateur (lEDSAC ou
Electronic Delay Storage Automatic Calculator). Ce jeu de morpion a t cr par A.S.
Douglas dans le cadre de sa thse sur linteraction homme-ordinateur luniversit de
Cambridge.
1958 : Tennis for Two est un autre prcurseur du jeu vido cr par William Higinbotham
fonctionnant sur oscilloscope et circuit lectronique ddi. Il a t conu pour distraire
les visiteurs lors des portes ouvertes du laboratoire national de Brookhaven.
1962 : Space War a t dvelopp dans le cadre du MIT (Massachusetts Institute of Tech-
nology) par Steve Russel et dautres tudiants dans lobjectif de montrer les performances
techniques du PDP-1 (Programmed Data Processor-1) de la firme DEC (Digital Equip-
ment Corporation). Deux joueurs sont ncessaires pour raliser une partie. Chacun deux
contrle un vaisseau spatial soumis la gravit dune toile. Lobjectif consiste tirer
sur le vaisseau de ladversaire tout en contrlant sa trajectoire pour ne pas entrer en col-
11
lision avec le soleil. Chaque joueur dispose dune quantit de carburant et de munitions
limits. Space War est considr comme tant le premier jeu vido sur ordinateur avoir
inspir des produits commerciaux. En effet, en septembre 1971, Galaxy Game (une ver-
sion reprogramme de Space War sur un PDP-11) est la premire machine de jeu vido
commerciale (borne darcade). Ce jeu conu en un seul exemplaire a t install au Tres-
sider Student Union de luniversit de Stanford. En Novembre de cette mme anne,
Computer Space est la premire borne darcade payante tre distribue en srie. Ce jeu
est galement inspir de Space War.
Septembre 1972 : lOdyssey, distribue par Magnavox, est la premire console de salon.
Elle est vendue avec 6 jeux intgrs et un ensemble daccessoires dont des caches appli-
quer sur lcran de tlvision pour simuler le dcor du jeu. la fin de cette mme anne,
Atari dveloppe et commercialise Pong. Cest le premier jeu vido remporter un rel
succs, il marquera le dmarrage de lindustrie du jeu vido. Pong, Space Invader (1978)
dvelopp par Taito, Pac-Man (1980) dvelopp par Namco et Tetris (1984) dAlexei
Pajitnov sont considrs comme de grands classiques de lhistoire des jeux vido.
1976 : La Fairchild Channel F est la premire console de jeux vido base sur un systme
de cartouches. Les consoles des annes 80 et dbut 90 telles que la NES (Nintendo Enter-
tainment System) et la super NES de Nintendo ainsi que la Master System I et II et la
MegaDrive de Sega reprendront ce systme. Il faudra attendre 1988 pour voir apparatre
un nouveau mdia de support de jeux tel que le CD-ROM avec la console PC Engine de
NEC (Nippon Electric Company). Le CD-ROM supplantera le systme de cartouches en
1994 avec larrive de la 3D et des consoles cinquime gnration (la Saturn de Sega et
la Playstation de Sony).
1977 : La console Atari 2600 contribue la dmocratisation des jeux vido en permettant
lmergence de grands classiques tels que Space Invader ou Pac-Man prsents ci-dessus.
1979 : Cration de la Microvision par MB (Milton Bradley company) la premire console
de jeux vido portable quipe dun cran cristaux liquides. Le principe de console
portable explosera rellement en 1989 avec la sortie de la Game Boy de Nintendo.
1981 : Donkey Kong cr par Nintendo pose les bases du jeu de plateforme et lance lun
des personnages les plus clbres de lhistoire du jeu vido : Mario.
1986 : Habitat est le premier monde virtuel commercial en ligne . Cr par Lucasfilm
Games en collaboration avec Quantum Computer Services (qui est devenu depuis Ame-
rica Online (AOL)), cet environnement est reprsent par des scnes animes en deux
12
dimensions dans lesquelles interagissaient des utilisateurs connects via des modems.
Habitat tient son origine dans les MUD (Multiple User Dimensions), mondes virtuels en
mode texte apparus au dbut des annes 80 avec les premiers systmes en ligne (les
BBS ou Bulletin Board Systems). Habitat a russi drainer, lpoque, quinze mille utili-
sateurs sur une base totale de cent mille utilisateurs de ce type de service en ligne . Ces
mondes virtuels comme les MUD ou Habitat, communment appels des ChatWorlds
(littralement : mondes o lon bavarde), peuvent tre considrs comme les anctres
des jeux massivement multijoueurs (Massively Multiplayer Online Game) ou MMOG
modernes comme Ultima Online (1997) dOrigin Systems et Electronic Arts, Everquest
(1999) de Verant Interactive ou World of Warcraft (2004) de Blizzard Entertainment.
1992 : Wolfenstein 3D cr par Id Software initi le genre de tir subjectif. Il sera suivi
lanne daprs par Doom (de Id Software galement) qui dmocratisera ce genre de jeu
et le portera au niveau multijoueur. Ce dernier est donc probablement lorigine de tous
les jeux en rseau actuels. Il est communment admis que la version shareware de Doom
a t rcupre quinze millions de fois sur Internet et/ou passe dindividu individu.
1993 : Dune2 cr par Westwood Studios dfinit un nouveau genre de jeu vido en posant
les bases des jeux de stratgie temps rel modernes.
1998 : Sega lance la sixime gnration de consoles avec la Dreamcast. Sony et Nintendo
ne tardent pas contre-attaquer en sortant respectivement la Playstation 2 en 2000 et la
GameCube en 2001. Cette mme anne, Sega se retire du march des consoles de salon
avec larrt de la production de la Dreamcast et Microsoft lance sa console : la Xbox.
2006 : Les consoles septime gnration voient le jour avec entre autres la Wii de Nin-
tendo qui rvolutionne la manire de jouer grce ces priphriques dentre intgrant de
nouvelles technologies telles quun acclromtre, le Bluetooth, un systme de pointage,
etc.
Ce bref historique montre que lvolution du jeu vido est fonction des deux composantes
matrielle et logicielles. En effet, chaque nouvelle technologie introduite par les diffrentes
gnrations de consoles et dordinateurs a permis la conception de jeux toujours plus innovants.
Inversement, ces mmes jeux qui ont marqus lhistoire par leur popularit ou leur ingniosit
sont des moteurs indispensables au dveloppement des nouvelles technologies.
13
1.1.2 Classification
Le march du jeu vido est donc en augmentation croissante. Lenqute de lESA [Ass09]
(Entertainment Software Association 5 ) indique que le nombre de jeux vido vendus aux tats-
Unis est pass de 72,8 millions en 1996 298,2 millions en 2008. Cette progression de 300%
dnote leffervescence de cette industrie qui ne cesse de proposer de nouvelles innovations
dans lobjectif de toujours surprendre les joueurs. Ce cercle vertueux, sur le plan conomique
a pour consquence une augmentation de loffre vido-ludique. Pour mieux apprhender cette
diversit, plusieurs tentatives de classification des jeux vido ont t proposes.
Chris Crawford [Cra84, chap. 3] prsente, ds 1984, sa taxonomie des jeux vido. Il insiste
sur la ncessit dun classement afin de rvler les liens et diffrences entre les familles et les
membres dune mme famille de jeux vido. Dj, Crawford est bien conscient de la grande
instabilit des jeux vido due lvolution rapide de ces derniers et nhsite pas prdire
lobsolescence ou linexactitude de sa propre taxonomie. Crawford dfinit donc deux grandes
catgories de jeux pour reprsenter lensemble des jeux vido existants cette poque : les jeux
de dextrit/action et les jeux de stratgie.
Les jeux de dextrit/action font intervenir en priorit la perception et lhabilet motrice.
Dans les annes 80, cette famille de jeu vido est la plus populaire. Elle est caractrise par des
jeux en temps rel qui mettent laccent sur les graphismes, le son et lutilisation de joysticks ou
de manettes au dtriment du clavier. Les comptences premires demandes aux joueurs sont
une bonne coordination il/main et un trs faible temps de raction. Ces types de jeux sont
regroups dans six sous-catgories : les jeux de combats, les jeux de labyrinthes, les jeux de
sports, les jeux de barres (bass sur Pong 6 ), les jeux de courses et les jeux divers (ensemble
des jeux nentrant pas compltement dans cette taxonomie).
Les jeux de stratgie mettent plus laccent sur la rflexion que sur la manipulation. Crawford
divise les jeux de stratgie en six catgories : les jeux daventure, les jeux de rle, les jeux de
guerre, les jeux de hasard, les jeux ducatifs et les jeux de communication.
Mark J. P. Wolf [Wol02, chap. 6] prsente, plus rcemment (2002), une classification par
genre. Il analyse la classification iconographique du cinma (drame, policier, comdie, etc.) et
tudie la portabilit aux jeux vido. Il en dduit quune telle classification ne peut tre adapte
5. http://www.theesa.com/ accd le 31 Mars 2010.
6. Atari, 1972
14
au jeu vido en raison de la composante interactive qui est, selon lui, un facteur important de
lexprience de jeu. En effet, un mme thme comme la science-fiction peut servir de support
diffrents types de jeux. Dans ce cas, la distinction entre ces jeux porte sur la manire dont le
joueur interagit avec le jeu et non sur le contenu du jeu. Wolf dfinit donc quarante deux genres
dont voici quelques exemples :
Abstract : ce type de jeu sans reprsentation physique implique souvent un objectif non
orient ou organis par une narration.
Capturing : jeu dont lobjectif principal est la capture dobjets ou de personnages qui
sloignent et tentent desquiver le joueur.
Catching : jeu dont lobjectif principal est la prise dobjets ou de personnages qui nes-
saient pas dviter activement le joueur.
Collecting : jeu dont lobjectif principal est la collecte dobjets statiques ou en mouvement
sur une petite zone.
Combat : jeu qui implique un ou deux joueurs (lun deux pouvant tre contrl par le
jeu) se tirant lun sur lautre laide de projectiles. Chaque joueur possde des moyens
similaires pour un combat quilibr.
Escape : jeu dont lobjectif principal est lesquive de poursuivants ou la sortie denclos.
Fighting : jeu qui implique le combat de personnages habituellement main nue, un
contre un, sans utilisation darmes ou de projectiles.
Maze : jeu dont lobjectif consiste se dplacer avec succs dans un labyrinthe.
Shoot em up : jeu dont lobjectif est de tirer sur plusieurs adversaires ou objets en vue
gnralement de les dtruire.
Sports : jeu qui est une adaptation dun jeu de sport existant ou dune variation de celui-ci.
Strategy : jeu qui met laccent sur lutilisation dune stratgie. Les actions rapides ou
lutilisation de rflexes ne sont gnralement pas ncessaires pour terminer le jeu.
Target : jeu dont lobjectif principal est datteindre (ou de tirer) sur des cibles statiques.
Ces quelques exemples illustrent la finesse de cette classification. Ces types de jeux sont
identifis comme parfois trs proches les uns des autres limage des genres Shoot em up et
target ou catching, collecting et capturing. Selon Wolf chaque jeu peut tre rattach plusieurs
genres en raison des diffrents types dactions et objectifs prsents dans un mme jeu.
Julian Alvarez [Alv07, chap. 4, sec. 2.2] (2007), quant lui, propose une classification base
sur ltude du gameplay des jeux vido. Alvarez sappuie sur la dfinition de Jean-Nol Portugal
15
qui dfinit le gameplay comme tant les rgles du jeu, les buts gnraux et locaux attribus
au joueur, les moyens daction et de libert concds lutilisateur dans lunivers virtuel. Ainsi
que les organisations spatiale, temporelle et dramaturgique . Aprs avoir tudi plus de 500
jeux, Alvarez dfinit 11 briques gameplay (Answer, Avoid, Block (Maintain), Create, Destroy
(Collect), Have luck, Manage, Move, Position, Shoot et Toy) et 4 mtabriques gameplay (Brain
compose de Answer et Avoid, God compose de Manage et Create, Killer compose de Shoot
et Destroy (Collect) et Driver compose de Move et Avoid). Les mtabriques sont dfinies
comme 1 : une combinaison de deux briques gameplay de nature complmentaire qui donne
ainsi naissance un dfi. 2 : Ajouter une brique gameplay une mtabrique, confre au dfi
port par cette dernire, une variante, qui cependant naffecte pas sa nature profonde. 3 : Si
lon ajoute plusieurs briques gameplay une mtabrique, le point (2) reste probablement vrai
tant que la mise en prsence de ces briques gameplay ne constitue pas leur tour une autre
mtabrique. 4 : Associer des mtabriques revient associer leur challenge respectif .
partir de ces 4 mtabriques, Alvarez dfinit 15 manires possibles de les combiner. Ces
diffrentes combinaisons correspondent 15 types de challenges distincts de jeux vido. Les
briques gameplay non utilises dans une des combinaisons permettent didentifier les variantes
de jeux vido pour un type de challenge particulier. Alvarez, par ailleurs, met en vidence
une relation inversement proportionnelle entre le nombre de mtabriques impliques dans le
challenge et le nombre de variantes possibles de jeu, ceci tant d au nombre restreint de briques
gameplay restantes.
La presse spcialise du jeu vido propose galement diffrentes classifications dpendantes

des lignes ditoriales de chaque magazine. Ces classifications sont sans nul doute les plus
consultes et utilises par les communauts de joueurs, elles mritent donc dtre mention-
nes. Parmi lensemble des magazines accessibles en ligne, GameSpot 7 est retenu de part sa
grande popularit. Selon Alexa 8 et Compete 9 , deux sites web danalyse du trafic sur Internet,
GameSpot serait le magazine de jeu vido le plus consult sur Internet en atteignant en moyenne
dans le classement global le 220me rang mondial avec plus de 5000 visiteurs par mois sur lan-
ne 2009. Les jeux rpertoris par ce site sont classs en 36 catgories dont les classiques jeux
7. http://www.gamespot.com accd le 02 Avril 2010

8. http://www.alexa.com accd le 02 Avril 2010
9. http://siteanalytics.compete.com accd le 02 Avril 2010
16
1.2. Gnralits sur les jeux srieux
daction, daventure, de course, de plates-formes, de rle, de simulation, de sport, de stratgie

temps rel et de tir subjectif pour ne citer que ceux-l.
titre dexemple, nous prsentons le positionnement du jeu Pac-Man 10 dans ces diverses
classifications. Lobjectif de ce jeu consiste collecter des bonus tout en esquivant les fantmes
prsents dans le labyrinthe. Pour Crawford, Pac-Man est un jeu de dextrit/action appartenant
la sous-catgorie des jeux de labyrinthe. Pour Wolf, ce jeu peut tre class dans les genres
Abstract, Collecting, Escape et Maze. Pour Alvarez, Pac-Man est caractris par la mtabrique
Driver et la brique Destroy (Collect). Enfin GameSpot, classe Pac-Man dans les simples jeux
daction.
Ces quelques exemples de classification illustrent la difficult dordonner les jeux vido de
manire prcise, exhaustive et prenne. La cause de cette difficult rside dans une composante
importante de la conception dun jeu vido : linnovation. Celle-ci porte autant sur le logiciel
que sur le matriel et a pour objectif de proposer aux joueurs sans cesse de nouvelles sensations.
Les classifications sont toutefois ncessaires pour apprhender la masse des jeux vido dune
poque donne. Se pose alors la question du positionnement des jeux srieux vis--vis des
jeux vido.
1.2 Gnralits sur les jeux srieux

Le terme jeu srieux , tel que nous lentendons aujourdhui, semble avoir t voqu
pour la premire fois, en 1970, par Clark Abt dans son livre Serious Games [Abt70]. Dans cet
ouvrage, le terme Serious Games est utilis pour des jeux de cartes ou de plateaux conus dans
un but ducatif.
Actuellement, lexpression jeu srieux est gnralement utilise dans un contexte infor-
matique plus prononc et caractrise une gamme de jeux vido bien plus large que le simple
jeu ducatif. En effet, un jeu vido conu avec un objectif autre que le simple divertissement
peut souvent tre considr comme un jeu srieux. Mickael Zyda [Zyd05] reprend sa dfini-
tion des jeux vido pour caractriser le jeu srieux comme un dfi intellectuel lanc sur
un ordinateur selon des rgles spcifiques. Il utilise le divertissement pour servir la forma-
tion, lducation, la sant, la scurit civile et comme stratgie de communication dans
10. Namco, 1980
17
des milieux institutionnels ou privs . Outre cette dfinition, Zyda identifie un point critique
de la conception dun jeu srieux concernant le positionnement du jeu par rapport au con-
cept de srieux (message vhicul quil soit dordre formatif, ducatif, informatif, etc.).
Zyda [Zyd05] crit ce propos que la pdagogie doit tre subordonne au scnario du jeu
la composante ludique doit primer . Lhypothse considre est que si un jeu est attractif, amu-
sant, stimulant et encourage le joueur progresser, alors le joueur intgrera automatiquement
les caractristiques du jeu et de nombreuses informations.
1.2.1 Historique et domaines dapplication
Trs tt dans lhistoire des civilisations, des activits culturelles sont apparues. Elles ser-
vaient distraire le peuple (jeux olympiques grecs ou jeux du cirque romains). Quelques jeux
font galement leur apparition comme la pettie grecque ou le latroncule romain (voir
figure 1.2). Ce sont des jeux de prise par encerclement, connotation guerrire (anctres du jeu
de dames). Ces jeux nont pas pour objectif premier lducation ou la rsolution de problmes
particuliers. Cependant, ce sont les jeux les plus anciens qui nous sont parvenus, bass sur un
raisonnement intellectuel, faisant intervenir la rflexion, la planification et non le hasard.
F IGURE 1.3 Premier jeu srieux : Army

F IGURE 1.2 Un jeu de latroncule .
Battlezone.
Plus rcemment, on pourrait attribuer le rang de premier jeu srieux Army Battlezone (voir
figure 1.3), un projet dvelopp par Atari en 1980, conu pour lentranement des militaires
amricains.
18
Par la suite, des groupes varis aux tats-Unis et au Royaume-Uni, ont utilis le principe de
lducation par le jeu 11 pour voquer des problmes sociaux ou de sant tels que la toxicomanie,
la vaccination, les grossesses adolescentes, le SIDA et le cancer. En France, les premires tenta-
tives grande chelle dducation par le jeu se retrouvent principalement dans la communaut
des muses scientifiques. Le Palais de la dcouverte et la Cit des sciences et de lindus-
trie Paris sont les premiers exemples avoir tent lexprience. Suite ces initiatives, un
nombre croissant de muses a vu le jour tel que la Cit de lespace Toulouse, le Centre
National de la Mer Nasicaa Boulogne-sur-Mer, Vulcania prs de Clermont-Ferrand et
Bioscope Ungersheim en Alsace.
La dfinition de Zyda prsente dans la section 1.2 met en exergue la diversit des do-
maines dapplication dans lesquels les jeux srieux peuvent tre employs. Cette diversit sem-
blant saccrotre continuellement, Julian Alvarez [Alv07, chap. 1, sec. 3] propose six domaines
dapplication afin de classer les jeux srieux : militaire, militant, marketing, ducatif/formatif,
informatif et mdical. Pour illustrer cette htrognit, nous prsentons par ordre chrono-
logique quelques exemples de jeux srieux aux domaines dapplication et aux objectifs dif-
frents.
F IGURE 1.4 Americas Army.
Americas Army 12 (voir figure 1.4) est un jeu conu en 2002 par linstitut MOVES (Model-
ling, Virtual Environments, and Simulation) du Naval Postgraduate School de Monterey, Cali-
fornie (Etats-Unis). Il a t initialement dvelopp comme outil de recrutement pour larme
11. http://www.socialimpactgames.com/
12. http://www.americasarmy.com/ accd le 25 Mars 2010.
19
des Etats-Unis. Il est devenu lun des premiers jeux srieux remporter un rel succs. Cest
lun des dix jeux daction les plus populaires jou en ligne. Le succs de ce jeu confirme donc
le potentiel des jeux srieux et ouvre la voie vers les autres secteurs dactivits pouvant avoir
recours ce nouvel outil. Nous pourrions classer Americas Army dans les jeux srieux de type
militaire et marketing en raison de sa volont de promouvoir larme des Etats-Unis.
Tactical Language & Culture 13 est un jeu initi en 2003 comme un projet de recherche au
laboratoire Southern Californias Information Sciences Institute sous le financement de DARPA
(Defence Advanced Research Projects Agency). Son but est denseigner les langues et cultures
trangres. Actuellement, ce jeu propose des enseignements pour larabe dIrak (Tactical Iraqi),
le pashtou dAfghanistan (Tactical Pashto), et le franais du Sahel Africain (Tactical French)
en vue de prparer les militaires aux oprations dans ces rgions. Tactical Language & Culture
est un jeu bas sur un jeu de rle. Pour permettre une communication immersive, le joueur
interagit avec un tuteur virtuel qui value lapprenant et lui fournit des retours sur ces erreurs.
Nous pourrions classer Tactical Language & Culture dans les jeux srieux de type militaire et
ducatif/formatif.
F IGURE 1.5 Darfur is dying : un jeu srieux militant.
Darfur is Dying 14 (voir figure 1.5) est un jeu dvelopp avec la fondation Reebok Human
Rights et le groupe International Crisis. Le but de ce jeu est de faire prendre conscience au grand
public des consquences de la crise du Darfour sur la population. Le joueur contrle lun de ces
habitants et doit maintenir en fonctionnement un camp de rfugis face aux possibles attaques
13. http://www.tacticallanguage.com/ accd le 25 Mars 2010.

14. http://www.darfurisdying.com/ accd le 25 Mars 2010.
20
des miliciens. Lobjectif de ce jeu est de toucher un maximum de personnes, par consquent,
cest un mini jeu gratuit et accessible en ligne depuis le mois dAvril 2006. Nous pourrions
classer Darfur is Dying dans les jeux srieux de type militant et informatif.
Moonshield 15 (publi en Octobre 2008) est un jeu de gestion/stratgie cr par la socit
KTM Advance. Il propose au joueur, dans un contexte danticipation proche, de mettre en uvre
les technologies de la socit Thales pour prserver la terre dune pluie dastrodes qui pourrait
dtruire toute civilisation. Cest un jeu gratuit et accessible en ligne. Nous pourrions classer
Moonshield dans les jeux srieux de type marketing et informatif.
Quelques rsultats dutilisation de jeux srieux en contexte rel : Rick Blunt [Blu06] a
analys trois jeux (Industry Giant II, Zapitalism et Virtual U) et leurs impacts sur les rsultats
dtudiants suivant des formations en conomie. Il a tudi cette influence en fonction du sexe,
de lorigine ethnique et de lge des participants. Il en conclut que dans tous les cas les jeux
srieux apportent un gain significatif la formation (voir figure 1.6).
F IGURE 1.6 Influence du jeu Zapitalism

F IGURE 1.7 Utilit du jeu Virtual U en
sur les performances des tudiants.
fonction de lge des participants.
Avec le jeu (courbe 1), 83% des personnes ob-
Les scores sont moins bon sans utiliser le jeu
tiennent la note maximale A. Sans lutilisation
(les quatre premiers btons) quavec le jeu
du jeu (courbe 2), il y a davantage de mauvais
(les quatre btons suivants) lexception de la
rsultats (D et F).
tranche dge 41-50 ans (le dernier bton).
On notera une exception intressante pour les personnes de 41 50 ans (voir figure 1.7)
qui obtiennent de moins bons rsultats. Blunt note ce propos que ces donnes renforcent la
perception selon laquelle les personnes de cette gnration apprennent mieux avec des mthodes
traditionnelles avec lesquelles elles se sont construites. Dans leur cas, lutilisation dun jeu
15. http://www.moonshield.com/ accd le 25 Mars 2010.
21
vido reprsente une difficult supplmentaire aux obstacles pistmologiques inhrents la

discipline conomique.
1.2.2 Composantes dun jeu srieux
Les quelques jeux srieux prsents dans la section 1.2.1 utilisent le divertissement pour
atteindre diffrents objectifs : Americas Army est un outil de recrutement ; Tactical Language
& Culture a pour but denseigner ; Darfur is dying tente de sensibiliser ; Moonshield est utilis
des fins de communication. Dans tous les cas, ces jeux ont su habilement quilibrer les deux
composantes : jeu et srieux . En effet, un jeu srieux nest pas seulement un logiciel, un
scnario et une interface graphique. Il implique une pdagogie pour atteindre son objectif. Cet
ajout, sans subordonner lhistoire, rend le jeu srieux. La dimension pdagogique est donc un
point important qui doit tre intgre ds les premires phases de conception du jeu srieux.
Dans un contexte de jeu srieux ducatif, Johnson et al. [JVM05] dtaillent lensemble des
composantes propres aux jeux vido et prcieuses pour maximiser lapprentissage :
le gameplay est lune des principales caractristiques dun jeu russi. Johnson et al.
dfinissent le gameplay comme toutes les activits et stratgies employes par les concep-
teurs de jeux pour obtenir et garder le joueur engag et motiv durant tout le jeu. Le
gameplay ne rsulte pas que du graphisme. Deux aspects du gameplay sont importants :
engager le joueur chaque instant et relier chaque action aux objectifs futurs ;
un feedback (retour dinformation) doit tre gnr par le jeu suite aux actions du joueur
pour lui permettre de chercher amliorer ses performances. Ces retours sont trs impor-
tants pour les jeux srieux, car ils indiquent au joueur sil russit ou non ;
une interface simple, bien dfinie, qui supporte les interactions entre le joueur et le jeu
(laffordance) est gage de qualit. Par exemple, elle peut suggrer ou guider les actions de
lutilisateur. Ces ajouts dinformations ne correspondent pas une scne relle, mais sont
ncessaires pour maintenir une interaction fluide entre le joueur et le jeu (voir figure 1.8) ;
les difficults surmonter doivent tre adaptes lexprience du joueur. Sil y a un trop
grand dcalage entre les capacits du joueur et la difficult demande, le jeu perdra de son
intrt. Il est donc souhaitable de proposer une version allge du jeu rel o la complexit
du gameplay est limite. Ceci permet au joueur de dvelopper ses comptences avant de
rencontrer les dfis du jeu complet ;
22
dans les jeux srieux modernes, lutilisation du scnario est fondamentale pour maintenir
lintrt du joueur et lencourager sidentifier au personnage ;
enfin, un bon jeu doit tre ludique. Cet aspect permet de maintenir lintrt et une attitude
positive du joueur.
F IGURE 1.8 Exemple daffordance dans un jeu vido.

La flche au dessus du personnage aide le joueur dans la comprhension de la scne.
En vue de comprendre pourquoi un joueur est motiv par lenvironnement de jeu, Siang et
Rao [SR03] ont adapt la pyramide des besoins de Maslow. Cette hirarchie est divise en sept
niveaux o les premiers servent de base aux niveaux suprieurs. Les sept niveaux par ordre de
priorit sont les suivants : (1) Le besoin de rgles, les joueurs recherchent des informations
pour comprendre les rgles de base structurant le jeu ; (2) Le besoin de sret, les joueurs ont
besoin de trouver de laide sur le fonctionnement du jeu ; (3) Le besoin dappartenance, les
joueurs ont besoin de sapproprier le jeu pour se sentir capable datteindre les objectifs ; (4)
Le besoin destime, les joueurs ont besoin dtre valoriss par le jeu (feedback, progression,
score, comptition, etc.) ; (5) Le besoin de connatre et de comprendre, les joueurs ont besoin
de dcouvrir les informations/bonus cachs et de les mettre en relation en vue de les rinvestir
en situation de jeu ; (6) Le besoin desthtique, les joueurs ont besoin de beaux graphismes,
deffets visuels, dune musique approprie, deffets sonores, etc. ; (7) Le besoin dauto accom-
plissement, les joueurs veulent tre capables de projeter leur crativit et imagination dans le
jeu sous contrainte du respect des rgles.
Cette hirarchie des besoins permet de garder lesprit quelques principes lors de la concep-
tion dun jeu srieux. Par exemple, des graphismes saisissants ne sauveront pas eux seuls un
23
mauvais gameplay. Siang et Rao prcisent que si un joueur ne comprend pas les rgles du
jeu dans les premires minutes, il risque simplement de sen dsintresser. Mais lorsque le jeu
srieux est correctement quilibr, des rsultats intressants peuvent tre obtenus.
Outre toutes ces caractristiques, Wolf et Alvarez (voir section 1.1.2) soulignent limpor-
tance de fixer les critres de classement selon linteractivit. Dans ce sens le concept de jeu
srieux ne caractrise pas un genre de jeu particulier mais est une composante des genres de
jeux existants. En reprenant la classification de GameSpot, il est alors possible dimaginer des
jeux srieux daventure, de plates-formes, de stratgie temps rel, etc. La combinaison du con-
cept de jeu srieux avec le cas des jeux de simulation pose alors le problme de sa diffrence
avec les simulateurs.
1.3 Gnralits sur les simulateurs

Le dictionnaire TLFi dfinit un simulateur comme un dispositif exprimental ou pro-
gramme dordinateur qui permet de reproduire artificiellement le fonctionnement rel dun ap-
pareil, dune machine, dun systme, dun phnomne, des fins dtude, de dmonstration ou
dexplication . Le point commun de tout simulateur est donc de reproduire artificiellement
un fonctionnement rel. La forme et la finalit du simulateur dpendent de lobjectif attein-
dre. Par exemple, les simulateurs de vol sont composs dun poste de pilotage rel pour prparer
les pilotes dans des conditions ralistes alors que les logiciels de simulation mtorologique sont
purement logiciels et sont utiliss des fins dtudes et de prvision. Dans ces deux exemples,
la reproduction de la ralit est la composante premire que doivent respecter les simulateurs.
Ltude de la simulation et de la modlisation se rapporte la reprsentation du temps et
ltat de la simulation dans un modle. Sur cette base, les simulateurs sont traditionnellement
classs selon le modle quils adoptent [NWFR06]. Un simulateur bas sur le modle de Monte
Carlo prsente les diffrents tats de la simulation sans reprsentation explicite du temps. Un
simulateur bas sur un modle dvnements discrets indique les changements dtat des ins-
tants prcis de la simulation. Les simulateurs bass sur une simulation continue dcrivent les
changements dtat en continu travers le temps. Les modles combinant vnements discrets
et simulation continue permettent dappliquer les deux techniques dans un mme simulateur.
Les simulateurs bass sur un modle de simulation hybride contiennent gnralement un sous-
modle analytique dans un modle dvnements discrets.
24
1.3. Gnralits sur les simulateurs
1.3.1 Domaines dapplication

Les simulateurs et les technologies de simulation sont utiliss dans de nombreux domaines
scientifiques et industriels. Narayanasamy et al. [NWFR06] dressent un ventail des domaines
dapplications traits par les simulateurs :
lanalyse de systmes en vue de comprendre leur fonctionnement et leurs concepts ;
lducation pour offrir un environnement qui promeut le dveloppement de modles
mentaux chez lapprenant ;
lapprentissage et lacceptation pour rpondre aux questions relatives aux systmes qui
attendent un certain nombre de prrequis et aux sous-systmes qui contribuent de manire
significative lamlioration des performances de systmes plus larges ;
la recherche pour recrer des environnements artificiels afin de tester les composantes du
systme ou tester le comportement dun ou plusieurs individus dans cet environnement
des fins de comparaisons ou de catgorisation ;
larme pour supporter plusieurs objectifs comme lentranement, lanalyse, lapprentis-
sage, la rptition de missions et lvaluation.
1.3.2 Historique
Cet historique retrace lvolution des simulateurs interactifs et plus particulirement des
simulateurs dentranement bass sur une simulation continue car ce sont les plus proches des
jeux vido. Ces simulateurs sont dits interactifs car ils intgrent lhomme dans la boucle de
simulation. Les systmes de ralit virtuelle sont couramment utiliss dans les simulateurs pour
positionner lutilisateur en situation dinteraction avec le monde virtuel. Un dialogue doit donc
stablir entre lhomme et la machine, cest la boucle perception, cognition, action (voir
figure 1.9) dfinie dans le Trait de la ralit virtuelle [FMT06, p. 9]. Lutilisateur peroit le
monde virtuel au travers dinterfaces sensorielles. Les priphriques permettent lutilisateur
de raliser des activits qui sont transmises au calculateur. Celui-ci les interprte et modifie
lenvironnement si besoin, puis restitue les informations sensorielles lutilisateur.
1910 : Lon Levavasseur conoit un des premiers simulateur de vol, le tonneau An-
toinette . Le poste de pilotage, mont sur rotule, est actionn manuellement en lacet,
roulis et tangage (voir Figure 1.10) ;
1915 : tmoignage photographique dun simulateur questre mcanique en bois (voir
figure 1.10) ;
25
F IGURE 1.9 Boucle perception, cognition, action en communication avec le monde virtuel.
F IGURE 1.10 Simulateurs.

De gauche droite et de haut en bas : le tonneau Antoinette de Lon Levavasseur (1910), simulateur
questre mcanique en bois (1915), le Link Trainer dEdwin Link (1929), un simulateur de vol civil
mouvement six axes , poste de pilotage exprimental dun simulateur NASA.
1929 : Edwin Link conoit le Link Trainer (voir Figure 1.10). Ce simulateur utilis
lors de la seconde guerre mondiale marque le dbut de lutilisation de simulateurs dans
un cadre de formation. Ds 1940, les ordinateurs seront intgrs aux simulateurs pour
rsoudre les quations de vol. Aujourdhui, lutilisation de simulateurs pour la formation
26
1.3. Gnralits sur les simulateurs
des pilotes davion (civils ou militaires) sest dmocratise. Les simulateurs les plus r-
cents tendent vers un ralisme de plus en plus pouss avec lamlioration des systmes
de mouvements (six degrs de libert) et des systmes de visualisation (images hautes
dfinitions, miroir courb) ;
1983 : SIMNET (SIMulator NETworking) a pour objectif de fournir un monde virtuel
permettant de simuler un champ de bataille o cent mille entits (simulateurs diffrents
et dlocaliss) peuvent voluer. Lapplication doit pouvoir fonctionner en temps rel, en
rpartition totale et tre peu coteuse par rapport au cot dune simulation grandeur na-
ture. Le problme cl du projet est de relier, travers un rseau, les diffrentes entits
afin de crer un champ de bataille virtuel cohrent. Il sera oprationnel en 1990. Trois ans
plus tard, DIS (Distributed Interactive Simulation) est le successeur de SIMNET. Avec ce
systme, un simple ordinateur pourvu dune carte rseau et pouvant grer le protocole de
communication de DIS peut prendre part la simulation ;
1984 : Inspir par les simulateurs de vol, le centre de recherche sudois VTI (Vg och
transportforskningsinstitutet) Linkping conoit lun des premiers simulateurs de con-
duite automobile. De nombreux constructeurs automobiles ont dvelopp, depuis, leurs
propres simulateurs en vue dtudier le comportement des automobilistes au volant de
leurs voitures. Le plus grand, actuellement en fonctionnement, a t conu par Toyota.
Il est install au centre technique de Higashifuji (2007). Ce simulateur de 4,5 mtres de
haut et 7,1 mtres de diamtre peut se dplacer sur 700 m2 et sincliner jusqu 25 degrs
pour recrer des acclrations de 0,5g.
27
Conclusion
La croissance de ventes des jeux vido (voir figure 1.11) tmoigne de la dmocratisation de
ce type de divertissement. Sue Blackman [Bla05] fait une synthse de ce domaine dactivits.
Les investissements confrs cette industrie, pour rpondre la demande du march, permet-
tent le dveloppement doutils et de bibliothques facilitant et amliorant la conception des jeux
vido. Les moteurs graphiques des jeux vido, de plus en plus perfectionns, peuvent mme tre
utiliss pour des applications autres que le jeu, car ils proposent des rendus temps rels et des
moteurs physiques ralistes. Des applications dentranement, de visualisation interactive et de
simulation de situation utilisent largement les technologies des jeux vido.
310
270
Millions d'units
230
190
150
110
70
1996 1997 1998 2000 2002 2004 2006 2008
Anne
F IGURE 1.11 Croissance de ventes des jeux vido de 1996 2008.

Donnes extraites de lenqute de lESA [Ass09].
Americas Army est un bon exemple de logiciel considr comme un jeu vido quand il est
tlcharg et jou pour sa composante ludique, comme un jeu srieux quand il est utilis comme
outil de recrutement et comme un simulateur quand il est intgr dans les stages dentranement
militaire. Il est alors possible de considrer les jeux srieux comme des intermdiaires entre les
jeux vido et les simulateurs. Ils possdent la composante ludique des jeux vido tout en pro-
posant, parfois, un objectif de formation ou dapprentissage propre aux simulateurs. Toutefois,
dans certains cas les frontires entre ces trois types dapplications restent floues.
La recherche conduite dans ce mmoire se concentre sur la conception, la ralisation et
lanalyse dun jeu srieux de stratgie temps rel pour lapprentissage de la programmation.
Dans ce cadre, il convient de prsenter en dtail ce type de jeu.
28
2
Jeux de stratgie temps rel (STR)
Parmi les classifications de jeux vido prsentes dans la section 1.1.2, celle de GameSpot
dfinit trois types de jeux de stratgie : les jeux de stratgie temps rel (STR), les jeux de
stratgie au tour par tour et les autres jeux de stratgie 16 . Le choix de lutilisation dun STR
comme base au jeu srieux est motiv dans un premier temps par sa complexit qui en fait un
environnement intressant pour la mise en pratique dexercices de programmation. Dautre part,
les jeux de stratgie reprsentent un genre de jeu populaire sur ordinateur comme le confirme les
chiffres de lESA [Ass09]. Celle-ci positionne les jeux de stratgie comme le type de jeu le plus
vendu sur ordinateur aux tats-Unis avec 34,6% des ventes sur lanne 2009. Enfin, lexistence
de moteur de jeu de STR code source ouvert reprsente une base utile la ralisation dun jeu
srieux. Ce chapitre dfinit donc le jeu de STR travers lanalyse de Dune 2 17 (un jeu ayant
fortement concouru lmergence de ce genre), prsente ensuite travers un court historique
les innovations importantes apportes par de nombreux nouveaux titres et dcrit enfin quelques
projets code source ouvert tmoins de leffervescence induite par les jeux de STR.
16. Le type autres jeux de stratgie regroupe lensemble des jeux de stratgie qui nentrent pas directement
dans lun des deux autres types (STR ou tour par tour). titre dexemple, la srie des Caesar (Sierra Enter-
tainment) et des Settlers (Blue Byte Software) sont classs par GameSpot dans cette catgorie.
17. Westwood Studios, 1992
29
Chapitre 2. Jeux de stratgie temps rel (STR)
2.1 Dfinition gnrale des jeux de STR fonde sur le jeu

Dune 2
Dune 2 est une adaptation en jeu vido du roman de Frank Herbert, Dune. Dans ce jeu, trois
Maisons (les Atrides, les Harkonnens et les Ordos) saffrontent pour le contrle de la plante
Arrakis. Le joueur incarne le rle dun commandant appartenant lune des trois Maisons. Il
devra livrer bataille contre les autres Maisons travers plusieurs missions. Son objectif consiste
dvelopper une base militaire en vue de lever une arme pour liminer les troupes et bases
ennemies.
Pour expliciter le fonctionnement de Dune 2, une analogie avec le jeu dchec savre perti-
nente. En effet, les checs font partie des jeux de stratgie, il est donc possible deffectuer un
certain nombre de comparaisons entre les checs et les jeux de STR. Le jeu dchec est compos
dun plateau et dun ensemble de pices. Le plateau est de topographie plane compos de 64
cases o chacune delle peut tre repre par un chiffre compris entre 1 et 8 (lignes) et une lettre
comprise entre a et h (colonnes). Chaque pice possde un certain nombre dattributs
tels que son apparence, sa position et son mode de dplacement.
De mme, Dune 2 propose au joueur de raliser les parties sur un certain nombre de cartes
gographiques (quivalentes au plateau du jeu dchec) avec un ensemble dunits de dpart
(quivalentes aux pices du jeu dchec). Au mme titre que les pices du jeu dchec se dpla-
cent sur le plateau de jeu, les units de Dune 2 voluent sur une carte o les positions des units
sont repres par des coordonnes x et y. La carte peut contenir du relief, diffrents types de
sols ainsi que des lments de dcors tels des impacts dobus, des btiments, des ressources, etc.
Gnralement, les ressources jouent un rle important dans les jeux de STR, car, prsentes en
quantits limites (lpice pour Dune 2), elles sont ncessaires et convoites par tous les joueurs.
Les units sont dotes galement dun certain nombre dattributs tels quune apparence, une
position, un mode de dplacement, mais aussi un capital sant, un champ de vision, un cot,
une force, etc. Lensemble de ces attributs caractrise le type dune unit.
Chaque nouveau jeu de STR tente dintroduire des innovations afin de surprendre les joueurs.
Ces innovations peuvent porter sur la qualit des graphismes, lunivers du jeu (mdival, futur-
iste, etc.), le scnario, les caractristiques des units, le nombre dunits, etc.
30
2.1. Dfinition gnrale des jeux de STR fonde sur le jeu Dune 2
partir de la dfinition du jeu vido de Mickael Zyda prsente dans la section 1.1 nous
avons identifi deux points cl pour caractriser un jeu vido savoir dfinir les rgles et les
buts du jeu.
2.1.1 Rgles
Dans Dune 2 quatre rgles fondamentales ont t identifies : le temps rel , le brouil-
lard de guerre le contrle indirect et larbre des technologies . Le temps rel est
oppos au tour par tour utilis aux checs par exemple o, chaque joueur, lun aprs lautre,
modifie ltat du jeu sa convenance. Dans un jeu en temps rel , chacun est libre de raliser
une action nimporte quel instant. Par consquent le joueur doit tre capable dadapter rapi-
dement sa stratgie un environnement hautement dynamique.
Le brouillard de guerre cache les parties de lenvironnement non encore explores par
le joueur. Les zones visibles dpendent en effet des positions de ses units sur la carte. En
consquence, les units de ladversaire sont caches tant quelles nentrent pas dans une zone
dj dcouverte par le joueur. La figure 2.1 illustre le brouillard de guerre tel quil tait
prsent dans Dune 2.
brouillard
de guerre
F IGURE 2.1 Reprsentation du brouillard de guerre dans Dune 2.
Le principe de brouillard de guerre a t amlior par la suite en prenant en compte le

champ de vision de chaque unit. Dans ce contexte, pour tre visibles, les units de ladver-
saire doivent pntrer le champ de vision dune unit contrle par le joueur et ne pas simple-
ment entrer dans une zone dj explore et non surveille. La figure 2.2 montre la diffrence
de perception dune situation de jeu en fonction de la prsence du brouillard de guerre et
de la prise en compte du champ de vision . La figure 2.2a prsente la scne de jeu. Elle
contient les units du joueur et de son adversaire ainsi quun certain nombre dlments de
31
dcor immobiles. La figure 2.2b illustre linfluence du brouillard de guerre. Il reprsente les
zones non explores par le joueur et cache les units adverses et les lments de dcor situs en
dessous. La figure 2.2c ajoute les champs de vision des units du joueur. Dornavant, seules les
units adverses sous surveillance sont visibles. Les lments de dcor immobiles prcdemment
dcouverts sont toujours connus et affichs.
(a) Scne de jeu. (b) Scne de jeu avec brouillard de (c) Scne de jeu avec brouillard de
guerre. guerre et champs de vision.
: Entit contrle par le joueur.
: Entit contrle par son adversaire.
: lment de dcor immobile.
F IGURE 2.2 Perception dune situation de jeu en fonction de la prsence du brouillard de
guerre et de la prise en compte du champ de vision .
Dans un contexte multijoueur, chaque joueur volue dans un environnement mal connu quil
doit explorer. La Figure 2.3 illustre linfluence du brouillard de guerre sur la perception
dune mme partie. Dans cette situation de jeu, le joueur A (voir figure 2.3a) contrle les units
triangulaires et a ordonn lune dentre elles (numrote 1) de sloigner vers la gauche. En
se dplaant, elle dtecte deux units du joueur B (numrotes 2 et 3). Inversement le joueur
B (voir figure 2.3b) qui contrle les units rectangulaires (dont celles numrotes 2 et 3) voit
apparatre lunit du joueur A (numrote 1) passant proximit de ses units.
Le contrle indirect permet au joueur de dfinir un ordre pour une ou plusieurs de ses
units. Celles-ci vont alors tenter de lexcuter sans que le joueur ait besoin de les contrler
directement. Celui-ci peut alors commander dautres units en parallle. Ce mode de contrle
permet galement de grer les conflits inhrents au temps rel . En effet, si deux units ont
reu lordre datteindre une mme position, le jeu rsoudra le conflit et dterminera automati-
quement celle qui atteindra la position finale et celle qui abandonnera son action.
32
2.1. Dfinition gnrale des jeux de STR fonde sur le jeu Dune 2
2 3 2 3
1 1
(a) cran de jeu du joueur A. (b) cran de jeu du joueur B.

: Entit contrle par le joueur A.
: Entit contrle par le joueur B
: lment de dcor immobile.
: Zone explore sous surveillance (champ de vision).
: Zone explore sans surveillance.
: Zone non explore (brouillard de guerre).
F IGURE 2.3 Influence du brouillard de guerre sur la perception de deux joueurs prenant
part une mme partie.
Enfin, larbre des technologies reprsente une architecture abstraite des diffrents l-
ments du jeu. En dbut de partie, le joueur possde un ensemble restreint dunits et de struc-
tures qui vont lui permettre den construire de nouvelles et de dbloquer ainsi de nouveaux
lments. La matrise de larbre des technologies est une part non ngligeable des jeux de
STR car elle permet un joueur expriment de rapidement accder une ou plusieurs techno-
logies ncessaires la mise en uvre de sa stratgie.
2.1.2 Buts
Traditionnellement les jeux de STR proposent deux modes de jeu : la campagne et les-
carmouche. Le mode campagne a pour objectif de sduire le joueur en vue de lui apprendre
jouer. Une campagne est divise en missions qui introduisent progressivement le contenu
et la complexit du jeu. Dans ce mode de jeu, le joueur devra atteindre des objectifs en lien
avec le droulement des vnements, comme atteindre une position, rsister aux attaques de
ladversaire ou construire une unit particulire.
33
Le mode escarmouche (non prsent dans Dune 2) a pour objectif dtendre la vie du jeu
en permettant au joueur de remporter des dfis contre dautres joueurs ou lordinateur. Dans ce
mode de jeu, le but consiste, en gnral, liminer toutes les units de ladversaire. Eliminer une
unit revient amener son capital sant une valeur nulle. Pour ce faire, le joueur doit ordonner
lune de ses units dattaquer lunit cible. Ces deux units vont alors engager un combat et
produire plusieurs assauts jusqu ce que lune dentre elles soit limine. Chaque assaut rduit
lnergie de ladversaire du nombre de points de dgts que peut infliger lattaquant.
En raison du brouillard de guerre , le joueur doit dans un premier temps ordonner ses
units mobiles daller explorer la carte en indiquant pour chacune delles une position attein-
dre. Lorsque ladversaire est dcouvert (i.e. lorsque lune des units du joueur est suffisamment
proche dune unit de ladversaire pour la dcouvrir) le joueur peut alors ordonner ses units
dengager le combat.
Ces quelques rgles et buts poss par Dune 2 ont t amliors par la suite avec les nouvelles
gnrations de jeux de STR.
2.2 Historique
De nombreux jeux de stratgie en temps rel ont exist avant Dune 2 limage de Stonkers 18
(1983), The Ancient Art of War 19 (1984) ou encore Populous 20 (1989). Lensemble de ces jeux
peuvent tre considrs comme les prcurseurs des jeux de STR actuels et ont certainement
inspir en leur temps les concepteurs de Dune 2. Ce dernier est nanmoins considr comme le
pre des jeux de STR car les rgles et buts issus de ce jeu semblent tre, encore aujourdhui,
reprsentatifs de la majorit des jeux de STR. Toutefois, certains ne reprennent pas en totalit
les principes poss par Dune 2, ce qui naffecte en rien leur appartenance cette famille de jeu.
Bien au contraire, cette diversit contribue renouveler et faire voluer les jeux de STR. Pour
illustrer ces volutions, lhistorique suivant prsente, par ordre chronologique, quelques jeux
vido ayant particips lmancipation des jeux de STR depuis la sortie de Dune 2 en 1992.
1994 : Warcraft dvelopp par Blizzard Entertainment est le premier titre dune srie
ayant fortement particip dmocratiser les jeux de STR. Il a initi laspect multijoueur
18. Imagine Software, 1983

19. Evryware, 1984
20. Bullfrog, 1989
34
2.2. Historique
travers le mode escarmouche et a introduit la fonctionnalit de pouvoir slectionner

plusieurs units et de les commander simultanment.
1995 : Command & Conquer dvelopp par Westwood Studio est galement le premier jeu
dune longue srie. Il a notamment dvelopp le principe de gestion de groupes dunits.
1996 : Warcraft 2 amliore le brouillard de guerre en exploitant le champ de vision
de chaque unit.
1997 : Total Annihilation dvelopp par Cavedog Entertainment est le premier STR
reprsenter les units et les cartes de jeu par des maillages 3D. Il introduit galement un
moteur physique raliste dans un jeu de STR. Dans cette mme anne, Age of Empires
dvelopp par Ensemble Studios met laccent sur larbre des technologies et propose
une architecture plus complexe inspire des jeux de stratgie en tour par tour tels que
Civilization 21 .
1998 : Starcraft dvelopp par Blizzard Entertainment est le jeu de STR avoir remport
le plus grand succs. Trs peu de jeux vido ont eu une dure de vie suprieure 10 ans.
Un circuit de comptitions internationales (incluant des championnats professionnels)
sest organis autour de ce jeu. Dans cette mme anne, le jeu Battlezone dvelopp par
Activision tente un mlange des jeux de STR et des jeux de tir subjectif.
1999 : Homeworld dvelopp par Relic Entertainment introduit un environnement tridi-
mensionnel et autorise une libert de mouvement en tout point de lespace.
2001 : Cossacks dvelopp par GSC Game World porte le nombre dunits contrlables
plus de 8000.
2002 : Warcraft 3 dvelopp par Blizzard Entertainment intgre certains aspects du jeu de
rle dans les jeux de STR.
Les annes 90 ont donc vu la naissance et les volutions majeures des jeux de STR actuels.
Historiquement, ce type de jeu est principalement distribu sur ordinateur. La premire raison
trouve son origine dans linteraction. Ce type de jeu ncessite un dispositif de pointage rapide
et prcis. Contrairement au priphrique dentre historique des consoles de jeu (la manette), la
souris de lordinateur se prte bien mieux ces spcifications. La deuxime raison vient de la
forte composante multijoueur non disponible sur console avant la sixime gnration (1998).
Cet aspect multijoueur est donc une composante importante des jeux vido et a fortement
contribu au succs de certains jeux de STR comme Starcraft. La conception et la mise au point
21. MicroProse, 1991
35
de ce mode de jeu implique des choix importants dans le processus de ralisation. A ce titre, il
convient de prsenter les diffrents types darchitectures rparties.
2.3 Architectures rparties

Larchitecture rpartie dtermine lorganisation physique des diffrentes machines ainsi que
leur rle. Lemplacement des donnes et leur gestion dpendent galement de cette architecture.
Les deux grands principes sarticulent autour de la prsence ou non dun serveur, il sera alors
question de systmes centraliss et de systmes sans serveur.
2.3.1 Systmes centraliss

Ils sorganisent autour de deux entits : le serveur (une machine gnralement trs puissante
en termes de capacits dentre-sortie qui fournit des services) et le client (une machine o
sexcute un programme qui communique avec le serveur pour rcuprer des informations). Ces
systmes peuvent tre dcoups en trois sous groupes : larchitecture client-serveur centralise,
larchitecture client-serveur distribue et larchitecture client-serveur distribue avec plusieurs
serveurs :
architecture client-serveur centralise (voir figure 2.4) : la base de donnes reprsentant
le monde virtuel est entirement gre par un seul serveur. Lorsquun client se connecte
ce serveur, il exige des ressources (mmoire, CPU (Central Processing Unit), bande
passante) mais plus le nombre de clients augmente plus cette exigence sera difficile
satisfaire. Ce modle darchitecture est videmment peu extensible et permet de grer
au mieux une cinquantaine dutilisateurs en mme temps dans le cas de communications
purement textuelles (MUD par exemple) ;
architecture client-serveur distribue : la base de donnes reprsentant le monde virtuel
est rpartie sur les diffrents clients. Seules les communications entre les clients sont
gres par le serveur. Cette amlioration rduit lutilisation de la bande passante, mais le
serveur reste un goulot dtranglement ;
architecture client-serveur distribue avec plusieurs serveurs : Pour grer ce problme
plusieurs sont mis en place et communiquent. Ces serveurs sont organiss et peuvent
grer les clients de diverses faons : partitionnement bas sur la localisation physique
ou virtuelle des clients. Concernant la localisation physique, chaque serveur doit avoir
36
2.3. Architectures rparties
F IGURE 2.4 Architecture client-serveur centralise.
une image du monde virtuel dans son ensemble, ce qui est donc difficilement exten-
sible. La localisation virtuelle est plus facilement extensible car chaque serveur ne gre
quune partie du monde virtuel. Cependant, comme les clients sont ingalement rpartis
dans le monde virtuel, certains serveurs peuvent tre rapidement surchargs. Il devient
donc ncessaire de mettre en place une gestion des clients en vue dquilibrer la charge
des diffrents serveurs. Le problme de distribution de charges est rsolu par des algo-
rithmes statiques, dynamiques et adaptatifs o les algorithmes adaptatifs sont considrs
comme une classe spciale des algorithmes dynamiques. Les algorithmes de distribution
de charges dynamiques sont encore classs en algorithmes de partage de charges et en
algorithmes de mise en correspondance de charges. Lquilibrage des charges nest pas
la seule difficult surmonter dans ce type darchitecture. En effet, laugmentation du
nombre de serveurs rend le maintient dune base de donnes cohrente plus difficile.
Dautre part, les messages envoys par les clients peuvent traverser plusieurs serveurs
avant daboutir au destinataire ce qui a pour consquence daugmenter la latence 22 et
donc de rduire le niveau dinteractivit. Cependant, cette architecture a pour avantage de
diminuer limpact de lajout de nouveaux clients. Larchitecture client-serveur distribue
avec plusieurs serveurs est couramment utilise pour supporter les MMOG (Duong et
al. [DZ03] en prsentent un exemple). Steinkuehler [Ste04] qualifie de MMOG tout jeu
22. latence : temps pris par un message pour passer dun hte un autre en lui ajoutant le temps du traitement
de linformation mise et reue
37
qui satisfait une accessibilit en ligne un trs grand nombre de joueurs et qui assure
une persistance du jeu quil y ait des joueurs connects ou pas. En raison de leur grande
interactivit, la migration des clients est une tche trs lourde, car des milliers de person-
nes sont gres par le jeu.
2.3.2 Systmes sans serveur

Ils sont organiss autour de larchitecture gal gal (Peer-to-Peer ou P2P). Dans cette
configuration, chaque ordinateur a le mme rle, il apporte de la mmoire, du temps de calcul et
de la bande passante pour grer les tats des donnes partages (voir figure 2.5). La base de don-
nes reprsentant le monde virtuel est duplique sur les diffrentes machines qui communiquent
les modifications locales tous les autres ordinateurs.
F IGURE 2.5 Architecture pair pair distribue en communication point point.
Ce type darchitecture prsente deux inconvnients majeurs :

au niveau de lextensibilit : le nombre de messages de mise jour augmente proportion-
nellement avec le nombre de machines. Pour pallier ce type de problme, il est possible
de diminuer la frquence des messages de mise jour grce, par exemple, la technique
du dead-reckoning. Cette mthode de prdiction consiste dterminer le comportement
dune entit virtuelle en fonction de ses anciens messages de mise jour. Dans ce cadre,
un nouveau message est envoyer seulement si la prdiction est trop mauvaise par rapport
la situation relle ;
38
2.3. Architectures rparties
au niveau du maintien de la cohrence des copies de la base de donnes reprsentant le

monde virtuel. De nombreux mcanismes, issus des systmes dexploitation distribus,
existent pour grer ce problme, du plus simple : un instant donn, un seul ordinateur
est autoris modifier la base de donnes et ce droit circule de machine en machine
(grce un anneau jeton logique par exemple) ; au plus complexe : toutes les machines
procdent des modifications en prcisant leur date daltration et lorsquun conflit se
produit la modification la plus ancienne est prise en compte et les autres sont annules.
Traditionnellement les MMOG sont dvelopps sur une architecture client-serveur, car les
serveurs grent plus facilement les comptes des joueurs ainsi que les tats du jeu. Cependant,
cette architecture est moins flexible, plus onreuse et limite lextensibilit du nombre de joueurs.
Knutsson et al. [KLXH04] proposent une approche base sur le P2P avec un systme grandis-
sant et rtrcissant dynamiquement avec le nombre de joueurs. Trois types de problmes doivent
tre rsolus pour rendre cette approche pleinement applicable : la performance, la disponibilit
(perte dun nud et maintient dun grand nombre de redondance), et la scurit (protger les
comptes et empcher la tricherie). Avec cette architecture rseau et pour un mme nombre de
joueurs par rgion, le nombre total de joueurs connects na aucune consquence sur les perfor-
mances. En revanche, le systme est plus sensible aux diffrences de concentration de joueurs,
mais ce problme peut tre rsolu par le jeu en limitant le nombre de joueurs par rgion ou en
modifiant dynamiquement la taille des rgions en fonction de laffluence des joueurs.
Synthse
Chacune de ces deux architectures possde des avantages et des inconvnients, le choix
nest pas vident. Tout dpend de lapplication et de ses contraintes en termes dextensibilit,
de fiabilit, de simplicit et dinteractivit.
Le modle client-serveur est particulirement recommand pour des applications ncessi-
tant un grand niveau de fiabilit. Les ressources tant centralises, il est plus facile de grer des
ressources communes tous les utilisateurs et dviter les problmes de redondance et de contra-
diction. La scurit est accrue, car le nombre de points dentre permettant laccs aux donnes
est moins important. En revanche, le cot est lev en raison de la mise en place des infrastruc-
tures (btiments, ordinateurs, climatisations, etc.). De plus, le serveur est le maillon faible de
larchitecture client-serveur, tant donn que toute lapplication est architecture autour de lui.
La panne dun serveur peut perturber, voire mme bloquer, compltement lapplication.
39
Le P2P, quant lui, est plus flexible, plus extensible et beaucoup moins onreux en terme
de matriel, mais il est aussi plus difficile de garantir des performances, de la disponibilit et
de la scurit, car tout moment un nud responsable de donnes peut disparatre. Tradition-
nellement, le mode de jeu multijoueur des STR est implment sur une architecture P2P. La
publication du code rseau de la srie des Age of Empires [BT01] en est une illustration.
Concernant les jeux de STR massivement multijoueurs (ou MMORTS - Massively Mul-
tiplayer Online Real-Time Strategy games), peu dexemples existent. Il est possible de citer
OGame 23 et Saga 24 . Les difficults lies cette forme de MMOG portent sur la gestion des
joueurs hors ligne et aux problmes techniques lis la perception des joueurs de lenvi-
ronnement. La plupart des MMORTS placent le joueur la tte dun empire quil doit faire
prosprer. Lorsque ce dernier se dconnecte des serveurs, toutes les entits relatives son em-
pire restent instancies dans le jeu en raison de la persistance du monde virtuel et se retrouvent
sans commandement. Le jeu doit alors intgrer des IA (Intelligences Artificielles) performantes
capables de prendre le relais ou instaurer des rgles de jeu spcifiques pour protger les joueurs
dconnects.
Les problmes techniques lis aux MMORTS viennent du fait que le joueur ne contrle
pas quun seul avatar 25 mais des dizaines voire des centaines dentits simultanment. Cha-
cune dentre elles peroit une partie du monde virtuel et augmente par consquence la quantit
dinformations vhiculer travers le rseau. Ce phnomne est accentu si le niveau dinterac-
tion du MMORTS tend se rapprocher de celui des RTS classiques. Pour cette raison la plupart
des MMORTS rduisent les simulations qui requirent un degr de synchronisation lev avec
les serveurs comme la rduction des champs de vision ou la gestion des collisions. Par con-
squent, les MMORTS ne reprsentent actuellement quune niche de joueurs rduite par rapport
aux communauts gravitant autour des MMORPG (Massively multiplayer online role-playing
game).
La majorit des innovations prsentes ci-dessus ont t apportes par lintermdiaire de
logiciels propritaires. Les projets de STR code source ouvert qui peuvent servir de base la
conception dun jeu srieux ddi lapprentissage de la programmation intgrent nombre de
ces innovations. ce titre, la section suivante en prsente quelques exemples.
23. http://www.ogame.org/ accd le 1 Juillet 2010.

24. http://www.playsaga.com/ accd le 1 Juillet 2010.
25. avatar : entit reprsentant un joueur dans un jeu vido
40
2.4. Exemples de jeux de STR code source ouvert
2.4 Exemples de jeux de STR code source ouvert

De nombreux jeux de STR code source ouvert existent et tmoignent de lintrt que
suscite ce type de jeu auprs des communauts de joueurs. Parmi ces projets, quelques-uns
intgrent la 3D et un mode de jeu multijoueur limage de Spring 26 , ORTS 27 et WarZone
2100 28 .
2.4.1 Spring
Le projet Spring, inspir du jeu commercial Total Annihilation (prsent dans lhistorique de
la section 2.2), a t amorc par Stephan Johansson, membre du groupe Swedish Yankspankers 29
(SY). Lobjectif initial de ce projet tait de rutiliser le contenu du jeu commercial dans un
nouveau moteur plus performant. Cet objectif ayant t atteint, le projet a volu pour servir de
base de nouveaux jeux de RTS originaux.
Spring est donc un moteur de jeu de STR. Il prend en charge la simulation du jeu, la ges-
tion des communications rseaux (architecture P2P), le rendu graphique et sonore et le charge-
ment dIA externes. Il dispose, en outre, dun interprteur Lua 30 qui permet aux utilisateurs
de rassembler des scripts au sein dune archive charge et excute par le moteur. Grce cette
fonctionnalit, chaque utilisateur est libre de crer son propre contenu et donc de concevoir avec
Spring son propre jeu de STR.
Spring bnficie dune communaut de joueurs active. Elle participe lvolution du projet
en proposant de nouveaux contenus (jeux, IA, cartes. . .) et la fiabilisation du jeu en dcouvrant
les bogues corrigs ensuite par le groupe de dveloppeurs. Plusieurs jeux 31 sont actuellement
disponibles sur Spring dont (sans exhaustivit) : XTA le premier jeu distribu par le groupe SY
avec la premire version de Spring ; Balanced Annihilation le jeu le plus jou par la commu-
naut ; Star Wars : Imperial Winter bas sur lunivers de George Lucas ; et Kernel Panic.
Ce dernier (illustr par la figure 2.6) est un jeu de STR simplifi : il ny a pas de ges-
tion de ressources except le temps et lespace ; toutes les units sont gratuites ; larbre des
technologies est peu important avec moins de dix units par faction ; il utilise un rendu vec-
26. http://springrts.com/ accd le 15 Mai 2010.
27. http://webdocs.cs.ualberta.ca/~mburo/orts/ accd le 17 Mai 2010.
28. http://wz2100.net/ accd le 18 Mai 2010.
29. http://www.clan-sy.com/ accd le 15 Mai 2010.
30. http://www.lua.org/ accd le 15 Mai 2010.
31. http://springrts.com/wiki/Games accd le 15 Mai 2010.
41
toriel original en adquation avec lunivers du jeu. Ces caractristiques mettent laccent sur la
stratgie et la tactique dans un jeu orient action et accessible tous les joueurs.
Lunivers du jeu Kernel Panic se positionne au sein mme dun ordinateur o le joueur peut
prendre le contrle dune des trois factions disponibles : les Systmes , les Pirates et
les Rseaux . Chacune dentre elles propose diffrentes units comme par exemple le BIT,
lOCTET et lASSEMBLEUR chez les Systmes , le VIRUS, le BOGUE et le VER chez
les Pirates et le PORT, le PAREFEU et le PAQUET chez les Rseaux . La figure 2.7
prsente en dtail la hirarchie de cration des units des Systmes . Ainsi le NOYAU (unit
matresse de cette faction) peut gnrer des BITS, des OCTETS, des POINTEURS et des AS-
SEMBLEURS. Ce dernier peut son tour gnrer des SOCKETS (qui pourront produire des
BITS) et des TERMINAUX.
Un Noyau
Un Assembleur
Un Octet Un Pointeur
Un Socket Un Terminal
Un Bit
F IGURE 2.6 Situation de jeu dans Kernel
Panic. F IGURE 2.7 Hirarchie de cration des
units des Systmes .
2.4.2 ORTS
Ce jeu est principalement dvelopp par Michael Buro et Timothy Furtak du dpartement
informatique de luniversit des sciences dAlberta (Canada). ORTS (Open Real-Time Stra-
tegy) est un environnement de programmation ddi ltude de problmes dIA temps rels
(recherche de chemins, traitement dinformations incompltes, planification de tches. . .) dans
un contexte de jeu de STR.
42
Buro et Furtak [BF05] notent que les jeux de STR commerciaux sont ferms et ne permettent
pas aux chercheurs de connecter leurs modules dIA aux jeux. Les IA des jeux de STR actuels
souffrent dun manque de planification et dapprentissage, domaine dans lequel les joueurs sont
toujours plus efficaces que les IA. Ils ont donc dvelopp ORTS pour permettre aux program-
meurs confirms dintgrer et de tester leurs IA dans un moteur de STR totalement libre. Ils
prcisent quORTS est un moteur de jeu de STR (voir figure 2.8) qui permet aux utilisateurs de
dfinir leurs propres jeux sous la forme de scripts qui dcrivent les units, les structures et leurs
interactions.
F IGURE 2.8 Situation de jeu dans ORTS
La composante originale dORTS concerne son architecture rseau destine viter la

tricherie lors des parties multi-utilisateur [Bur02]. Larchitecture dORTS est base sur un sys-
tme centralis client-serveur. Dans cette architecture, chaque client se connecte un serveur
et gnre les actions des objets contrls par le joueur. Le serveur, quant lui, envoie les infor-
mations visibles de chaque joueur vers son client respectif et reoit les actions des objets pour
les excuter.
Plusieurs comptitions de programmation ont t organises avec ORTS. Quatre situations
de jeu taient proposes : rcolter un maximum de ressources en 10 minutes ; dtruire autant
dadversaires que possible en 15 minutes ; dtruire tous les btiments adverses en 20 minutes ;
dtruire autant dadversaires que possible en 5 minutes. Les dfis relever lors de ces comp-
43
titions portent entre autres sur la recherche de chemins, la gestion de groupes dunits, le combat
petite chelle, lallocation de ressources et lexploration.
2.4.3 WarZone 2100

WarZone 2100 (illustr figure 2.9) est lorigine un jeu commercial dvelopp par Pumpkin
Studios et publi par Eidos Interactive. Il a t distribu partir de 1999 sur Microsoft Windows
et la console Playstation. En dcembre 2004, son code source et la majorit de ses donnes
ont t transfrs sous licence GNU GPL (General Public License). Les restrictions sur les
squences danimation et les pistes sonores ont t ouvertes le 10 juin 2008. Comme Spring,
WarZone 2100 est bas sur une architecture P2P.
En raison de son origine commerciale, ce jeu bnficie dun scnario original. Ce dernier
projette le joueur dans un avenir proche o les civilisations ont t ananties suite une srie de
frappes nuclaires. Alors que la plupart des survivants vivotent, un groupe de personnes tente
de reconstruire une civilisation grce aux technologies davant guerre.
F IGURE 2.9 Situation de jeu dans WarZone F IGURE 2.10 Systme de conception du-
2100. nits.
La particularit de ce jeu porte sur une utilisation originale de larbre des technologies
travers un systme de conception dunits (voir figure 2.10). Il donne lopportunit au joueur de
concevoir ses propres units (composes dun chssis, dun systme de propulsion et dune
tourelle) en fonction des technologies dcouvertes au cours des parties. Avec plus de 400
44
technologies diffrentes, ce jeu permet la mise en uvre dune grande varit dunits et donc
de stratgies potentielles.
limage de Spring et dORTS, WarZone 2100 peut galement tre considr comme un
moteur pour crer des jeux. laide dun langage de script proche du C, appel WZScript,
chaque utilisateur est libre de modifier une grande partie du jeu original (telle que les units,
larbre de recherche, le gameplay. . .) et damliorer lIA du jeu. Un diteur de carte est gale-
ment la disposition des joueurs pour leur permettre de gnrer leurs propres zones de jeu.
Conclusion
Les quelques exemples exposs ci-dessus prsentent des similarits. Premirement ils se
dfinissent tous comme des moteurs de STR destins tre amliors ou servir de base
la conception de nouveaux jeux. Cette philosophie de coopration et de partage induite par le
logiciel libre permet ces projets de proposer des outils fiables et fonctionnels.
La deuxime similitude porte sur la mise en uvre dinterfaces pour la ralisation dIA.
Cette fonctionnalit ouvre la voie de nouvelles et intressantes mthodes dinteractions. Le
premier exemple porte sur la ralisation de tournois dIA autonomes. Un second exemple con-
cerne la ralisation de systmes hybrides o les joueurs humains conoivent et utilisent des
interfaces graphiques sophistiques. Ces dernires permettent de dlguer certaines tches
des modules dIA afin daugmenter les performances des joueurs dans le jeu. Ce dernier point
est certainement la contribution majeure des jeux code source ouvert cette famille de jeu
vido.
Ces quelques similarits constituent une base opportune la conception dun jeu srieux
centr sur la pratique de la programmation. Dans ce cadre, il convient de prsenter linfor-
matique en tant que discipline scientifique.
45
3
Formation en informatique
Linformatique influence dune manire significative de nombreux domaines lis aux acti-
vits humaines. Dans nos socits, une grande partie de la population utilise linformatique
dans un cadre priv. Dun point de vue professionnel, de nombreux secteurs dactivit sont en
demande de qualifications informatiques propres.
Pour rpondre cette diversit, le modle de formation anglo-saxon structure linforma-
tique en cinq grandes disciplines. Ce modle diffre du modle franais en ce qui concerne le
dcoupage strict de la discipline. Toutefois, aucun rapport dtaill du modle franais nexiste
notre connaissance. Pour cette raison le modle anglo-saxon est prsent en dtail puis mis en
perspective dans notre vision du modle franais.
Malgr lomniprsence de linformatique dans la socit, les tudiants dlaissent cette disci-
pline et les structures de formation voient leurs effectifs stagner voire diminuer. Dans ce cadre,
quelques exemples dinnovations pdagogiques sont prsents. Leur enjeu consiste motiver
les tudiants intgrer et poursuivre des formations en informatique en vue dviter une pnurie
dinformaticiens.
3.1 Analyse du modle anglo-saxon

Depuis plus de quarante ans, quatre organisations majeures aux tats-Unis proposent des di-
rectives pour les formations en informatique luniversit : lACM 32 (Association for Comput-
32. http://www.acm.org/ consult le 25 Juin 2010
47
Chapitre 3. Formation en informatique
ing Machinery), lAIS 33 (Association for Information Systems), lAITP 34 (Association of Infor-
mation Technology Professionals) et lIEEE-CS 35 (Computer Society of the Institute for Elec-
trical and Electronic Engineers). Aujourdhui, ces socits collaborent pour dcrire la diversit
des enseignements lis linformatique dans le modle anglo-saxon.
3.1.1 Dcoupage et points communs des disciplines informatiques

Le rapport ACM/AIS/IEEE-CS [AAIC05] explicite le panorama des diffrentes branches
de linformatique luniversit. Ce rapport divise linformatique en cinq disciplines majeures :
1. Computer Engineering (CE) dont lapplication dominante concerne les systmes embar-
qus (dveloppement de dispositifs tant sur le plan logiciel que matriel) ;
2. Computer Science (CS) qui fournit des bases compltes pour permettre aux diplms de
sadapter aux nouvelles technologies et aux nouvelles ides ;
3. Information Systems (IS) pour lesquels les jeunes diplms doivent tre performants en
spcification, conception, et implmentation afin de dterminer les besoins dune organi-
sation ;
4. Information Technology (IT) qui a pour objectif de comprendre les systmes informa-
tiques et leurs logiciels et sengage rsoudre tous les problmes en rapport avec ces
systmes ;
5. Software Engineering (SE) dont lobjectif est de former un personnel capable de grer
des projets de logiciels importants, complexes et fiables.
Ces cinq disciplines couvrent lensemble des thmes et domaines dapplications lis linfor-
matique. Bien que chacune ait un objectif de formation propre, de nombreuses connaissances
et aptitudes sont transversales lensemble dentre elles.
Les programmes dtudes en informatique sont des combinaisons dun ensemble de thmes
ayant des poids diffrents en fonction de la spcialit enseigne. Le rapport ACM/AIS/IEEE
[AAIC05, chap. 3] dfinit 40 thmes et indique leur poids dans chacune des cinq disciplines
informatiques. Le poids est caractris par deux valeurs comprises entre 0 (faible) et 5 (leve)
qui reprsentent limportance dun thme pour le domaine. Ces deux valeurs indiquent respec-
tivement lexigence minimale et maximale attendue par la discipline relativement aux autres.
33. http://home.aisnet.org/ consult le 25 Juin 2010
34. http://www.aitp.org/ consult le 25 Juin 2010
35. http://www.computer.org/ consult le 25 Juin 2010
48
3.1. Analyse du modle anglo-saxon
Le tableau 3.1 donne un exemple dvaluation issue de ce rapport. Dans cet exemple, Algo-
rithmes et complexit a une valeur minimale de 4 en CS ce qui en fait un thme important de
cette discipline. A contrario, Support technique (avec une valeur maximale de 1) fait partie
des thmes peu ou pas abord en CS. Dans un autre contexte, celui de IT, lexigence de ces
mmes thmes est inverse.
TABLE 3.1 Exemple dvaluation de thmes en fonction des disciplines informatiques (Extrait
de [AAIC05, p. 24]).
CS IT
Thme
min max min max
Algorithmes et complexit 4 5 1 2
Support technique 0 1 5 5
Grce ces valeurs, il est alors possible de dterminer les thmes fondamentaux qui re-
quirent la plus grande exigence pour lensemble des disciplines informatiques. Nous calculons
lexigence pour un thme particulier (not Et ) laide de la formule 3.1 o eM ini,t
reprsente lexigence minimale attendue par la ime discipline informatique pour le thme t .
Les quatre thmes les plus fondamentaux parmi les 40 dfinis sont donc : Les fondamentaux
de la programmation (Et = 3, 4) ; Linteraction homme machine (Et = 2, 6) ; Lanalyse
des besoins techniques (Et = 2, 4) ; La conception de logiciels (Et = 2, 4).
PnbDisciplines
eM ini,t
Et = i=1
(3.1)
nbDisciplines
Le rapport ACM/AIS/IEEE [AAIC05, chap. 3] dfinit galement 60 aptitudes parmi 11

catgories et value leur poids pour chaque discipline informatique. Contrairement aux thmes,
lexigence de chaque aptitude est estime par une seule valeur comprise entre 0 et 5. En cal-
culant la moyenne des exigences pour chaque aptitude (note Ea dans la formule 3.2 o
ei,a reprsente lexigence attendue par la ime discipline informatique pour laptitude a ),
nous pouvons dterminer les trois premires aptitudes fondamentales dun informaticien parmi
les 60 dfinies : Raliser des programmes simples (Ea = 4, 2) ; Crer une interface utili-
sateur (Ea = 4) ; Matriser un traitement de texte (Ea = 3, 8).
49
PnbDisciplines
ei,a
Ea = i=1
(3.2)
nbDisciplines
Lanalyse de ce rapport a permis didentifier les deux composantes essentielles et communes

aux cinq disciplines informatiques : acqurir les fondamentaux de la programmation et
tre capable de raliser des programmes simples .
Daprs le TLFi, le terme informatique caractrise la science du traitement rationnel,
notamment par machines automatiques, de linformation considre comme le support des
connaissances humaines et des communications dans les domaines technique, conomique
et social . Ce terme a t invent en France, en 1962, par Philippe Dreyfus. cette mme
poque, aux tats-Unis, les premires formations mergent et sont de trois sortes [AAIC05,
chap. 2] : Computer Science (CS), electrical engineering (EE) et Information Systems (IS).
Les tudiants qui souhaitaient devenir experts dans le dveloppement de logiciels ou acqurir
les comptences thoriques sur lutilisation des ordinateurs suivaient des formations en CS.
Ceux qui souhaitaient travailler sur le matriel suivaient des formations en EE. Enfin, ceux qui
souhaitaient utiliser le matriel et le logiciel pour rsoudre des problmes lis aux entreprises
suivaient des formations en IS. Dans ce contexte linformatique telle quelle est dfinie en
France fait rfrence au CS. Cest au cours des annes 90 que sont apparues aux tats-Unis
les nouvelles disciplines comme le Computer Engineering (CE) le Software Engineering (SE)
et lInformation Technology (IT). Cette dcomposition nayant pas t ralise dans le modle
franais, linformatique en France regroupe bien entendu le CS mais aussi tout ou partie du CE,
du SE, de lIT et de LIS. Le CS est donc la discipline du modle anglo-saxon la plus proche
historiquement de linformatique et mrite donc dtre prsente en dtail.
3.1.2 Analyse du Computer Science
Cette discipline est prsente de manire plus dtaille dans un second rapport de lACM/-
IEEE [AIC01]. Les parties suivantes effectuent une synthse de ce rapport travers la prsen-
tation de larchitecture des enseignements, le dtail des diffrentes approches envisageables et
le positionnement de lapprentissage de la programmation.
50
Architecture des enseignements
Le rapport de lACM/IEEE [AIC01] structure les connaissances en trois niveaux : les do-
maines qui reprsentent les diffrents champs disciplinaires ; les units qui constituent les mo-
dules thmatiques de chaque domaine ; et les thmes qui composent les cours de chaque unit.
Les enseignements, proprement parler, sont diviss en trois catgories en rapport avec le
niveau auquel ils se produisent. Les enseignements dsigns comme introductifs sont typi-
quement les cours dispenss en premire anne universitaire. Les enseignements interm-
diaires se rattachent aux cours de deuxime et troisime annes et fournissent des bases requises
pour aborder les enseignements avancs des dernires annes.
Chaque formation est dfinie par un cur et un ensemble dunits facultatives. Le cur se
compose dunits denseignements requises pour tous les tudiants en CS. Toutefois, le cur
lui seul ne suffit pas linstruction complte, les units facultatives ont donc pour objectif
de parfaire la formation. Pour offrir une grande flexibilit sur la mise en uvre de ces ensei-
gnements, le rapport propose plusieurs mises en uvre des diffrentes catgories. titre dillus-
tration, les enseignements introductifs peuvent tre proposs sous six approches diffrentes :
imprative, oriente objet, fonctionnelle, tendue, algorithmique et matrielle. Nous noterons
que pour chaque approche, il nest fait aucune recommandation sur un langage de program-
mation utiliser.
Dtail des six approches des enseignements introductifs
Approche imprative : Cette approche est la plus rpandue, elle aborde lintroduction la
programmation via un style de programmation impratif. Il est important de noter que les pre-
miers enseignements de cette approche peuvent tre raliss laide dun langage orient ob-
jet (OO) pour illustrer les exemples et exercices de programmation. La diffrence entre cette
approche et le modle OO porte sur laccentuation et lordonnancement des premiers ensei-
gnements. Mme si un langage de programmation OO est utilis, les premiers enseignements
se concentrent sur les aspects impratifs du langage : expressions, structures de contrle, proc-
dures et fonctions, etc. Les techniques de conception OO sont alors reportes dans les ensei-
gnements futurs. Adopter lapproche imprative signifie que les tudiants seront moins exposs
aux techniques de la programmation OO que sils avaient suivit lapproche du mme nom. Le
fait de positionner la conception OO au second plan est souvent peru comme une faiblesse de
cette approche.
51
Approche oriente objet : Cette approche se concentre galement sur la programmation, elle
met laccent sur les principes de la conception OO ds le dbut des enseignements. Les premiers
cours portent sur les notions dobjets et dhritage afin de familiariser trs tt les tudiants ces
concepts. Aprs avoir expriment ces notions dans un contexte de programmes interactifs sim-
ples, les enseignements sorientent vers lintroduction des traditionnelles structures de contrle
mais toujours dans un contexte li la conception OO. Les enseignements futurs abordent en-
suite lalgorithmique, les structures de donnes fondamentales et les problmes de lingnierie
du logiciel. Une critique rcurrente sur cette approche porte sur la complexit des langages
utiliss dans les travaux pratiques, tels que le Java ou le C++. Par consquent, les enseignants
doivent veiller introduire ces langages issus du monde professionnel dune manire limiter
leur complexit pour ne pas submerger des tudiants novices en la matire.
Approche fonctionnelle : Cette approche se caractrise par lutilisation dun langage fonc-
tionnel qui prsente les avantages suivants : ce paradigme de programmation est peu connu
des tudiants ce qui rend les promotions plus homognes ; la syntaxe minimale des langages
fonctionnels permet de concentrer le cours sur les notions fondamentales ; plusieurs concepts
importants, comme la rcursivit, les structures de donnes lies et les fonctions sont exprimes
trs naturellement et peuvent tre abordes plus tt dans la formation. Une critique, souvent
mise en vidence dans cette approche, porte sur la ncessit de demander aux tudiants un
raisonnement plus abstrait que pour les langages de programmation traditionnels et ceci trs tt
dans la formation. Alors que cette comptence est prcieuse et ncessaire la formation dun
informaticien, la placer trop tt peut dcourager les tudiants non familiariss avec ce type de
raisonnement. Enfin, pour couvrir lensemble des comptences requises dans un enseignement
introductif, les notions lies la conception et la programmation OO devront tre abordes
dans la deuxime partie du cours.
Approche tendue : Daprs cette approche, aborder lenseignement de linformatique par la

programmation donne une vision limite de la discipline aux tudiants. En effet, linformatique
est un domaine en constante volution qui inclut de nombreuses activits au del de la simple
programmation. Les enseignements qui la privilgient peinent sensibiliser les tudiants aux
autres domaines et styles de pense qui font de linformatique un tout. Pour fournir une vision
plus holistique de la discipline, les premiers enseignements prsentent linformatique relati-
vement lenvironnement dans lequel elle se manifeste. Lavantage principal de cette approche
52
est de fournir aux tudiants une vision globale de la discipline pour leur permettre de dterminer
sils souhaitent ltudier en profondeur. Le principal inconvnient de cette approche reste lajout
de cours supplmentaires qui diffrent dans le temps les enseignements introductifs classiques.
Approche algorithmique : Dans cette approche, les concepts basiques de linformatique sont
introduits laide de pseudocodes au lieu de langages excutables. En introduisant les concepts
basiques dalgorithmique sans langage particulier, cette approche minimise les proccupations
lies aux dtails syntaxiques de la programmation. Elle demande aux tudiants de raisonner et
dexpliquer la conception de leurs algorithmes en les droulant manuellement. Elle leur permet
de travailler sur des ensembles de donnes et des structures de contrle sans affronter les particu-
larits invitablement lies aux langages de programmation. Lorsque les tudiants ont des bases
solides en algorithmique ainsi que sur la manipulation des donnes et des structures de contrle
en pseudocode, ils abordent un langage plus conventionnel. En raison de leur exprience plus
pousse en algorithmique, les tudiants progressent plus rapidement dans leur matrise du lan-
gage. Ils peuvent se concentrer sur des notions de programmation efficaces ou le dbogage. Par
ailleurs, les tudiants peuvent se sentir frustrs de ne pouvoir tester leurs algorithmes dans un
contexte rel. Les premiers enseignements tant centrs sur lalgorithmique, la deuxime partie
devra aborder les techniques de conception et de programmation OO.
Approche matrielle : Cette approche enseigne les bases de linformatique au niveau de la

machine puis intgre des concepts de plus en plus abstraits. Tout dabord, elle aborde les circuits
avec lutilisation de registres et dunits arithmtiques simples, puis les contextualisent dans une
machine de von Neumann. La programmation est alors aborde avec un langage de haut niveau
de type OO. Alors que cette approche fonctionne bien avec les tudiants qui prfrent compren-
dre le processus de calcul dans tous ces dtails, elle est moins efficace face au dveloppement
croissant du logiciel et des machines virtuelles qui tentent de sparer le processus de program-
mation du matriel sous-jacent. Cette approche est donc particulirement bien adapte pour la
discipline CE o une exposition prcoce au matriel est essentielle.
Importance des fondamentaux de la programmation
La section 3.1.1 a permis didentifier les fondamentaux de la programmation comme

une connaissance primordiale en informatique. Quen est-il pour le Computer Science ?
53
En CS, cette connaissance est structure sous lappellation Fondamentaux de la Program-

mation (FP) diviss en cinq units denseignements : Fondamentaux de la construction de
programmes (FP1) ; Algorithmes et rsolution de problmes (FP2) ; Fondamentaux sur
les structures de donnes (FP3) ; Rcursivit (FP4) ; et Programmation vnementielle
(FP5) . Les thmes abords dans ces diffrentes units portent sur la manipulation de varia-
bles, les structures de contrle, lutilisation de dbogueurs, les tableaux, les pointeurs et les
rfrences, la propagation dvnements, etc.
Quelle que soit lapproche (imprative, fonctionnelle, etc.), les FP reprsentent une part
importante du cur des diffrentes formations. Toutefois, la proportion des FP vis--vis des
autres units denseignements varie en fonction du modle de mise en uvre. Historiquement,
la majorit des tablissements utilisent un modle en deux semestres pour les enseignements
introductifs. Mais alors que le contenu des leons a volu au cours du temps pour rpondre aux
changements des technologies et des approches pdagogiques, la longueur des enseignements
est reste la mme. Le rapport de lACM/IEEE [AIC01] propose donc pour certaines approches
(imprative, oriente objet et tendue) un modle en trois semestres de manire fournir une
vision plus large et plus complte de linformatique. Le choix dune approche et dun modle de
mise en uvre est la charge de lquipe pdagogique. En effet, parmi lensemble des combi-
naisons possibles, une seule approche de lun des deux modles est ncessaire pour assurer
lensemble des enseignements informatiques des enseignements introductifs.
Outre la prsentation de larchitecture modulaire des enseignements introductifs, la figure 3.1

indique limportance des fondamentaux de la programmation dans le cur des diffrentes for-
mations (39% de lapproche imprative du modle en trois semestres, 37% de lapproche imp-
rative du modle en deux semestres, 40% de lapproche algorithmique, etc.). Dans leur majo-
rit, les units denseignements traitant des FP font parties du cur de toutes les approches et
sont abordes lors des premires annes (en moyenne : 30,7% des enseignements introductifs,
5,85% des enseignements intermdiaires et 0% des enseignements avancs). Cette rpartition
positionne les FP comme lun des thmes centraux des enseignements introductifs indispen-
sables aux tudiants pour aborder la suite de leurs tudes en CS. Les Autres enseignements
sont complmentaires des enseignements informatiques et doivent tre associs lapproche
choisie par lquipe pdagogique.
54
Enseignements introductifs
Modle en trois Modle en deux

semestres semestres
enseignements
oriente objet
oriente objet
algorithmique
fonctionnelle
imprative
imprative
matrielle
Approche
Approche
Approche
Approche
Approche
Approche
Approche
Approche
tendue
Autres
39,31% 40% 24,17% 37,18% 39,74% 37,5% 40,25% 37,5% 0%
30,7%
OU
ET
Lgende
Importance des Enseignements Enseignements
fondamentaux de la
programmation pour le intermediaires 5,85% avancs 0%
40%
coeur des formations
F IGURE 3.1 Architecture modulaire des enseignements introductifs et importance des fonda-
mentaux de la programmation
3.1.3 Comparaison avec le modle franais
Comme il nexiste pas notre connaissance de rapport dtaill sur lenseignement de linfor-
matique en France, nous usons de notre exprience denseignant pour comparer le modle
anglo-saxon notre vision du modle franais.
La principale diffrence identifie porte sur la dcomposition en disciplines qui ne peut tre
reporte directement dans le modle franais. En effet, en France linformatique en tant que
discipline scientifique regroupe le CS et tout ou partie des autres disciplines du modle anglo-
saxon. Toujours est-il que lacquisition des fondamentaux de la programmation et la capacit
raliser des programmes simples sont deux composantes essentielles dans lenseignement de
linformatique en France. Pour illustrer ces propos, le PPN (Programme Pdagogique National)
du DUT Informatique [Min05] dfinit comme objectif gnral de la formation de former les
tudiants tre capable de participer la conception, la ralisation et la mise en uvre de
systmes informatiques correspondant aux besoins des utilisateurs . Dans ce cadre, le module
55
Algorithmique et Programmation fait rfrence aux FP du modle anglo-saxon et reprsente

une part importante de lunit denseignement Informatique avec 41% des enseignements
de premire anne et 24% des enseignements de deuxime anne. Les fiches mtiers ROME
(Rpertoire Oprationnel des Mtiers et des Emplois) cres par le Pole emploi 36 illustrent
galement les activits et comptences attendues en France pour un mtier particulier. Con-
cernant les professions relatives aux tudes et dveloppement informatique (fiche ROME
M1805) la conception et le dveloppement de programmes et applications informatiques et
lalgorithmique font respectivement parties des six activits et huit comptences basiques
de cette fiche.
Les six approches de lenseignement introductif, quant elles, peuvent tre parfaitement
intgres au modle franais. Les approches impratives, algorithmiques, OO et fonctionnelles
sont cependant les plus rpandues. Pour illustrer ce propos, la nouvelle habilitation de lUniver-
sit Paul Sabatier value par lAERES (Agence dvaluation de la Recherche et de lEnsei-
gnement Suprieur) change son offre denseignement dune approche fonctionnelle en une ap-
proche imprative pour les annes 2011 2014. Un autre exemple porte sur lintgration de
lalgorithmique au programme de Mathmatiques de seconde gnrale et technologique en ly-
ce. Cette rforme est entre en application la rentre de lanne scolaire 2009-2010 [Bul09].
Malgr les diffrences de structuration de la discipline entre le modle anglo-saxon et le
modle franais, le savoir enseign et les mthodes denseignement restent les mmes.
3.2 Analyse de lattractivit de la discipline informatique

Lenseignement de linformatique est n avec le dveloppement des ordinateurs centraux
aux tats-Unis et en Europe la fin des annes 40. Lavnement des microprocesseurs la fin
des annes 70 a relanc la discipline mais depuis quelques annes, le nombre dtudiants in-
scrit en informatique dans des pays o cet enseignement tait jusqualors en expansion com-
mence dcliner. De nombreux travaux relatent ce phnomne comme ceux de Crenshaw
et al. [CCMT08] et de Kelleher [Kel06]. Le rapport de lACM/AIS/IEEE [AAIC05, p. 39]
souligne galement cette tendance : les universits affirment que rgulirement 50% ou plus
de leurs tudiants ayant initialement choisi des tudes en informatique dcident rapidement
dabandonner . La dernire mise jour de ce rapport consacre au Computer Science [AIC08]
36. http://www.pole-emploi.fr/accueil/ consult le 28 Juin 2010
56
3.2. Analyse de lattractivit de la discipline informatique
ddie un chapitre entier ce quelle nomme la crise de linformatique dans lenseignement.

Notre universit subit le mme phnomne avec une baisse de 30% dtudiants inscrits en deux-
ime anne de licence informatique sur les sept dernires annes (148 inscrits en 2003, 104
inscrits en 2009).
La raison de ce dclin reste encore floue, toutefois les chercheurs en pdagogie saccor-
dent dire que les tudiants novices en informatique trouvent souvent la discipline thorique,
technique, ou ennuyeuse Stamm [Sta07]. En effet, lenvironnement informatique utilis tous
les jours par les tudiants, pour jouer ou pour dialoguer par exemple, est trs diffrent des dis-
positifs dploys dans les enseignements. Ainsi, les jeunes peroivent limportance de linfor-
matique dans leur quotidien et dans les activits professionnelles comme la production de
musique et de film, le dveloppement de sites Web ou de jeux vido, mais ont des difficults
faire le lien avec les enseignements dispenss en informatique.
Dautre part, se former en informatique est une activit complexe, en particulier pour les
novices, comme en tmoigne lapprentissage des fondamentaux de la programmation. Dans
les units denseignements qui composent ce domaine, les tudiants se trouvent confronts
plusieurs obstacles pistmologiques comme la manipulation des boucles (Ginat [Gin04] et
Soloway et al. [SBE83]), des conditions, ou lassemblage de programmes base de composants.
Les structures de contrle et les algorithmes posent souvent problme de par leur abstraction
et leur nature dynamique (Seppl et al. [SMK06]. Pour apprendre programmer les tudiants
doivent donc connatre les concepts et connaissances lies aux units denseignement, mais
pour les matriser, ils doivent pratiquer la programmation.
Pour tenter dapporter une solution la la crise de linformatique dans lenseignement, il
convient de remotiver les tudiants travers de nouvelles innovations pdagogiques. Ces inno-
vations ne doivent pas dnaturer le contenu fondamental de la discipline ou rduire son niveau
acadmique. En effet, les tudiants doivent acqurir les prrequis ncessaires leur poursuite
dtude dans le cadre des enseignements intermdiaires et avancs.
3.2.1 Motivation et performances

Que signifie le terme motivation et quelle peut tre son influence sur les performances
des tudiants et donc sur leur apprentissage ? Viau [Via97] dfinit la motivation en contexte sco-
laire comme suit : . . .tat dynamique qui a son origine dans les perceptions quun lve a de
lui-mme et de son environnement et qui lincite choisir une activit, sy engager et per-
57
svrer dans son accomplissement afin datteindre un but . Dans son modle, la performance
dun lve raliser une activit correspond aux rsultats observables de lapprentissage et con-
stitue une consquence de la motivation (elle en est un indicateur). Agir sur la motivation permet
indirectement de faire voluer les performances des tudiants. Dans ce contexte, la motivation
est caractrise par des dterminants et des indicateurs.
Les dterminants de la motivation concernent :
la perception de la valeur dune activit, cest un jugement que ltudiant porte sur
lutilit dune activit en vue datteindre des buts quil poursuit. La dtermination de buts
court, moyen et long terme est la base de la perception de la valeur dune activit
(concept de perspective future). Ces buts peuvent tre classs en deux grandes catgories :
1. les buts sociaux concernent la relation quun lve tablit avec les autres lves et
avec lenseignant ;
2. Les buts scolaires qui ont trait lapprentissage et ses comptences dont les buts
dapprentissage (ceux que nous poursuivons lorsque nous accomplissons une acti-
vit pour acqurir des connaissances - motivation intrinsque) et les buts de perfor-
mance (ceux que nous poursuivons lorsque nous voulons russir une activit pour
que les autres nous estiment et nous reconnaissent ou encore pour obtenir une r-
compense, des flicitations, etc. - motivation extrinsque).
la perception de sa comptence accomplir une activit, cest une perception de soi
par laquelle la personne, avant dentreprendre une activit qui comporte un degr lev
dincertitude quant sa russite, value ses capacits laccomplir de manire adquate.
Selon Bandura [Ban86], cette perception provient de quatre sources :
1. les performances antrieures qui correspondent aux succs et checs passs dun
tudiant ;
2. lobservation dautres personnes excuter une activit. Observer un pair influence
davantage la perception quun tudiant de sa comptence que dobserver un pro-
fesseur ;
3. la persuasion dont le but est de convaincre un lve de ses capacits accomplir une
activit ;
4. les ractions physiologiques et motives sont galement une source de la perception
quun lve de sa comptence.
58
la perception de la contrlabilit dune activit, cest la perception quun lve a du de-

gr de contrle quil possde sur le droulement et les consquences dune activit quon
lui propose de faire. Limpuissance apprise est probablement la forme la plus extrme
de perception dincontrlabilit quun lve puisse ressentir. Weiner [Wei92] a class les
causes de la contrlabilit selon trois dimensions :
1. le lieu de la cause permet de faire la distinction entre les causes internes llve et
les causes externes ;
2. la stabilit de la cause. Une cause est dite stable lorsquelle a un caractre permanent
aux yeux de ltudiant. A loppos, une cause qui, comme leffort, est susceptible
de fluctuer rgulirement est dite modifiable.
3. le contrle de la cause. Une cause est dite contrlable lorsquun lve peroit quil
aurait pu lviter sil avait voulu ; par contre, elle est dite incontrlable lorsquil
peroit quil navait aucun pouvoir sur elle.
Les indicateurs de la motivation sont caractriss par :

le choix dentreprendre une activit, un lve motiv choisit dentreprendre une activit
dapprentissage tandis quun lve dmotiv a tendance lviter ;
la persvrance, mesure en calculant le temps que llve consacre des activits
comme la prise de notes, laccomplissement dexercices, la comprhension de ses erreurs,
ltude de manuels, etc. ;
lengagement cognitif, dfini comme lutilisation par llve de stratgies dapprentis-
sage et de stratgies dautorgulation lorsquil accomplit une activit. Les stratgies dap-
prentissage sont principalement de trois types :
1. les stratgies de mmorisation (exemple : copier ses connaissances dans un cahier

de note) ;
2. les stratgies dorganisation (exemple : faire des tableaux, des schmas) ;
3. les stratgies dlaboration (exemple : rsumer un texte, dfinir les concepts dans
ces propres mots).
Les stratgies dautorgulation sont des stratgies cognitives qui sont utilises par llve ;
en ce sens, elles ne sont pas observables. Zimmerman [Zim86] les classe en trois cat-
gories :
59
1. les stratgies mtacognitives correspondent la conscience quune personne de

son fonctionnement cognitif et des stratgies quelle utilise pour rguler sa faon de
travailler intellectuellement (planification, monitoring et autovaluation) ;
2. les stratgies de gestion ont trait lorganisation de lapprentissage. Lorganisa-
tion du travail dans le temps, le lieu dapprentissage, et les ressources humaines et
matrielles requises caractrisent cette organisation de lapprentissage ;
3. les stratgies motivationnelles sont utilises pour augmenter ou conserver la moti-
vation accomplir une activit.
la performance, correspond aux rsultats observables de lapprentissage. Cest une cons-
quence de la motivation et cest ce qui en fait un indicateur. Toutefois, ne pas oublier la
relation inverse, cest--dire linfluence quexerce la performance sur la motivation de
ltudiant. La performance nest pas seulement une consquence de la motivation, elle en
est galement une source.
Intervenir sur une seule composante motivationnelle de ce modle peut influencer positi-
vement toutes les autres et indirectement amliorer les performances des tudiants. Linnovation
pdagogique sinscrit dans cette dynamique.
3.2.2 Innovations pdagogiques

La recherche dans le domaine de lenseignement de linformatique consacre une part impor-
tante de ces travaux aux problmes du recrutement et du maintien des tudiants dans les forma-
tions informatiques [FPC+ 04]. De nombreuses rponses sont donc proposes dans la littrature
pour aider les tudiants dpasser les difficults prsentes en introduction de cette section.
Les propositions sont gnralement de deux types : la premire consiste faire voluer lenvi-
ronnement de travail des tudiants, la seconde consiste travailler les exercices proposs aux
tudiants.
Construction denvironnements de programmation pour novices
De nombreux environnements de programmation pour novices ont t dvelopps. La plu-

part utilisent des langages de programmation base de blocs. Dans ce contexte chaque bloc
(ou brique) reprsente un lment du langage comme une structure de contrle, un oprateur,
une variable, une fonction, etc. Ces dernires peuvent tre combines par glisser-dposer en
60
vue de construire un programme informatique. La couleur ou la forme des briques symbolise

la grammaire du langage et aident les programmeurs les combiner de manire correcte. Cette
mtaphore de programmation permet donc aux tudiants de faire abstraction de la syntaxe, sou-
vent source derreurs, pour directement sintresser la rsolution de problmes.
Scratch 37 [MBK+ 04] (voir figure 3.2) est un environnement de programmation utilisable par
les enfants pour crer leurs propres histoires animes, jeux vido ou crations interactives et les
partager sur le Web.
F IGURE 3.2 Scratch
Alors que les enfants crent et changent des projets Scratch, ils apprennent les notions im-
portantes de mathmatiques, de calcul et de programmation tout en travaillant de manire col-
laborative leur crativit et leur raisonnement. Scratch a donc t conu dans un esprit densei-
gnement et dapprentissage. Il peut tre utilis dans de nombreux contextes diffrents : dans
37. http://scratch.mit.edu/ consult le 29 Juin 2010
61
lenseignement (cole, collge et lyce), dans les muses, les centres de loisir et la maison.
Cette application est notamment mentionne comme lun des logiciels utilisable comme support
lenseignement de lalgorithmique en seconde gnrale et technologique au lyce [Edu09]. Il
a t conu spcialement pour les jeunes de 8 16 ans mais peut tre galement utilis par
les enfants avec laide de leurs parents et luniversit dans les enseignements dintroduction
la programmation. Autour de cette application gravite une communaut denseignants qui
partagent en ligne leurs expriences et leurs ressources. Linterface graphique de Scratch est
notamment traduite en une cinquantaine de langues diffrentes. Scratch est dvelopp par le
Lifelong Kindergarten Group du MIT Media Lab, avec le support financier du National Sci-
ence Foundation, de Microsoft, de lIntel Foundation, de Nokia, dIomega et du MIT Media Lab
research consortia.
Les lments cls intgrs Scratch sont un systme de programmation base de blocs, un
outil de manipulation de mdias et un systme de partage et de collaboration. Le langage de
bloc utilis par Scratch permet de manipuler les concepts de squence, ditration, dinstruction
conditionnelle, de variable et de liste. Il fournit galement les briques utiles la programmation
vnementielle et parallle et la gestion des priphriques dentre tels que le clavier et la
souris. En revanche la version actuelle de Scratch ne fournit pas de briques pour crer des proc-
dures et des fonctions, pour aborder la programmation OO, pour grer les exceptions et pour
manipuler les fichiers. Par consquent les concepts lis au passage de paramtres, la rcursi-
vit, la dfinition de classes et lhritage ne peuvent pas tre traits avec cet environnement
de programmation.
Scratch dfinit trois types de blocs : les blocs de pile , les chapeaux et les rap-
porteurs . Les blocs de pile sont caractriss par une bosse en dessous et une encoche en
dessus limage du bloc suivant : . Ces blocs peuvent donc tre embots les
uns dans les autres pour former des piles et acceptent, pour certains, des paramtres en entre.
Les blocs de pile peuvent tre compars des procdures. Les chapeaux sont des blocs
placs en haut de pile. Ils attendent des vnements particuliers pour lancer lexcution de la
pile sous-jacente. Les rapporteurs sont conus pour sinsrer dans les zones dentre des
autres blocs. Ils peuvent rapporter trois types de donnes : un nombre, une chane de caractre
ou un boolen. Les rapporteurs peuvent tre compars des fonctions.
62
StarLogo TNG (The Next Generation) 38 [KY05] (voir figure 3.3) est le successeur de Star-
Logo lui mme hritier du langage Logo (de Papert).
F IGURE 3.3 StarLogo The Next Generation
Alors que cette version conserve la philosophie du premier StarLogo (un outil utile pour
crer et comprendre la simulation de systmes complexes), il apporte deux innovations princi-
pales : un systme de programmation base de blocs pour attirer un public plus jeune pratiquer
la programmation et un environnement 3D afin daugmenter la richesse des jeux et des modles
de simulation raliss. StarLogo TNG est dvelopp par le MIT Scheller Teacher Education
Program.
La structuration des blocs dans StarLogo TNG sarticule autour dune quinzaine de palettes.
Certaines donnent accs la gestion des conditions initiales et lexcution du programme, au
contrle du mouvement des agents, la manipulation du son et de lenvironnement 3D (ter-
rain et agents), aux priphriques de contrle (clavier et joystick) et la gestion du point de
vue. Dautres permettent daccder aux structures de contrle, aux oprateurs logiques et la
manipulation des variables et des listes. Dans StarLogo TNG, les types manipuls sont les nom-
bres, les boolens et les chanes de caractres. Des palettes spcifiques fournissent les blocks
38. http://education.mit.edu/drupal/starlogo-tng consult le 29 Juin 2010
63
ncessaires aux calculs mathmatiques et la manipulation des chanes de caractres. Enfin

StarLogo TNG autorise la cration et lutilisation de procdures avec passage de paramtres
mais ne fournit pas de support pour aborder les concepts de la programmation oriente objet.
Enfin, StarLogo TNG bnficie dune communaut active qui propose travers le site Web 39
une srie de didacticiels qui prsentent loutil et ses performances notamment en termes de
simulation et de systme multi-agents. Des supports de cours complets sont galement la
disposition des enseignants et abordent des thmes comme la cration dun jeu vido ou la
simulation de lactivit des termites, dun feu de fort et dune pidmie entre autres. Chaque
cours propose une ingnierie didactique avec pour la plupart : supports de cours, ressources
ncessaires aux tudiants, corrections, feuilles dexercices et valuations.
Alice 40 (voir figure 3.4) est un environnement de programmation 3D ddi la cration de

jeux vido, de cinmatiques partager sur le Web ou danimations en vue de raconter des
histoires. Cest galement un outil denseignement qui permet aux tudiants dapprendre les
fondamentaux de la programmation avec une approche OO [CDP03]. Dans Alice, des objets
3D (personnages, animaux et vhicules) peuplent le monde virtuel et les tudiants crent des
programmes pour les animer. La programmation est ralise laide dun systme de blocs qui
permet une programmation OO et une forme simplifie de programmation parallle. Ce systme
est donc naturellement compos dun ensemble de briques pour manipuler les structures de
contrle, accder aux oprateurs propres au langage et grer les vnements utilisables dans
lenvironnement. Chaque objet du monde virtuel est galement compos dun ensemble de
briques qui reprsentent les attributs, mthodes et fonctions encapsuls dans lobjet.
Deux versions dAlice sont actuellement disponibles. La premire version, Alice 2.2, est
ddie un public lycen voire premires annes universitaires. La deuxime version, Story-
telling Alice, dveloppe par Caitlin Kelleher [KPK07] a t conu pour un public plus jeune
(collge) et fminin. Les expriences ralises avec ces outils semblent montrer une relle ca-
pacit motiver les lves poursuivre une formation en informatique.
limage de Scratch et de StarLogo TNG, Alice bnficie dune communaut dutilisateurs
(tudiants et enseignants) fdre autour des forums et ressources accessibles via le site Web.
Actuellement plus de 2000 tablissements de formation attestent avoir dj utilis Alice dans
leurs enseignements.
39. http://education.mit.edu/drupal/starlogo-tng/learn consult le 29 Juin 2010
40. http://www.alice.org/ consult le 30 Juin 2010
64
F IGURE 3.4 Alice
Kodu 41 est dvelopp par Microsoft Research sur Windows et Xbox 360, cet environnement de
programmation se veut accessible aux enfants et divertissant pour tout public. Cet outil est ddi
spcialement la cration de jeux vido et fournit un environnement complet de conception,
de ralisation et de test des jeux produits. Linterface de programmation est le cur de cet
outil. Elle intgre un langage simple entirement base dicnes. Un programme est structur
en pages qui sont dcomposes en rgles, elles-mmes divises en conditions et actions. Les
conditions sont toutes values simultanment. Le langage de Kodu tant conu spcialement
pour la cration de jeux, il fournit des primitives adaptes. Les programmes sont exprims sous
la forme de termes physiques utilisant les concepts de vision, daudition, et de temps pour
contrler le comportement des personnages. Contrairement aux langages de programmation
41. http://fuse.microsoft.com/projects-kodu.html consult le 30 Juin 2010
65
classiques, Kodu peut exprimer les concepts avancs de conception de jeu dune manire simple,
directe et intuitive (voir figure 3.5).
F IGURE 3.5 Kodu
Associ cet outil, le Kodu Classroom Kit est disponible aux enseignants et fournit
un ensemble de leons et dactivits. Les leons sont conues pour tre flexibles de manire
ce que lenseignant puisse y trouver ce quil juge adapt son contexte denseignement.
travers ces leons, Kodu introduit la logique, la rsolution de problmes, les conditions et les
squences dinstructions avec une approche oriente objet. Il permet galement de montrer que
la programmation est un outil de cration qui permet aux tudiants de travailler leur imagination.
Ce Kit fournit galement des enqutes destines aux enseignants et tudiants qui utilisent le jeu.
Ces enqutes retourner aux concepteurs du jeu ont pour objectif de fournir un cadre danalyse
sur les expriences ralises.
Cleogo [CB98] est un environnement de travail collaboratif qui permet plusieurs personnes
de dvelopper simultanment des programmes laide de trois mtaphores de programmation :
un langage de manipulation directe, un langage iconique et un langage base de texte standard.
66
La programmation textuelle utilise le dialecte du langage Logo lexception des commandes de

traitement des listes. Les lignes du programme sont excutes au fur et mesure de leur saisie.
Lutilisateur peut r-excuter une ligne ou une squence de lignes laide dun historique. La
programmation iconique est ralise travers une interface reprsentant tous les lments du
langage utilis par Cleogo (dfinition et appel de procdures, gestion des paramtres, utili-
sation de boucles et de conditions, calcul dexpressions). Toutes les actions ralises travers
linterface iconique sont retranscrites dans les modes de programmation base de texte et de
manipulation directe. La programmation manipulation directe est plus limite que les deux
autres paradigmes. Elle permet seulement lutilisateur de contrler la tortue laide de la
souris. Ce dernier peut donc dplacer la tortue et la faire avancer et reculer, tourner gauche et
droite et (ds)activer le trac. Chaque action est immdiatement rpercute dans les environ-
nements iconiques et textuels. Lutilisateur peut galement enregistrer des squences dactions
pour crer des procdures mais ne peut les appeler ou traiter les conditions, les boucles et les ex-
pressions travers lenvironnement de manipulation directe. Toutefois, les enfants utilisateurs
de ce paradigme ne semblent pas avoir de problme avec ce manque dquivalence entre les
diffrentes mtaphores.
Le fait de proposer plusieurs paradigmes de programmation laisse la libert lutilisa-

teur de choisir celle qui lui correspond le mieux. Toutefois, quel que soit le paradigme choisi,
chaque action dun utilisateur est immdiatement communique tous les participants. Lob-
jectif de Cleogo est donc de permettre une collaboration en temps rel o chaque utilisateur
est au courant des actions de ses collaborateurs et peut librement partager son systme de con-
trle. Chaque utilisateur a sa propre interface et peut prendre part une collaboration via une
connexion internet, auquel cas, une communication audio doit tre tablie pour permettre un
change naturel entre les participants. Les actions des diffrents utilisateurs sont ralises en
temps rel et peuvent conduire des situations contradictoires. Cest alors aux participants de
grer le conflit par la communication. Le seul objectif du logiciel et dassurer que chaque par-
ticipant soit au courant des actions de autres personnes.
Lutilisation peut sembler dsordonne car chaque participant est libre de faire ce quil
souhaite quand il le souhaite. Mais lobjectif de Cleogo porte justement sur cet aspect et pousse
les utilisateurs sorganiser pour rsoudre un problme de manire cohrente.
67
Compalgo 42 (voir figure 3.6) est un environnement de programmation en langage algorith-

mique. Ce langage, typ et procdural, supporte la dclaration de structures, de fonctions et
de procdures. Il permet aussi la programmation modulaire grce la dfinition et limpor-
tation de bibliothques de programmes. Il intgre : un diteur graphique multi-documents avec
coloration syntaxique, une console dexcution et de saisie et un dbogueur. Compalgo est
dvelopp par des enseignements de lIUT (Institut Universitaire de Technologie) A Paul
Sabatier Toulouse III. Il est utilis dans une approche algorithmique des fins dinitiation
la programmation pour les tudiants de premire anne de DUT Informatique.
F IGURE 3.6 Compalgo
Associ cet outil, les bibliothques et exemples ncessaires la ralisation des travaux
pratiques sont diffuses via la plateforme Moodle de lIUT (Moodle est un environnement
dapprentissage libre base sur une application Web gratuite que les acteurs de lducation peu-
vent utiliser pour crer des sites dapprentissage autour de contenus et dactivits pdagogiques,
ici Compalgo). Compalgo nest donc pas limage des prcdents exemples un langage de
programmation base de blocs mais fournit aux tudiants un environnement de programmation
42. http://www.iut-tlse3.fr/moodle/course/view.php?id=1528 consult le 30 Juin 2010
68
o le langage utilis reflte la structure syntaxique et grammaticale du langage algorithmique

utilis en travaux dirigs.
Conceptions dexercices adapts au centre dintrt des tudiants
Stevenson et Wagner [SW06] ont analys des manuels dexercices et leurs usages his-
toriques pour noncer huit principes de base en vue de concevoir de bons exercices de
programmation : tre bas sur un problme du monde rel ; permettre aux tudiants de raliser
une solution raliste ce problme ; leur permettre de se concentrer sur un problme actuel du
cours dans un contexte de programmes consquents ; tre stimulant ; tre intressant ; utiliser
une ou plusieurs interfaces de programmation applicatives ; proposer plusieurs niveaux dexer-
cices qui permettent une optimisation des programmes ; permettre la crativit et linnovation.
Pour mettre en place ces exercices, les auteurs proposent une pdagogie par projet base sur
un robot dindexation et un valuateur de courriels indsirables. Greitzer et al. [GKH07], quant
eux, expliquent en particulier quune approche efficace consiste encourager lapprenant
travailler immdiatement sur des tches ralistes et significatives.
Dans cette optique, une approche prometteuse consiste utiliser la culture vido-ludique
des tudiants pour les motiver, travers un jeu vido, investir du temps dans la pratique de
la programmation. Deux orientations ont t explores : dvelopper un nouveau jeu vido ou
jouer un jeu vido.
Pour la premire orientation, nous pouvons citer trois exemples. Chen et Cheng [CC07]
proposent de demander aux tudiants, travers un projet collaboratif, dimplmenter en C++
un mini jeu vido interactif en un semestre, laide dun cadre mthodologique. Gestwicki et
Sun [GS08] ont ralis une tude de cas sur le jeu EEClone. Ce jeu de type arcade est impl-
ment en Java : les tudiants analysent diffrents patrons de conception avec EEClone et partir
de cette exprience, tudient comment ils peuvent les intgrer dans leur propre jeu. Leutenegger
et Edgington [LE07] utilisent directement les jeux vido pour enseigner les bases de linforma-
tique. Ces auteurs soutiennent que la programmation de jeux vido motive surtout les novices.
Ils utilisent le dveloppement de jeux 2D comme thme central.
La seconde orientation consiste permettre ltudiant dapprendre la programmation dans
le contexte dun jeu vido. La majorit des jeux existants de ce type permettent au joueur de
programmer un robot afin de le faire combattre dans une arne contre un ou plusieurs robots
programms par dautres joueurs. La bataille de robots est excute en temps rel sur lcran
69
de lordinateur et la motivation de jeu merge de la comptition entre les joueurs. Ces jeux
sont conus pour aider les tudiants pratiquer un langage de programmation spcifique. Ces
jeux sont accessibles tout type de programmeur, des dbutants (un simple robot peut tre crit
en quelques minutes) aux experts (raliser une vritable IA peut prendre plusieurs mois). A
titre dexemple, Robocode 43 [Har04] (voir figure 3.7) est compatible avec Java, Marv-
ins Arena 44 est compatible avec tous les langages .NET, Gun-Tactyx 45 utilise le langage
SMALL et Robot Battle 46 utilise un langage de script spcifique. Dans ce type de jeu, lacti-
vit de programmation est distincte de la simulation. Tout dabord, le joueur crit une IA pour
son robot, puis lexcute dans le contexte du jeu. Ainsi, le joueur est inactif durant la simulation
et devient spectateur du droulement de son programme.
F IGURE 3.7 Robocode : un simulateur de batailles de robots.
Toujours dans cette seconde orientation, Colobot 47 place le joueur dans le rle dun explo-
rateur spatial dont lobjectif est dexplorer et coloniser des plantes la recherche de matires
premires ncessaires sa survie. Le joueur peut progressivement construire et programmer de
nouveaux robots pour laider dans ces diffrentes tches et se protger contre les cratures
primitives et hostiles prsentes sur certaines plantes. Ce jeu mise sur un scnario original
pour motiver le joueur rsoudre les problmes auxquels il se trouve confront. Le langage
de programmation utilis est un langage orient objet similaire au C++.
43. http://robocode.sourceforge.net/ consult le 8 Janvier 2010
44. http://www.marvinsarena.com consult le 8 Janvier 2010
45. http://apocalyx.sourceforge.net/guntactyxconsult le 8 Janvier 2010
46. http://www.robotbattle.com consult le 8 Janvier 2010
47. http://www.ceebot.com/colobot/index-f.php consult le 8 Janvier 2010
70
Cest le seul exemple de jeu vido que nous connaissons qui intgre la programmation
dans son scnario de manire interactive et cohrente avec lunivers du jeu (voir figure 3.8). Il
inclut galement une prsentation pdagogique des concepts de programmation via une docu-
mentation dtaille consultable directement dans le contexte du jeu. Colobot est dfini par ses
concepteurs comme un jeu de STR. Pourtant, les jeux temps rel sont dynamiques et requirent
une forte interaction de la part du joueur alors que lactivit de programmation ncessite du
temps de conception et de ralisation. Par consquent, les rgles classiques des jeux de STR
ont t modifies dans Colobot pour permettre cette intgration. Le joueur ne peut contrler
directement quune seule entit la fois, do lutilit dautomatiser ces robots laide de pro-
grammes. Le mode multijoueur est absent pour viter les temps dattente entre joueurs pendant
les phases de programmation.
F IGURE 3.8 Colobot : un jeu srieux pour lapprentissage de la programmation.
Autres approches
La RoboCup 48 (voir figure 3.9) est une initiative ducative de recherche internationale. Son
but est de regrouper la recherche en intelligence artificielle et en robotique. Cette manifesta-
tion intgre et examine une gamme tendue de technologies travers trois comptitions : la
RoboCupSoccer, la RoboCupRescue et la RoboCupJunior. Cette initiative diffre des batailles
de robots en raison de son rapprochement avec la robotique (programmation de robots physiques)
et de par les objectifs de jeux qui ne portent pas sur la destruction de robots adverses. La
48. http://www.robocup.org/Intro.htm
71
RoboCupSoccer consiste confronter des robots rels ou simuls dans des matchs de foot. Dif-
frentes ligues et modes de jeu ont t imagin, en vue de permettre la participation dun maxi-
mum de disciplines scientifiques, pour traiter de problmes sur les environnements dynamiques
et la manipulation dinformations incompltes ou bruites. La RoboCupRescue est une nou-
velle comptition mise en place pour apporter plus de diversit. Elle est complmentaire de la
RoboCupSoccer en proposant des dfis dans la logistique et la planification long terme pour la
collaboration dagents htrognes et dquipes dagents. Enfin, pour les jeunes, la RoboCupJu-
nior est une comptition fortement oriente sur lducation et destine fournir une introduction
excitante aux caractristiques de la robotique.
F IGURE 3.9 La RoboCup 2007 (Allemagne).
WISE (Wireless Intelligent agent Simulation Environment) [CHHY04] prsente galement

une approche originale difficile classer. Cet outil se trouve cheval entre le jeu vido et
la manipulation de robots physiques limage de la RoboCup. WISE combine une version
virtuelle et physique du jeu Wumpus World. Il permet une distribution physique dagents (hu-
main ou robot) pour un jeu interactif et fournit un environnement dynamique dapprentissage
qui permet la mise en application dun grand nombre de concepts informatiques. Le jeu peut
tre utilis comme un outil de dmonstration lors de cours magistraux et peut permettre aux
tudiants, lors de travaux dirigs, de travailler sur des exercices pour tester, tendre, ou modifier
le simulateur. WISE peut tre jou de manire cooprative ou comptitive et ncessite, pour la
version physique, un grand nombre de ressources (espace, robots, etc.). Ce jeu a t utilis pour
lenseignement de lintelligence artificielle, du multimdia et des rseaux.
72
Un dernier exemple sortant de lordinaire est le jeu de socit c-jump (voir figure 3.10).
Ce jeu de plateau permet de dcouvrir les fondamentaux de la programmation comme la s-
quence, les structures de contrle conditionnelles et itratives et le concept de variables. Chaque
joueur contrle un pion (un nivoplanchiste ou snowboardeur) et doit tre le premier atteindre
larrive (i.e. avoir parcouru tout le programme).
F IGURE 3.10 C-jump : un jeu de plateau pour dcouvrir les fondamentaux de la program-
mation.
Conclusion
Malgr lomniprsence de linformatique dans nos socits, les nouveaux tudiants sont peu
attirs par cette discipline. La raison de ce phnomne semble rsider dans la difficult quont
les formations proposer des contenus en lien direct avec les applications du monde courant.
De ce fait, les tudiants peinent se projeter dans lavenir travers une telle prsentation de la
formation.
Pour rsoudre ce problme, le rapport de lACM/IEEE [AIC08] nonce un certain nombre
de recommandations :
ne pas changer la nature fondamentale de la discipline, cest--dire ne pas simplifier la
formation ou rduire son niveau acadmique ;
proposer une formation qui soit intressante et attractive aux tudiants actuels et qui leur
fournisse les connaissances et comptences requises pour une carrire en informatique ;
reconnatre que la crise de linformatique est un problme important pour la commu-
naut informatique. De nombreuses recherches et exprimentations actuelles portent sur
ce problme, mais il est important dencourager et de soutenir de nouvelles tentatives
ce sujet ;
73
ne pas proposer de conseils reconnus comme tant efficaces dans des environnements
spcifiques mais faire des propositions gnriques. De cette manire, diffrents groupes
de la communaut seront encourags chercher des solutions appropries leurs tu-
diants.
Parmi les propositions prsentes dans ce chapitre, lapproche base sur les jeux vido est
retenue, car elle semble avoir un potentiel dattraction et de motivation important auprs des
gnrations actuelles.
74
Conclusion de ltat de lart
Le jeu srieux permet donc une immersion et une interaction avec un monde virtuel qui peut
servir de support une formation. La composante ludique du jeu permet de motiver le joueur et
le maintient dans une dynamique dapprentissage. Le jeu srieux peut donc prendre une place
importante et simposer comme un complment aux mthodes de formation classiques. De plus
son utilisabilit dans la plupart des secteurs dactivits lui donne un avantage certain pour son
devenir. Les principaux travaux sur les jeux srieux, pour permettre leur essor et leur dve-
loppement, doivent porter sur linfrastructure, la conception de jeux cognitifs et limmersion
(Michael Zyda [Zyd05]).
linfrastructure consiste dvelopper les MMO, les moteurs de jeux et leurs outils, le
streaming (streaming : technique consistant transmettre des donnes aux utilisateurs et
les rendre disponibles au fur et mesure de leur arrive pour ainsi viter lattente dun
tlchargement complet), les consoles de jeux nouvelles gnrations, le sans fil et les
technologies mobiles ;
la conception de jeux cognitifs doit sappuyer sur la modlisation et la simulation des
motions et des comportements humains. Elle doit galement analyser et innover sur des
styles et genres de jeux nouveaux. Enfin, lintgration dune pdagogie dans lhistoire des
jeux srieux reste un point important approfondir ;
limmersion doit tre amliore travers le graphisme, le son, lhaptique, mais aussi en
utilisant les motions et ltat du joueur.
Dans ce sens, les jeux srieux peuvent apporter leur contribution la rsolution de la crise
de linformatique dans lenseignement. Cette orientation a dailleurs t prsente travers
les batailles de robots et Colobot qui peuvent tre considrs comme des jeux srieux pour
lapprentissage de la programmation (voir dfinition section 1.2).
Paralllement ces outils clairement dfinis, les moteurs de jeux de STR code source
ouvert prsentent des caractristiques intressantes pour aborder le problme de la motivation
75
Conclusion de ltat de lart
des tudiants en informatique. En effet leur interface de programmation dIA combine la

possibilit de modifier le contenu du jeu doit permettre la conception de jeux de STR o la
pratique de la programmation aurait son importance. Il serait alors possible de proposer aux
tudiants des jeux srieux pour lapprentissage de la programmation plus proches des standards
des jeux vido.
76
Deuxime partie
Contributions
77
4
Conception dun jeu srieux de STR pour

lapprentissage des fondamentaux de la
programmation
Dans le cadre de ce travail de recherche, lobjectif principal consiste concevoir, raliser et

valuer un jeu srieux de STR pour lapprentissage de la programmation. Le choix de ce type
de jeu comme support au jeu srieux a t prsent dans le chapitre 2 et se justifie par les trois
composantes suivantes : un environnement complexe propice la mise en place de problmes
informatiques, une popularit auprs des joueurs et une disponibilit de moteurs de jeu code
source ouvert rutilisables.
La conception du jeu srieux a suivi trois tapes principales. La premire a consist vrifier
la popularit des jeux de STR auprs dun chantillon dtudiants apprenant la programmation
et de dfinir le principe gnral du jeu srieux. La deuxime phase a regroup lensemble des
ralisations techniques qui permettent lintgration de la programmation dans les jeux de STR.
Enfin la dernire tape a consist concevoir le jeu proprement dit en y intgrant de manire
cohrente le savoir enseigner.
4.1 Cadrage du jeu srieux

Cette section sattache donc vrifier la popularit des jeux de STR auprs des tudiants
susceptibles dutiliser le jeu srieux. En effet, pour esprer bnficier du potentiel motivationnel
79
Chapitre 4. Conception dun jeu srieux de STR pour lapprentissage de la programmation
du jeu vido, il est prfrable de baser le jeu srieux sur un genre apprci des tudiants. Enfin, le
fonctionnement gnral du jeu est prsent avec notamment lintgration de la programmation
dans lactivit de jeu.
4.1.1 Popularit des jeux de STR auprs des tudiants

La popularit des jeux de STR a t vrifie par trois sries denqutes ralises de septem-
bre 2007 juin 2010 auprs de 900 tudiants rpartis dans huit formations diffrentes, soit 59%
des inscriptions pdagogiques. Les formations choisies pour cette enqute proposent toutes un
enseignement des fondamentaux de la programmation. La pratique du jeu vido pour ces tu-
diants en fonction du sexe et du type de formation est synthtis dans la figure 4.1. Il apparat
sur ces graphiques, que les tudiants des formations IUT sont plus joueurs que les tudiants
de la facult. De mme, le public fminin est moins sensibilis aux jeux vido que le public
masculin. Il importe toutefois de prciser que, dans ces enqutes, les tudiantes reprsentent
seulement 19% de la population. Avec 77% de joueurs parmi lensemble des tudiants inter-
rogs, ces donnes corroborent les chiffres de lESA [Ass09] et illustrent la popularit des jeux
vido auprs des tudiants dinformatique.
Etudiants Etudiantes Tous participants
Profil 8% 13%
51% 49%
IUT 92% 87%
Profil 18% 34% 29%

Facult 82% 66% 71%
Tous 14% 37% 23%

profils 86% 63% 77%
Joueur Non joueur
F IGURE 4.1 Pourcentage de joueurs en fonction du sexe et du type de formation.

Enqute ralise auprs de 900 tudiants dont 730 garons et 170 filles sur les 1533 inscriptions
pdagogiques des huit formations interroges.
La premire srie denqutes concerne 181 tudiants (154 garons et 27 filles) dans trois
formations diffrentes (deux en informatique et une en gnie civil). Dans ce questionnaire, neuf
80
4.1. Cadrage du jeu srieux
familles de jeu sont proposes et chaque tudiant joueur indique les types de jeu pratiqus. La
figure 4.2 met en vidence le pourcentage de joueurs pour chaque type de jeu. Notons que le
jeu de STR arrive en tte et se trouve tre galement jou par les filles (57% des filles joueuses
jouent aux jeux de stratgie).
70%
60%
50%
40%
30%
20%
10%
0%
Aventure
Rle
Course
Sport
Stratgie
Rflexion
Combat
Tir
Plates-formes
F IGURE 4.2 Enqute 1 : Pourcentage de joueurs en fonction du type de jeu.
Enqute ralise auprs de 181 tudiants dont 154 garons et 27 filles.
La deuxime srie denqutes concerne 113 tudiants dinformatique (78 garons et 35

filles). Lobjectif est daffiner la perception de la pratique du jeu vido chez les tudiants. Pour
cela, les tudiants joueurs attribuent une note de 1 7 aux neuf familles de jeux proposes. La
note maximale indique quun type de jeu est particulirement apprci dun tudiant alors que
la note minimale dnote le contraire. Il est donc possible de dterminer trois classes dappr-
ciation en fonction de la rpartition des notes des tudiants : les types de jeu non populaires
sont ceux dont le nombre maximum dtudiants se situe sur les notes 1 et 2 ; les types de jeu
indiffrents sont ceux dont le nombre maximum dtudiants se situe sur les notes 3, 4 et 5 ;
les types de jeu populaires sont ceux dont le nombre maximum dtudiants se situe sur les
notes 6 et 7. la vue des donnes rcoltes aucun type de jeu nentre dans la premire classe
des jeux non populaires . La figure 4.3 prsente les types de jeu entrant dans la classe in-
diffrents et la figure 4.4 prsente les types de jeux de la classe populaire (les jeux de STR
font partie de ce groupe). Il est apparu que la classification propose tait parfois mal interprte
par les tudiants qui prouvaient donc des difficults valuer leur intrt pour chaque famille
de jeu. Par consquent, une troisime srie denqutes a donc t ralise.
Dans cette dernire version du questionnaire, les tudiants joueurs doivent simplement lis-
ter leurs cinq jeux prfrs. Chaque jeu est ensuite class suivant la nomenclature du magazine
81
40
45
35
40
30
35
25
30
Rflexion 20 STR
25 Plates-formes Rle
15
20 Course Aventure
15 Combat 10
Tir 5
10
Sport
5 0
indiffrent
0 non populaire populaire
non populaire indiffrent populaire
F IGURE 4.4 Enqute 2 : Rparti-

F IGURE 4.3 Enqute 2 : Rpartition de lintrt des
tion de lintrt des tudiants pour
tudiants pour les jeux indiffrents .
les jeux populaires .
Enqute ralise auprs de 113 tudiants dont 78 garons et
Enqute ralise auprs de 113 tu-
35 filles.
diants dont 78 garons et 35 filles.
spcialis GameSpot prsent dans la section 1.1.2. La classification de GameSpot a t choisie

en raison de sa visibilit (magazine de jeux vido le plus consult sur Internet) et de la prsence
sur le site Web dune base de donnes importante accompagne dun moteur de recherche qui
facilite le classement de chaque jeu vido. Lors de ces enqutes, 606 tudiants (498 garons
et 108 filles) de cinq formations en informatique ont t interrogs. 321 jeux diffrents ont t
identifis parmi les 1891 occurrences de jeux cits. Afin daugmenter la lisibilit des infor-
mations rcoltes, seules les catgories mentionnes par plus de 10% des tudiants joueurs sont
prsentes dans les rsultats. Il apparat que les jeux de STR sont mentionns par 36% des tu-
diants (voir figure 4.5). Ils occupent donc une place importante et se positionnent comme le
troisime type de jeu prfr parmi les 36 catgories de la classification de GameSpot. Pour les
filles joueuses, les jeux de STR sont mentionns pour 17% dentre elles ce qui place ce type de
jeu en sixime position (voir figure 4.6).
La premire srie denqutes a permis dobtenir une vision exhaustive de la pratique du
jeu vido par les tudiants en fonction dune classification donne. Dans cette approche, les
tudiants doivent dterminer les catgories correspondantes leurs jeux prfrs. La deuxime
srie denqute a permis dobtenir une vision plus prcise et a montr quaucun type de jeu ne
fait rellement lunanimit entre les tudiants. En effet les trois classes dapprciation sont tou-
jours reprsentes de manire non ngligeable pour chaque type de jeu. Le point critique de la
82
70%
60%
50%
40%
30%
20%
10%
0%
Tir subjectif
Action / Aventure
Rle
Tir tactique
Sport (football)
Rle (MMO)
Course
Stratgie (STR)
Plates-formes
F IGURE 4.5 Enqute 3 : Les neuf catgories de jeu les plus mentionns parmi la classification
de GameSpot.
Enqute ralise auprs de 606 tudiants dont 498 garons et 108 filles.
70%
60%
50%
40%
30%
20%
10%
0%
Action / Aventure
Puzzle
Strategie (STR)
Sport (autre)
Strategie (autre)
Vie artificielle
Course
Rle
Sport (Football)
Plates-formes
Divers
F IGURE 4.6 Enqute 3 : Les onze catgories de jeu les plus mentionns par les tudiantes
joueuses parmi la classification de GameSpot.
Extraction des donnes pour les 108 tudiantes de la troisime srie denqutes.
mthode utilise lors de ces deux premires enqutes porte sur la terminologie employe pour
caractriser les diffrents types de jeux et sur la difficult de certains tudiants projeter leurs
jeux dans la classification propose. La troisime srie denqutes avait donc pour objectif de
remdier a ce problme en dchargeant les tudiants de cette tche et en transfrant lactivit
83
de classement lors de lanalyse des donnes. Mais cette approche pose le problme de la com-
pltude des informations et de la capacit dterminer de manire exhaustive les types de jeux
apprcis des tudiants partir dun chantillon de jeux.
Lanalyse croise de ces diffrentes enqutes a tout de mme permis de vrifier la bonne
popularit des jeux de STR auprs des tudiants en informatique. Par consquent, le choix
initial dun jeu de STR comme support au jeu srieux sest avr tre en lien direct avec les
centres dintrts des tudiants susceptibles dutiliser le jeu. Mais, en quoi consiste rellement
ce jeu srieux ? La section suivante aborde cette question travers une prsentation gnrale du
jeu srieux.
4.1.2 Fonctionnement gnral du jeu srieux
Afin dvaluer lintrt du jeu srieux dans diffrentes situations denseignement, une tape
incontournable est de rechercher et convaincre des enseignants daccepter de dployer le jeu
dans leur formation. Lutilisation dun jeu srieux adaptable diffrents contextes, cest--dire
diffrents langages et paradigmes de programmation, diffrentes mthodes pdagogiques et dif-
frents tudiants doit faciliter ladhsion des enseignants. Lanalyse des outils existants ddis
lapprentissage de la programmation a permis didentifier les batailles de robots et Colobot
comme tant des jeux srieux proches de jeux de STR (voir section 3.2.2). Malgr leurs qualits
propres, ces jeux ne sont pas utilisables dans diffrents contextes denseignements puisquils
reposent sur un langage de programmation spcifique qui peut ne pas correspondre aux choix
pdagogiques des enseignants. Il devient alors pertinent de concevoir un jeu srieux gratuit et
portable. La gratuit est une caractristique supplmentaire pour favoriser lutilisation du logi-
ciel dans un milieu universitaire et viter que des problmes dordre financier soient un frein
la ralisation des exprimentations.
Les jeux de STR sont des programmes extrmement complexes, composs de plusieurs
dizaines de milliers de lignes de code. Lobjectif ntant pas de raliser un nouveau jeu de STR,
lutilisation dun moteur de jeu existant sest impos. Ce moteur doit avoir son code source
ouvert pour permettre dy intgrer les fonctionnalits lies au jeu srieux.
Dans les jeux de STR, le joueur donne des ordres ses units pour raliser des actions
comme se dplacer, construire, ou attaquer. Ces ordres sont donns en cliquant sur la carte
laide de la souris. Dans la mesure o ces ordres peuvent tre remplacs par des instructions
84
de programmation, puis enchans et ordonns pour tre transmis au moteur de jeu, la transfor-
mation dun STR en jeu srieux pour lapprentissage de la programmation devient possible.
Suite lanalyse des systmes existants, tels que Colobot et les batailles de robots, une
mthode dinteraction compatible avec les jeux de STR et la pratique de la programmation est
propose. Cette mthode sarticule autour de deux phases. Dans un premier temps le joueur/tu-
diant conoit des programmes capables de contrler ses units en vue de leur attribuer des com-
portements. Cette phase de conception est ralise la manire des jeux de bataille de robots o
le joueur/tudiant crit son IA puis la teste dans le contexte du jeu. Puis, dans un second temps,
une fois ses programmes mis au point, le joueur/tudiant les utilise dans les diffrents modes de
jeu (campagne et escarmouche). Tout en conservant une interaction directe sur lenvironnement,
le joueur/tudiant peut excuter ses programmes en cours de partie la manire de Colobot. Ce
modle peut tre facilement port N tudiants en exploitant le composant multijoueur des jeux
de STR o chaque participant est libre de concevoir des programmes et de les utiliser en cours
de partie sil les juge pertinents (voir figure 4.7).
Programme
1 2
Jeu de
Etudiant 1 2 2 Etudiant 3
STR
1
2 2
2 Programme
Programme
1
Etudiant 2
F IGURE 4.7 Interaction entre chaque joueur, leur programme et le jeu de STR.
Phase 1 : Codage
Phase 2 : Interaction
Lactivit de jeu consiste alors crire des programmes plus ou moins sophistiqus destins
commander des units, ouvrant ainsi la voie diffrents niveaux de complexit. Lutilisation
de la programmation peut devenir un ressort qui renforce lapprentissage, car elle apporte un
intrt nouveau au jeu en permettant au joueur de dpasser les contraintes dinteraction lies
aux priphriques dentre/sortie et ses comptences physiques. La programmation peut lui
permettre de dlguer certaines tches ses programmes afin de se concentrer sur les aspects
85
du jeu les plus intressants. Les spcifications de notre jeu srieux sont donc les suivantes :
vhiculer des concepts de programmation, tre portable dans diffrents contextes denseigne-
ment, tre bas sur un jeu de STR, conserver le gameplay du jeu de STR support et autoriser le
contrle des units via des programmes informatiques.
Pour permettre la communication entre le programme du joueur et un jeu de STR, le systme
Prog&Play a t dvelopp.
4.2 Spcification du systme Prog&Play

Lobjectif du systme Prog&Play est de permettre au joueur de raliser des programmes ca-
pables dinteragir avec un jeu de STR. De cette manire, le joueur pourra suivre le droulement
de son programme travers le comportement de ses units dans le jeu vido. Chaque moteur
de jeu, prsent dans la section 2.4, propose un langage de script et une interface associe pour
permettre aux joueurs de personnaliser le jeu ou de crer leur propre IA. Or, ces langages de
script peuvent ne pas correspondre aux approches choisies par les enseignants pour aborder les
fondamentaux de la programmation. Pour cette raison, le systme Prog&Play est conu comme
une interface entre les moteurs de STR et les langages de programmation. Parmi un ensemble
de langages et un ensemble de moteurs compatibles Prog&Play, chaque enseignant est libre de
choisir les deux composantes les plus adaptes son approche pdagogique (voir figure 4.8).
Langages de
programmation
Moteurs de STR
C/C++
Scratch Spring
Ada
Java Prog&Play Warzone 2100
Compalgo ORTS
OCaml ...
...
F IGURE 4.8 Prog&Play : une interface entre les langages de programmation et les moteurs de
STR.
Prog&Play est donc disponible sous la forme dune API (Application Programming Inter-
face) utilisable par les joueurs pour concevoir des programmes compatibles avec les jeux de
STR qui intgrent le systme.
86
4.2. Spcification du systme Prog&Play
4.2.1 Premire version
LAPI Prog&Play, telle quelle a t utilise pour les expriences, est lvolution dun pre-
mier systme bas sur lutilisation dune bibliothque dynamique et de la conception dun en-
vironnement de dveloppement ddi. La section suivante prsente ce systme et pointe les
limites qui ont conduit concevoir lAPI Prog&Play.
Vue densemble
Cette premire version, structure autour dune bibliothque dynamique, est compose de
trois entits : le moteur de jeu, la bibliothque dynamique contenant le code du joueur et le
centre de dveloppement.
Dans ce systme (dont larchitecture fonctionnelle des diffrents composants est prsente
dans la figure 4.9), le moteur du jeu doit tre modifi pour permettre le chargement de la biblio-
thque ( travers le Chargeur ) et fournir aux joueurs les outils ncessaires la manipulation
des donnes (grce l IMJ - Interface du Moteur de Jeu ). La bibliothque dynamique
possde une interface ( IGCU - Interface de Gestion du Code de lUtilisateur ) qui permet
son utilisation et un thread (ou processus lger) pour lexcution du code du joueur.
Moteur de jeu
Bibliothque dynamique
utilise
IMJ
Thread
Programme pilote
IGCU Chargeur
modifie construit interagit
interagit
Centre de dveloppement
Joueur
F IGURE 4.9 Architecture fonctionnelle (version 1).
87
L IMJ assure une double fonctionnalit. Premirement, cest une interface fournissant
lutilisateur la possibilit dinteragir avec le jeu, elle sert de point dentre vers le moteur.
Lensemble des fonctions accessibles par cette interface doit tre en relation avec les connais-
sances du joueur, les objectifs pdagogiques, etc. Deuximement, elle assure la synchronisation
entre le code du joueur et le moteur du jeu, ceci afin de respecter lintgrit et la consistance du
droulement de la partie.
L IGCU permet de contrler lexcution du code de lutilisateur travers deux points
dentre, les fonctions :
void IGCU_Start(IMJ* data) et void IGCU_Stop(void).
Ces deux fonctions permettent respectivement de lancer lexcution de lIA dans un thread
en lui indiquant les donnes utilisables travers une IMJ et de stopper proprement lexcu-
tion de ce thread contenant lIA.
Le Chargeur est conu pour charger la bibliothque dynamique lorsque celle-ci est cre
ou modifie. Il a galement la responsabilit de la librer de la mmoire si celle-ci est supprime
du systme de fichier. Le Chargeur a une autre utilit : il pilote lexcution du code de
lutilisateur travers les points dentre de l IGCU afin de maintenir la mme version entre
la bibliothque et le code excut. Lalgorithme 1 prsente le fonctionnement du Chargeur .
Finalement, le centre de dveloppement permet au joueur de modifier son code contenu
dans la bibliothque et de (re)construire celle-ci pour indiquer au moteur que le code a chang
et quil est temps de le mettre jour.
Bibliothque dynamique
La smantique du terme bibliothque dynamique rsume bien son utilit. La bibliothque

fournit des fonctions qui peuvent tre appeles et excutes par le programme qui la consulte.
Quant la notion de dynamique, elle indique que la bibliothque pourra tre charge, utilise et
limine pendant lexcution du programme.
Dans cette premire version, la bibliothque contient le code saisi par le joueur et dfinit le
comportement de ses units. Le jeu utilise donc cette bibliothque pour dterminer les actions
raliser. chaque modification de la bibliothque, la nouvelle IA est recharge. Grce ce
principe, le code contenant le comportement des units est compltement indpendant du jeu.
Le joueur peut donc maintenant modifier son code et le recompiler sous forme dune biblio-
thque pour quil soit automatiquement intgr au jeu en cours de partie. En rgle gnrale, la
88
Algorithme 1 Gestion de la bibliothque dynamique

tantque le jeu est en fonctionnement faire
si la bibliothque dynamique existe alors
si la bibliothque dynamique a t mise jour alors
si IGCU _Stop est charg alors
Stopper lIA en cours dexcution (IGCU _Stop)
finsi
Charger les points dentre (IGCU _Start et IGCU _Stop)
si les points dentre ont t correctement chargs alors
Lancer lexcution de lIA (IGCU _Start)
sinon
Librer les points dentre (IGCU _Start et IGCU _Stop)
finsi
finsi
sinon
finsi
finsi
fin tantque
finsi
bibliothque se suffit elle mme. Pourtant, dans notre application, elle est cense accder la
boite outils du moteur afin de manipuler les donnes.
Lexcution de la bibliothque est ralise dans un thread pour permettre au client de
rester actif et apte ragir aux actions de lutilisateur ou du serveur. Dornavant, des IA com-
plexes peuvent tre mises en place sans influencer les performances du jeu. En contre partie, la
programmation parallle introduit des difficults supplmentaires pour fiabiliser le systme. En
effet, ce type de programmation demande la mise en place de mcanismes entre les diffrents
processus pour permettre dassurer la synchronisation et la cohrence des donnes partages
tout en tant transparent pour le joueur.
La fiabilit du systme est galement assure en le protgeant contre les bogues gnrs par
les tudiants. En effet, les joueurs tant en apprentissage de la programmation, il est fortement
probable que ceux-ci ralisent des erreurs. Ces bogues peuvent causer des erreurs systmes
(erreur de segmentation par exemple) ou des leves dexceptions. Pour rcuprer les erreurs d-
89
clenches dans la bibliothque les signaux systmes sont utiliss. Ainsi, lorsquune interruption
est gnre dans le code du joueur, seul le thread excutant le code du joueur est interrompu.
Une information est alors donne au joueur pour linformer du type derreur ayant arrt son IA.
De cette manire, le fonctionnement du jeu nest pas dpendant des mauvais fonctionnements
de lIA.
Lutilisation de la bibliothque dynamique possde un avantage supplmentaire. Elle dis-
simule au joueur la complexit du jeu vido. En rgle gnrale, vouloir modifier une partie dun
programme consiste, au pralable, analyser la structure, lorganisation et le fonctionnement
de lapplication. La bibliothque dynamique aide le joueur en extrayant lIA du jeu. De cette
manire, lutilisateur na pas conscience des difficults lies lintgration de son code dans le
moteur de jeu.
Environnement de dveloppement
La bibliothque dynamique donne au joueur lopportunit de modifier son code de faon

interactive. Elle lassiste dans son travail en cachant la complexit du moteur. Cependant, luti-
lisation du jeu reste fastidieuse en raison de larborescence et des dpendances des fichiers
(emplacement des fichiers sources et de la bibliothque dynamique gnre, options de compi-
lation, etc.). Dans ces conditions, il tait ncessaire de rendre le logiciel plus intuitif en crant
un environnement de dveloppement appele le centre de dveloppement (CDD) (figure 4.10).
F IGURE 4.10 Le centre de dveloppement.
90
Le CDD est un composant qui facilite la conception et la manipulation des ralisations du

joueur. Il est complmentaire du jeu et simplifie la gestion des projets travers un ensemble
de menus. Cependant, le CDD est indpendant et nest pas ncessaire au fonctionnement du
moteur et vice versa. Il complte la bibliothque dynamique en simplifiant la manipulation
du systme de synchronisation et de liaison entre le code du joueur et le jeu. Ainsi, le joueur
peut alors utiliser les fonctions de l IMJ pour manipuler les entits du jeu et implmenter
la classique fonction int main (){...} comme si son code tait indpendant du jeu.
Lors de la compilation, cette fonction est renomme en GCU_exec et utilis par l IGCU
pour lancer lexcution de lIA. Grce au CDD, le joueur peut facilement compiler et injecter
son code dans le moteur afin dobserver les rsultats.
Critiques
Cette solution permet de stocker le programme compil du joueur dans une bibliothque
charge dynamiquement au cours de lexcution du jeu. Moyennant quelques optimisations
lutilisation de bibliothques dynamiques permet de satisfaire les contraintes suivantes :
1. permettre aux joueurs dintgrer leur code au jeu dynamiquement ;
2. protger le jeu contre les bogues venant des programmes des joueurs ;
3. cacher la complexit du moteur de jeu ;
4. tre compatible avec diffrents langages de programmation.
Cependant, certains langages dits interprts ne permettent pas la gnration de biblio-

thques dynamiques. Par consquent, le point (4) nest satisfait que pour un sous-ensemble
des langages de programmation. Dans ce cadre, une seconde version nomme Prog&Play a t
dveloppe pour sinterfacer avec ce type de langages.
Concernant le CDD, laide la conception et la manipulation introduite par cet diteur se
trouve tre insuffisante pour compenser les performances et fonctionnalits des environnements
de dveloppement ddis chaque langage de programmation. Dautre part, en contexte rel,
les enseignants font un choix de langage et dditeur associ. Lidal est donc de pouvoir utiliser
lAPI Prog&Play via les environnements de programmation choisis par les enseignants. Pour
ces deux raisons, le principe dun environnement de dveloppement ddi au jeu a t aban-
donn.
91
4.2.2 Seconde version

Dans la nouvelle version, le programme de ltudiant compil ou interprt est indpendant
du moteur de jeu et communique avec le jeu via une mmoire partage.
Description gnrale
Les mmoires partages sont utilises comme mthodes de communication interprocessus

cest--dire comme un moyen dchanger des donnes entre programmes fonctionnant en mme
temps. LAPI Prog&Play sert dinterface la gestion de cette mmoire partage pour simplifier
la communication et la synchronisation entre le programme du joueur et le moteur de jeu. Deux
interfaces sont donc disponibles : la partie Client est utilise par le joueur pour dvelopper
son propre programme et la partie Fournisseur est intgre au moteur du jeu. Sur demande
du programme du joueur, les donnes pertinentes du jeu sont copies dans la mmoire partage.
Pour viter des situations incohrentes, le programme du joueur travaille sur cette copie. Le
programme du joueur lit les donnes et crit les commandes travers linterface Client .
La mmoire partage est rgulirement vrifie par le moteur de jeu pour raliser les actions
en attente. De cette manire, nimporte quel instant, le joueur peut stopper lexcution de
son programme, le modifier et le relancer pour quil se reconnecte la mmoire partage sans
perturber le droulement du jeu. Cette architecture fonctionnelle est prsente dans la figure
4.11.
Mmoire
partage
Moteur de jeu
lit Copie de crit
Prog&Play l'tat du jeu Prog&Play
(Client) Commandes (Fournisseur)
crit en attente lit
utilise interagit
modifie
Programme
Joueur
F IGURE 4.11 Architecture fonctionnelle (version 2).
92
Le Fournisseur a donc en charge la gestion de la mmoire partage. La figure 4.12

prsente la squence dinteraction entre le Fournisseur et la mmoire partage.
Fournisseur <<create>> Mmoire partage
<<crer>>
1 : Initialisation()
loop
boucle
2 : Rafrachissement demand ?()
[J eu non termin]
3 : rponse
opt
4 : Calculer la mise jour()
[rponse = vrai] 5 : Envoyer la mise jour()
6 : Rcuprer les commandes en attente()
7 : commandes en attente de traitement
8 : Excution des commandes()
9 : Quitter()
<<dtruire>>
<<destroy>>
F IGURE 4.12 Gestion de la mmoire partage par le Fournisseur .
Dans un premier temps, le Fournisseur cre et initialise la mmoire partage de manire

ce quelle soit accessible par le Client . Aprs cette initialisation, le jeu entre dans la boucle
de simulation et chaque itration le Fournisseur consulte la mmoire partage pour savoir
si un rafrachissement est demand. Si tel est le cas, le Fournisseur calcule la mise jour
en fonction de ltat courant du jeu et la copie dans la mmoire partage. Le Fournisseur
sattache ensuite traiter les commandes dfinies par le Client . Enfin lorsque le jeu est
termin, le Fournisseur nettoie et libre la mmoire partage.
Du ct Client , lappel aux fonctions de lAPI peut tre ralis aprs stre connect la
mmoire partage et avoir demand un premier rafrachissement. Dans le cas contraire, les fonc-
93
tions de lAPI retournent un code derreur ou lvent une exception en fonction du langage uti-
lis. Lors dune demande de rafrachissement, cet appel est bloquant tant que le Fournisseur
na pas dtect et ralis la mise jour. La figure 4.13 illustre une squence dinteraction entre
le Fournisseur , le Client et la mmoire partage avec le cas particulier dune demande
de rafrachissement.
Fournisseur Mmoire partage Client

<<create>>
<<crer>>
1 : Initialisation()
2 : Connexion
4 : Rafrachissement demand ?()

3 : Demande de rafrachissement()
5 : vrai
6 : Calculer la mise jour()
7 : Envoyer la mise jour()
8 : mise jour termine
Appel des fonctions de l'API autre

que la connexion et la dconnexion
<<dtruire>>
10 : Quitter() 9 : Dconnexion
<<destroy>>
F IGURE 4.13 Cas particulier du rafrachissement ct Client .
Description dtaille
Le diagramme de classes UML de la figure 4.14 dcrit les structures internes lAPI ainsi
que les diffrentes relations entre celles-ci.
Il convient dapporter quelques explications sur ce diagramme en commenant par la struc-
ture qui reprsente lensemble des donnes transfrables via la mmoire partage : PP_Shared-
94
PP_ Pos
+specialArea 11
+x: Float
0..*
0 +pos
+y: Float
+mapSize
1
1 1
1 +startPos
PP_ SharedUnit
PP_ SharedData +unit +id: Integer
+type: Integer
+update: Boolean
0..*
0 +health: Float
+gameOver: Boolean
+maxHealth: Float
+group: Integer
+pendingCommand 1
1 +coalition
0..*
0
PP_ SharedCommand <<enumeration>>
PP_ Coalition
+unitId: Integer
+group: Integer +MY_COALITION
+commandType: Integer +ALLY_COALITION
+commandCode: Integer +ENEMY_COALITION
+resource 0..*
0
PP_ Ressources +commandQueue 0..*
0
0..*
0 +param PP_ Command
PP_ CommandParam
F IGURE 4.14 Diagramme de classes de lAPI Prog&Play.
Data. Elle contient notamment lensemble des units accessibles par linterface Client .
Chaque unit est reprsente par la structure PP_SharedUnit qui contient un identifiant, un
type, un capital sant courant et maximum, un groupe, une position, un ensemble de comman-
des traiter et une coalition. Cette dernire est reprsente par lnumration PP_Coalition
qui est compose de trois membres : MY_COALITION reprsente les units contrles par
le joueur ; ALLY_COALITION reprsente les units contrles par un alli du joueur ; EN-
EMY_COALITION reprsente les units contrles par un ennemi du joueur.
La structure PP_SharedData contient galement une liste de zones spciales (specialArea)

qui permet de transfrer un ensemble de positions via lAPI. Il importe alors en fonction du
jeu et de ses donnes de dfinir la reprsentation de ces positions de faon ce quelles soient
utilisables par le joueur.
95
Une dernire prcision concerne la reprsentation des commandes qui intervient sous la
forme de deux structures : PP_Command et PP_SharedCommand. La premire reprsente
lensemble des commandes traiter pour une unit. Ces commandes ont t dfinies par le
joueur ou son programme lors des pas de simulation prcdents. La seconde, (PP_SharedCom-
mand), reprsente lensemble des commandes dfinies par le programme du joueur et non en-
core traites par le jeu. Si les instances de cette structure sont valides, les commandes associes
se retrouveront sous la forme dinstances de PP_Command lors des mises jour venir.
Le diagramme de composants UML de la figure 4.15 dcrit lorganisation du systme du
point de vue des lments logiciels et exprime donc les dpendances entre le programme du
joueur et le jeu. Les deux interfaces Fournisseur et Client sont disponibles via une im-
plmentation en C dtaille en annexe A. Ce langage a t choisi comme base de lAPI en
raison de son utilisation rpandue qui en fait un langage interoprable avec de nombreux autres
langages de programmation.
Pour implmenter le systme Prog&Play, le choix sest orient vers lutilisation de la biblio-
thque Boost interprocess 49 qui propose une solution portable et efficace de gestion des m-
moires partages. Dautre part, cette bibliothque offre la possibilit dutiliser dans la mmoire
partage des conteneurs complexes comme les vecteurs ou les maps par exemple.
Conclusion
LAPI Prog&Play a t conue pour cacher la complexit de synchronisation dune commu-
nication interprocessus et donner la possibilit daccder un sous ensemble des donnes du
jeu. Ce sous ensemble de donnes permet de simplifier la comprhension du jeu en rduisant
la quantit dinformations accessibles par les programmes des tudiants. Cette simplification a
un second intrt li la portabilit de lAPI Prog&Play, car, si cette API tait trop proche des
spcifications dun jeu particulier, il serait alors difficile, voire mme impossible, de lutiliser
avec de nouveaux jeux. Cette simplification des donnes implique des limitations quant la
ralisation des IA possibles. En effet, en simplifiant les donnes accessibles, certaines infor-
mations de ltat du jeu et certaines fonctionnalits ne sont plus accessibles travers lAPI. Le
choix des donnes transfres travers lAPI Prog&Play est un point critique toujours en cours
dvolution. Actuellement, un joueur a accs, travers lAPI, ltat de fin de partie, la taille
49. http://www.boost.org/doc/libs/1_39_0/doc/html/interprocess.html consult le 8

Janvier 2010
96
<<librairie>>
Boost/ interprocess
Programme du joueur
<<Importe>>
Interface Client
Prog&Play
+PP_Open()
+PP_Close()
Client +PP_Refresh()
+PP_IsGameOver(): Boolean
+PP_GetMapSize(): Position
<<Importe>> <<Accde>> +PP_GetStartPosition(): Position
+PP_GetSpecialAreas(): Positions
+PP_GetResource(id: Resource): Integer
Fournisseur +PP_GetNumUnits(c: Coalition): Interger
+PP_GetUnitAt(i: Integer, c: Coalition): Unit
+PP_Unit_GetCoalition(u: Unit): Coalition
+PP_Unit_GetType(u: Unit): Type
<<Accde>> +PP_Unit_GetPosition(u: Unit): Position Moteur de jeu
+PP_Unit_GetHealth(u: Unit): Float
+PP_Unit_GetMaxHealth(u: Unit): Float
+PP_Unit_GetGroup(u: Unit): Group
+PP_Unit_GetPendingCommands(u: Unit): Commands
+PP_Unit_SetGroup(u: Unit, g: Group)
+PP_Unit_ActionOnUnit(u: Unit, a: Action, t: Unit)
Mmoire partage +PP_Unit_ActionOnPosition(u: Unit, a: Action, t: Position)
+PP_Unit_UntargetedAction(u: Unit, a: Action, p: Float)
Interface Fournisseur
+PP_Init()
+PP_Quit()
+PP_NeadUpdate(): Boolean
+PP_Update(u: Units, gameOver: Boolean, mapSize: Position, start: Position, specialAreas: Positions, r: Resources)
+PP_GetPendingCommands(): Commands
F IGURE 4.15 Diagramme de composants du systme Prog&Play.
de la carte, sa position de dpart sur la carte, aux units visibles (non caches par le brouillard
de guerre), ses rserves de ressources et un ensemble de positions particulires.
Lutilisabilit du systme Prog&Play a t vrifie au fur et mesure de son dveloppement

travers son intgration dans diffrents moteurs de STR tels que ORTS, Spring et WarZone
2100.
97
4.3 Intgration de Prog&Play dans diffrents jeux de STR

Intgrer le systme Prog&Play dans un jeu de STR requiert dy apporter des modifications
et donc davoir accs au code source. La principale difficult lie cette tche consiste com-
prendre le code du jeu afin de dterminer dans quel module intgrer les modifications. En effet,
les moteurs de jeux de STR dans lesquels lAPI Prog&Play a t intgre sont des applications
complexes de plusieurs dizaines de milliers de lignes de code. Cette complexit confirme la
ncessit dune interface adapte aux comptences et connaissances des tudiants novices en
programmation.
Lintgration du systme Prog&Play dans plusieurs jeux de STR laisse le choix aux en-
seignants du jeu utiliser. En effet, lunivers du jeu et les caractristiques de gameplay peuvent
influencer la mise en place des exercices de programmation et donc tre plus ou moins adapts
au profil de leurs tudiants.
La premire version du systme Prog&Play a t dveloppe sur ORTS. La seconde version,
quant elle, a t intgre Spring et WarZone 2100.
4.3.1 Intgration ORTS

ORTS est un moteur de jeu de STR atypique du point de vue de son architecture rseau
client-serveur. Lintgration de cette version de Prog&Play, base sur lutilisation dune biblio-
thque dynamique, est ralise par la modification du logiciel client. Ces modifications consis-
tent intgrer le CDD ainsi que les composants ncessaires au chargement de la bibliothque
dynamique tels que le Chargeur et l IMJ .
La mise en uvre du Chargeur dans le client dORTS consiste implmenter lalgo-
rithme 1 prsent page 88 avec notamment le passage de l IMJ la bibliothque dynamique
en appelant la fonction IGCU_Start. Dans le contexte dORTS, l IMJ est compose de
deux points dentre. Le premier donne accs ltat du jeu (le gsm ou GameStateModule) et
le second donne accs au contrle des units (le pc ou PlayerCommander). chaque pas de
simulation, le serveur envoie chaque client sa propre vue. De cette manire, la tricherie est im-
possible car les donnes accessibles via le gsm ont t valides par le serveur. Par consquent,
seuls les objets visibles par le joueur sont accessibles via le gsm. Le pc, quant lui, fournit un
ensemble de mthodes utiles au contrle des units, comme dfinir un dplacement, une attaque
ou une construction. noter que le gsm et le pc sont des instances de classes internes ORTS.
98
4.3. Intgration de Prog&Play dans diffrents jeux de STR
Elles donnent un accs complet aux donnes mais restent complexes utiliser, en particulier
pour des dbutants en programmation.
Pour intgrer la seconde version de Prog&Play, le choix du jeu support sest orient vers le
moteur de Spring. La raison de ce changement de moteur est due la richesse et la plus grande
stabilit de Spring par rapport ORTS qui en est un stade plus exprimental.
4.3.2 Intgration Spring

Spring, fort dune communaut active, prsente de nombreux jeux et ressources associes.
Intgrer Prog&Play Spring rend lAPI automatiquement compatible une gamme importante
de jeux de STR et augmente donc par consquent lventail des jeux srieux ralisables.
Spring est bas sur une architecture rpartie de type P2P. Dans cette architecture, la base
de donnes reprsentant le monde virtuel est duplique sur les diffrentes machines. Par con-
squent, chaque partie prenante du jeu accde lensemble des donnes telles que les positions
ou le nombre dunits adverses. Le brouillard de guerre joue alors son rle de filtre pour
cacher les donnes non accessibles au joueur en fonction de la position et du champ de vision
de ces units. Dans Prog&Play, les donnes accessibles via lAPI Client doivent respecter
la visualisation graphique telle quelle est dfinie au moment dun rafrachissement. Lors de
lintgration de la partie Fournisseur de Prog&Play dans le jeu, une attention particulire
doit donc tre porte sur le filtrage des donnes transfres dans la mmoire partage. titre
dexemple, pour dterminer si une unit est accessible via la partie Client de Prog&Play,
elle doit soit appartenir au joueur ou lun de ses allis, soit appartenir un ennemi et tre
visible par le joueur. Lorsquune unit est slectionne pour tre accessible travers linterface
Client , lensemble de ces attributs compatibles avec la structure de donnes de Prog&Play
doit tre extrait et copi dans la mmoire partage (voir la structure PP_SharedUnit de la
figure 4.14 page 95).
La structure PP_SharedData , interne lAPI Prog&Play (voir figure 4.14 page 95), con-
tient une liste de zones spciales (specialArea) prvue pour stocker un ensemble de positions.
Dans Spring, cette liste est utilise pour transfrer les emplacements des sources gothermiques.
Ces dernires sont utilises de deux manires diffrentes par les jeux construits sur Spring. La
majorit utilise les sources gothermiques comme une ressource utilisable par des centrales pour
gnrer de llectricit. Kernel Panic, quant lui, les redfinit comme des sources de donnes
qui reprsentent les emplacements o la construction de structures est possible.
99
LAPI Prog&Play est conue pour tre intgre plusieurs jeux de STR. Cependant, pour
utiliser la partie Client , quelques informations doit tre fourni en complment de la spcifi-
cation du langage de programmation utilis. En effet, les types dunits et les actions ralisables
sont propres chaque jeu de STR. Par consquent, pour interprter le type dune unit ou pour
dfinir une action raliser, un ensemble de constantes doivent tre fournies au joueur en mme
temps que la spcification de la partie Client . titre dexemple dans KP, lordre de dplace-
ment (MOVE) est reprsent par la valeur 10 , lordre de construction dun SOCKET par
la valeur -41 et le type des units BIT et OCTET sont respectivement 4 et 7 . La
dfinition dun ensemble de constantes pour identifier chaque type dunit et chaque action est
un complment indispensable lutilisation de la partie Client de Prog&Play.
Moyennant la gnration dune liste de constantes pour chaque jeu bas sur Spring, lAPI
Prog&Play est compatible avec chacun dentre eux. La seconde version de Prog&Play a gale-
ment t intgre dans un deuxime moteur de jeu de STR : WarZone 2100.
4.3.3 Intgration WarZone 2100

Lintgration de la seconde version de Prog&Play WarZone 2100 poursuit deux objectifs :
montrer que lAPI est compatible avec un produit originairement commercial et augmenter le
nombre de jeux compatibles Prog&Play et en consquence lespace des jeux srieux ralisables.
limage de Spring, WarZone 2100 est bas sur une architecture P2P qui ncessite de porter
une attention particulire aux donnes transfres dans la mmoire partage. Lenjeu tant de
fournir une information exacte afin dviter laccs des donnes caches et donc la tricherie.
Pour WarZone 2100, les zones spciales sont utilises pour stocker la position des puits de
ptroles sur lesquels peuvent tre construit des derricks. Le ptrole est la seule ressource de ce
jeu, elle est ncessaire la construction des btiments et des units et la recherche de nouvelles
technologies.
La particularit de WarZone 2100 porte sur un systme de conception dunits qui permet
au joueur partir dun chssis, dun systme de propulsion et dune tourelle de concevoir les
units adaptes sa stratgie de jeu. Cette fonctionnalit a pour consquence de complexifier la
gnration des constantes ncessaires lutilisation de linterface Client . En effet, avec plus
de 400 technologies diffrentes, le nombre de constantes ncessaires pour caractriser toutes
les units est tel quelles en deviennent inutilisables. En se cantonnant aux units mobiles, les
77 technologies de tourelles combines aux 14 technologies de chssis et aux 5 technologies
100
4.3. Intgration de Prog&Play dans diffrents jeux de STR
de propulsions permettent de raliser 5390 units diffrentes. Pour pallier cette combinatoire
importante et faciliter lutilisation de lAPI, un type dunit reprsente une famille qui regroupe
plusieurs sortes dunits. titre dexemple, les familles Constructeur et Transporteur ,
qui regroupent de nombreux types dunits diffrentes, sont respectivement reprsents par les
valeurs 3 et 6 . En consquence, la conception et la cration dunits dans WarZone 2100
ne peuvent tre pilotes travers lAPI Prog&Play. En revanche, les actions plus classiques
comme un dplacement ou la construction dun btiment sont ralisables. Pour illustration,
lordre de dplacement (MOVE) est reprsent par la valeur 2 et lordre de construction
dune usine de niveau 1 est reprsent par la valeur -851971 .
Cette originalit de WarZone 2100 illustre la limite de lAPI Prog&Play, qui, en raison de
la gnralit des donnes manipules lui permet dtre intgre dans des jeux de STR diffrents
mais ne peut retranscrire les subtilits propres chacun de ces jeux. Toutefois, cette limite
renforce lune des spcifications du jeu srieux : maintenir linteraction classique entre le joueur
et le jeu. De cette manire, au cours de la simulation, le joueur est actif (il joue) pour raliser
les tches non prises en compte par son programme.
Conclusion
Pour illustrer concrtement la portabilit de la deuxime version de lAPI Prog&Play dans

diffrents jeux de STR, le programme en langage C de la figure 4.16 fonctionne sur WarZone
2100 et lensemble des jeux de Spring (XTA, Balanced Annihilation, Star Wars : Imperial Winter
et Kernel Panic entre autres).
Lintgration des deux versions de Prog&Play a donc t ralise dans plusieurs moteurs
de STR, lobjectif tant de tester lutilisabilit du systme dans diffrents contextes de jeu. La
principale difficult rencontre porte sur la comprhension du code des moteurs tudis qui
manquent parfois de documentation dtaille. Cette difficult se trouverait grandement rduite
si lintgration tait ralise par un ou plusieurs dveloppeurs du jeu qui ont une connaissance
et une matrise du code de leur projet bien plus importante que la notre.
Concernant la seconde version, lintgration Spring et WarZone 2100 a montr la n-
cessit de fournir une spcification des constantes utiles pour reprsenter les donnes du jeu.
Lannexe B prsente une implmentation en langage C de lensemble des constantes utiles la
gestion des units de la faction Systme de Kernel Panic.
101
# i n c l u d e " P P _ C l i e n t . h " / i n t e r f a c e " C l i e n t " de l API Prog&P l a y /

# i f d e f SPRING
/ L i s t e des c o n s t a n t e s propres a Spring /
# include " constantsList_Spring . h"
#else
/ L i s t e d e s c o n s t a n t e s p r o p r e s a WarZone 2100 /
# include " constantsList_WZ . h"
# endif
i n t main ( v o i d ) {
int i ;
/ d e f i n i t i o n de l a p o s i t i o n c i b l e /
PP_Pos p ;
p . x = 10.0;
p . y = 10.0;
PP_Open ( ) ; / o u v e r t u r e de l API Prog&P l a y /
P P _ R e f r e s h ( ) ; / Demande d une m i s e a j o u r d e s d o n n e e s /
/ P a r c o u r s de t o u t e s l e s u n i t e s /
f o r ( i = 0 ; i < PP_GetNumUnits ( MY_COALITION ) ; i ++) {
/ Ordonner a l u n i t e c o u r a n t e de s e d e p l a c e r /
P P _ U n i t _ A c t i o n O n P o s i t i o n ( P P _ G e t U n i t A t ( MY_COALITION , i ) , MOVE, p ) ;
}
P P _ C l o s e ( ) ; / F e r m e t u r e de l API Prog&P l a y /
return 0;
}
F IGURE 4.16 Exemple de programme en langage C fonctionnel avec plusieurs jeux de STR
intgrant le systme Prog&Play.
Cet exemple dplace lensemble des units du joueur la position (10, 10).
Les diffrentes versions de Prog&Play et leurs intgrations dans plusieurs moteurs de STR
montrent la possibilit dutiliser ces moteurs comme bases la conception de jeux srieux pour
lapprentissage de la programmation.
4.4 Conception du jeu srieux
ce stade, les jeux de STR associs Prog&Play sont des outils pour pratiquer la program-
mation mais ne constituent pas encore des jeux srieux. En effet, la dernire tape manquante
consiste motiver le joueur pratiquer la programmation dans ce type denvironnement en vue
de lui faire atteindre des objectifs dapprentissage. Une premire tentative de conception de jeu
102
4.4. Conception du jeu srieux
srieux a t ncessaire avant den raliser un suffisamment structur pour tre dploy dans un
contexte rel denseignement.
4.4.1 Premire version de Prog&Play avec ORTS
Cette premire exprimentation a consist dvelopper une application en lien direct avec
un cas denseignement rel. Les tudiants de luniversit Paul Sabatier (Toulouse III) inscrits en
premire anne de licence STS (Science, Technologies, Sant) qui suivent au second semestre
la majeure IMM (Informatique, Mathmatiques, Mcanique) ont dans leur enseignement de
linformatique un mini projet raliser durant les dernires sances de travaux pratiques (TP).
Le sujet de lanne universitaire 2007-2008 portait sur la ralisation en langage C dun rsolveur
de sudoku. Au cours des cinq dernires sances, les tudiants taient guids dans la ralisation
de ce rsolveur. Ils taient, cette occasion, confronts la manipulation des entres/sorties,
des tableaux, des types de donnes, des sous-programmes et des techniques de rsolution.
Lobjectif fix consistait vrifier la possibilit de transposer un exercice de TP dans le
contexte dORTS. ce titre, une carte de jeu spciale a t cre pour reprsenter la grille
du sudoku (voir figure 4.17) ainsi quun ensemble de vaisseaux reprsentant les 81 chiffres
positionnables sur le sudoku (voir figure 4.18).
F IGURE 4.18 Un vaisseau reprsentant

un chiffre positionner sur la grille de su-
doku.
F IGURE 4.17 Grille de sudoku vide dans

ORTS.
103
Pour simplifier la manipulation des vaisseaux une interface de haut niveau est propose. Elle
permet dabstraire la complexit du gsm et du pc et se compose seulement de deux procdures :
void ORTS_initialise_jeux(void) : initialise un ensemble de donnes permettant de grer
le positionnement des vaisseaux et se charge, en outre, de dplacer les vaisseaux lex-
trieur du sudoku sil en reste dans la grille.
void ORTS_positionne_vaisseau(int l, int c, int candidat) : cherche un vaisseau de numro
candidat (inclus dans lintervalle [1; 9]) lextrieur du sudoku et le positionne sur la
case situe sur la ligne numro l (incluse dans lintervalle [0; 8]) et la colonne numro
c (incluse dans lintervalle [0; 8]).
Grce ces deux fonctions, il est possible de positionner les vaisseaux pour reprsenter ltat
initial de la grille de sudoku (voir figure 4.19) et dafficher la solution gnre par le rsolveur
dans le contexte du jeu (voir figure 4.20).
F IGURE 4.19 Vaisseaux positionns confor- F IGURE 4.20 Vaisseaux positionns confor-
mment ltat initial de la grille de sudoku mment la solution de la grille de sudoku
(avant rsolution). (aprs rsolution).
Cette application est donc fonctionnelle, elle illustre la possibilit de projeter des exerci-
ces de programmation rels dans le contexte dORTS. Toutefois, elle ne constitue pas un jeu
srieux de STR au sens strict car la rsolution dun sudoku et le positionnement de vaisseaux
sur une carte na aucun lien avec le principe, les rgles et les buts des jeux de STR. Cet exemple
104
montre toute la difficult de conception dun jeu srieux. Il ne suffit pas dhabiller un prob-
lme quelconque avec un environnement 3D pour prtendre raliser un jeu srieux, car, dans ce
cas, la composante jeu est inexistante et la motivation espre en consquence sen trouve
fortement rduite. Pour cette raison, cette application na pas t teste avec des tudiants en
contexte rel. En effet, lvaluation doit porter sur un jeu srieux o la programmation est une
composante importante du gameplay de manire exploiter les caractristiques des jeux de STR
et bnficier de leur potentiel motivationnel.
4.4.2 Seconde version de Prog&Play avec Spring

Pour raliser la version aboutie, Spring sest avr plus performant quORTS en raison de
la richesse des jeux disponibles sur ce moteur. Le choix sest orient vers le jeu Kernel Panic
en raison des trois caractristiques suivantes :
la simplicit de larbre des technologies et linexistence de la gestion de ressources per-
mettent aux joueurs novices de comprendre et matriser rapidement les rgles et buts du
jeu ;
le jeu appartient au domaine public ce qui permet une utilisation totalement libre et gra-
tuite ;
lunivers informatique du jeu est en lien direct avec le contenu de la discipline enseigner.
Pour profiter de la motivation induite par les jeux de STR, lintgration des objectifs dap-
prentissage doit se mler aux structures de jeu prexistantes. Le mode campagne et le mode
escarmouche sont deux formes de jeu diffrentes exploiter pour la ralisation du jeu srieux.
Le mode campagne
Le mode campagne est structur autour dun scnario divis en missions. Chacune delles
propose au joueur datteindre un objectif afin de passer la suivante et ainsi progresser dans
le scnario. La motivation, dans ce mode de jeu, est maintenue par la volont du joueur dtre
acteur dans la rsolution de lintrigue.
Ce mode de jeu peut tre utilis dans une approche classique de lenseignement bas sur la
confrontation de ltudiant une srie dexercices. Chaque mission pose un problme que ltu-
diant doit rsoudre laide dun programme informatique. Toute la difficult consiste alors
proposer des problmes qui mettent en exergue le savoir enseigner et qui soient lis au scnario
du jeu. Dans le contexte de Kernel Panic et des objectifs dapprentissage centrs sur les fonda-
105
mentaux de la programmation, le scnario de la campagne propose est le suivant : Depuis

un certain nombre dannes, une guerre secrte fait rage au sein mme des ordinateurs. Des
attaques ont rgulirement lieu contre dinnocentes victimes. Aujourdhui cest votre tour. Votre
agresseur a captur le contrleur de votre souris. Vous devez le rcuprer. Votre seule solution :
la programmation . Cette campagne est actuellement divise en sept missions :
Mission 1 : Lors de la prcdente attaque, vous avez perdu de nombreuses units et
celles qui vous restent sont disperses sur la carte. Un seul BIT est encore sous votre con-
trle. Un rapport vous est parvenu vous indiquant quun OCTET se trouverait au point
de ralliement (1983, 1279). Dplacez votre unique entit cette position pour tenter de
retrouver lOCTET perdu. Bon courage commandant. . . . Dans cette mission, le joueur
contrle une seule unit. Il doit simplement la dplacer la position indique dans le
briefing. Pour atteindre cet objectif, le joueur doit raliser un petit programme en mani-
pulant des variables, des types, des affectations, des fonctions et le passage de paramtre.
Lorsque le BIT atteint la position indique, lOCTET recherch ne sy trouve pas. La
deuxime mission est alors propose ;
Mission 2 : Le rapport que vous aviez reu tait correct mais lOCTET ne se trouve
plus au point de ralliement prvu. Des traces vous indiquent quil sest loign dans la
direction 119 par rapport au Nord (sens anti-horaire). La fracheur des indices vous
indique quil nest pas loin. Dplacez votre BIT de 1060 units dans cette direction .
Cette mission reprend les concepts de programmation de la premire mission et ajoute
un calcul trigonomtrique pour dterminer la position atteindre en fonction dun angle
et dune distance parcourir. Elle illustre par ce fait la possibilit dintgrer des calculs
mathmatiques dans le jeu en lien avec le scnario. la fin de cette mission, lorsque le
BIT a atteint la position correctement calcule, lOCTET recherch est dcouvert et la
troisime mission est dbloque.
Mission 3 : LOCTET, qui vient de se rallier vous, vous informe que dautres entits
se sont regroupes non loin de l. Il vous communique les coordonnes de la forma-
tion dOCTETS quil tentait de rejoindre avant votre arrive (479, 1825). Il vous indique
galement quun ensemble de BITS sest rassembl aux coordonnes (1400, 1371). Afin
de rcuprer ces nouvelles forces, ordonnez vos deux entits de rejoindre leurs compa-
triotes respectifs . Dans cette mission le joueur contrle deux units et doit donner un
ordre de dplacement diffrent en fonction de leur type (BIT ou OCTET). Tout naturel-
lement la structure de contrle conditionnelle est introduite pour oprer cette slection.
106
Mission 4 : Toutes les entits que vous possdez ont subi de lourds dommages lors de la
prcdente attaque. Vous devez les rparer avant de lancer la contre-attaque. Le dernier
ASSEMBLEUR encore en marche et capable deffectuer les rparations est en route vers
le point de ralliement aux coordonnes (256, 1024). Dplacez toute votre arme la
rencontre de cet ASSEMBLEUR . Dans cette mission le joueur contrle lensemble des
units rcupres la mission 3 et doit toutes les dplacer vers une position prcise. Une
structure de contrle itrative doit donc tre utilise pour parcourir lensemble des units
et ordonner chacune dentre elles de se dplacer vers le point de ralliement indiqu.
Mission 5 : LASSEMBLEUR vient dapparatre sur la carte, aidez le rejoindre le reste
de votre arme. Dplacez uniquement lASSEMBLEUR aux coordonnes (256, 811) .
Dans cette mission, le joueur contrle un ensemble dunits compos des entits de la
mission 4 et de lASSEMBLEUR. Pour dplacer uniquement ce dernier, le joueur doit
le rechercher parmi la liste des units contrles. Lutilisation de structures de contrle
conditionnelles et itratives est requise pour rsoudre ce problme.
Mission 6 : Votre arme est maintenant regroupe et vous disposez du dernier ASSEM-
BLEUR du secteur encore en marche. Ordonnez-lui de rparer toute votre arme . Pour
raliser cette rparation, limbrication de structures de contrle conditionnelles et itra-
tives est ncessaire. Une difficult supplmentaire est introduite travers lutilisation de
la fonction PP_Refresh qui permet dobtenir les mises jour des donnes du jeu
et ainsi suivre ltat de rparation des units. Lorsque toutes les units sont rpares, la
dernire mission de la campagne est dbloque.
Mission 7 : Votre arme est fin prte retourner au combat. Le contrleur de votre
souris est actuellement aux mains de votre adversaire. Il est temps daller le rcuprer.
Lancez lattaque sur la position (1792, 256). Noubliez pas que lASSEMBLEUR peut
vous tre dune aide prcieuse. . . Bonne chance commandant . Cette dernire mission,
volontairement ouverte, est dsquilibre en faveur de lordinateur. Aucune indication
nest donne sur la dmarche suivre pour remporter la victoire. Simplement, la dernire
phrase du briefing a pour objectif dinciter les tudiants intgrer lASSEMBLEUR dans
leur stratgie. Ils peuvent sen servir pour rtablir lquilibre en rparant les units endom-
mages en cours de combat et en construisant des structures afin de produire des units
supplmentaires.
En rsum, le joueur commence la campagne avec un seul BIT et doit sen servir pour
rcuprer des units disperses sur la carte. Une fois son arme reconstitue et prte au combat,
107
le joueur peut mener une attaque pour rcuprer le contrleur de la souris et recouvrer son
utilisation. Une solution en langage C des six premires missions est propose en annexe C. La
septime tant plus ouverte ne prsente pas de solution type.
Grce ce jeu de missions, le joueur est acteur du droulement de lhistoire et progresse
dans le scnario aprs chaque objectif atteint. Cette dynamique est utilise pour introduire pro-
gressivement dans chaque mission un concept algorithmique ou une difficult supplmentaire
en vue de proposer de nouveaux dfis en lien avec le savoir enseigner. La squence est donc
introduite lors de la premire mission, la structure de contrle conditionnelle lors de la troisime,
la structure de contrle itrative lors de la quatrime et les structures de contrle imbriques lors
de la sixime. La dernire mission, plus ouverte, permet aux tudiants de concevoir et dimpl-
menter une stratgie de jeu laide des comptences acquises lors des six premires missions.
Dans ce scnario une contrainte forte est impose, le contrle du jeu laide de la souris
est dsactiv. La seule mthode dinteraction possible reste donc la programmation. Cette cam-
pagne prsente donc un double objectif : vhiculer les fondamentaux de la programmation et
former les tudiants lutilisation de lAPI pour quils puissent la rutiliser dans un contexte
plus ouvert. Le mode escarmouche peut en tre la suite logique.
Le mode escarmouche
Le mode escarmouche est bas sur un modle de comptition. Le joueur avec ses ventuels
allis doit atteindre un objectif et se confronter un ou plusieurs adversaires. La motivation dans
ce mode de jeu est maintenue par la volont du joueur atteindre une performance suprieure
ses adversaires.
Lexploitation de ce mode de jeu dans lenseignement repose sur lutilisation dune approche
par projet qui consiste laisser les tudiants concevoir et raliser leurs propres IA. Lobjectif
final est de permettre aux tudiants dutiliser leurs productions dans une comptition organise.
Plusieurs modalits de mise en uvre sont alors dfinies notamment vis--vis des projets pro-
poss et de leur encadrement. Concernant les comptitions, deux solutions sont envisageables.
Premire solution : utiliser le mode multijoueur classique de Kernel Panic. Chaque joueur
choisit sa faction Systme , Pirate ou Rseaux et commence la partie avec lunit
matresse associe. partir de celle-ci, le joueur gnre des units et dveloppe sa stratgie.
Dans le contexte de Prog&Play, la seule diffrence consiste autoriser lutilisation de pro-
108
grammes informatiques raliss avec lAPI. Lobjectif, ici, est de faire raliser aux tudiants un
programme utilisable lors de jeux multijoueurs. Ils sont donc amens analyser leur stratgie
de jeu et imaginer les parties qui peuvent tre automatises et dlgues un programme.
Voici quelques exemples dalgorithmes :
espionnage : lobjectif de cet algorithme consiste contrler un groupe dunits charg

dexplorer la carte en vue de surveiller les positions de ladversaire. Connatre les mou-
vements de ladversaire permet danticiper ses actions et dadapter sa stratgie en cons-
quence. Sans la programmation, cette activit est fastidieuse car le joueur doit manuel-
lement dplacer ses espions, tre attentif leurs dcouvertes et grer le renouvellement
du groupe. Le temps pass ces tches ne peut tre consacr aux autres activits de la
stratgie.
miner le terrain : lobjectif de cet algorithme consiste miner des points stratgiques de
la carte de jeu en vue de ralentir lexpansion des adversaires. Bien souvent dans Kernel
Panic le vainqueur est le joueur qui a su prendre rapidement des positions et empcher
ses adversaires de se dvelopper. Comme lespionnage, la gestion dun champ de mines
demande au joueur beaucoup de temps pour reconstruire les mines dtruites et soutenir
les perces ventuelles des adversaires. Lutilisation dun programme qui prend en charge
cette partie peut fournir un avantage consquent au joueur.
rparer les units endommages : cet algorithme est vou tre utilis dans les phases
de combat pour soutenir les units engages. Lobjectif consiste utiliser les capacits
de certaines units (comme lASSEMBLEUR) pour maintenir les units stratgiques en
bonne sant. Lissue dune confrontation entre deux groupes dunits peut basculer en
faveur du plus faible si celui-ci est soutenu par une maintenance efficace. Un joueur qui a
ralis le mode campagne pourra rutiliser le code de la sixime mission et ladapter au
contexte de jeu multijoueur.
repli automatique : limage de lalgorithme prcdent, celui-ci peut tre utile au cours
dune confrontation. Il sattache estimer lissue dun combat en vue de dterminer sil
semble judicieux de le poursuivre. En effet, gnrer de nouvelles units prend du temps, il
convient alors de ne pas en perdre inutilement. Une estimation juste des risques encourus
permet dviter les pertes inutiles et fait donc gagner du temps au joueur concern.
109
Seconde solution : dfinir un cadre plus restreint o toutes les fonctionnalits du jeu ne sont
pas accessibles. Voici trois exemples de comptitions inspires de celles organises autour du
jeu ORTS :
1. exploitation de ressources : cette premire catgorie ne peut mise en uvre avec Ker-
nel Panic car elle est base sur lexploitation des ressources inexistantes dans ce jeu. En
revanche, Balanced Annihilation, un des autres jeux de Spring compatible Prog&Play,
peut tre utilis. Chaque joueur commence la partie avec une unit matresse (le Com-
mander) positionne alatoirement sur la carte. Le monde est peupl dunits neutres et
invincibles qui se dplacent alatoirement sur la carte. Seules les branches de larbre des
technologies associes la gestion des ressources sont actives si bien que les seules
constructions possibles sont les structures de production, de stockage dnergie et de m-
tal ainsi que les units de constructions de ces structures. Lobjectif est de mettre en place
une chane de production dnergie et de mtal la plus productive possible en un temps
imparti.
2. combat stratgique : cette deuxime catgorie est parfaitement applicable Kernel Panic.
Deux joueurs commencent la partie avec cinq SOCKETS chacun et dix OCTETS posi-
tionns autour de chaque SOCKETS. Les SOCKETS du premier joueur sont positionns
alatoirement sur la carte. Ceux du second joueur sont placs de manire symtrique.
Le brouillard de guerre est dsactiv et limage de la premire catgorie, le monde est
peupl dunits neutres et invincibles qui se dplacent alatoirement sur la carte. Lob-
jectif de ce jeu est de dtruire autant de SOCKETS adverses que possible en un temps
imparti.
3. combat petite chelle : cette troisime catgorie se rapproche des batailles de robots
prsentes dans la section 3.2.2 page 69. Deux joueurs commencent la partie avec une
cinquantaine de BITS chacun positionns alatoirement dans les premiers quarts gauche
et droit de la carte. Cette dernire est plane et le brouillard de guerre est dsactiv. Lob-
jectif de ce jeu est de dtruire autant dunits adverses que possible en un temps imparti.
Quelque soit la mise en uvre envisage, lobjectif final est de permettre aux tudiants
dapporter une rponse au problme pos, de la matrialiser sous la forme dun langage infor-
matique, puis de la tester dans un environnement raliste. Reste la charge des enseignants le
choix de dterminer les modalits dencadrement ( distance ou en prsentiel), la mthode de
travail des tudiants (en autonomie, en binmes ou en groupe), etc. Toutefois, dans la mesure
110
o linteraction directe entre le joueur et le jeu est autorise, lvaluation ne doit pas porter sur
le rsultat de la comptition (nombre de victoires et de dfaites) mais bien sur lanalyse du code
ralis. En effet, il est difficile de dterminer dans quelle proportion une victoire est due au
programme ralis ou au simple talent de joueur dun tudiant. La comptition finale est donc
l comme un lment de motivation et non comme un outil dvaluation.
Quelque soit le mode de jeu utilis, la cration de situations de jeu est ncessaire pour reflter
le droulement de la campagne ou le contexte dune comptition. Pour aider la conception de
ces situations de jeu, un squelette de scnarios est propos.
Squelette de scnarios
F IGURE 4.22 Exemple daffordance

dans la mission 1.
Le marqueur Point de ralliement (1983,
1279) aide le joueur comprendre o
F IGURE 4.21 Exemple de briefing (Mission 1)
dplacer le BIT.
Pour permettre aux professeurs dadapter le jeu leurs enseignements, ils doivent pouvoir
crer de nouvelles situations de jeu. titre dexemple, raliser une mission dune campagne
consiste intgrer le texte de briefing dans le jeu (voir figure 4.21), positionner les units du
joueur ainsi que les units allies et ennemies sur la carte, positionner le point de vue, ajouter
de laffordance pour aider la comprhension de la scne (voir figure 4.22) et dfinir les con-
ditions de victoire et de dfaite. lorigine, les premires versions de scnarios taient intgrs
111
directement dans le moteur du jeu. Cette solution rendait leur maintenabilit et leur volutivit
difficile car elle ncessitait une recompilation systmatique du moteur. Pour faciliter la cration
et la maintenance de nouveaux scnarios de jeu, linterprteur Lua de Spring a t utilis.
En effet, Spring dispose dun interprteur Lua permettant aux utilisateurs de structurer des
scripts au sein dune archive charge et excute dynamiquement par le moteur. Tous les jeux
fonctionnant sur Spring sont bass sur cette technologie. Pour permettre aux enseignants de
crer des scnarios adaptes leurs enseignements un squelette darchive leur est propos. Le
squelette contient quelques scripts prdfinis qui grent lexcution du scnario et laffichage
de menus. Pour construire un scnario de jeu, lenseignant doit simplement implmenter les
fonctions suivantes : la fonction Start sert initialiser le scnario courant ; la fonction Show-
Briefing permet de dfinir le contexte de jeu ; la fonction Update est utilise pour dfinir des
vnements au cours de jeu et dterminer les conditions de victoire et de dfaite ; la fonction
Stop doit nettoyer lensemble des donnes alloues pour le scnario courant. Chacune de ces
fonctions sont automatiquement appeles au cours de la simulation. Une campagne est donc une
structuration squentielle de scnarios alors quune comptition est un simple scnario conu
pour tre fonctionnel en mode multijoueur.
Pour implmenter ces fonctions, les enseignants utilisent les interfaces Lua de Spring 50 .
Pour des problmes de scurit, Spring possde trois contextes dexcution : le LuaUI ,
le LuaRules (unsynced) et le LuaRules (synced) . En fonction du contexte, certaines
interfaces ne sont pas actives. Le code des scnarios tant excut dans le contexte LuaRules
(unsynced) , seules les interfaces compatibles dans ce contexte sont utilisables 51 .
Ce squelette a initialement t ralis comme base la conception de campagnes. Toutefois,
Il peut tre utilis pour prparer les comptitions du mode escarmouche. Dans tout les cas,
lobjectif est de simplifier la conception de campagnes et de comptitions pour permettre aux
enseignants de construire de nouvelles ressources pdagogiques adaptes leurs tudiants.
50. Interfaces Lua de Spring : http://springrts.com/wiki/Lua_Scripting.

51. Validit des interfaces Lua de Spring en fonction du contexte dexcution : http://springrts.com/
wiki/Category:Lua.
112
4.5. Portage de la partie Client de Prog&Play vers diffrents langages de programmation
Conclusion
Le jeu srieux, valu dans le chapitre suivant, est donc une combinaison des trois entits
suivantes : Spring, Prog&Play et un mode de jeu (campagne ou escarmouche) (voir figure 4.23).
Outil de
programmation
Spring Prog&Play
Jeu Srieux
Jeu Exercice
Campagne
Escarmouche
F IGURE 4.23 Composition du jeu srieux.
Ce jeu srieux est donc bas sur la seconde version de Prog&Play. Lintgration de lAPI
dans les moteurs Spring et WarZone 2100 illustre la compatibilit de cette version avec plusieurs
jeux de STR. Pour valider la portabilit totale de lAPI, il reste tudier le portage de la partie
Client de Prog&Play vers diffrents langages de programmation. Linterface bas niveau de
la partie Client est disponible en langage C. Par consquent, tout langage capable de charger
une bibliothque C peut utiliser le systme Prog&Play. Actuellement, des interfaces pour les
langages C, C++, Java, Ada, OCaml, Scratch et Compalgo ont t dveloppes.
4.5 Portage de la partie Client de Prog&Play vers dif-

frents langages de programmation
Conformment la prsentation de linformatique en tant que discipline scientifique, larchi-
tecture des enseignements introductifs (voir section 3.1.2) peut tre structure en six approches
diffrentes : imprative, oriente objet, fonctionnelle, tendue, algorithmique et matrielle. Les
langages de programmation utiliss dans ces approches peuvent tre impratifs, orients objet
ou fonctionnels. Pour montrer la portabilit de Prog&Play dans les diffrentes mthodologies
denseignements, cette section prsente linterfaage de lAPI Prog&Play avec quelques lan-
gages de programmation compatibles avec les diffrentes approches.
113
4.5.1 Prog&Play en C/C++

LAPI Prog&Play, telle quelle a t prsente en dtail dans la section 4.2.2, est disponible
travers la librairie pp-client dont lutilisation est possible grce aux interfaces PP_Client.h
et PP_Error.h (voir figure 4.24, le dtail de ces interfaces est disponible en annexe A). Dans
une approche imprative, il est possible dutiliser directement cette interface pour interagir avec
le jeu vido.
pp-client
PP_Client.h PP_Error.h
utilise
ProgrammeEtudiant.c
F IGURE 4.24 Graphe de dpendance de Prog&Play pour programmer en C.
Les liens troits entre le C et le C++ rendent dautre part lutilisation de lAPI possible
dans un contexte orient objet (OO). Le diagramme de classe de la figure 4.25 prsente une
proposition de lAPI sous une forme OO. La classe PP (Prog&Play) fournit les mthodes
ncessaires pour accder lensemble des donnes du jeu comme la position de dpart, le niveau
des ressources disponibles ou lensemble des units propres une coalition.
114
PP_Command
+getOrder(): Integer Unit
0..* +commandQueue +getId(): Integer

+getType(): Integer
+getHealth(): Float
+getMaxhealth(): Float
+getGroup(): Integer
+setgroup(g: Integer)
+removeFromGroup()
+command(action: Integer, param: Float)
+coalition 1 +command(action: Integer, PP_Pos: position)
+command(action: Integer, Unit: target)
<<enumeration>>
PP_Coalition +unit 0..*
+MY_COALITION
+ALLY_COALITION <<enumeration>>+coalition : PP_Coalition
+ENEMY_COALITION PP
+open()
+refresh()
1 +mapSize +close()
+isGameOver(): Boolean
PP_Pos
+pos 0..*
+resource 0..*
+getX(): Float
1 +specialArea
+getY(): Float PP_Ressources
1 +startPos +getLevel(): Integer
F IGURE 4.25 Proposition dune reprsentation de lAPI Prog&Play sous une forme oriente
objet.
115
4.5.2 Prog&Play en Java

Le langage de programmation Java est, limage du C, un langage utilis dans de nom-
breuses formations pour aborder les concepts orients objets. Le langage Java fournit un mca-
nisme (le JNI - Java Native Interface) pour appeler depuis la JVM (Java Virtual Machine) des
bibliothques ralises en langage C. La figure 4.26 prsente le graphe de dpendance entre les
diffrentes interfaces. La librairie pp_java grce JNI adapte les fonctions et types mani-
puls par la librairie native C ( pp-client ) en fonctions et types de donnes exploitables en
Java. Les fichiers Unit.java et PP.java implmentent respectivement les classes Unit
et PP proposes dans la figure 4.25 et accdent aux donnes du jeu via la classe implmente
dans le fichier PP_Native.java . titre dexemple, une position est reprsente en C par une
structure compose de deux rels x et y. Le transfert de cette structure en Java seffectue par
lintermdiaire dun tableau de rels qui est son tour recompact sous la forme dune instance
de classe reprsentant une position.
pp-client
utilise
pp_java
PP_Native.java
importe
Unit.java PP.java
F IGURE 4.26 Graphe de dpendances de Prog&Play pour programmer en Java.
4.5.3 Prog&Play en Compalgo

Compalgo tel quil a t dfini dans la section 3.2.2 est un environnement de program-
mation conu des fins dinitiation la programmation pour les tudiants de premire anne
de DUT Informatique. Cet environnement de programmation ainsi que son interprte associ
sont raliss en Java. Lintgration de Prog&Play dans Compalgo a donc pu tre produite
116
laide de la librairie pp_java (voir figure 4.27). Lextension de linterprte a consist ren-
dre exploitable en Compalgo les types et fonctions accessibles via la classe PP_Native .
titre dexemple, un objet tel quune position ne peut tre transfr directement linterprte
Compalgo et doit tre dcompos en valeurs de type de base pour tre ensuite reconstruit sous
la forme dun enregistrement. Des modifications supplmentaires ont port sur la gestion du
passage des paramtres (entre, sortie et mise jour) et lajout de fonctions non incluses dans
la bibliothque du langage mais utiles pour la ralisation dIA (tirer un nombre alatoire et
effectuer une pause).
pp-client pp.spec
PP_Client.h PP_Error.h Spcification
en Compalgo
de l'extension
lie Prog&Play inclue
utilise
pp_java Interprteur
PP_Native.java Compalgo jeu.algo
utilise
implmente
inclue
ProgrammeEtudiant.algo jeu.spec
F IGURE 4.27 Graphe de dpendances de Prog&Play pour programmer en Compalgo.
Le fichier pp.spec est la spcification bas niveau en Compalgo de lextension incluse

dans linterprte. Dans cette spcification, les donnes sont dcomposes en valeurs de type
de base. Une interface de plus haut niveau ( jeu.spec ) est donc propose aux tudiants et
prsente les donnes de manire plus naturelle.
4.5.4 Prog&Play en OCaml

OCaml (Objective Caml) est un langage fonctionnel qui offre des possibilits de program-
mation imprative, OO et modulaire. Ce langage est caractris par un typage statique fort et
infr cest--dire que le type dune fonction est dtermin automatiquement suivant lutilisa-
tion de ces paramtres. Le filtrage par motif est une autre spcificit qui permet aux program-
meurs de manipuler aisment des structures de donnes complexes. Enfin, en tant que langage
fonctionnel, il gre la rcursion terminale et permet lutilisation de fonctions dordre suprieur
117
et de fermetures. La rcursion terminale est un cas particulier de la rcursivit qui permet de ne

pas stocker la pile dexcution et donc dconomiser de lespace mmoire. Les fonctions dor-
dre suprieur sont des fonctions qui acceptent en entre une ou plusieurs fonctions et/ou qui en
renvoient une. Les fermetures sont des fonctions dclares lintrieur dune autre fonction et
qui font rfrence aux variables locales ou aux paramtres de la fonction dans laquelle elles sont
dfinies. Le langage OCaml est donc un langage utilisable dans des approches fonctionnelles
de lapprentissage de la programmation.
Le langage OCaml est distribu avec une suite de logiciels dont un interprte interactif, un
compilateur, un dbogueur et une bibliothque standard, entre autres. Il est galement fourni
avec une interface de compatibilit qui permet de lier du code OCaml des primitives en
C. Cette fonctionnalit a t utilise pour connecter la librairie pp-client au module PP
reprsent par la librairie pp_ocaml et le fichier dinterface pp.ml (voir figure 4.28). Ce
module sattache grer les erreurs et rendre les donnes et fonctions manipulables dans
un contexte fonctionnel. titre dexemple, plutt que dtre accessibles une une, les units
dune coalition sont fournies sous la forme dune liste exploitable de manire rcursive. Dautre
part, les fonctions de gestion de lAPI telles que les fonctions C int PP_Open(void) et
int PP_Refresh(void) (voir dtail en annexe A.2) ont une utilisation purement squen-
tielle. Elles sont donc inexistantes dans linterface OCaml et sont gres en interne dans la
bibliothque pp_ocaml . Ainsi, la programmation du jeu peut tre ralise dune manire
purement fonctionnelle.
pp-client
utilise
pp_ocaml
pp.a l
importe
ProgrammeEtudiant.ml
F IGURE 4.28 Graphe de dpendances de Prog&Play pour programmer en OCaml.
118
4.5.5 Prog&Play en Ada

Ada est un langage conu dans le dbut des annes 1980 pour le dpartement de la Dfense
des tats-Unis. En raison dun typage fort et de la structuration du code autour des paquetages,
ce langage est souvent utilis pour lenseignement de la programmation car il aide les dbutants
en informatique acqurir de solides bases en programmation. Dans un contexte dinitiation
linformatique, Ada peut tre employ dans une approche imprative ou en tant que langage
dillustration dans une approche algorithmique.
pp-client
PP_Client.h
utilise
adaDevice
utilise
implmente
pp.adb pp.ads
importe
ProgrammeEtudiant.adb
F IGURE 4.29 Graphe de dpendances de Prog&Play pour programmer en Ada.
Ada permet en outre dutiliser des composants crits dans dautres langages tel que le C
grce au paquetage Interfaces.C qui dfinit des types compatibles. La figure 4.29 illus-
tre la connexion directe qui peut stablir entre du code Ada ( pp.ads ) et des fonctions C
implmentes dans la librairie ( pp-client ). Le module adaDevice permet de rsoudre une
subtilit lie lappel de la fonction C PP_Unit_ActionOnPosition . Cette dernire
prend comme troisime paramtre une position dfinie comme tant une structure compose des
champs x et y. Or le passage des structures de Ada C se fait par adresse, il a donc fallu crer
une couche supplmentaire ( adaDevice ) adapte ce type de passage qui fait linterface vers
la fonction C cible.
4.5.6 Prog&Play en Scratch

Scratch est crit laide de Squeak, une implmentation libre du langage Smalltalk-80.
Squeak se prsente comme un environnement de programmation dynamique et fournit la possi-
bilit de charger des primitives externes crites en C. Le module ProgAndPlayPlugin (voir
119
figure 4.30) redfinit lensemble des fonctions de la librairie pp-client pour quelles soient
exploitables par Squeak.
pp-client
utilise
ProgAndPlayPlugin
utilise
Scratch
utilise
ProgrammeEtudiant.sb
F IGURE 4.30 Graphe de dpendances de Prog&Play pour programmer en Scratch.
Outre cette redfinition, linterface graphique de Scratch a t modifie pour y intgrer une
nouvelle catgorie de blocs nomme Progandplay . Cette dernire, identifiable par sa couleur
rouge, donne accs aux briques ddies la manipulation de lAPI Prog&Play (voir figure 4.31).
Dans Scratch, les blocs dits rapporteurs ne peuvent retourner que des types de base tels
quun nombre, une chane de caractres ou un boolen. Par consquent, et titre dexemple, la
fonction C qui retourne la position de dpart du joueur sur la carte est accessible dans Scratch
travers deux briques distinctes. Elles rapportent respectivement les valeurs x et y de la position
de dpart :
En-tte de la fonction C : PP_Pos PP_GetStartPosition(void);

Briques Scratch correspondantes : et .
Scratch tel quil a t dfini dans la section 3.2.2 est un environnement de programmation
utilisable par des enfants pour crer leurs propres histoires animes, jeux vido ou crations
interactives. Toutes les nouvelles briques introduites avec la catgorie Progandplay sont
bien sr combinables avec les autres blocs du langage de faon respecter les applications
initiales de Scratch.
120
F IGURE 4.31 Interface de Scratch modifie pour utiliser Prog&Play.

Le programme en Scratch prsent dans cette image dplace lensemble des units du joueur la
position (10, 10).
Conclusion
La portage de la partie Client de Prog&Play vers diffrents paradigmes de program-
mation ouvre le jeu lensemble des approches pdagogiques de lenseignement des fonda-
mentaux de la programmation. LAPI, telle quelle a t prsente dans la section 4.2.2, est
donc compatible avec des langages impratifs, fonctionnels et OO quils soient interprts ou
compils.
Ces interfaces sont des illustrations du champ des possibles. Ces langages sont issus pour la
plupart des formations dans lesquelles des exprimentations ont t menes, en particulier pour
le C, Java, Compalgo et OCaml. Les interfaces dveloppes en Ada et Scratch semblent tre
particulirement intressantes pour lapprentissage de la programmation. En particulier linter-
faage de Prog&Play avec Scratch ouvre des pistes de recherche intressantes sur lvaluation
de la combinaison de ces deux technologies. Selon la dmarche expose, il est possible soit
121
de concevoir dautres interfaces adaptes de nouveaux langages de programmation, soit plus

simplement dadapter les interfaces existantes des contextes denseignements particuliers.
Lintgration de la partie Fournisseur de Prog&Play dans diffrents jeux de STR permet
daugmenter la diversit des jeux srieux ralisables. Pour tre utilisable, chaque jeu doit fournir
un ensemble de constantes pour identifier chaque type dunit et chaque action ralisable dans
le jeu. Ces spcifications doivent alors tre implmentes dans les langages de programmation
des diffrents portages de linterface Client . De cette manire, chaque jeu maintiendra son
interoprabilit avec lensemble des langages compatibles avec Prog&Play.
La conception dun jeu srieux sur les fondamentaux de la programmation a donc t ralis
grce Kernel Panic et lintgration de Prog&Play dans Spring. Les diffrentes interfaces de
lAPI, disponibles dans diffrents langage, permettent alors dutiliser le jeu dans lensemble des
approches pdagogiques et aide la recherche de contextes dexprimentation.
122
5
valuation
Le jeu tant oprationnel, il reste valuer son efficacit et sa pertinence en contexte densei-
gnement. Ce processus tant une tche complexe, il convient de construire un modle dva-
luation afin de pouvoir mener diffrentes exprimentations dans divers contextes. Chaque va-
luation participe lamlioration de loutil.
Introduction
Lingnierie didactique de Cobb et al. [CCD+ 03] sert de support lvaluation du jeu
srieux. Cette mthodologie vise exprimenter de nouvelles formes dapprentissages travers
la mise en uvre de moyens spcifiques. Dans cette approche, le chercheur tente de valider une
thorie humble concernant les processus dapprentissage et envisage deffectuer une srie
dexprimentations pour la tester. Pour chaque itration, le principe consiste construire, en
collaboration avec les protagonistes, une ingnierie didactique, la mettre en uvre au cours
dune ou plusieurs exprimentations en procdant de multiples observations puis analyser
les rsultats afin de proposer une ventuelle nouvelle ingnierie didactique destine tester
de nouveaux lments concernant la thorie. Chaque itration permet de faire varier diffrents
paramtres supports par la thorie. Lobjectif nest pas de construire une ingnierie didactique
idale mais bien de valider une thorie concernant lapprentissage.
Dans le cas prsent, il sagit de valider lhypothse selon laquelle lapprentissage de la
programmation au travers dun jeu srieux contribue motiver les tudiants et les encourage
poursuivre leur formation en informatique. Lide transmettre serait que lactivit de program-
123
Chapitre 5. valuation
mation peut tre agrable en soi et que son existence nest pas circonscrite au cadre strictement
scolaire de la ralisation dexercices.
Lapplication de cette mthodologie lvaluation du jeu srieux conduit ainsi envisager
plusieurs itrations. Chaque itration correspond un contexte diffrent dexprimentation de
loutil associ une ingnierie didactique spcifique mettant en uvre une exploration particu-
lire de la thorie valider. De plus, chaque itration, un ensemble de critres dvaluation
doit tre envisag pour mesurer les effets de loutil en regard des objectifs fixs.
5.1 Premire exprimentation

Cette premire exprimentation a pour objectif dobserver le comportement des tudiants
vis--vis du jeu srieux afin de dterminer sil possde rellement un potentiel motivationnel.
Pour raliser la premire itration nous avons choisi un environnement connu nous permettant
dapprcier limpact de lutilisation du jeu srieux sous couvert de notre propre pratique en-
seignante. Ainsi cette premire exprimentation a t ralise dans le cadre dun cours dalgo-
rithmique ordinaire dlivr dans un contexte familier.
5.1.1 Contexte de lexprimentation

Lexprience a eu lieu avec des tudiants de premire anne en informatique de lIUT A
de Toulouse. Sur une promotion de cent quatre-vingt seize tudiants, quinze tudiants parmi
quarante volontaires ont t slectionns. La slection sest effectue partir dun questionnaire
destin valuer leur motivation pour jouer aux jeux vido et pour apprendre la programmation.
Ce questionnaire est bas sur les buts de Viau [Via97] ; le modle de valeur et de succs des
aspirations de Bandura [Ban97] ; et le modle causal de Pintrich et Schunk [PS96]. Chaque
modle suggre des indicateurs spcifiques que nous avons adapts la motivation des tudiants
pour pratiquer la programmation et les jeux vido. Nous nous sommes inspirs du questionnaire
motivated strategies for learning [PMB93].
Ces tudiants sont novices en programmation. Au dbut de lexprimentation, ils connais-
sent un seul langage de programmation : le Compalgo. Durant cinq sances dune heure trente
minutes, les tudiants ont ainsi utilis lAPI Prog&Play avec le langage Compalgo dans un
environnement Windows. Lors de la ralisation de cette exprimentation, la campagne du jeu
srieux ntait compose que de cinq missions savoir les missions 1, 3, 4, 6 et 7 prsentes
124
5.1. Premire exprimentation
page 106. Les briefings taient alors lgrement diffrents de manire prsenter un scnario
cohrent.
Conformment au programme pdagogique national du DUT Informatique [Min05], les
enseignements du tronc commun de la formation initiale en quatre semestres sont structurs
en deux groupes. Le premier est constitu par le champ disciplinaire Informatique (not
Info). Le second apporte les Connaissances et Comptences Gnrales (not CCG). Lors
des deux premiers semestres, ces deux groupes sont composs de trois units denseignements
chacun. L Informatique regroupe lAP (Algorithmique et Programmation), lASR (Archi-
tecture, Systmes et Rseaux) et lOMGL (Outils et Modles du Gnie Logiciel). le CCG re-
groupe : les mathmatiques ; lconomie et gestion des organisation ; les langues, lexpression
et la communication. Lexprimentation a t conduite dans le cadre des enseignements dAP
au dbut du second semestre.
La dfinition dune ingnierie didactique et de critres dvaluation constitue un pralable
pour valuer cette premire confrontation du jeu srieux avec des tudiants en contexte rel.
5.1.2 Conception du protocole dvaluation

Lingnierie didactique, conue pour cette premire itration, a t divise en deux phases
(voir tableau 5.1) : la premire consiste laisser les tudiants jouer Kernel Panic sans utiliser
la programmation afin quils puissent dcouvrir lunivers du jeu, les units et leurs caractris-
tiques. La deuxime phase concerne lactivit de programmation proprement dite : aprs une
prsentation de lAPI Prog&Play, les tudiants sattachent rsoudre les cinq missions en ral-
isant de petits programmes. Pour chaque mission, lenseignant prsente les objectifs de jeu et
aide les tudiants concevoir une solution algorithmique du problme. Aprs avoir conu un
programme rsolvant la mission courante, ltape dinstitutionnalisation permet de rcapituler
lensemble des concepts abords lors de la mission. Aprs ces deux premires phases, les tu-
diants sont thoriquement capables de raliser de courts programmes compatibles avec le jeu
Kernel Panic.
Eu gard aux objectifs de cette exprimentation, trois critres dvaluation ont t dfinis :
lapprentissage de la programmation ; lamusement ; et lutilisabilit du systme. Les deux
premiers critres valuent le concept de jeu srieux sous langle de lapprentissage de la
programmation et du divertissement procur par le jeu. Le dernier critre permet didentifier les
composants du jeu qui peuvent perturber les tudiants.
125
TABLE 5.1 Organisation des enseignements.
Phase 1 Phase 2
Prsentation de lAPI Prog&Play et ralisation des cinq
missions de la campagne
Prsentation du jeu initial et
Pour chaque mission
jeu en rseau
(1) Prsentation des objectifs
(2) Les tudiants programment leur(s) solution(s)
(3) Institutionnalisation
Les paramtres de lvaluation ont t fixs a priori, en dfinissant les critres et les indi-
cateurs de lvaluation avant lexprimentation (approche ex ante ). Leur organisation tem-
porelle lors de lexprimentation est prsente dans la figure 5.1. Par souci de lisibilit, le dtail
des indicateurs est prsent au fur et mesure de leur analyse lors de cette premire itration.
Resultats aux examens du second semestre

Analyse des travaux des
Resultats aux tudiants :
examens du - qualit des programmes
premier semestre - progression dans le jeu
- nombre de compilations
et d'excutions requises
TEMPS
Dbut de Fin de
l'exprimentation l'exprimentation
Evaluation des Questionnaire post
prrequis exprimental sur :
- l'utilisabilit
- l'amusement
F IGURE 5.1 Organisation temporelle de lvaluation pour la premire exprimentation.
126
5.1.3 Rsultats
valuation des prrequis
Le premier indicateur prsent concerne lvaluation des prrequis. Il nest pas li direc-
tement lun des trois critres dvaluation, mais a pour but de dterminer le profil des tudiants.
Cette valuation a t construite partir des travaux de Ginat et al. [Gin04] sur la boucle algo-
rithmique. Les tudiants rpondent huit questions progressives, sur papier en une vingtaine de
minutes et sans documentation. Ce test est propos aprs la phase de jeu et son valuation nest
pas prise en compte pour la validation du semestre.
Les solutions des tudiants ont t analyses daprs les critres de Smith et Cordova [SC05]
en portant une attention particulire sur les solutions produites et les sorties attendues. Les
identifiants doivent tre explicites et suivre les conventions de nommage et les programmes
construits doivent tre simples et lgants. Enfin, une attention est porte lindentation, aux
commentaires et la lisibilit du code.
Afin dvaluer la pertinence de ce test, les rsultats des tudiants cet exercice sont com-
pars leur rsultat de lexamen d algorithmique et programmation du premier semestre.
Cette comparaison est visualise dans la figure 5.2 et met en vidence pour chacun des quinze
tudiants, leurs notes (entre 0 et 20) lexamen dalgorithmique et cette valuation des prreq-
uis. A lexception des tudiants 6 et 14, lvaluation semble reflter leur niveau de russite
(lerreur moyenne est de 2,06 points).
20
16
Note d'un tudiant
12
l'examen
Note
8 d'algorithmique
Note d'un tudiant
4 l'valuation
propose
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Etudiant
F IGURE 5.2 Comparaison des rsultats des tudiants notre valuation et lexamen dalgo-
rithmique.
127
Critre 1 : Apprentissage de la programmation
Lvaluation de lapprentissage est base sur les travaux de Chen et Cheng [CC07], Gest-
wicki et Sun [GS08] et Leutenegger et Edgington [LE07]. Ces travaux ont permis de dfinir
trois indicateurs : lacquisition de connaissances, la qualit des programmes et la quantit de
travail fourni.
Acquisition de connaissances : pour valuer limpact du jeu sur lapprentissage des tu-
diants, la variation des rsultats des tudiants entre les examens du premier et du second semestre
est compare entre ceux qui ont utilis le jeu srieux et ceux qui ne lont pas utilis. Ces exam-
ens sont conus par des enseignants externes au projet.
En raison du faible chantillon dtudiants dans cette premire exprimentation, une com-
paraison statistique des deux populations est non valable. Toutefois, il est apparu que les tu-
diants ayant particip cet atelier dont le niveau en algorithmique tait faible, ont plutt amlior
leurs rsultats au second semestre (voir tableau 5.2).
TABLE 5.2 volution moyenne des notes entre les examens du premier et du second semestre
pour les tudiants qui ont particip latelier et dont le niveau algorithmique tait faible au
premier semestre (note dAP au S1 < 10).
AP Info CCG
volution moyenne + 1,77 + 1,62 + 0,24
Qualit des programmes : la qualit des programmes est value daprs les critres de
Smith et Cordova [SC05]. Parmi lensemble des critres dfinis par ces auteurs, les critres
suivants sont retenus pour cette premire itration centre sur les fondamentaux de la program-
mation : lexactitude des programmes, le style de programmation et la documentation des pro-
grammes et de leur conception.
Pour cette exprimentation, lindicateur na pas fourni de donnes pertinentes. En effet,
le niveau dbutant des tudiants valus, les problmes relativement ferms des missions pro-
poses et le mode dencadrement des sances ont contribu homogniser les solutions rcu-
pres.
Quantit de travail fourni : la quantit de travail ralis est value en fonction de la progres-
sion des tudiants dans le jeu (nombre de missions termines) et pour chaque mission, du nom-
128
bre de compilations et dexcutions ncessaires lobtention dune solution fonctionnelle. Ces

donnes ont pu tre rcupres aprs avoir intgr un espion lenvironnement de dvelop-
pement utilis lors des sances denseignement. Grce ces donnes, nous pouvons dfinir, pour
chaque mission m , un indice de difficult (not dm ) prsent dans la figure 5.3. Cet indice
de difficult est calcul comme indiqu dans lquation 5.1, o nbEtudiantsm est le nombre
dtudiants ayant termin la mission m et nbCompilationsim et nbExecutionsim
sont respectivement le nombre de compilations et dexcutions requises par le ime tudiant pour
complter la mission m .
PnbEtudiantsm
nbCompilationsim + nbExecutionsim
dm = i=1
(5.1)
nbEtudiantsm
25
20
15 Indice de
difficult
10 Nombre
d'tudiants qui
5 ont termin une
mission
0
M M M M M
iss iss iss iss iss
ion ion ion ion ion
1 2 3 4 5
F IGURE 5.3 Indice de difficult pour chaque mission.
Contrairement aux attentes, la difficult des missions nest pas rgulire. Un cart important
existe entre la troisime et la quatrime mission. Par consquent, quelques tudiants se sont
retrouvs bloqus et nont pu terminer la campagne. Du point de vue du jeu, les dernires mis-
sions doivent prsenter un niveau de difficult suprieur aux prcdentes de manire proposer
un dfi au joueur. Mais cette difficult doit tre progressive.
La baisse de lindice de difficult entre les missions 1 et 3 montre lappropriation progressive
de lAPI par les tudiants et leur capacit la combiner avec des structures de contrle simples.
129
Critre 2 : Amusement
Ce critre a t valu au travers dun questionnaire soumis aux tudiants lissue de lex-
prience. Les questions sont prsentes figure 5.4.
Q1 : Avez-vous apprci le scnario de la campagne (les missions) ? (1 = Pas du tout , 7 =

Beaucoup )
Q2 : Pensez-vous que lutilisation de la programmation dans Kernel Panic augmente le diver-
tissement ?
Rduit le divertissement Ne change rien
Augmente le divertissement Je ne sais pas
F IGURE 5.4 Extrait du questionnaire post exprimental en rapport avec lamusement.
La rponse moyenne pour la premire question (Q1, figure 5.4) est de 5,85 et montre que
les tudiants ont apprci la campagne. Dune manire informelle, nous pensons que lintrt
port aux missions est en partie d la premire phase de lexprimentation. En effet, la session
de jeu en rseau a permis aux tudiants de sapproprier lunivers du jeu et a rendu limmersion
des tudiants dans le scnario plus facile.
La seconde question (Q2, figure 5.4) est cruciale. Introduire des concepts algorithmiques
dans le jeu ne doit pas en rduire le divertissement. Cette condition est due la dfinition des
jeux srieux qui doivent tre avant tout divertissants. Or, 100% des tudiants ont trouv que
lutilisation de la programmation dans le jeu augmentait le divertissement.
Critre 3 : Utilisabilit du systme
Lintgration de lAPI Prog&Play dans Spring est fonctionnelle car aucun bogue critique
na t rvl durant lexprience. Reste tudier limpact du jeu sur le degr de satisfaction
des tudiants aprs lavoir utilis. Pour ce faire, la hirarchie des besoins du joueur de Siang et
Rao [SR03] prsente dans la section 1.2.2 a t analyse dans le contexte du jeu srieux. La
figure 5.5 montre la satisfaction des tudiants pour chaque niveau de la pyramide pour notre jeu
srieux.
La plus faible satisfaction concerne le besoin desthtique (6) avec une satisfaction moyenne
de 47%. Le graphisme vectoriel de Kernel Panic semble tre moyennement apprci par les
tudiants. Nanmoins, ce STR simplifi permet un apprentissage rapide et constitue un avantage
130
(7) Auto accomplissement
(6) Esthtique
(5) Connatre et comprendre
(4) Estime
Valeur moyenne
(3) Appartenance
(2) Sret
(1) Rgles
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%100%
Pourcentage de satisfaction
F IGURE 5.5 Satisfaction moyenne des tudiants pour chaque niveau de la pyramide des be-
soins (IUT A dpartement informatique Toulouse III).
pour les bas niveaux de la pyramide. Le choix de Kernel Panic comme base au jeu srieux est
donc valid.
Actuellement, les informations daide propos de la programmation, le contenu dappren-

tissage et lutilisabilit du jeu ne sont pas incluses dans le jeu et doivent tre ajoutes par len-
seignant. Le second niveau (besoin de sret) est donc rsolu, en grande partie, par lencadrant.
Synthse de la premire exprimentation
Cette exprimentation a permis de vrifier que le jeu est amusant et motivant : amusant
car tous les tudiants ont trouv que lutilisation de la programmation dans le jeu augmente le
divertissement ; et motivant car mme si une session de jeu en rseau tait initialement prvue
lors de la dernire sance, plus de la moiti des tudiants ont prfr continuer programmer
plutt que de jouer. En conclusion, cette premire itration a permis de valider le jeu srieux
tant sur son utilisabilit que sur son potentiel ludique.
131
5.2 Deuxime exprimentation

Cette deuxime exprimentation a pour objectif de mettre en application le jeu dans un
contexte denseignement diffrent de manire vrifier sa portabilit. Une attention particulire
est porte lobservation de lenseignant de manire dterminer limpact de lintroduction du
jeu dans ses activits.

Cette exprimentation a t ralise dans le cadre dun soutien pour les tudiants de luni-
versit Paul Sabatier (Toulouse III) inscrits en premire anne de licence STS (Science, Techno-
logies, Sant) qui suivent au second semestre la majeure IMM (Informatique, Mathmatiques,
Mcanique). Ce soutien tait organis de la manire suivante : toutes les deux sances de travaux
dirigs (TD), une valuation (sous la forme de QCM) est distribue aux tudiants pour jauger
la progression de leur apprentissage par rapport lvaluation prcdente. Les tudiants qui
natteignent pas la moyenne, sont invits participer au soutien. Les valuations proposes sont
gres par lquipe pdagogique de la formation et nont aucun lien avec le jeu srieux.
Le soutien ntant pas obligatoire, peu dtudiants font la dmarche de venir aux sances.
Dans ce cadre, deux types de soutien leur ont t proposs : un premier classique et un second
avec le jeu srieux.
Pour respecter le contexte denseignement utilis au second semestre de cette formation, les
tudiants manipulent le jeu dans un environnement Linux (Mandriva 2008) laide de linter-
face en langage C et de lditeur de texte Kate . limage de la premire exprimentation,
la campagne nest compos que de cinq missions savoir les missions 1, 3, 4, 6 et 7 prsentes
page 106.
5.2.2 Intgration du jeu srieux dans la formation

Dans cette exprimentation, le jeu est intgr la formation et doit donc sadapter au calen-
drier des enseignements prsents dans le tableau 5.3. Le premier TP a pour objectif de familia-
riser les tudiants avec le contenu dun ordinateur en leur permettant de dmonter entirement
une unit centrale (processeur, carte mre, disque dur, mmoire vive, etc.).
Le deuxime TP se concentre sur le systme Linux avec la prsentation des commandes
basiques du shell. La premire sance de soutien prend effet cet instant alors que les tu-
132
5.2. Deuxime exprimentation
TABLE 5.3 Calendrier des enseignements du L1S2 de lUniversit Paul Sabatier.
Semaine TD QCM TP Soutien

...
TD1 (Langage algorith-
3
mique)
4 TD2 (Tableaux de situations) QCM1 TP1 (Architecture)
TP2 (Environnement multi-
5 TD3 (Introduction au C) S1
fentre et shell Linux)
TP3 (Environnement dex-
TD4 (Raffinage et sous-
6 QCM2 cution, compilation et struc- S2
programmes)
tures de contrle)
TD5 (Sous-programmes et TP4 (Tableaux de situation et
7 S3
tableaux) dbogage)
TD6 (Sous-programmes et TP5 (sous-programmes,
8 QCM3 S4
types simples) tableaux et dbogage)
TD7 (Sous-programmes,
9 TP6 (Projet) S5
types complexes et raffinage)
TD8 (Dveloppement dun
10 QCM4 TP7 (Projet) S6
cas complexe et raffinage)
TD9 (Recherches et tri
11 TP8 (Projet) S7
basique)
12 TP9 (Projet) S8
diants nont pas encore eu de travaux pratiques de programmation. Par consquent, cette pre-
mire sance se consacre la prsentation de lunivers du jeu travers la ralisation dune
mini comptition. Cette phase correspond ltape 1 de lorganisation des enseignements (voir
tableau 5.1 page 126) de la premire exprimentation. cette occasion les tudiants manipulent
lenvironnement Linux et rinvestissent les comptences acquises lors du deuxime TP.
Le troisime TP introduit lenvironnement dexcution et de compilation ainsi que la syn-
taxe en langage C des structures de contrle. Les tudiants ont donc simplement eu une intro-
duction au langage C avant la deuxime sance de soutien. Dautre part, sils participent au
soutien, ils ont thoriquement eu quelques difficults lors des premires sances de travaux
dirigs. Par consquent, cette deuxime sance de soutien propose de rsoudre les premires
missions de la campagne laide du langage algorithmique vu en TD. Une surcouche linter-
face C de lAPI Prog&Play a donc t cre ( PP_ALGO.h - voir annexe D). Elle dfinit les
mots cls du langage algorithmique ainsi que les oprateurs utilisables pour interagir avec le
133
jeu Kernel Panic. Les mots cls de ce langage algorithmique sont les suivants : Debut, Fin, Si,
Alors, Sinon, FinSi, TantQue, Faire, FinTantQue, Et, Ou, Non, VRAI et FAUX. Les oprateurs
disponibles sont prsents dans le tableau 5.4.
TABLE 5.4 Oprateurs disponibles pour interagir avec le jeu Kernel Panic en langage algo-
rithmique.
Oprateur Description
Ouvre la connexion avec le jeu. Cet oprateur doit tre
OUVRIR_JEU
appel avant tout autre oprateur.
Ferme la connexion avec le jeu. Cet oprateur doit
FERMER_JEU imprativement tre le dernier oprateur tre appel
avant la fin du programme.
current_unit Reprsente lunit en cours dutilisation.
initialise lunit courante la premire unit contrle
PREMIERE_UNITE
par le joueur.
Fait passer lunit courante lunit suivante con-
UNITE_SUIVANTE
trle par le joueur.
DERNIERE_UNITE Fournit la dernire unit contrlable par le joueur.
EST_UN_BIT Indique VRAI si lunit courante est un BIT.
EST_UN_BYTE Indique VRAI si lunit courante est un BYTE.
Indique VRAI si lunit courante est un ASSEM-
EST_UN_ASSEMBLEUR
BLEUR.
Donne lordre lunit courante de se dplacer vers
DEPLACER_VERS(xCible, yCible)
les coordonnes indiques.
Grce ce langage algorithmique, les tudiants peuvent raliser les trois premires missions
sur les cinq que contenait la campagne lors de cette exprimentation. Lutilisation du langage
algorithmique tudi en TD, pour cette sance de soutien, permet aux tudiants de formuler
une premire solution aux problmes poss dans les missions et dobserver les rsultats dans le
contexte du jeu.
Les figures 5.6 et 5.7 prsentent les solutions respectives en langage algorithmique des
missions 1 et 3 de la campagne telle quelle tait propose au moment de lexprimentation.
Pour simplifier la compilation des programmes crit, un Makefile est fourni aux tudiants et
quelques informations sont donnes sur lutilisation de la commande make.
Sur les sances suivantes, les tudiants transforment leurs solutions algorithmiques en des
programmes crits en langage C. De cette manire, ils mettent en application les concepts de
dcomposition de problmes et de raffinage successif.
134
5.2. Deuxime exprimentation
# i n c l u d e "PP_ALGO . h " # i n c l u d e "PP_ALGO . h "
/ Mission 1 : / Mission 3 :
deplacer l unique u n i t e a d e p l a c e r t o u t e v o t r e armee a l a r e n c o n t r e
la p o s i t i o n (1983 , 1279) de l ASSEMBLEUR /
p o u r t e n t e r de r e t r o u v e r Debut
l OCTET p e r d u . / OUVRIR_JEU ;
Debut PREMIERE_UNITE ;
OUVRIR_JEU ; TantQue c u r r e n t _ u n i t ! = DERNIERE_UNITE
PREMIERE_UNITE ; Faire
DEPLACER_VERS( 1 9 8 3 , DEPLACER_VERS( 2 5 6 , 1 0 2 4 ) ;
1279) ; UNITE_SUIVANTE ;
FERMER_JEU ; FinTantQue
Fin DEPLACER_VERS( 2 5 6 , 1 0 2 4 ) ;
FERMER_JEU ;
Fin
F IGURE 5.6 Solution de la pre-
mire mission en langage algorith- F IGURE 5.7 Solution de la troisime mission en lan-
mique. gage algorithmique.
En raison de facteurs externes lexprimentation (mouvement social tudiant avec blocage

de btiments denseignement), la conduite des dernires sances sest trouv fortement pertur-
be. Toutefois, il a tout de mme t possible de raliser les observations souhaites sur les
activits de lenseignant.
5.2.3 Rsultats
Pour tudier limpact du jeu sur les activits de lenseignant, la troisime sance de soutien
a t filme. Le visionnage de cette vido a permis didentifier trois activits principales dont
celles ddies : au jeu - utilisabilit du jeu ; au savoir enseigner - contenu dapprentis-
sages ; et aux autres tches. Le temps utilis par lenseignant pour chacune de ces activits,
est dtaill dans le tableau 5.5.
TABLE 5.5 Dure des activits pour une sance denseignement.
Activits Dure
Utilisabilit du jeu 22 min 13 s
Contenu dapprentissages 1 h 3 min 42 s
Autres tches 41 min 27 s
135
Lactivit utilisabilit du jeu concerne des explications sur le contrle du jeu (comment
lancer le jeu ? Comment dplacer la camra ?) et sur linteraction entre les programmes des
tudiants et le jeu (comment accder ou commander une unit ? Comment vrifier si le pro-
gramme est correct ?). Lactivit contenu dapprentissages concerne les explications sur les
obstacles de programmation tels que les variables (type, affectation, enregistrement), les fonc-
tions (appel, passage de paramtres), ou les structures de contrle (conditionnelles, itratives).
Lactivit autres tches concerne les tches administratives (accueil des tudiants, appel),
des explications sur lutilisation du systme dexploitation, etc.
Au regard des activits nonces prcdemment, le cur de lenseignement repose sur le
contenu de lapprentissage. Cette rpartition est opportune, car, les explications lies au jeu
ne doivent pas empiter de manire excessive sur les activits de lenseignant. Dautre part, le
temps consacr lutilisabilit du jeu diminue au fur et mesure que les tudiants deviennent
experts dans la manipulation du jeu. Certaines interventions de lenseignant sont comptabilises
dans diffrentes activits ce qui explique pourquoi la somme des dures de chaque activit est
suprieure la dure dune sance (deux heures).
Toutefois, lactivit Utilisabilit du jeu reprsente une part non ngligeable des expli-
cations notamment lors des premires sances. Une question se pose alors sur la capacit dun
enseignant novice en jeu de STR utiliser un tel outil dans ses enseignements. Dautant plus
que ces explications contribuent fortement satisfaire le second niveau de la pyramide des be-
soins. Une rponse cette question peut venir directement des tudiants. En effet, comme le
montre la dernire enqute ralise (voir section 4.1.1), les jeux de STR sont apprcis par 36%
des joueurs soit 27% de la population totale. Par consquent, un certain nombre dtudiants
matrisera rapidement le jeu. Une solution consiste alors inciter ces tudiants aider leurs
camarades mieux contrler lenvironnement de jeu. Cette solution permet en outre dinitier
la communication entre les tudiants et de favoriser lentraide. Crenshaw et al. [CCMT08] no-
tent ce propos que le manque de communication et dchange entre les tudiants est un des
facteurs favorisant le dsintressement des tudiants pour linformatique.
Synthse de la deuxime exprimentation
Malgr les vnements qui ont perturbs les enseignements, cette itration a permis dans un
premier temps de valider la portabilit du jeu srieux dans un contexte diffrent de la premire
exprimentation. En effet, tout en respectant lorganisation des enseignements, il a t possible
136
5.3. Troisime exprimentation
dintgrer le jeu avec cohrence dans le calendrier. La cration dune surcouche algorithmique
linterface C de lAPI montre galement la possibilit dadapter les interfaces prexistantes
un contexte particulier.
Dans un deuxime temps, lobservation des activits de lenseignant met en vidence que
le cur de lenseignement repose bien sur les concepts de programmation. Il importe, tout de
mme, de souligner limportance non ngligeable des explications lies lutilisation du jeu et
donc la ncessit de lenseignant matriser les jeux de STR ou savoir solliciter laide des
tudiants sur ce point.
Enfin cette exprimentation vrifie le potentiel motivationnel du jeu srieux qui a su attirer
une dizaine dtudiants contre seulement deux pour le soutien traditionnel.
5.3 Troisime exprimentation

Cette troisime exprimentation a pour objectif dtudier la mise en uvre du jeu a une plus
grande chelle, afin dvaluer linfluence de ce dernier sur la motivation des tudiants et son
apprciation par des enseignants externes au projet.

Pour cette exprimentation, le jeu a t intgr dans le tronc commun du parcours IMP
(Informatique, Mathmatiques, Physique) au premier semestre de la premire anne de licence
STS de luniversit Paul Sabatier. Dans cette formation, linformatique est aborde par une
approche fonctionnelle. Les tudiants mettent en application les notions de ce paradigme de
programmation lors de six sances de travaux pratiques en environnement Linux et laide du
langage de programmation OCaml.
La promotion, compose de plus de trois cent tudiants, est structure en trois sections
chacune divise en groupe de TD dune trentaine dtudiants. Chaque groupe de TD est alors
spar en deux sous-groupes pour les TP. Laffectation des tudiants dans les groupes de TP se
fait de manire alatoire. Une quinzaine denseignants prennent part la formation.
Pour tenter dvaluer linfluence du jeu sur lapprentissage de la programmation, la promo-
tion a t divise en deux pour la ralisation des TP. En accord avec lquipe pdagogique, les
sous-groupes impairs ont servi de groupes tmoins et ont ralis les TP classiques alors que les
137
sous-groupes pairs ont utilis le jeu, do la ncessit de modifier les supports de TP pour les
sous-groupes concerns.
5.3.2 Intgration du jeu srieux dans la formation

La prcondition mise par lquipe pdagogique pour pouvoir valider lintgration du jeu
dans la formation porte sur la capacit de ce dernier maintenir les concepts enseigns de
lapproche classique. Le tableau 5.6 prsente le calendrier et les objectifs des enseignements de
TP dans la version classique.
TABLE 5.6 Calendrier des enseignements de travaux pratiques dinformatique au L1S1 de

lUniversit Paul Sabatier.
TP Objectifs
Prsentation de lenvironnement de travail : le systme dexploitation Linux (Man-
1 driva 2008), le gestionnaire de fentres KDE, la boucle interactive de OCaml et ldi-
teur de texte Kate.
Ralisation de fonctions arithmtiques : utilisation du filtrage, des n-uplets, des fer-
2
metures, de la rcursivit et des fonctions dj ralises ; initiation la dichotomie.
Utilisation de la bibliothque graphique : prsentation du concept de bibliothque,
3
calculs trigonomtriques, optimisation et rcursivit.
Manipulation des listes : traitement et construction de listes ; utilisation du filtrage et
4
de la rcursivit sur les listes ; prsentation du concept de prdicat ; tris.
Gestion dune base de donnes : rutilisation de fonctions des TP prcdents ; projec-
5 et 6 tion, limination de doublons, slection, mise jour et tri ; manipulation de types de
donnes utilisateurs.
Les modifications apportes pour intgrer le jeux dans les TP, tout en respectant les con-
cepts enseigner, se concentrent sur les sances 1, 3 et 4. Aprs avoir t valids par lquipe
pdagogique, les modifications sont les suivantes :
TP 1 : Outre la prsentation du systme Linux, le premier TP est utilis pour prsenter le
jeu et son univers. Il explique dune manire dtaille la procdure suivre pour raliser
des parties en mode multijoueur. Les tudiants sont invits tester le jeu en sances libres
avant la troisime sance de TP.
TP 3 : La troisime sance de TP est centre sur lutilisation dune bibliothque. Le sup-
port a donc t totalement rcrit pour prsenter lAPI Prog&Play ainsi que la campagne.
Afin de respecter le type dexercice prsent dans le support originel, une nouvelle mis-
138
sion a t ajoute aux cinq missions dj existantes. Dans cette exprimentation, la cam-
pagne est donc compose de six missions savoir les missions 1, 2, 3, 4, 6 et 7 prsentes
page 106. Lors de cette troisime sance, les tudiants sont invits raliser les quatre
premires missions de cette nouvelle campagne. Par cet intermdiaire, les tudiants sini-
tient lutilisation dune bibliothque avec la premire mission, ralisent un exercice de
trigonomtrie dans la deuxime, manipulent le filtrage dans la troisime et la rcursivit
dans la quatrime.
TP 4 : Enfin la quatrime sance de TP a galement t compltement rcrite. Lors de
cette sance les tudiants travaillent la ralisation de la cinquime mission (soit la mis-
sion 6 de la campagne prsente page 107). Ils commencent par crer des fonctions pour
manipuler des listes dunits et les utilisent pour terminer une premire fois la mission.
laide dalgorithmes de tris, les tudiants ralisent une seconde solution plus efficace et
entrevoient ainsi le principe de loptimisation, non trait lors du TP 3 modifi. La dernire
mission de la campagne est raliser en sance libre.
En raison du nombre important denseignants prenant part cette formation (une quinzaine),
une sance pralable leur a t propose pour leur prsenter le jeu, les modifications apportes
aux sujets de TP et la solution des exercices. lissue de cette formation, de nombreuses remar-
ques ont permis de faire voluer les supports de TP avant la mise en uvre auprs des tudiants.
Par exemple : la sance de jeu, initialement prvue en encadrement lors de la premire sance,
est raliser en sance libre, do lajout dune description dtaille en annexe du premier TP ;
nous vitons dsormais aux tudiants de chercher dans la bibliothque en prsentant chaque
nouvelle fonction utile la ralisation dun exercice ; nous simplifions aussi le chargement de
la bibliothque en fournissant aux tudiants une base de fichiers prconfigurs.
Enfin, une ressource pdagogique a t cre pour permettre aux tudiants de prparer les
TP chez eux. Cette initiative a t motive par la difficult dinstaller le jeu notamment dans
un environnement Linux. Pour simplifier cette procdure, un live-DVD 52 a t conu et un
exemplaire en a t distribue chaque tudiant. Il contient le jeu srieux, les sujets de TP,
divers langages de programmation et toutes les ressources ncessaires pour raliser les TP. Son
utilisation est simple, il suffit dinsrer le live-DVD dans un lecteur DVD et de redmarrer lor-
dinateur. Celui-ci va alors amorcer le systme dexploitation inclus dans le live-DVD. Lorsque
le chargement est termin, ltudiant peut utiliser le systme pour jouer au jeu, raliser les TP,
52. Un live-DVD contient en son sein un systme dexploitation complet ainsi quune suite de logiciels. Le
live-DVD conu cette occasion est bas sur un systme dexploitation Linux (distribution Kubuntu).
139
crire des rapports, prparer des prsentations, etc. La difficult principale lie la conception
de cette ressource repose sur lexcution du jeu vido avec des performances graphiques cor-
rectes. En effet, le jeu srieux tant bas sur Kernel Panic, il ncessite lexploitation dune carte
graphique. Si celle-ci est mal gre par le systme, les performances du jeu sont grandement
dgrades ce qui nuit la jouabilit. Or, pour des raisons de portabilit, les systmes inclus
dans les live-DVD ne proposent quune gestion minimaliste des cartes graphiques ce qui rend
souvent lutilisation des jeux vido 3D impossible. Pour rsoudre ce problme, les fichiers sys-
tmes du live-DVD ont t modifis pour dtecter au dmarrage la carte graphique prsente sur
lordinateur et installer le pilote associ sil existe.
Ce live-DVD et la cration de supports de TP propres au jeu srieux sont les ressources
qui permettent lintgration du jeu dans la formation. Pour valuer linfluence du jeu sur la
motivation des tudiants et son utilisabilit par des enseignants externes au projet, un nouveau
protocole dvaluation simpose.
5.3.3 Conception du protocole dvaluation

Conformment aux objectifs fixs dans cette exprimentation, deux critres dvaluation
sont fixs : linfluence du jeu srieux sur la motivation des tudiants ; et lapprciation du
jeu srieux par les enseignants. De mme que pour la premire itration, une approche ex-ante
est privilgie et les indicateurs sont dfinis avant lexprimentation de manire tre rcolts
au fur et mesure de son droulement (voir figure 5.8).
Du point de vue de la motivation, lobjectif consiste valuer lvolution de la motivation
des tudiants entre le dbut et la fin du semestre. Pour ce faire, un questionnaire leur est dis-
tribu deux reprises : la premire fois au dbut du semestre, pour talonner leur motivation ; la
deuxime fois la fin du semestre, pour permettre den constater les volutions. Les questions
sont donc lgrement remanies en fonction de la premire ou de la seconde distribution. Ces
questionnaires sont bass sur le modle de Viau [Via97] (prsent section 3.2.1). Chaque ques-
tion fait rfrence une composante de ce modle dont les associations sont prsentes dans
le tableau 5.7. Les tudiants indiquent pour chaque question une valeur entre 1 et 7. La valeur
maximale indique un acquiescement total la question ou laffirmation alors que la valeur
minimale dnote le contraire.
140
Resultats des tudiants :

Resultats des tudiants
- aux travaux pratiques
l'examen de mi-semestre
- l'examen terminal
Dbut de Fin de
l'exprimentation l'exprimentation
TEMPS
Questionnaire post exprimental :

- motivation des tudiants
- bilan des enseignants
Questionnaire pr exprimental :
- motivation des tudiants
- a priori des enseignants
F IGURE 5.8 Organisation temporelle de lvaluation pour la troisime exprimentation.
TABLE 5.7 Association entre les questions des questionnaires et les composantes du modle
motivationnel de Viau.
Question Composante motivationnelle Poids

Avez-vous un projet professionnel ou de dterminant (perception de la valeur
2/48
poursuite dtude prcis ? dune activit (perspective future))
Ce que (japprendrai/japprends) en
dterminant (perception de la valeur
programmation me (valorisera/valorise) 2/48
dune activit (buts sociaux))
auprs de mon entourage.
dterminant (perception de la valeur
Je poursuis des tudes pour acqurir de
dune activit (buts scolaires dappren- 2/48
nouvelles connaissances.
tissage))
Je poursuis des tudes pour tre es- dterminant (perception de la valeur
tim, reconnu ou encore pour obtenir un dune activit (buts scolaires de perfor- 2/48
diplme. mance))
dterminant (perception de sa comp-
Je pense avoir les bases ncessaires pour
tence accomplir une activit (perfor- 2/48
poursuivre cette formation.
mances antrieures))
Suite sur la prochaine page
141

Lobservation dautres personnes ral- dterminant (perception de sa comp-
isant des exercices me permet de me tence accomplir une activit (observa- 2/48
dire : moi aussi je peux y arriver . tions))
Jai besoin que lon me convainque de dterminant (perception de sa comp-
mes capacits pour accomplir une acti- tence accomplir une activit (persua- 2/48
vit. sion))
Mon motivit me rend incapable de dterminant (perception de sa comp-
russir une activit comme, par exem- tence accomplir une activit (ractions 2/48
ple, un examen. physiologiques et motives))
Les difficults que (je rencontre lors de
dterminant (perception de contrla-
mes tudes/jai rencontr en informa- 2/48
bilit (impuissance apprise))
tique) sont irrmdiables.
En gnral, mes rsultats (/en program-
mation) sont plus lis mes com-
ptences qu des facteurs externes 2/48
bilit (lieu de la cause : interne/externe))
comme des grves, les choix pdago-
giques des enseignants, etc.
Mes rsultats sont plus lis aux efforts dterminant (perception de contrla-
que je fournis qu mes comptences bilit (stabilit de la cause : modifi- 2/48
intellectuelles. able/stable))
Mes checs passs auraient pu tre
bilit (contrle de la cause : con- 2/48
vits si je lavais souhait.
trlable/incontrlable)
Quand je suis en cours ou en TD et
indicateur (choix dentreprendre une
que lenseignant parle, je pense autre 3/48
activit (vitement))
chose et je ncoute pas tout ce quil dit.
indicateur (choix dentreprendre une
Je rends toujours mes travaux temps. 3/48
activit (vitement))
Suite sur la prochaine page
142

Pour prparer les examens crits, je fais
toutes les annales des annes prc- indicateur (persvrance) 3/48
dentes.
Je consacre une partie importante de
indicateur (persvrance) 3/48
mon temps tudier.
Lorsque jtudie, jutilise des tech-
niques dapprentissage comme, par indicateur (engagement cognitif
3/48
exemple, raliser des fiches, faire des (stratgies dapprentissage))
schmas, etc.
indicateur (engagement cognitif
Jai conscience des stratgies que juti-
(stratgies dautorgulation : mtaco- 1/48
lise pour rguler ma faon de travailler.
gnitive))
Je suis organis dans mon travail univer- indicateur (engagement cognitif
1/48
sitaire. (stratgies dautorgulation : gestion))
indicateur (engagement cognitif
Quand je rencontre une activit difficile,
(stratgies dautorgulation : motiva- 1/48
je reste motiv pour laccomplir.
tionnelle))
Comment estimez-vous votre niveau en
indicateur (performance) 3/48
informatique.
Total 45/48
Ce questionnaire permet dvaluer chaque composante du modle motivationnel de Viau,

mais demande des donnes complmentaires telles que les notes des tudiants aux examens.
Ces notes sont un indicateur de la performance des tudiants et sont prendre en compte pour
lvaluation finale de lvolution de leur motivation au cours du semestre. Avec un poids de
3/48, cet indicateur complte donc le questionnaire prsent table 5.7.
Dans ce questionnaire, il ny a pas de rponses justes ou fausses. Par exemple pour laffir-
mation Je suis organis dans mon travail scolaire , lvaluation ne consiste pas dterminer
si ltudiant est effectivement organis ou pas, mais simplement observer comment il peroit
son organisation lors du premier questionnement (premier TP) puis lors du second (dernier TP).
Lobjectif est donc de rcolter le point de vue de chaque tudiant avant et aprs lexprimen-
tation en vue dobserver une ventuelle volution de sa motivation.
143
Du point de vue de lencadrement des sances, cette exprimentation est la premire faire
participer des enseignants externes au projet. ce titre, deux questionnaires relativement ou-
verts ont t proposs aux enseignants. Le premier, distribu avant la premire sance de travaux
pratiques, interroge les enseignants sur leur rapport au jeu vido, leur pratique enseignante et
leurs a priori sur le jeu srieux propos. Le deuxime questionnaire, distribu aprs la dernire
sance de travaux pratiques, permet aux enseignants dexprimer leur point de vue sur les dif-
ficults rencontres durant les sances, les consquences du jeu sur les tudiants (motivation,
apprentissage) et sur une ventuelle reconduite de lexprimentation.
5.3.4 Rsultats
Critre 1 : Influence du jeu sur la motivation des tudiants
Lvaluation de linfluence du jeu srieux sur la motivation des tudiants est dtermine en
grande partie par les rponses aux questionnaires distribus et par lvolution de leurs rsultats
aux cours du semestre.
Analyse des notes des tudiants :
TABLE 5.8 Calendrier des valuations au L1S1 de lUniversit Paul Sabatier.
Semaine TP valuation
...
7 QCM3
8 TP1 Contrle continu
9 TP2 QCM4
10 TP3
11 TP4
12 TP5 QCM5
13 TP6
... Rvisions
17 Contrle terminal
Lobtention de lunit denseignement dans laquelle le jeu srieux a t intgr, dpend

principalement de trois valuations. Le calendrier de ces valuations vis--vis des sances de
TP est prsent dans le tableau 5.8. La premire valuation est un contrle continu pass par
les tudiants mi-semestre, soit la mme semaine que la premire sance de TP. La deuxime
144
est la note de travaux pratiques attribue en fonction de la participation des tudiants durant les
TP. La troisime est un contrle terminal de fin de semestre. Outre ces valuations, un contrle
continu est mis en place sous la forme de QCM pour lorganisation du soutien. La conception
de ces contrles et lvaluation des productions des tudiants sont ralises par des enseignants
externes au projet.
La figure 5.9 prsente les moyennes des notes obtenues aux diffrentes valuations (QCM
exclus) en fonction des sous-groupes de TP. Lanalyse de ces donnes fait apparatre une baisse
des rsultats entre le contrle de mi-semestre et le contrle terminal et cela quel que soit le
sous-groupe de TP. Toutefois, cette baisse est moins importante pour les groupes ayant utilis
le jeu srieux ( 1,25 points contre 1,55 pour le groupe de rfrence).
Groupe Groupe
tmoin Prog&Play Groupe Groupe
tmoin Prog&Play
14
15
13 14
12 13
11 12
Moyenne
Moyenne
10 11
9 10
9
8
8
7
7
6 6
Travaux pratiques 1 2 3 4 5
Contrle continu Contrle terminal
QCM
F IGURE 5.9 Moyennes des notes obtenues

F IGURE 5.10 Moyennes des notes obtenues
aux valuations en fonction du groupe dtudi-
aux QCM en fonction du groupe dtudiants.
ants.
Cette diffrence ne peut tre attribue qu la seule utilisation du jeu. En effet, de nom-
breux paramtres incontrlable, d la mise en uvre de lexprimentation en contexte rel,
ont galement pu participer ce rsultat. Par exemple, les tudiants ayant utilis le jeu taient en
moyenne plus performants que les autres avant mme le dbut des TP (voir moyennes du con-
trle continu figure 5.9). Cette diffrence initiale doit tre prise en compte pour interprter les
rsultats. Nanmoins, lcart initial constat lors du contrle continu ( 0,7 point) est maintenu
145
lors de lvaluation de TP ( 0,74 point) et augment lors du contrle terminal ( 1 point).

Le jeu srieux est donc lun des nombreux facteurs ayant contribus obtenir ces rsultats.
Concernant lanalyse des QCM (voir figure 5.10), la meilleure performance initiale des
tudiants du groupe Prog&Play est confirme lors du premier QCM. Toutefois, les rsultats
entre les deux groupes se rduisent lors du deuxime QCM et deviennent quivalents partir du
troisime. Il faut noter que le contrle continu a t ralis la semaine suivant le QCM 3 et que
les sances de TP avec le jeu ont eu lieu entre les QCM 4 et 5 (voir tableau 5.8). Par consquent,
les rsultats au QCM numro 5, centr sur les listes, apportent linformation selon laquelle le
TP4 bas sur le jeu srieux a tout aussi bien prpar les tudiants la manipulation des listes
que le TP classique.
Conformment au protocole dvaluation, la variation des notes entre le contrle continu et
le contrle terminal de chaque tudiant est intgre au calcul de la motivation.
volution de la motivation : Lanalyse de cette volution est conduite suite aux question-
naires retourns par les tudiants. Parmi les trois cents quatre tudiants inscrits pdagogi-
quement, cent soixante-seize ont retourn les deux questionnaires dont quatre-vingt six appar-
tenant au groupe tmoins et quatre vingt dix au groupe Prog&Play ; lanalyse des donnes sef-
fectue donc sur cet chantillon.
Le tableau 5.9 prsente lvolution moyenne de la motivation en fonction des groupes de TP.
Le premier constat porte sur la motivation gnrale qui est reste relativement stable malgr une
lgre baisse quel que soit le groupe considr. Les tudiants du groupe 2 semblent avoir tout
de mme mieux conserv leur motivation (baisse de 0,03 points) par rapport aux tudiants
du groupe 1 (baisse de 0,21 points). La diffrence entre ces deux groupes est de lordre de
0,18 point sur lchelle de valeur comprise entre 1 et 7. On peut noter que 46% des tudiants
du groupe 2 ont vu leur motivation progresser contre 35% du groupe 1.
TABLE 5.9 volution moyenne de la motivation en fonction des groupes de TP.
Groupe Utilisation
numro du jeu Motivation
1 -0,21
2 X -0,03
0,18 Diffrence
146
Pour dterminer la composante principalement responsable de cette lgre variation, lanal-

yse est porte au niveau des dterminants et des indicateurs (voir tableau 5.10). Il apparat ainsi
que cette variation est rpartie sur lensemble des composantes du modle motivationnel de
Viau lexception de la performance (I4) qui est identique entre les deux chantillons.
TABLE 5.10 volution moyenne de la motivation pour chaque composante du modle moti-
vationnel de Viau en fonction des groupes de TP.
Groupe Utilisation Dterminant Indicateur

numro du jeu D1 D2 D3 I1 I2 I3 I4
1 -0,25 -0,13 -0,29 -0,35 -0,25 -0,07 -0,1
2 X -0,12 0,09 -0,09 -0,03 -0,07 0,05 -0,07
0,13 0,23 0,20 0,32 0,18 0,12 0,03 Diffrence
D1 : Perception de la valeur dune activit
D2 : Perception de sa comptence accomplir une activit
D3 : Perception de la contrlabilit dune activit
I1 : Choix dentreprendre une activit
I2 : Persvrance
I3 : Engagement cognitif
I4 : Performance
Un dernier indice de motivation concerne le choix dorientation des tudiants au second

semestre. En effet, suite au parcours IMP (Informatique, Mathmatiques, Physique) suivi au
premier semestre, les tudiants ont le choix au second semestre entre neuf majeures dont celle
incluant linformatique (IMM - Informatique, Mathmatiques, Mcanique). Parmi les tudiants
du groupe Prog&Play, 55% ont choisi cette majeure contre 49% pour le groupe tmoin.
la vue de ces rsultats, il convient de rester prudent quant aux conclusions trop htives. En
effet, suite lenqute et au suivi des tudiants, les donnes rcoltes plaident en faveur du jeu
srieux pour maintenir la motivation. Toutefois, les diffrences enregistres restent relativement
faibles et nous ne pouvons affirmer que les diffrences observes sont exclusivement dues
lintgration du jeu srieux dans la formation.
Pour complter ces rsultats, le point de vue des tudiants sur le jeu et cette exprimentation
a t rcolt lors de lenqute post exprimentale. Concernant lamusement, les deux questions
prsentes dans la figure 5.4 (page 130) ont t rutilises. La rponse moyenne pour la premire
question est de 4,14 soit une apprciation modre du scnario du jeu. Cette impression se
retrouve naturellement dans les rponses la seconde question. Alors que 100% des tudiants
de la premire exprimentation avaient trouv que lutilisation de la programmation dans le jeu
147
augmentait le divertissement, 42% des tudiants de cette enqute votent pour une augmentation,
22% nindiquent aucun changement, 21% ne se prononcent pas et 15% trouvent que cela le
rduit. Donc 64% des tudiants estiment que le jeu srieux est au moins aussi divertissant que
le jeu sans la programmation.
Pour la pyramide des besoins (voir figure 5.11), les trois premiers niveaux de base restent
relativement hauts alors que les niveaux 4, 5 et 7 ont fortement diminus par rapport la pre-
mire exprimentation (voir figure 5.5 page 131). Alors que le jeu tait identique la premire
itration ( lexception de la nouvelle mission), les rsultats sur lutilisabilit et lamusement
sont infrieurs. Pour expliquer cette diffrence, les critiques des tudiants ont t tudies et les
remarques rcurrentes portent essentiellement sur la lourdeur des supports de TP. Nous infrons
de ces critiques que les supports de TP ont nui la comprhension du jeu et son potentiel
ludique.
(6) Esthtique
(4) Estime
Valeur moyenne
(3) Appartenance
(2) Sret
(1) Rgles
0% 10% 20% 30% 40% 50% 60% 70% 80% 90%100%
Pourcentage de satisfaction
F IGURE 5.11 Satisfaction moyenne des tudiants pour chaque niveau de la pyramide des
besoins (L1S1 IMP Toulouse III).
Malgr cela, les tudiants ont dans lensemble apprci linitiative et sont demandeurs de
ce type de pdagogie (voir figure 5.12). 89% des tudiants interrogs nont pas dopinion dfa-
vorable sur lintrt dutiliser un jeu vido pour apprendre programmer et 85% pensent quun
TP bas sur un jeu vido peut avoir sa place dans cette formation.
148
60
50
40 Selon vous, y-a-t'il un

Nombre de vote
intrt utiliser un jeu

vido pour apprendre
30 programmer ?
Pensez-vous que des
20 TP bass sur un jeu
vido ont leur place
dans cette formation ?
10
0
1 2 3 4 5 6 7
Note (1 = "Pas du tout", 7 = "Tout fait")
F IGURE 5.12 Perception des tudiants de lutilit dun jeu vido pour apprendre la program-
mation.
Critre 2 : Apprciation du jeu srieux par les enseignants
Pour valuer lapprciation du jeu srieux par les enseignants, deux questionnaires ont t
raliss. Le premier a t distribu lors de la phase de dfinition du protocole dvaluation durant
le second semestre de lanne universitaire prcdent cette itration. Le deuxime a t rempli
par les enseignants de TP la fin du premier semestre de lanne universitaire contemporaine
lexprimentation. En raison de ce chevauchement, certains enseignants ayant collabors
lintgration du jeu srieux dans la formation nont pas particip lexprimentation et vice
versa. Par consquent, la population des enseignants est lgrement diffrente pour les deux
questionnaires.
Pour la premire enqute, quinze enseignants ont rpondu dont trois femmes et douze
hommes. Dans cet chantillon, neuf attestent avoir une exprience de joueur. Ce premier ques-
tionnaire les interroge sur les jeux vido, leur pratique enseignante et leur a priori sur le concept
dun jeu srieux appliqu la programmation.
Quels sont, selon vous, les qualits et dfauts inhrents aux jeux vido ? cette ques-
tion, les enseignants ont principalement relev trois qualits dont la capacit des jeux vido
favoriser la rflexion travers le dveloppement de stratgies de jeu, dtendre et permettre
149
limmersion dans des environnements virtuels. Dans une moindre mesure, laspect comptition
travers le mode de jeu multijoueur, le scnario, la motivation et la crativit sont nots comme
tant des qualits intrinsques aux jeux vido. Concernant les dfauts, la principale inquitude
porte sur le danger laddiction et la coupure de la ralit. Certains enseignants les trouvent
complexes et les associent une perte de temps.
Quels problmes rencontrent vos tudiants dans lapprentissage de la programmation et

quelles solutions mettez-vous en uvre pour tenter dy rpondre ? Selon les enseignants
interrogs, les tudiants se trouvent principalement en difficult pour exprimer une solution
algorithmique un problme donn. Cette difficult est en partie due, selon eux, des lacunes
dans la matrise de lalgorithmique et des structures de contrle et des difficults de raison-
nement logique et dabstraction. cela, sajoute un manque de motivation, de travail et de
rigueur, associ aux problmes de syntaxe inhrents aux langages de programmation. Pour aider
les tudiants surmonter ces difficults, les enseignants utilisent majoritairement lexemple et
suggrent des mthodes de travail pour stimuler lautonomie des tudiants.
A priori, pensez-vous quun jeu vido puisse aider les tudiants surmonter leurs diffi-
cults ? Pourquoi ? Pour cette question, six enseignants ne se prononcent pas, sept portent
un jugement positif et deux ngatif. Les a priori positifs positionnent le jeu vido comme un
outil concret, proche du centre dintrt des tudiants qui permet une visualisation immdiate
de leurs programmes dans le contexte du jeu. Mais la principale hypothse positive porte sur la
capacit du jeu vido augmenter la motivation des tudiants travailler en informatique. Les
quelques a priori ngatifs se fondent sur la crainte : de donner une image errone de linfor-
matique qui ne se cantonne pas aux jeux vido ; de favoriser principalement les garons ; de
perdre du temps expliquer le jeu au dtriment des concepts algorithmiques ; et de dtourner
les tudiants du fond en raison de la dimension ludique du jeu. Les enseignants sans opinion
sont en attente de rsultats.
Etes vous favorable cette exprimentation ? Pourquoi ? Cette question tait fondamen-
tale pour la mise en place du jeu srieux dans la formation. Il ntait pas envisageable de d-
ployer le jeu si les enseignants de travaux pratiques navaient pas t consentants. Sur les quinze
questionnaires rcolts, onze sont favorables la mise en place de lexprience et quatre ne se
sont pas prononcs. Les raisons de cette acceptation sont principalement motives par le souhait
150
de faire voluer loffre de formation, par lespoir de motiver les tudiants et par la simple curio-
sit des rsultats venir.
Pour la seconde enqute, quinze enseignants dont douze identiques au premier questionnaire
ont rpondu. Ce groupe se compose de quatre femmes et onze hommes. Ce second questionnaire
permet aux enseignants de dresser un bilan de lexprimentation. Concernant la prparation des
sances de TP bases sur le jeu srieux, lensemble des enseignants affirme que cela demande
une charge de travail quivalente la prparation dun nouveau TP. Nanmoins, les enseignants
non joueurs ont particulirement apprci la sance de formation de quatre heures organise
avant le premier TP.
Du point de vue des consquences du jeu sur la motivation et les performances des tudiants,
le bilan est fortement contrast. Sur le plan des performances, la plupart des enseignants ont le
sentiment que les TP modifis ont t contre-productifs pour de nombreux tudiants (il faut
noter que se ressenti ne se retrouve pas dans les rsultats aux valuations prsentes figures 5.9
et 5.10 page 145). Les principales critiques portent essentiellement sur les supports de TP trop
longs, do une perte de temps et une pratique de la programmation moins importante que pour
les TP classiques. En revanche sur le plan de la motivation, la majorit des enseignants constate
un effet positif sur lessentiel des tudiants.
Enfin il leur a t demand leur point de vue quant une ventuelle reconduite de lexp-
rimentation lanne suivante. Deux enseignants ne souhaitent pas voir cette exprimentation
reconduite. Le premier qui a uniquement encadr un TP classique soppose simplement au
principe dintgrer un jeu dans la formation. Le second nuance son opinion, il trouve que lAPI
Prog&Play complique les TP ce qui dsavantage les tudiants dj en difficult. Cependant, il
ajoute que sil existe une solution permettant de simplifier lutilisation de la bibliothque et la
manipulation des entits dans le jeu, ce type de TP pourrait tre maintenu et gnralis.
Les autres enseignants sont favorables une reconduite de lexprimentation sous rserve
de modifications. Six dentre eux proposent de conserver les deux formes de TP mais suggrent
de laisser le choix aux tudiants. Sept dentre eux prfreraient gnraliser les TP bass sur le
jeu de faon fournir une formation quivalente tous les tudiants. Dans tous les cas, ces
enseignants sont en demande dune simplification de la bibliothque et des sujets de TP.
151
Synthse de la troisime exprimentation
Cette exprimentation est donc riche en enseignements et a permis de mettre en vidence la

difficult de mener une exprimentation dans le cadre dune formation de plusieurs centaines
dtudiants. En effet en raison du nombre important dtudiants, lintgration du jeu a d tre
conduite dans un cadre moins souple que la ralisation dun atelier ou dun soutien. Le jeu a
donc t intgr dans le calendrier des enseignements et les TP ont t adapts pour conserver
lensemble des concepts manipuls lors des TP classiques. La consquence de cette fusion a
rendu les sujets proposs difficilement ralisables dans le temps imparti.
Ainsi, cette exprimentation met en vidence que les rsultats obtenus dpendent non seule-
ment du jeu srieux mais aussi de son dploiement, de lencadrement, des documents, etc. Cette
premire exprimentation grande chelle a donc permis de valider la portabilit du jeu avec
une approche fonctionnelle et dclaircir les prconditions au dploiement du jeu (formation
des enseignants, rdaction des supports denseignements et adaptation des calendriers). Fort de
cette exprience, les prochaines exprimentations de cette ampleur devront intgrer de manire
plus importante le jeu dans la formation. titre dexemple, il serait envisageable dtudier les
missions de la campagne en TD travers la prsentation de lAPI et ltude des algorithmes
de chaque mission. Lajout de sances de TP supplmentaires ddies au jeu pourrait tre une
solution pour permettre une intgration naturelle du jeu sans dnaturer le contenu fondamental
de la discipline ou rduire son niveau acadmique. En effet, lors de cette exprimentation, la
part du jeu dans la formation na reprsent que quatre heures de travaux pratiques sur les
soixante douze heures que compte lunit denseignement. Laisser une part plus importante au
jeu srieux devrait permettre daborder les TP de manire plus progressive de faon permettre
aux tudiants de conserver une certaine initiative. De cette manire, la composante jeu sera
rvle et favorisera le dveloppement de la motivation.
5.4 Diffusion du jeu srieux

Suite la ralisation de ces trois exprimentations et la communication ralise autour de
ce projet, quelques collaborations ont pu tre inities et ont permis de dployer le jeu dans de
nouvelles formations. Pour aider les enseignants intresss par le projet, un protocole dvalua-
tion gnrique a t conu pour servir de cadre modulaire au dploiement du jeu. Ce protocole
est inspir de ceux mis en place lors des premires exprimentations.
152
5.4. Diffusion du jeu srieux
La principale nouveaut porte sur lajout dune troisime phase de manire illustrer la pos-
sibilit dutiliser le mode de jeu multijoueur (voir tableau 5.11). Cette dernire phase peut tre
aborde travers une approche par projet, o les tudiants dveloppent en autonomie leur propre
IA. Lensemble des solutions prsentes page 108 peuvent tre dployes lors de cette phase.
Si les tudiants sont autoriss communiquer entre eux, ils peuvent dvelopper des stratgies
dalliance ou de coopration, ou simplement sentraider sur des problmes de programmation.
Lorsque tous les programmes sont complets et oprationnels, la comptition peut tre organise
pour permettre aux tudiants de jouer en utilisant leurs programmes. Une attention particulire
doit tre apporte au rle des programmes, lactivit des tudiants et aux stratgies utilises.
Ces observations sont la base de la dernire tape o les tudiants et les enseignants analysent
le jeu et tentent de trouver les raisons des victoires et des dfaites.
TABLE 5.11 Organisation des enseignements avec prise en compte du mode multijoueur.
Phase 1 Phase 2 Phase 3

Prsentation de lAPI Prog&Play et
ralisation des missions de la cam- Ralisation dIA
Prsentation du
pagne et test des
jeu initial et jeu en
programmes crs
rseau Pour chaque mission
lors de parties en
(1) Prsentation des objectifs mode multijoueur
(2) Les tudiants programment
leur(s) solution(s)
(3) Institutionnalisation
Outre cette proposition dorganisation des enseignements, les questionnaires et enqutes

relatives au jeu srieux sont mises disposition des enseignants. De nombreuses informations
et documents daide sur linstallation du jeu et son utilisation sont galement disponibles sur les
pages web associes au jeu srieux 53 .
Les exprimentations prsentes ci-dessous sont donc les illustrations de la diffusion du jeu
srieux dans diverses formations.
53. http://www.irit.fr/~Mathieu.Muratet/progAndPlay.php accd le 07 Aot 2010
153
5.4.1 Premire diffusion
Cette exprimentation a t mene par Andr Pninou et Marie-Franoise Canut du dpar-

tement informatique de lIUT B de Blagnac (Toulouse II). Le jeu srieux a t dploy dans
deux units denseignement diffrentes. La premire mise en uvre a eu lieu au premier semestre
sous la forme dun soutien lapprentissage du langage C. Trente cinq tudiants, sur les cent
quinze de la promotion, ont particip trois sances dune heure et trente minutes. Ces tu-
diants ont t slectionns en fonction de leur rsultat au contrle continu dalgorithmique
(note infrieure 10/20). Lobjectif de ce soutien tait de leur faire approfondir les lments
fondamentaux du langage et les sous-programmes.
La seconde mise en uvre a eu lieu au semestre 3 sous la forme dun soutien lapprentis-
sage du langage Java. Une quinzaine dtudiants volontaires, sur les cent huit de la promotion,
ont particip aux trois sances dune heure et trente minutes. Lobjectif de ce soutien tait de
faire manipuler le concept dobjet travers le jeu. De part ce dploiement, ces enseignants
ont montr la portabilit du jeu dans un module de programmation orient objet. Les tudiants
taient utilisateurs du diagramme de classe prsent figure 4.25 page 115.
Concernant le ressenti des enseignants sur ces exprimentations, le point positif soulign
porte sur la mise en pratique originale de la programmation (contexte diffrent des ensei-
gnements classiques, retour immdiat des programmes excuts). linverse, une premire
critique porte sur la richesse de lAPI, difficile matriser par les tudiants en seulement trois
sances. Une adaptation plus approfondie aurait d tre apporte notamment pour la premire
mise en uvre. Une seconde limite concerne la ncessit, pour lenseignant, de matriser le jeu
afin de comprendre les diffrentes stratgies qui peuvent amener aux solutions de chaque mis-
sion. Cette difficult rencontre par les enseignants se retrouve dans lanalyse de la pyramide
des besoins du joueur o la satisfaction des niveaux suprieurs est relativement moyenne alors
que les bases sont particulirement bien poses (voir figures 5.13a et 5.13b).
Du point de vue de la motivation, lanalyse des questionnaires rcolts lors de la premire
mise en uvre (quarante-trois au total dont vingt-trois tudiants ayant particip au soutien)
montrent une augmentation de la motivation de 0,43 point pour les tudiants ayant particip
au soutien et une augmentation de 0,21 point pour les autres.
Enfin, sur les deux exprimentations, le principe du jeu srieux semble tre apprci par les
tudiants car 55% des tudiants ont trouv que lintroduction de la programmation augmentait
le divertissement, 29% ont trouv que lamusement tait identique et seulement 8% ont trouv
154
(7) (7)
(6) (6)
(5) (5)
(4) (4)
(3) (3)
(p) (p)
(1) (1)
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
(a) Semestre 1 - langage C. (b) Semestre 3 - langage Java.

(6) Esthtique
(4) Estime
(3) Appartenance
(2) Sret
(1) Rgles
F IGURE 5.13 Satisfaction moyenne des tudiants pour chaque niveau de la pyramide des
besoins (IUT B Toulouse II).
que cela le rduisait (8% ne se prononcent pas). Donc, 84% des tudiants estiment que le jeu
srieux est au moins aussi divertissant que le jeu sans la programmation.
5.4.2 Deuxime diffusion

Suite la premire exprimentation au dpartement informatique de lIUT A (Toulouse III),
les ressources cres sur la plateforme Moodle lors de cet enseignement ont t restructures
pour crer un squelette de cours utilisable par lensemble des dpartements de lIUT. Cet espace
est organis autour de trois thmes : la prsentation du jeu, lingnierie pdagogique associe
et les aspects techniques. Il peut tre export par les enseignants pour leur propre utilisation et
leur fournit un cadre pdagogique directement oprationnel. Lenseignant adapte alors le jeu
son contexte pdagogique et peut, son tour, distribuer ces contributions et ainsi participer au
dveloppement du jeu srieux.
Cette initiative a permis de dployer le jeu dans deux nouveaux dpartements : SeRCom
(Services et Rseaux de Communication) du site Castrais et GE2I (Gnie Electrique et Infor-
matique Industrielle) du site Toulousain.
155
Concernant le dpartement SeRCom, les enseignants (Sylvain Barreau et Emmanuel Con-

chon) ont intgr le jeu la formation initiale du premier semestre dans lunit denseigne-
ment culture technologique et dveloppement multimdia initiation la programmation .
Soixante tudiants, rpartis dans quatre groupes de TP, ont alors utilis le langage C pour raliser
la campagne du jeu sur un volume horaire dune dizaine dheures. Ce module vise lapprentis-
sage des structures algorithmiques de base et de la modularit via les fonctions. Suite cette
premire utilisation, ils envisagent de reconduire lexprience avec la mme organisation pda-
gogique (tous les tudiants, premier semestre, module Algorithmique). Toutefois, ils notent la
ncessit de mieux prparer les sances, ils proposent notamment dadapter la bibliothque
au niveau de leurs tudiants et dintgrer plus troitement le jeu au reste de la formation et
lvaluation du module dans lequel il est utilis.
Pour le second dpartement (GE2I), le jeu a t utilis dans une filire dite de remdia-
tion comprenant des tudiants en difficult. Cette filire propose un amnagement des ensei-
gnements destin permettre aux tudiants de raccrocher la formation initiale sans subir un
redoublement. Dans ce contexte, lexprimentation tait centre sur la capacit du jeu motiver
les tudiants pratiquer la programmation. Sur un volume horaire de 10 heures, quinze tu-
diants ont utilis le C++ pour rsoudre la campagne du jeu. Ces enseignements ont t conduits
par Jrmie Guiochet qui souhaite galement renouveler lexprience. Selon lui, les tudiants
ont montr leur implication en travaillant chez eux alors que cela ntait pas demand. Il note
galement que le profil des remdis est particulirement bien adapt ce projet. Par ailleurs,
Monsieur Guiochet a notamment pu mettre en place avec quelques tudiants la troisime phase
de lorganisation des enseignements prsente tableau 5.11 page 153. Lors de cette phase, les
tudiants ont adapt leur algorithme de la dernire mission pour le tester dans une session en
mode multijoueur. Enfin, Monsieur Guiochet a utilis le squelette de scnarios pour crer un
contexte de jeu original utilis pour lvaluation des TP. Dans cet examen, ltudiant contrle
une arme affaiblie compose dun Assembleur, dun Byte et de neuf Bits pour combattre une
douzaine de Bits adverses. Les questions poses traitent de la conception de fonctions et de
la manipulation de tableaux. Les tudiants doivent notamment rechercher lassembleur parmi
lensemble de ses units, trier les units endommages par capital sant croissant et les rparer,
rechercher la position de larme adverse sur la carte et lancer une attaque.
156
5.4.3 Troisime diffusion

Une dernire collaboration a t mene avec Elisabeth Delozanne et Franoise Le Calvez
de luniversit Pierre et Marie Curie (Paris VI). cette occasion, une nouvelle mission a t
ajoute la campagne qui se compose donc des sept missions prsentes page 106. Lajout
de cette nouvelle mission, par rapport aux autres exprimentations, a pour objectif de dcom-
poser le problme de la rparation (Mission 4). En effet, cet exercice est peru par les tudiants
comme tant le plus complexe, car il aborde deux difficults : la recherche dun lment dans
un ensemble ordonn et lapplication dune opration chaque lment de cet ensemble. Le
problme de la recherche est donc abord une premire fois dans la nouvelle mission 5 o le
joueur doit rechercher lassembleur parmi lensemble des units et le dplacer la rencontre de
larme. La mission 6 (anciennement numro 5) peut alors tre considre plus sereinement de
par le traitement de la recherche lors de la mission prcdente. La dernire mission a galement
t mise jour afin de proposer un dfi plus consquent pour terminer la campagne. En effet, au
cours des diffrentes exprimentations, de nombreux tudiants ont t frustrs par sa simplicit.
Une premire exprimentation a t mene avec 5 enseignants (deux en cole primaire et
trois en lyce) qui suivent un master 2 spcialit Ingnierie de la formation en ligne dans
lequel ils ont choisi une unit denseignement libre de Java. Le jeu a t utilis durant deux
sances de trois heures une semaine dintervalle. Lobjectif de cette exprimentation tait
de prendre un premier contact avec le jeu dans un contexte denseignement trs souple. Les
difficults rencontres taient principalement dordre technique (installation du jeu sur les or-
dinateurs portables des participants et la configuration du rseau). Les participants lexpri-
mentation auraient souhait un environnement simple pour installer et configurer le jeu auto-
matiquement sur leur ordinateur. Toutefois, en raison de lorientation modulaire du jeu srieux,
il semble difficile de fournir un environnement compatible avec lensemble des mises en uvre
possibles. Par consquent, il incombe aux enseignants et au service technique associ la for-
mation dinstaller le jeu et de configurer le systme pour utiliser lenvironnement de program-
mation de la formation et permettre le jeu en rseau si besoin est.
Suite ce premier test, une deuxime exprimentation a eu lieu dans le cadre dune unit
denseignement transverse oriente TICE 54 du L1 (intitule Insertion TICE ). Dans cette
UE, lenseignant propose un ensemble de projets dont un tait bas sur le jeu srieux. Il a donc
demand Elisabeth Delozanne et Franoise Le Calvez de prendre en charge quelques tu-
54. TICE : Technologies de lInformation et de la Communication dans lEnseignement
157
diants pour les faire travailler sur la rsolution de la campagne laide du langage C. Parmi
lensemble des volontaires, huit tudiants qui suivaient le module dinitiation la program-
mation imprative en C au second semestre ont t retenus.
Deux sances de deux heures en prsentiel ont t organises une semaine dintervalle
pour prsenter le jeu et les lments de programmation non traits en cours (utilisation dune
bibliothque, enregistrements, etc.). Suite cette prsentation, les trois premires missions ont
t tudies dabord laide du langage algorithmique conu lors de la deuxime exprimen-
tation (voir annexe D) puis en langage C. Le travail en binme est encourag par les enca-
drantes qui notent un rel intrt des tudiants pour le jeu lui-mme et pour linterface de la
bibliothque. Suite ces deux sances, les binmes avaient deux mois pour terminer la cam-
pagne en autonomie et prparer une prsentation sur le travail effectu. plusieurs reprises
des rendez-vous taient proposs aux tudiants pour les aider dans les difficults rencontres,
seul un tudiant a jug bon den profiter. Le jour de la soutenance, six tudiants sur huit taient
prsents. Deux tudiants ont travaill seuls et les quatre autres en binme. Les deux tudiants
absents ont demand passer la deuxime session.
Le bilan dress par Elisabeth Delozanne et Franoise Le Calvez est trs positif. Elles ont
dabord t impressionnes par la diversit des stratgies envisages et des exposs prpars.
Les tudiants ont trouv quils programmaient quelque chose de rel et ont apprci ce projet.
Les cinq tudiants qui ont termin la dernire mission ont spontanment voulu tester la stratgie
dveloppe dans un contexte de jeu rel. La motivation tait donc largement au rendez-vous.
Ce type de projet sera donc reconduit avec les adaptations suivantes : mettre en place une
session de jeu en rseau ; recommander lcriture de fonctions pour dcomposer chaque prob-
lme en sous problmes ; avant la soutenance organiser une sance de regroupement pour faire
le point, dpanner ceux qui sont bloqus et permettre ceux qui ont fini, de tester leur stratgie
contre dautres binmes ; inciter les tudiants communiquer par courriel et via la plateforme
denseignement Sakai.
Synthse des diffusions
Lors de ces collaborations, sept enseignants ont utilis le jeu dans leurs formations. Ces
quelques exprimentations supplmentaires, ralises pour certaines en totale autonomie, il-
lustrent la portabilit du jeu srieux dans diffrents contextes denseignements. De part la d-
158
marche volontaire de ces enseignants, ils ont su prendre le temps de matriser loutil et de
lintgrer dans leur projet pdagogique.
Concernant les difficults rencontres par les enseignants lors du dploiement du jeu, elles
sont essentiellement dordre technique (installation et paramtrage du jeu et configuration du
rseau pour autoriser les parties en mode multijoueur). Du point de vue de la conduite des
sances, les premires mises en uvre permettent aux enseignants de raliser quil est nces-
saire de prparer le jeu pour leurs tudiants. En effet, le jeu tel quil est distribu fournit une
base pour son dploiement mais demande tre adapt chaque contexte denseignement.
Cette prparation peut passer par une simplification des interfaces de lAPI, une adaptation du
calendrier des enseignements, lajout de nouvelles missions, etc.
Conclusion
Ces quelques exprimentations fournissent un premier retour sur le jeu srieux. Le cadre
fourni par lingnierie didactique de Cobb et al. [CCD+ 03] a permis de raliser trois itrations.
Lobjectif de la premire exprimentation consistait observer une premire confrontation entre
des tudiants et le jeu. Lvaluation a donc port sur les composantes fondamentales de ce jeu
srieux : lapprentissage, lamusement et lutilisabilit. Grce aux donnes rcoltes, lamu-
sement et lutilisabilit du jeu srieux ont t valids. Concernant lapprentissage, des donnes
supplmentaires taient requises pour valuer limpact du jeu sur cette composante.
Suite cette premire exprimentation, la question de la portabilit du jeu dans un contexte
denseignement diffrent sest alors pose. La deuxime itration sest donc centre sur cette
problmatique. cette occasion lobservation dune sance denseignement a permis de rcolter
des informations sur linfluence de lintgration du jeu sur les activits de lenseignant.
Aprs avoir vrifi la portabilit du jeu lors de la deuxime exprimentation, litration
suivante a consist dployer le jeu plus grande chelle afin dvaluer linfluence de ce dernier
sur la motivation des tudiants et son apprciation par des enseignants externes au projet. Suites
aux donnes rcoltes, trois prconditions aux dploiement du jeu ont pu tre dgages : former
les enseignants lutilisation du jeu srieux, prvoir une place suffisante pour le jeu srieux dans
le calendrier des enseignements et concevoir les ressources denseignement en consquence.
Entre ces trois itrations et la diffusion du jeu, plus de trois cents tudiants ont manipul
le jeu srieux et une vingtaine denseignants externes au projet ont pris part lencadrement
de sances. Grce lensemble des exprimentations et des commentaires laisss par tous ces
159
participants, le jeux srieux compos de la campagne prsente page 106 semble tre plus parti-
culirement adapt un public dtudiants volontaires o lencadrement laisse une place suffi-
sante au jeu.
Le dtail des donnes relatives ces exprimentations peut mtre demand cette adresse :
Mathieu.Muratet@irit.fr.
160
Conclusion des contributions
Le travail effectu dans cette thse a donc consist concevoir, raliser et valuer un jeu
srieux pour lapprentissage des fondamentaux de la programmation.
Concernant la conception, les fondements du jeu srieux sont structurs autour des modes
de jeu campagne et escarmouche o lAPI Prog&Play permet aux tudiants dinteragir avec
le jeu par la programmation. Le mode campagne est utilis pour proposer aux tudiants un
scnario original compos de missions difficult croissante. Le mode escarmouche incite les
tudiants travailler sur des projets o lobjectif final consiste relever un dfi pour remporter
une comptition finale. Dans les deux cas, les missions ou les projets posent des problmes dans
le contexte du jeu qui doivent tre rsolus par la ralisation de programmes informatiques.
Ce jeu srieux a t ralis laide du moteur de jeu de STR Spring et du jeu Kernel Panic.
Dans cet univers, une campagne compose initialement de cinq missions a volu au cours
des exprimentations jusqu atteindre les sept missions actuelles. Le choix dun jeu de STR
comme support au jeu srieux est justifi par trois composantes : cest un environnement com-
plexe propice la mise en place de problmes informatique, cest un type de jeu populaire
auprs des tudiants et de nombreux moteurs code source ouvert sont accessibles sur Internet.
Linteraction avec le jeu par la programmation est rendue possible laide de lAPI Prog&Play.
Cette API est toujours en volution de manire proposer une interface la plus simple possible
tout en conservant une interaction maximale avec des jeux de STR diffrents. Une part impor-
tante des spcifications du jeu srieux porte sur le problme de sa portabilit diffrents con-
textes denseignement. Dans ce cadre, linterface Client de lAPI Prog&Play a t traduite
dans diffrents langages de programmation adapt aux approches denseignement imprative,
oriente objet et fonctionnelle.
Grce cette ouverture, le jeu srieux a pu tre dploy dans de nombreux contextes densei-
gnements diffrents. Ces exprimentations ont permis davoir un retour sur le jeu et donnent
161
Conclusion des contributions
quelques premiers lments de rponses quant la pertinence dun tel jeu srieux pour lap-
prentissage des fondamentaux de la programmation.
162
Conclusions et perspectives
163
Ce travail de recherche sest donc attach tudier un jeu srieux sur les fondamentaux de
la programmation. Une tude prliminaire a consist positionner les jeux srieux vis--vis des
jeux vido et des simulateurs. Lobjectif de cette tude tait de bien comprendre les tenants et
les aboutissants des jeux srieux en vue den concevoir un, adapt la pratique de la program-
mation. La raison dune recherche sur ce sujet est motive par la crise de linformatique
dans lenseignement. Pour encourager les tudiants revenir vers cette discipline, lutilisation
de nouvelle solutions pdagogiques doivent tre envisages et lutilisation de jeux srieux en est
une. Pour tenter de motiver les tudiants, lapproche envisage consiste baser le jeu srieux
sur un type de jeu reconnu par les tudiants. Le choix sest orient vers les jeux de STR. Dans
ce cadre, une tude approfondie de ce type de jeu a t conduite en vue didentifier les rgles
et buts associs chaque mode de jeu. Fort de ces premires tudes thoriques, une approche
pragmatique a t envisage travers la conception, la ralisation, la mise en pratique et lval-
uation dun jeu srieux sur les fondamentaux de la programmation. Ce dernier est actuellement
structur autour de trois composantes principales : un moteur de jeu, lAPI Prog&Play et un
mode de jeu (campagne ou escarmouche).
La difficult principale de conception dun jeu srieux porte sur lintgration du message
vhiculer dune manire cohrente avec lunivers du jeu sans en dnaturer la composante
ludique. Le travail ralis lors de la conception de la campagne de Kernel Panic constitue rel-
lement lintgration du savoir enseigner dans lunivers du jeu. Lapprciation de la campagne
par les tudiants lors des diffrentes exprimentations tend valider la ralisation du jeu srieux
du point de vue du divertissement et de la cohrence des problmes poss. Du point de vue
de lapprentissage, de nouvelles exprimentations sont requises avant de tirer des conclusions
dfinitives.
Une premire perspective de travail consiste donc poursuivre les exprimentations en in-
tgrant dune manire plus consquente le jeu dans les formations. En effet, en augmentant la
prsence du jeu dans le calendrier des enseignements, linfluence de ce dernier sur les tudiants
devrait sen trouver amplifie. Il serait alors plus facile den observer les consquences relles.
Le jeu de STR a servi de cadre cette tude, mais il serait possible denvisager la ralisation
dun jeu srieux pour lapprentissage de la programmation avec dautres familles de jeux sup-
ports. Ceci pourrait permettre de proposer plusieurs types de jeux srieux de manire ce que
les tudiants puissent en choisir un en fonction de leurs prfrences. ce propos, les enqutes
ralises auprs des tudiants, sur leur pratique du jeu vido, sont poursuivre afin de conserver
un regard sur lvolution de leurs centres dintrts.
165
Une deuxime perspective de travail plus long terme consiste donc concevoir, raliser et
valuer des jeux srieux pour lapprentissage de la programmation bass sur des types de jeux
autres que les jeux de STR. Il serait alors intressant de comparer lamusement, lapprentissage
ou la facilit dintgrer le savoir enseigner pour chaque type de jeu.
Au cours du dveloppement de la bibliothque Prog&Play, la partie Client de lAPI a
t rendu compatible avec lenvironnement de programmation Scratch. Ce portage offre trois
avantages majeurs : premirement le jeu bnficie des atouts de la programmation base de
blocs (simplicit de manipulation, erreurs de syntaxe impossibles, etc.), deuximement, il prof-
ite des avantages dun environnement de programmation (interaction avec le jeu et excution
des programmes simplifis) et troisimement, il est rendu accessible un public plus jeune de
lycens et collgiens.
Cette combinaison entre Scratch et le jeu srieux forme donc une troisime perspective
de recherche pour tudier limpact de ces deux technologies sur la motivation des tudiants.
Dautre part, avec la rforme des lyces et lintgration de lalgorithmique au programme de
Mathmatiques de seconde gnrale et technologique, Scratch est nomm comme lun des outils
utilisable en classe. Par consquent, lutilisation combine de Scratch et du jeu srieux ouvre la
voie de nouveaux contextes dexprimentation sur un public plus jeune en cours dorientation.
Du point de vue des exprimentations, leffort a port sur lvaluation dun jeu srieux
abordant les fondamentaux de la programmation. ce titre, une campagne de sept missions
a t conue. Les exprimentations ralises ont t menes avec des tudiants novices voire
dbutants en programmation et ont montr un rel intrt de leur part pour ce type de pdagogie.
De nombreuses exprimentations peuvent encore tre menes et constituent une quatrime
perspective de recherche. Un premier exemple porte sur ltude de lapproche par projet asso-
cie au mode escarmouche. Ce type de mise en uvre peut laisser une part dinitiative plus
importante aux tudiants et favoriser le travail en autonomie et en quipe. Un second exem-
ple porte sur la ralisation de nouvelles campagnes pour aborder des concepts de program-
mation avancs tels que la programmation parallle ou vnementielle, les concepts orients
objet (hritage, polymorphisme, etc.) ou encore les communications rseaux. De cette manire,
le jeu srieux pourrait tre test dans des niveaux acadmiques plus levs. La confrontation du
jeu srieux avec des programmeurs confirms peut laisser place des tudes intressantes. Dans
tous les cas, lvaluation de ces exprimentations doit solliciter une attention particulire afin
didentifier les composantes responsables des rsultats obtenus (le type de jeu, Kernel Panic, le
langage utilis, linterface de lAPI Prog&Play, la mise en uvre, le mode de jeu, etc.).
166
Enfin, tout au long de ces travaux et des rencontres effectues autour de ce projet, un
questionnement rcurrent portait sur lefficacit dune telle approche base sur un jeu srieux.
Du point de vue de la motivation, les retours des tudiants et des enseignants valident lintrt
du jeu srieux. En sappuyant alors sur les travaux de Viau et du lien troit entre motivation et
performance, il est possible dinfrer une influence positive et indirecte du jeu sur les perfor-
mances des tudiants. Toutefois, il convient de ne pas gnraliser ces rsultats, en effet, il nex-
iste pas lheure actuelle de mthode pdagogique efficace pour tous les tudiants quel que soit
le contexte dapprentissage. Le jeu srieux est une solution parmi tant dautres et lexprience
accumule au cours des exprimentations permet de dfinir un cadre dans lequel lutilisation
de ce jeu srieux est envisageable. Tout dabord, le jeu srieux semble trouver sa place en tant
que complment aux formations classiques. Le soutien ou des ateliers de programmation sont
particulirement bien adapts son dploiement, car ils laissent le temps aux tudiants de con-
cevoir et raliser leurs solutions aux problmes poss (missions ou projets). Ensuite, le choix
dutiliser le jeu doit tre laiss aux tudiants. Par exemple, si un projet est envisag au cours
dune formation, deux sujets pourront tre proposs dont un sera bas sur le jeu srieux. ce
propos, si la progression du march du jeu vido continue sur sa lance, le nombre dtudiants
potentiellement intress par ce type dapproche devrait sen trouver galement augment. En-
fin, intgrer le jeu une formation suppose une double adaptation : premirement le jeu doit tre
ajust au profil des tudiants via linterface de programmation et deuximement le calendrier
des enseignements de la formation devra tre modifi pour laisser une place suffisante au jeu.
Le respect de ces trois recommandations favorisera une mise en uvre russie du jeu srieux
comme lment de dynamisation des formations informatiques, de motivation et de facteur de
russite pour les tudiants.
167
Bibliographie
[AAIC05] ACM, AIS, and IEEE-CS. Computing Curricula 2005, The Overview Report.
ACM Press. and IEEE Computer Society Press., New York, 2005.
[Abt70] C. Abt. Serious Games. University Press of America, 1970.
[AIC01] ACM and IEEE-CS. Computing Curricula 2001, Computer Science. ACM Press.
and IEEE Computer Society Press., New York, 2001.
[AIC08] ACM and IEEE-CS. Computer Science Curriculum 2008 : An Interim Revision of
CS2001. ACM Press. and IEEE Computer Society Press., New York, 2008.
[Alv07] J. Alvarez. Du jeu vido au serious game, approches culturelle, pragmatique et
formelle. PhD thesis, Universit de Toulouse, 2007.
[Ass09] Entertainment Software Association. Essential facts about the computer and
video game industry. http://www.theesa.com/facts/pdfs/ESA_EF_
2009.pdf accd le 28 juin 2010, 2009.
[Ban86] A. Bandura. Social Foundations of Thought and Action : A Social Cognitive The-
ory. Englewood Cliffs (N. J.) : Prentice-Hall, 1986.
[Ban97] A. Bandura. Self-efficacy : The exercise of control. New York : Worth Publishers,
1997.
[BF05] M. Buro and T. Furtak. On the development of a free rts game engine, March
2005. GameOnNA Conference.
[Bla05] S. Blackman. Serious games. . . and less ! SIGGRAPH Comput. Graph., 39(1) :12
16, 2005.
[Blu06] R. Blunt. Game-based learning works : Teaching business courses with video
games. In Serious Games Summit D.C., Washington, DC, USA, oct 2006.
169
Bibliographie
[BT01] P. Bettner and M. Terrano. 1500 archers on a 28.8 : Network programming an age
of empires and beyond. In GDC, mar 2001.
[Bul09] Buletin officiel n30. Mathmatiques, classe de seconde. http:
//media.education.gouv.fr/file/30/52/3/programme_
mathematiques_seconde_65523.pdf accd le 21 juillet 2010, publi le
23 Juillet 2009.
[Bur02] M. Buro. ORTS : A hack-free RTS game environment. In Computers and Games,
pages 280291, 2002.
[CB98] A. Cockburn and A. Bryant. Cleogo : Collaborative and multi-metaphor program-
ming for kids. In APCHI 98 : Proceedings of the Third Asian Pacific Computer
and Human Interaction, page 189, Washington, DC, USA, 1998. IEEE Computer
Society.
[CC07] W.-K. Chen and Y. C. Cheng. Teaching object-oriented programming laboratory
with computer game programming. IEEE Transactions on Education, 50(3) :197
203, aug 2007.
[CCD+ 03] P. Cobb, J. Confrey, A. DiSessa, R. Lehrer, and L. Schauble. Design experiments
in educational research. Educational Researcher, 32(1) :913, January 2003.
[CCMT08] T. L. Crenshaw, E. W. Chambers, H. Metcalf, and U. Thakkar. A case study of
retention practices at the university of illinois at urbana-champaign. 39th ACM
Technical Symposium on Computer Science Education, 40(1) :412416, 2008.
[CDP03] S. Cooper, W. Dann, and R. Pausch. Teaching objects-first in introductory com-
puter science. In SIGCSE 03 : Proceedings of the 34th SIGCSE technical sympo-
sium on Computer science education, pages 191195, New York, NY, USA, 2003.
ACM.
[CHHY04] D. J. Cook, L. B. Holder, M. Huber, and R. Yerraballi. Enhancing computer sci-
ence education with a wireless intelligent simulation environment. Journal of
Computing in Higher Education, 16(1), 2004.
[Cra84] C. Crawford. The Art of Computer Game Design. Osborne/McGraw-Hill, Berke-
ley, CA, USA, 1984.
[DZ03] T. N. B. Duong and S. Zhou. A dynamic load sharing algorithm for massively mul-
tiplayer online games. In The 11th IEEE International Conference on Networks,
pages 131136, 2003.
170
[Edu09] EduSCOL, Ministre de lducation nationale. Ressources pour la classe de sec-
onde - algorithmique. http://media.eduscol.education.fr/file/
Programmes/17/8/Doc_ress_algo_v25_109178.pdf accd le 21
juillet 2010, publi en Juin 2009.
[FMT06] P. Fuchs, G. Moreau, and J. Tisseau. Trait de la ralit virtuelle, Tome III., chap-
ter 1. Presses de lcole des Mines de Paris, 2006.
[FPC+ 04] S. Fincher, M. Petre, M. Clancy, T. Clear, M. Guzdial, C. D. Hundhausen, W. M.
McCracken, R. S. Rist, and J. T. Stasko. Computer Science Education Research,
chapter 1, pages 18. Taylor & Francis The Netherlands, Lisse, 2004.
[Gin04] D. Ginat. On novice loop boundaries and range conceptions. Computer Science
Education, 14(3) :165181, 2004.
[GKH07] F. L. Greitzer, O. A. Kuchar, and K. Huston. Cognitive science implications for
enhancing training effectiveness in a serious gaming context. J. Educ. Resour.
Comput., 7(3) :2, 2007.
[GS08] P. Gestwicki and F.-S. Sun. Teaching design patterns through computer game
development. ACM Journal on Educational Resources in Computing, 8(1) :122,
2008.
[Har04] K. Hartness. Robocode : using games to teach artificial intelligence. J. Comput.
Small Coll., 19(4) :287291, 2004.
[JVM05] W. Lewis Johnson, H. Vilhjalmsson, and S. Marsella. Serious games for language
learning : How much game, how much AI ? In 12th International Conference
on Artificial Intelligence in Education (AIED), Amsterdam, The Netherlands, july
2005.
[Kel06] C. Kelleher. Alice and the sims : the story from the alice side of the fence. In The
Annual Serious Games Summit DC Washington, DC, USA, October 3031, 2006.
[KLXH04] B. Knutsson, H. Lu, W. Xu, and B. Hopkins. Peer-to-peer support for massively
multiplayer games, March 2004. IEEE Infocom.
[KPK07] C. Kelleher, R. Pausch, and S. Kiesler. Storytelling alice motivates middle school
girls to learn computer programming. In CHI 07 : Proceedings of the SIGCHI
conference on Human factors in computing systems, pages 14551464, New York,
NY, USA, 2007. ACM.
171
Bibliographie
[KY05] E. Klopfer and S. Yoon. Developing games and simulations for today and tomor-
rows tech savvy youth. Tech Trends, 49(3) :3341, 2005.
[LE07] S. Leutenegger and J. Edgington. A games first approach to teaching introductory
programming. SIGCSE 07 : Proceedings of the 38th SIGCSE technical sympo-
sium on Computer science education, 39(1) :115118, mar 2007.
[MBK+ 04] J. Maloney, L. Burd, Y. Kafai, N. Rusk, B. Silverman, and M. Resnick. Scratch :
A sneak preview. In 2nd International Conference on Creating Connecting, and
Collaborating through Computing, pages 104109, Keihanna-Plaza, Kyoto, Japan,
jan 2004.
[Min05] Ministre de lducation nationale, de lenseignement suprieur et de la recherche.
Programme Pdagogique National du DUT Informatique . http://media.
enseignementsup-recherche.gouv.fr/file/77/6/776.pdf ac-
cd le 28 juin 2010, 2005.
[MTJ09] M. Muratet, P. Torguet, and J.-P. Jessel. Learning programming with an rts-based
serious game. In Otto Petrovic and Anthony Brand, editors, Serious Games on the
Move, pages 181192. Springer Vienna, 2009.
[MTJV08a] M. Muratet, P. Torguet, J.-P. Jessel, and F. Viallet. Apprentissage de la program-
mation laide dun jeu srieux. In Ludovia, page (en ligne), http://www.
ludovia.org, aot 2008. Ludovia.
[MTJV08b] M. Muratet, P. Torguet, J.-P. Jessel, and F. Viallet. Vers un jeu srieux pour en-
seigner la programmation. In Association Franaise de Ralit Virtuelle, Augmen-
te, Mixte et dInteraction 3D (AFRV), page (en ligne). AFRV, octobre 2008.
[MTJV09] M. Muratet, P. Torguet, J.-P. Jessel, and F. Viallet. Towards a serious game to help
students learn computer programming. International Journal of Computer Games
Technology, 2009 :(en ligne), 2009.
[MTVJ10a] M. Muratet, P. Torguet, F. Viallet, and J.-P. Jessel. Experimental feedback on
prog&play : a serious game for programming practice. Computer Graphics Forum,
2010.
[MTVJ10b] M. Muratet, P. Torguet, F. Viallet, and J.-P. Jessel. Experimental feedback on
prog&play, a serious game for programming practice (educational paper). In Euro-
graphics (EG), page (mdia lectronique), http://www.eg.org/, 2010. Eu-
rographics.
172
[MVTJ09] M. Muratet, F. Viallet, P. Torguet, and J.-P. Jessel. Une ingnierie pour jeux
srieux. In EIAH - Atelier Jeux Srieux : conception et usages, pages 5363.
Sbastien George et ric Sanchez, juin 2009.
[NWFR06] V. Narayanasamy, K. W. Wong, C. C. Fung, and S. Rai. Distinguishing games and
simulation games from simulators. Comput. Entertain., 4(2) :9, 2006.
[Pia94] J. Piaget. La formation du symbole chez lenfant : imitation, jeu et rve, image et
reprsentation. Paris, Delachaux et Niestl, 1994.
[PMB93] P. R. Pintrich, R. W. Marx, and R. A. Boyle. Beyond cold conceptual change :
the role of motivational beliefs and classroom contextual factors in the process of
contextual change. Educational Research, 630(2) :167199, 1993.
[PS96] P. R. Pintrich and D. H. Schunk. Motivation in Education : theory, research and
applications. Englewood Cliffs : Prentice Hall, 1996.
[SBE83] E. Soloway, J. Bonar, and K. Ehrlich. Cognitive strategies and looping constructs :
An empirical study. Communications of the ACM, 26(11) :853860, 1983.
[SC05] L. Smith and J. Cordova. Weighted primary trait analysis for computer program
evaluation. J. Comput. Small Coll., 20(6) :1419, 2005.
[SMK06] O. Seppl, L. Malmi, and A. Korhonen. Observations on student misconceptions -
a case study of the build heap algorithm. Computer Science Education, 16(3) :241
255, 2006.
[SR03] A. C. Siang and K. R. Radha. Theories of learning : a computer game perspec-
tive. In Fifth International Symposium on Multimedia Software Engineering, 2003.
Proceedings, pages 239245, dec 2003.
[Sta07] S. Stamm. Mixed nuts : atypical classroom techniques for computer science
courses. Crossroads The ACM Student Magazine, 10(4), 2007.
[Ste04] C. A. Steinkuehler. Learning in massively multiplayer online games. In ICLS
04 : Proceedings of the 6th international conference on Learning sciences, pages
521528. International Society of the Learning Sciences, 2004.
[SW06] D. E. Stevenson and P. J. Wagner. Developing real-world programming assign-
ments for cs1. In ITICSE 06 : Proceedings of the 11th annual SIGCSE confer-
ence on Innovation and technology in computer science education, pages 158162,
Bologna, Italy, jun 2006.
173
Bibliographie
[Via97] R. Viau. La motivation en contexte scolaire. Bruxelles : De Boeck, 1997.

[VMD+ 10] V. Viallet, M. Muratet, M. David, J.-L. Bach, P. Torguet, and O. Catteaun. Mutuali-
sation en iut dun jeu srieux pour lapprentissage de la programmation. In CIUEN
- Colloque International de lUniversit lre du Numrique. ( paratre), juin
2010.
[Wei92] B. Weiner, editor. Human Motivation. Newbury Park (CA) : Sage, 1992.
[Wol02] M. J. P. Wolf, editor. The Medium of the Video Game. University of Texas Press,
2002. Foreword By-Baer, Ralph H.
[Zim86] B. J. Zimmerman. Becoming a self-regulated learner : Which are the key subpro-
cesses ? Contemporary Educational Psychology, 11(4) :307313, 1986.
[Zyd05] M. Zyda. From visual simulation to virtual reality to games. Computer, 38(9) :25
32, 2005.
174
Troisime partie
Annexes
175
A
Dtail des interfaces de lAPI Prog&Play

en langage C
A.1 Interface Fournisseur
A.1.1 Types de donnes

# d e f i n e NB_COALITIONS 3
/ D e f i n i t l e s c o a l i t i o n s p o s s i b l e s /
t y p e d e f enum {
MY_COALITION ,
ALLY_COALITION ,
ENEMY_COALITION
} PP_Coalition ;
/ D e f i n i t une p o s i t i o n /
typedef struct {
float x;
float y;
} PP_Pos ;
/ D e f i n i t une l i s t e de p o s i t i o n s /
typedef struct {
int size ;
PP_Pos p o s ;
} PP_Positions ;
/ I d e n t i f i a n t d une u n i t e /
typedef i n t PP_Unit ;
177
Annexe A. Dtail des interfaces de lAPI Prog&Play en langage C
/ C o n t e n u d une u n i t e /
typedef struct {
PP_Unit i d ;
PP_Coalition c o a l i t i o n ;
int type ;
PP_Pos p o s ;
float health ;
f l o a t maxHealth ;
i n t group ;
i n t nbCommandQueue ;
i n t commandQueue ;
} PP_ShortUnit ;
/ D e f i n i t une l i s t e d u n i t e s /
typedef struct {
int size ;
PP_ShortUnit u n i t ;
} PP_Units ;
/ C o n t e n u d une commande /
typedef struct {
PP_Unit u n i t I d ;
i n t group ; / groupe d a f f e c t a t i o n /
/ Type de commande
1 : commande i n v a l i d e
0 : l a c i b l e de l a commande e s t une p o s i t i o n
1 : l a c i b l e de l a commande e s t une u n i t e
2 : l a commande n a p a s de c i b l e /
i n t commandType ;
i n t commandCode ; / c o d e de l a commande /
i n t nbParam ; / nombre de p a r a m e t t r e s /
f l o a t param ; / l i s t e d e s p a r a m e t t r e s /
} PP_ShortCommand ;
/ D e f i n i t une l i s t e de commandes /
typedef struct {
int size ;
PP_ShortCommand command ;
} PP_Commands ;
/ I d e n t i f i a n t d une r e s s o u r c e /
typedef i n t PP_Resource ;
/ D e f i n i t une l i s t e de r e s s o u r c e s /
typedef struct {
int size ;
PP_Resource r e s o u r c e ;
} PP_Resources ;
178
A.1. Interface Fournisseur
A.1.2 Enttes des fonctions
int PP_Init(void)
Initialise lAPI Prog&Play. Cette fonction doit tre appele avant lutilisation de toute
autre fonction de lAPI.
Retourne 0 en cas de succs et -1 sinon.
int PP_Quit(void)
Ferme et nettoie lAPI Prog&Play. Aprs appel de cette fonction, aucune autre fonction
de lAPI ne doit tre appele lexception de PP_Init.
int PP_NeadUpdate(void)
Retourne une valeur positive si une mise jour est demande et 0 sinon. -1 est retourn
en cas derreur.
int PP_Update(const PP_Units *units, const int *gameOver, const PP_Pos *mapSize, const
PP_Pos *startPos, const PP_Positions *specialAreas, const PP_Resources *resources)
units : nouvel ensemble des units. Si NULL, lancien ensemble est conserv.
gameOver : nouvel tat de fin de jeu. Si NULL, lancien tat est conserv. Si
*gameOver != 0, la partie est termine. Si *gameOver == 0, la partie est en cours
de droulement.
mapSize : nouvelle taille de la carte du jeu. Si NULL, lancienne taille est conserve.
startPos : nouvelle position de dpart du joueur sur la carte. Si NULL, lancienne posi-
tion est conserve.
specialAreas : nouvel ensemble des positions des zones spciales. Si NULL, lancien
ensemble est conserv.
resources : nouvel ensemble du niveau des ressources. Si NULL, lancien ensemble
est conserv.
Met jour ltat du jeu pour le client . Tous les paramtres en entre doivent tre des
pointeurs sur des donnes consistantes ou NULL. Toutes ces donnes sont recopies, il
incombe lutilisateur de librer la mmoire associe ces donnes.
PP_Commands* PP_GetPendingCommands(void)
Fournit les commandes dfinies par le client . Utiliser PP_FreePendingCommand pour
librer les commandes rcupres travers cette fonction.
Retourne les commandes dfinies par le client . NULL est retourn en cas derreur.
179
void PP_FreePendingCommands(PP_Commands *commands)

commands : ensemble des commandes en attente librer.
Libre la zone mmoire pointe par commands. Ne pas rfrencer cette zone mmoire
aprs lappel de cette fonction.
A.2 Interface Client
A.2.1 Types de donnes

# d e f i n e NB_COALITIONS 3
/ D e f i n i t l e s c o a l i t i o n s p o s s i b l e s /
t y p e d e f enum {
MY_COALITION ,
ALLY_COALITION ,
ENEMY_COALITION
} PP_Coalition ;
/ D e f i n i t une p o s i t i o n /
typedef struct {
float x;
float y;
} PP_Pos ;
/ I d e n t i f i a n t d une u n i t e /
typedef i n t PP_Unit ;
/ I d e n t i f i a n t d une r e s s o u r c e /
typedef i n t PP_Resource ;
A.2.2 Enttes des fonctions
int PP_Open(void)
Ouvre lAPI Prog&Play. Cette fonction doit tre appele avant lutilisation de toute autre
fonction de lAPI.
int PP_Close(void)
Ferme lAPI Prog&Play. Aprs appel de cette fonction, aucune autre fonction de lAPI ne
doit tre appele lexception de PP_Open.
180
A.2. Interface Client
int PP_Refresh(void)
Demande au jeu de mettre jour les donnes. Cette procdure est bloquante jusqu ce
que le jeu ait termin sa mise jour. Retourne 0 en cas de succs et -1 sinon.
int PP_IsGameOver(void)
Retourne une valeur positive si la partie est termine et 0 sinon. -1 est retourn en cas
derreur.
PP_Pos PP_GetMapSize(void)
Retourne la taille de la carte sur laquelle se droule la partie en cas de succs. La position
{-1.0, -1.0} est retourne en cas derreur.
PP_Pos PP_GetStartPosition(void)
Retourne la position de dpart du joueur sur la carte en cas de succs. La position {-1.0,
-1.0} est retourne en cas derreur.
int PP_GetNumSpecialAreas(void)
Retourne le nombre de zones spciales en cas de succs et -1 sinon.
PP_Pos PP_GetSpecialAreaPosition(int num)

num : identifiant de la zone spciale. Il doit tre inclus dans lintervalle [0; n[ o n est
le nombre de zones spciales (voir PP_GetNumSpecialAreas).
Retourne la position de la zone spciale en cas de succs. La position {-1.0, -1.0} est
retourne en cas derreur.
int PP_GetResource(PP_Resource id)
id : identifiant de la ressource dont le niveau de rserve doit tre connu.
Retourne le niveau de rserve courant en cas de succs et -1 sinon.
int PP_GetNumUnits(PP_Coalition c)
c : coalition consulter.
Retourne le nombre dunits (visibles par le joueur) de cette coalition en cas de succs et
-1 sinon.
PP_Unit PP_GetUnitAt(PP_Coalition c, int index)
c : coalition consulter.
index : ime unit visible de la coalition c. index doit tre inclus dans lintervalle [0; n[
o n est le nombre dunits visibles de la coalition c (voir PP_GetNumUnits).
Retourne la ime unit visible de la coalition c en cas de succs et -1 sinon.
181
PP_Coalition PP_Unit_GetCoalition(PP_Unit unit)

unit : unit consulter.
Retourne la coalition de lunit spcifie en cas de succs et -1 sinon.
int PP_Unit_GetType(PP_Unit unit)

Retourne le type de lunit spcifie en cas de succs et -1 sinon.
PP_Pos PP_Unit_GetPosition(PP_Unit unit)

Retourne la position de lunit spcifie en cas de succs. La position {-1.0, -1.0} est
retourne en cas derreur.
float PP_Unit_GetHealth(PP_Unit unit)
Retourne le capital sant de lunit spcifie en cas de succs et -1.0 sinon.
float PP_Unit_GetMaxHealth(PP_Unit unit)

Retourne le capital sant maximum de lunit spcifie en cas de succs et -1.0 sinon.
int PP_Unit_GetGroup(PP_Unit unit)

Retourne le numro de groupe de lunit spcifie en cas de succs. -2 est retourn si
lunit spcifie nest affecte aucun groupe. -1.0 est retourn en cas derreur.
int PP_Unit_SetGroup(PP_Unit unit, int group)
unit : unit commander. Seules les units contrles par le joueur peuvent recevoir
cet ordre.
group : groupe daffectation (>= 0). Si group == -1 alors lunit spcifie est retire de
son groupe.
Affecte lunit unit dans le groupe group.
int PP_Unit_GetNumPendingCommands(PP_Unit unit)
unit : unit consulter. Seules les units contrles par le joueur peuvent fournir cette
information.
182
A.2. Interface Client
Retourne le nombre de commandes empiles pour cette unit en cas de succs et -1 sinon.
int PP_Unit_GetPendingCommandAt(PP_Unit unit, int index)
unit : unit consulter. Seules les units contrles par le joueur peuvent fournir cette
information.
index : ime commande en attente de lunit spcifie. index doit tre inclus dans
lintervalle [0; n[ o n est le nombre de commandes empiles pour lunit unit (voir
PP_Unit_GetNumPendingCommands).
Retourne la ime commande de lunit unit en cas de succs et -1 sinon.
int PP_Unit_ActionOnUnit(PP_Unit unit, int action, PP_Unit target)
cet ordre.
action : action raliser.
target : unit cible.
Ordonne lunit unit de raliser laction spcifie sur lunit target.

int PP_Unit_ActionOnPosition(PP_Unit unit, int action, PP_Pos pos)
cet ordre.
target : position cible.
Ordonne lunit unit de raliser laction spcifie la position target.

int PP_Unit_UntargetedAction(PP_Unit unit, int action, float param)
cet ordre.
param : paramtre de laction. Si aucun paramtre nest requis pour laction spcifie,
indiquez la valeur -1.0.
Ordonne lunit unit de raliser laction spcifie avec le paramtre param.

183
A.3 Interface de gestion des erreurs
char* PP_GetError(void)
Fournit la dernire erreur gnre par lAPI Prog&Play.
Retourne la dernire erreur dfinie comme une chane de caractres termine par NULL.
Cette chane est alloue statiquement et na pas tre libre par lutilisateur.
void PP_ClearError(void)
Supprime toutes les informations de la dernire erreur gnre. Utile si lerreur a t
traite.
184
B
Implmentation de la liste de constantes de

Kernel Panic 3.8 en langage C
# i f n d e f CONSTANT_LIST_KP38
# d e f i n e CONSTANT_LIST_KP38
/
L i s t e d e s c o n s t a n t e s p o u r l e s u n i t e s d e s " S y s t e m e s " de K e r n e l P a n i c 3 . 8
/
/
i d e n t i f i a n t des u n i t e s
/
# d e f i n e ASSEMBLER 2
# d e f i n e BADBLOCK 3
# d e f i n e BIT 4
# d e f i n e BYTE 7
# d e f i n e KERNEL 24
# d e f i n e LOGIC_BOMB 25
# d e f i n e POINTER 37
# d e f i n e SIGNAL 40
# d e f i n e SOCKET 41
# d e f i n e TERMINAL 42
/
O r d r e s d i s p o n i b l e s p o u r : ASSEMBLER , BIT , BYTE , KERNEL , LOGIC_BOMB ,
POINTER e t SOCKET
/
# d e f i n e STOP 0 / attend 0 parametre /
# d e f i n e WAIT 5 / attend 0 parametre /
# d e f i n e FIRE_STATE 45 / attend 1 parametre :
0 . 0 => C e s s e r l e f e u
1 . 0 => R i p o s t e
185
Annexe B. Liste de constantes de Kernel Panic 3.8 en langage C
2 . 0 => Feu a v o l o n t e /
# d e f i n e SELF_DESTRUCTION 65 / attend 0 parametre /
# d e f i n e REPEAT 115 / attend 1 parametre :
0 . 0 => R e p e t i t i o n d e s a c t i v e e
1 . 0 => R e p e t i t i o n a c t i v e e /
/
O r d r e s d i s p o n i b l e s p o u r : ASSEMBLER , BIT , BYTE , KERNEL , POINTER e t
SOCKET
/
# d e f i n e MOVE 10 / attend 1 parametre :
une p o s i t i o n ou une u n i t e /
# d e f i n e PATROL 15 / attend 1 parametre :
# d e f i n e FIGHT 16 / attend 1 parametre :
# d e f i n e GUARD 25 / attend 1 parametre :
# d e f i n e MOVE_STATE 50 / attend 1 parametre :
0 . 0 => T e n i r p o s i t i o n
1 . 0 => M a n o e u v r e r
2 . 0 => V a d r o u i l l e r /
/
O r d r e s d i s p o n i b l e s p o u r : BIT , BYTE , KERNEL , LOGIC_BOMB , POINTER
e t SOCKET
/
# d e f i n e ATTACK 20 / attend 1 parametre :
/
O r d r e s d i s p o n i b l e s p o u r : ASSEMBLER
/
# d e f i n e REPAIR 40 / attend 1 parametre :
# d e f i n e RECLAIM 90 / attend 1 parametre :
# d e f i n e RESTORE 110 / attend 1 parametre :
# d e f i n e BUILD_BADBLOCK 3 / attend 1 parametre :
# d e f i n e BUILD_LOGIC_BOMB 25 / attend 1 parametre :
# d e f i n e BUILD_SOCKET 41 / attend 1 parametre :
# d e f i n e BUILD_TERMINAL 42 / attend 1 parametre :
# d e f i n e DEBUG 34 / attend 1 parametre :
/
O r d r e s d i s p o n i b l e s p o u r : KERNEL
/
# d e f i n e BUILD_ASSEMBLER 2 / attend 1 parametre :
186
# d e f i n e BUILD_BYTE 7 / attend 1 parametre :
# d e f i n e BUILD_POINTER 37 / attend 1 parametre :
/
O r d r e s d i s p o n i b l e s p o u r : KERNEL e t SOCKET
/
# d e f i n e BUILD_BIT 4 / attend 1 parametre :
/
O r d r e s d i s p o n i b l e s p o u r : BYTE
/
# d e f i n e LAUNCH_MINE 33395 / a t t e n d 0 p a r a m e t r e /
/
O r d r e s d i s p o n i b l e s p o u r : POINTER
/
# d e f i n e NX_FLAG 33389 / a t t e n d 1 p a r a m e t r e :
/
O r d r e s d i s p o n i b l e s p o u r : TERMINAL
/
# d e f i n e SIGTERM 35126 / a t t e n d 1 p a r a m e t r e :
/ /
/ I d e n t i f i a n t des r e s s o u r c e s /
/ /
# d e f i n e METAL 0
# d e f i n e ENERGY 1
# endif
187
C
Solution en langage C des six premires

missions de la campagne
C.1 Mission 1
# include " PP_Client . h"
# include " constantList_KP3 . 8 . h"
/ Solution Mission 1 /
PP_Pos p ; / P o s i t i o n a a t t e i n d r e /
PP_Unit u ; / Unite c o u r a n t e /
/ D e f i n i t i o n de l a p o s i t i o n c i b l e /
p . x = 1983.0;
p . y = 1279.0;
PP_Open ( ) ; / O u v e r t u r e de l API Prog&P l a y /
u = P P _ G e t U n i t A t ( MY_COALITION , 0 ) ; / R e c u p e r a t i o n de l a p r e m i e r e u n i t e /
/ Ordonner a c e t t e u n i t e de s e d e p l a c e r a l a p o s i t i o n c i b l e /
P P _ U n i t _ A c t i o n O n P o s i t i o n ( u , MOVE, p ) ;
return 0;
}
C.2 Mission 2
# i n c l u d e <math . h>
189
Annexe C. Solution en langage C des six premires missions de la campagne
d o u b l e r ; / a n g l e en r a d i a n /
PP_Pos p o s A r r i v e e ; / P o s i t i o n a a t t e i n d r e /

/ R e c u p e r a t i o n d e s c o o r d o n n e e s de l u n i t e /
PP_Pos p o s D e p a r t = P P _ U n i t _ G e t P o s i t i o n ( u ) ;
/ C a l c u l de l a n g l e en r a d i a n ( r e p e r e t r i g o n o m e t r i q u e ) /
r = 3.14159265(119+90) / 1 8 0 ;
/ C a l c u l de l a c o o r d o n n e e d a r r i v e e /
/ A t t e n t i o n : l o r i g i n e du r e p e r e e s t s i t u e en h a u t a g a u c h e de l a c a r t e /
posArrivee . x = posDepart . x + cos ( r ) 1060;
posArrivee . y = posDepart . y s i n ( r ) 1060;
/ Ordonner a c e t t e u n i t e de s e d e p l a c e r a l a p o s i t i o n c i b l e /
P P _ U n i t _ A c t i o n O n P o s i t i o n ( u , MOVE, p o s A r r i v e e ) ;
return 0;
}
C.3 Mission 3
PP_Pos b i t s ; / P o i n t de r a l l i e m e n t d e s BITS /
PP_Pos b y t e s ; / P o i n t de r a l l i e m e n t d e s OCTETS /
/ D e f i n i t i o n d e s p o i n t s de r a l l i e m e n t /
b i t s . x = 1400.0;
b i t s . y = 1371.0;
bytes . x = 479.0;
bytes . y = 1825.0;
/ E v a l u a t i o n du t y p e de l u n i t e /
i f ( P P _ U n it _ Ge t Ty p e ( u ) == BIT ) {
/ Ordonner a c e t t e u n i t e de r e j o i n d r e l e p o i n t de r a l l i e m e n t d e s BITS /
P P _ U n i t _ A c t i o n O n P o s i t i o n ( u , MOVE, b i t s ) ;
/ Passer a l u n i t e s u i v a n t e /
u = P P _ G e t U n i t A t ( MY_COALITION , 1 ) ;
190
C.4. Mission 4
/ Ordonner a c e t t e u n i t e de r e j o i n d r e l e p o i n t de r a l l i e m e n t d e s OCTETS /
P P _ U n i t _ A c t i o n O n P o s i t i o n ( u , MOVE, b y t e s ) ;
}
else {
/ Ordonner a c e t t e u n i t e de r e j o i n d r e l e p o i n t de r a l l i e m e n t d e s OCTETS /
P P _ U n i t _ A c t i o n O n P o s i t i o n ( u , MOVE, b y t e s ) ;
u = P P _ G e t U n i t A t ( MY_COALITION , 1 ) ;
/ Ordonner a c e t t e u n i t e de r e j o i n d r e l e p o i n t de r a l l i e m e n t d e s BITS /
P P _ U n i t _ A c t i o n O n P o s i t i o n ( u , MOVE, b i t s ) ;
}
return 0;
}
C.4 Mission 4
i n t i ; / Compteur de b o u c l e /
PP_Pos p o s ; / P o s i t i o n a a t t e i n d r e /
/ D e f i n i t i o n du p o i n t de r a l l i e m e n t /
pos . x = 2 5 6 . 0 ;
pos . y = 1 0 2 4 . 0 ;
/ Parcourir t o u t e s l e s u n i t e s /
i = 0;
w h i l e ( i < PP_GetNumUnits ( MY_COALITION ) ) {
/ R e c u p e r a t i o n de l u n i t e c o u r a n t e /
u = P P _ G e t U n i t A t ( MY_COALITION , i ) ;
/ Ordonner a c e t t e u n i t e de r e j o i n d r e l e p o i n t de r a l l i e m e n t /
P P _ U n i t _ A c t i o n O n P o s i t i o n ( u , MOVE, p o s ) ;
i ++;
}
return 0;
}
C.5 Mission 5
191
Annexe C. Solution en langage C des six premires missions de la campagne
PP_Pos p o s ; / P o s i t i o n a a t t e i n d r e /
/ D e f i n i t i o n du p o i n t de r a l l i e m e n t /
pos . x = 2 5 6 . 0 ;
pos . y = 8 1 1 . 0 ;
i = 0;
/ E v a l u a t i o n du t y p e de l u n i t e /
i f ( P P _ U n it _ Ge t T y p e ( u ) == ASSEMBLER) {
/ Ordonner a l ASSEMBLEUR de r e j o i n d r e l e p o i n t de r a l l i e m e n t /
P P _ U n i t _ A c t i o n O n P o s i t i o n ( u , MOVE, p o s ) ;
i = PP_GetNumUnits ( MY_COALITION ) ; / S o r t i r de l a b o u c l e /
}
else
i ++;
}
return 0;
}
C.6 Mission 6
P P _ U n i t u , a s s e m b l e u r ; / U n i t e s de t r a i t e m e n t /

/ R e c h e r c h e de l a s s e m b l e u r /
i = 0;
w h i l e ( i < PP_GetNumUnits ( MY_COALITION ) && P P _ Un i t_ G e t T y p e ( u ) ! = ASSEMBLER) {
i = i + 1;
192
C.6. Mission 6
}
/ Debuter la r e p a r a t i o n /
i f ( P P _ U n it _ Ge t Ty p e ( u ) == ASSEMBLER) {
assembleur = u ;
i = 0;
/ V e r i f i e r s i reparation necessaire /
i f ( PP_Unit_GetHealth ( u ) < PP_Unit_GetMaxHealth ( u ) ) {
/ Ordonner a l ASSEMBLEUR de commencer l a r e p a r a t i o n de l u n i t e c o u r a n t e /
P P _ U n i t _ A c t i o n O n U n i t ( a s s e m b l e u r , REPAIR , u ) ;
/ A t t e n t e de f i n de r e p a r a t i o n /
while ( PP_Unit_GetHealth ( u ) < PP_Unit_GetMaxHealth ( u ) ) {
PP_Refresh ( ) ;
}
}
i = i + 1;
}
}
return 0;
}
193
D
Ralisation dune interface algorithmique

pour le langage C : PP_ALGO.h
# i f n d e f PP_ALGO
# d e f i n e PP_ALGO

/ /
/ D e f i n i t i o n d e s m o t s c l e f s du l a n g a g e /
/ /
# d e f i n e Debut i n t main ( ) {
# define Fin }
# define Si i f (
# define Alors ) {
# define Sinon } e l s e {
# define FinSi }
# d e f i n e TantQue w h i l e (
# define Faire ) {
# d e f i n e FinTantQue }
# d e f i n e E t &&
# d e f i n e Ou | |
# d e f i n e Non !
# d e f i n e VRAI 1
# d e f i n e FAUX 0
/ /
/ D e f i n i t i o n des o p e r a t e u r s d i n t e r a c t i o n avec Kernel Panic /
/ /
/ Pour g e r e r l u n i t e c o u r a n t e /
PP_Unit c u r r e n t _ u n i t ;
195
Annexe D. Interface algorithmique pour le langage C : PP_ALGO.h
int current_id = 0;
/ Ouvre l a c o n n e x i o n a v e c l e j e u .
Cet o p e r a t e u r d o i t e t r e ap pe le avant t o u t a u t r e o p e r a t e u r /
# d e f i n e OUVRIR_JEU PP_Open ( ) ; P P _ R e f r e s h ( )
/ Ferme l a c o n n e x i o n a v e c l e j e u .
Cet o p e r a t e u r d o i t i m p e r a t i v e m e n t e t r e l e d e r n i e r o p e r a t e u r a e t r e a pp ele
a v a n t l a f i n du programme /
# d e f i n e FERMER_JEU P P _ C l o s e ( )
/ I n i t i a l i s e l u n i t e c o u r a n t e a l a premiere u n i t e c o n t r o l e e par l e j o u e u r /
# d e f i n e PREMIERE_UNITE c u r r e n t _ i d = 0 ; \
c u r r e n t _ u n i t = P P _ G e t U n i t A t ( MY_COALITION , c u r r e n t _ i d )
/ F a i t p a s s e r l u n i t e c o u r a n t e a l u n i t e s u i v a n t e c o n t r o l e e par l e j o u e u r /
# d e f i n e UNITE_SUIVANTE c u r r e n t _ i d + + ; \
c u r r e n t _ u n i t = P P _ G e t U n i t A t ( MY_COALITION , c u r r e n t _ i d )
/ F o u r n i t l a d e r n i e r e u n i t e c o n t r o l a b l e par l e j o u e u r /
# d e f i n e DERNIERE_UNITE P P _ G e t U n i t A t ( MY_COALITION , PP_GetNumUnits ( MY_COALITION ) 1)
/ I n d i q u e VRAI s i l u n i t e c o u r a n t e e s t un BIT /
# d e f i n e EST_UN_BIT ( P P _ Un i t_ G e tT y p e ( c u r r e n t _ u n i t ) == BIT )
/ I n d i q u e VRAI s i l u n i t e c o u r a n t e e s t un BYTE /
# d e f i n e EST_UN_BYTE ( P P _ U n it _ Ge t T y p e ( c u r r e n t _ u n i t ) == BYTE)
/ I n d i q u e VRAI s i l u n i t e c o u r a n t e e s t un ASSEMBLEUR /
# d e f i n e EST_UN_ASSEMBLEUR ( P P _ U n it _ Ge t Ty p e ( c u r r e n t _ u n i t ) == ASSEMBLER)
/ Donne l o r d r e a l u n i t e c o u r a n t e de s e d e p l a c e r v e r s l e s c o o r d o n n e e s i n d i q u e e s /
# d e f i n e DEPLACER_VERS ( x C i b l e , y C i b l e ) { \
PP_Pos p ; \
p . x = xCible ; \
p . y = yCible ; \
P P _ U n i t _ A c t i o n O n P o s i t i o n ( c u r r e n t _ u n i t , MOVE, p ) ; \
}
# endif
196
AUTHOR : Mathieu MURATET
TITLE : Conception, Implementation and Evaluation of a Real Time Strategy Serious Game
Dedicated to Introduce Programming Fundamentals
PhD SUPERVISOR : Pr. Jean-Pierre JESSEL
DATE OF VIVA : 2nd December 2008
ABSTRACT :
Video games are as much a part of students culture as TV, movies or books. Recently, students
are becoming less and less interested in science. Research on computer science teaching deals
with theses problems in order to find a solution to attract and retain students in computer science.
A promising solution consists in using students culture on video games in order to motivate
them to invest time in programming.
In this context, this document presents the conception, the implementation and the evaluation
of a serious game dedicated to introduce programming fundamentals. This game is based on a
real time strategy game where programming is a way to interact with the game. Thanks to the
Prog&Play system, the serious game has been evaluated in several teaching contexts.

(2011) Conception, Realisation Et Evaluation D'un Jeu Serieux de Strategie Temps Reel Pour L'apprentissage Des Fondamentaux de La Programmation

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

(2011) Conception, Realisation Et Evaluation D'un Jeu Serieux de Strategie Temps Reel Pour L'apprentissage Des Fondamentaux de La Programmation

Загружено:

Авторское право:

Доступные форматы

Conception, realisation et evaluation dun jeu serieux de

strategie temps reel pour lapprentissage des

To cite this version:

HAL Id: tel-00554287

HAL is a multi-disciplinary open access Larchive ouverte pluridisciplinaire HAL, est

MOTS-CLS : Jeux srieux, Apprentissage de la programmation, Prog&Play, Jeux de stratgie

DISCIPLINE ADMINISTRATIVE : Informatique

LABORATOIRE : Institut de Recherche en Informatique de Toulouse (IRIT)

Partie I tat de lart 7

Chapitre 1 Jeux vido, jeux srieux et simulateurs 9

Chapitre 2 Jeux de stratgie temps rel (STR) 29

2.3.2 Systmes sans serveur . . . . . . . . . . . . . . . . . . . . . . . . 38

Chapitre 3 Formation en informatique 47

Conclusion de ltat de lart 75

Chapitre 4 Conception dun jeu srieux de STR pour lapprentissage de la program-

Chapitre 5 valuation 123

Conclusion des contributions 161

Conclusions et perspectives 163

Partie III Annexes 175

Annexe A Dtail des interfaces de lAPI Prog&Play en langage C 177

Annexe B Liste de constantes de Kernel Panic 3.8 en langage C 185

Annexe C Solution en langage C des six premires missions de la campagne 189

Annexe D Interface algorithmique pour le langage C : PP_ALGO.h 195

1.1 Les Sims 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 Reprsentation du brouillard de guerre dans Dune 2. . . . . . . . . . . . . . 31

3.1 Architecture modulaire des enseignements introductifs et importance des fon-

4.1 Pourcentage de joueurs en fonction du sexe et du type de formation. . . . . . . 80

5.1 Organisation temporelle de lvaluation pour la premire exprimentation. . . . 126

Jeux vido, jeux srieux et simulateurs

1.1 Gnralits sur les jeux vido

Dans le dveloppement de lenfant, Jean Piaget introduit la rgle comme indicateur du

F IGURE 1.1 Les Sims 2.

La presse spcialise du jeu vido propose galement diffrentes classifications dpendantes

7. http://www.gamespot.com accd le 02 Avril 2010

daction, daventure, de course, de plates-formes, de rle, de simulation, de sport, de stratgie

1.2 Gnralits sur les jeux srieux

10. Namco, 1980

1.2.1 Historique et domaines dapplication

F IGURE 1.3 Premier jeu srieux : Army

F IGURE 1.4 Americas Army.

F IGURE 1.5 Darfur is dying : un jeu srieux militant.

13. http://www.tacticallanguage.com/ accd le 25 Mars 2010.

F IGURE 1.6 Influence du jeu Zapitalism

vido reprsente une difficult supplmentaire aux obstacles pistmologiques inhrents la

1.2.2 Composantes dun jeu srieux

F IGURE 1.8 Exemple daffordance dans un jeu vido.

1.3 Gnralits sur les simulateurs

1.3.1 Domaines dapplication

F IGURE 1.10 Simulateurs.

F IGURE 1.11 Croissance de ventes des jeux vido de 1996 2008.

Jeux de stratgie temps rel (STR)

2.1 Dfinition gnrale des jeux de STR fonde sur le jeu

F IGURE 2.1 Reprsentation du brouillard de guerre dans Dune 2.

Le principe de brouillard de guerre a t amlior par la suite en prenant en compte le

(a) cran de jeu du joueur A. (b) cran de jeu du joueur B.

18. Imagine Software, 1983

travers le mode escarmouche et a introduit la fonctionnalit de pouvoir slectionner

21. MicroProse, 1991

2.3 Architectures rparties

2.3.1 Systmes centraliss

F IGURE 2.4 Architecture client-serveur centralise.

2.3.2 Systmes sans serveur

F IGURE 2.5 Architecture pair pair distribue en communication point point.