Mais ce ne sont pas les seules parties qui semblent composer un « objet jeu ». Lorsque nous avons étudié les définitions du jeu, nous avons observé que Juul (2003) définissait le jeu en tant qu‟objet de la manière suivante :
« Un jeu est un système formel basé sur des règles donnant lieu à un résultat quantifiable variable. »41
Dans la suite de ses travaux, Juul (2005), affine sa vision de « l‟objet jeu »:
« Au sens littéral, un jeu est une machine à état variable : un jeu est une machine qui peut être dans différents états, qui peut répondre de façon différente à la même entrée, qui possède des fonctions d’entrée et de sortie, ainsi que des définitions liant chacun de ses états à des données entrantes. […] Quand vous jouez à un jeu, vous interagissez avec la machine à état variable qu’est le jeu. »42 [p.60]
41
“A game is a rule-based formal system with a variable and quantifiable outcome”
42
“In a literal sense, a game is a state machine: A game is a machine that can be in different states, it responds
differently to the same input at different times, it contains input and output functions and definitions of what state and what input will lead to what following state.[…] When you play a game, you are interacting with the state machine that is the game.”
Cette notion d‟un jeu en tant que machine à état variable se retrouve également chez Dormans (2009) , qui s‟appuie sur ce postulat pour proposer un système de représentation
formel du jeu par des diagrammes (p.70) :
« Un jeu peut être vu comme une machine à état variable : il y a un état initial et les actions du joueur (ainsi que celles du jeu) amènent de nouveaux états jusqu’à ce qu’un état final soit atteint. Dans la plupart des jeux pour un seul joueur, soit le joueur gagne, soit le jeu se termine prématurément. L’état courant d’un jeu reflète généralement la position du joueur, la position des autres joueurs, des alliés, des ennemis, et la répartition actuelle des ressources du jeu. A partir de l’état courant d’un jeu, il est possible d’analyser la progression du joueur vers l’objectif qu’il doit atteindre pour gagner. »43
La vision de Dormans a été influencée par le travail de Grünvogel (2005), qui voit les jeux comme un ensemble d‟objets à état variables :
« En faisant temporairement abstraction des dimensions sociale, psychologique et culturelle, un jeu est composé d’objets dont l’état change durant la partie. Les changements d’états de chaque objet sont régit par les règles du jeu et influencés par les joueurs ou par les autres objets. »44
En résumé, ces différentes approches nous incitent à considérer le jeu comme une machine à état variable. Les états de cette machine sont eux-mêmes le fruit des changements d‟états d‟objets internes. Nous pouvons alors voir un jeu non pas seulement comme une machine à état variable, mais bel et bien comme un système à état variable, en tout cas au sens où l‟entendent Salen & Zimmerman (2003) :
« Un système est un ensemble d’éléments mis en relation de manière à former un tout plus complexe »45 [p.55]
Ce système a état variable se caractérise par la présence d‟un état initial, autrement dit l‟état du jeu lorsque la partie commence. Nous avons vu qu‟il existe de nombreux outils permettant
de créer des « niveaux », des « circuits » et autres « cartes » (p.50). Concrètement, ces
« éditeurs de niveaux » permettent au créateur de disposer un ensemble d‟objets pour créer un espace de jeu, puis de définir l‟état de départ de chacun de ces objets. Par exemple, pour un jeu de plateforme, l‟éditeur permettra de placer les différents blocs sur lesquels l‟avatar du joueur pourra marcher, mais aussi de disposer des bonus à ramasser et des ennemis. Pour les ennemis, il pourra être proposé de définir certains paramètres, comme le nombre de points de vie au départ ou l‟arme à utiliser pour attaquer le joueur. A la lumière des définitions exposées précédemment, de tels « éditeurs de niveaux » permettent tout simplement de créer
l’état initial du système à état variable qu‟est « l‟objet jeu ». Nous avons déjà mis en
évidence trois « parties » d‟un jeu tant qu‟objet : l‟interface entrante, les règles et l‟interface sortante. Nous en identifions ici une quatrième : l’état initial.
Rappelons que la création de l‟état initial d‟un jeu, bien que faisant partie du processus de « Game Design », est généralement désignée par l‟expression « Level Design » (p.45).
43
“A game can be understood as a state machine: there is an initial state or condition and actions of the player
(and often the game, too) can bring about new states until an end state is reached. In the case of many single- player video games either the player wins or the game ends prematurely. The game‟s state usually reflects the player‟s location, the location of other players, allies and enemies, and the current distribution of vital game resources. From a game‟s state the player progress towards a goal can be read”
44“Leaving aside for a moment the social, psychological and cultural aspects of a game, a game consist of
objects which change their state during the play, where the evolution of their state is governed by the rules and influenced by the players or other objects.”
45
1.3 LE MODELE ISICO
En conclusion, nous avons donc identifié quatre « parties » qui composent un jeu, la notion de « jeu » étant ici entendue comme un « objet » créé par un concepteur :
- Initial State : l‟état initial du système à état variable qu‟est le jeu.
- Input : les moyens proposés au joueur pour envoyer des informations au système. - Compute : les mécanismes internes qui permettent au système de changer d‟état. - Output : la manière dont le système communique son état courant au joueur.
Ces quatre parties sont les différentes composantes créées par un concepteur lorsqu‟il conçoit un « objet jeu ». Nous proposons d‟appeler ce modèle théorique le modèle ISICO (abréviation de : Initial State, Input, Compute, Output). Ce modèle se focalise uniquement sur les différentes composantes d‟un jeu en tant qu‟objet. Il n‟est donc pas destiné à l‟analyse des jeux, mais plutôt à l‟analyse des « outils techniques » permettant de créer des jeux. En utilisant ce modèle comme grille de lecture, il est possible de classifier les outils techniques de création vidéoludique selon les « parties » d‟un jeu vidéo qu‟ils permettent de créer.
2 A
NALYSE D’
UN LARGE CORPUS D’
OUTILS TECHNIQUESL‟objectif visé par ce travail est de présenter une sélection d‟outils techniques permettant de créer des jeux vidéo, et de les classifier par un système adapté. Les résultats attendus de cette approche exploratoire sont l‟identification d‟approches de facilitation de la création de jeux vidéo. Ces éventuelles approches seront alors évaluées pour la création de Serious Games.
2.1 METHODOLOGIE
A ce jour, il n‟existe pas à notre connaissance de liste exhaustive d‟outils techniques de création vidéoludique destinés aux amateurs. Par contre, plusieurs listes de références plus ou moins complètes existent sur Internet. Par exemple, sur le site Ambrosine nous trouvons une
liste de 125 logiciels de création vidéoludique 46, sur Wikipedia une liste de 133 moteurs de
jeu47, sur If-Wiki sont référencés 76 outils dédiés à la fiction interactive48…
2.1.1 CLASSIFICATION DE 380 OUTILS TECHNIQUES AVEC LE MODELE ISICO
Nous avons commencé par explorer et analyser ces diverses listes, que nous avons complétées par de nombreuses références supplémentaires obtenues par le biais de recherches empiriques. Tel qu‟exposé précédemment, notre attention s‟est portée sur les « usines à jeux », même si nous avons également référencés d‟autres types d‟outils (SDK, éditeur de niveaux, Jeu 2.0…), afin d‟éprouver la fiabilité de notre système de classification. Un corpus d‟exactement 380
outils techniques a ainsi été rassemblé, puis classifié selon le modèle ISICO. Pour classifier
un outil, nous avons tout simplement regardé s‟il permettait de créer et/ou modifier chacune des quatre « parties » définies par le modèle ISICO.
D‟un point de vue méthodologique, nous avons été contraints d‟effectuer des choix sur le nombre d‟entrées dans le corpus attribuées à chaque outil. En effet, comme de nombreux logiciels destinés à la création, les outils techniques connaissent une évolution constante. Pour les logiciels distribués par Internet, il est très courant de voir des mises à jour mensuelles, voire quotidiennes pour les logiciels open-source. Il est bien évident que nous n‟avons pu référencer chacune de ces versions au sein de notre corpus. Nous avons donc donné priorité
46
Relevé le 23-02-11 sur http://www.ambrosine.com/resource.php
47
Relevé le 23-02-11 sur http://en.wikipedia.org/wiki/Category:Video_game_engines
48
aux versions « majeures » des logiciels (1.0, 2.0, 3.0…), ou à défaut aux versions qui introduisent des améliorations modifiant la classification de l‟outil (passage en open-source, ajout d‟un nouveau langage de programmation…). L‟objectif d‟un tel choix est de récolter des données historiques sur le champ des usines à jeux, sans pour autant biaiser le corpus en « sur-référençant » les outils qui connaissent des mises à jour régulières.
Le modèle ISICO, prometteur lorsque seule une dizaine de logiciels étaient classifiés, a montré ses limites une fois appliqué à l‟intégralité du corpus de 380 outils techniques. Empiriquement, de nombreuses informations semblaient manquer lors de la lecture du corpus. Par exemple, face à un groupe de 307 outils permettant de créer/modifier la partie « Compute » d‟un jeu vidéo, il nous manquait des informations plus précises sur les modalités de création : utilisation ou non d‟un langage de programmation, présence ou non d‟un éditeur visuel… De même, le fait de savoir si un outil permet de créer de nouveaux jeux autonomes (usine à jeux) ou s‟il permet uniquement de modifier un jeu existant (outil de modding) semble primordial. Cette information est pourtant absente du modèle ISICO.
2.1.2 LE MODELE ISICO ETENDU
A partir de l‟analyse des caractéristiques de ce premier corpus de 380 outils techniques, nous avons donc entrepris d‟étendre le modèle ISICO en lui rajoutant des « sous-catégories » qui permettrait d‟affiner la classification de chacune de ses quatre parties. Nous avons également rajouté deux critères de premier niveau, destinés à renseigner plus précisément sur le type du logiciel. En premier lieu, chaque logiciel se verra dorénavant classé selon qu‟il permette de « créer des nouveaux jeux autonomes » ou de « modifier un jeu existant ». Nous avons également rajouté un critère pour noter la présence d‟une éventuelle « plateforme de partage intégrée », comme c‟est le cas des outils de la famille du « Jeu 2.0 » (p.200). L‟ajout de ces nouveaux critères et de sous-catégories pour chacune des quatre parties du modèle ISICO permet de définir le modèle ISICO étendu. Ce modèle est composé des critères suivants :
- Type :
o Création de nouveaux jeux autonomes OU Modification d‟un jeu existant
o Présence d‟une plateforme d‟échange intégrée
- Initial State (Etat Initial) :
o Importation (fichier texte...) o Sélection dans une librairie o Editeur visuel
- Input (Interface entrante) : o Clavier
o Souris
o Divers (joystick, manette, tapis de danse…)
- Compute (Règles) :
o Configuration de paramètres o Editeur visuel
o Langage de script propriétaire o Langage de programmation commun - Output (Interface sortante) :
o Importation (image, son…) o Sélection dans une libraire o Editeur visuel
o Représentation 2D o Représentation 3D o Représentation textuelle
A une exception près, ces critères sont tous de type « case à cocher » : pour classifier un outil, il suffit de noter si oui ou non il propose chaque caractéristique listée par le modèle.
Si nous avons déjà explicité les critères du « Type », nous pouvons faire de même pour les « sous-catégories » rajoutées aux quatre parties du modèle ISICO. « Importation » désigne le fait que l‟outil ne propose pas de moyen direct pour créer ou modifier la partie concernée, mais permet de la modifier grâce à des fichiers générés par un autre logiciel. Par exemple, l‟usine à jeux de combats M.U.G.E.N. (Elecbyte, 1999-2011) ne propose pas de moyen pour éditer l‟état initial, mais n‟importe quel éditeur de texte permettra de créer des fichiers que l‟outil interprétera à cette fin. D‟une manière plus générale, la plupart des usines à jeux permettent au créateur d‟utiliser des fichiers images ou sons qui auront été créés à l‟extérieur de l‟outil. Le critère « Sélection dans une libraire » désigne quant à lui le fait que l‟outil propose une liste de choix limités pour la partie concernée. Par exemple, le logiciel The Sims Carnival Wizard (Electronic Arts, 2008) propose de créer l‟état initial du jeu uniquement en choisissant entre trois ou quatre « niveaux » préconstruits. Si le créateur souhaite pouvoir lui- même construire son niveau à partir d‟éléments de base, il devra se tourner vers un logiciel classifié avec le critère « Editeur visuel » pour la partie « Etat Initial ». Cet « éditeur visuel » permet de créer du contenu qui n‟a pas forcément été anticipé par le créateur de l‟outil. A l‟inverse, d‟autres outils proposent des menus qui ne permettent de régler qu‟une liste de paramètres présélectionnés. Ils sont alors désigné par le critère « Configuration de paramètres ». Loin d‟être anecdotique, cette différence est fondamentale, et renvoie au fait qu‟il existe deux grandes philosophies d‟éditeurs au sein des logiciels de création vidéoludique que nous avons étudiés :
- Les menus de choix prédéfinis. Ils proposent aux créateurs de jeux une série de choix déterminés par le concepteur du logiciel. Bien que très simples à utiliser, ces outils restreignent la créativité aux limites de l‟imagination du concepteur de l‟outil. Exemples : menus d‟options permettant de configurer les règles du jeu, bibliothèques d‟éléments graphiques à sélectionner…
- Les éditeurs de contenu émergents. Il s‟agit d‟un ensemble de fonctionnalités simples qui permettent de créer du contenu « émergent », autrement dit un contenu qui n‟aura pas été forcément anticipé par le concepteur de l‟outil. Bien que plus complexes à prendre en main, ils offrent une liberté de création nettement supérieure aux menus de choix prédéfinis.
Exemples : éditeurs de dessins, langages de script, éditeurs de niveaux…
Au delà de cette distinction fondamentale, nous avons également différencié les outils ayant recours à un langage de programmation pour la partie « Compute ». Le « langage de script propriétaire » désigne un langage de programmation inventé pour le logiciel, et qui lui est généralement spécifique. Ces types de langages s‟opposent aux « langages de programmation commun » tel que BASIC, Java, C++ ou .NET, dont le champ d‟application dépasse celui d‟une gamme de logiciels unique. Les langages de scripts sont néanmoins plus simples à apprendre qu‟un langage de programmation commun pour un novice. Ils s‟inspirent d‟ailleurs très largement des langages de programmation communs qu‟ils cherchent généralement à simplifier. Toujours pour la partie « Compute », le critère « Editeur visuel » désigne les logiciels dont la programmation se fait sans passer par un quelconque langage de programmation. Dans un autre registre, nous avons également rajouté des critères sur l‟aspect « Input ». La configuration de l‟interface entrante étant généralement laissée à la discrétion du joueur par le biais de menus d‟options (p.53), nous nous sommes contentés de noter si le logiciel permettait de créer des jeux utilisant le clavier, la souris, ou d‟autres types de périphériques de contrôle. Enfin, pour l‟aspect « Output », nous classifions les outils selon
qu‟ils permettent de créer des jeux s‟appuyant sur une représentation textuelle, de graphisme 2D, ou de 3D temps réel.
2.1.3 APPLICATION DU MODELE ISICO ETENDU A UN CORPUS DE 400 OUTILS
Nous avons alors utilisé ce modèle ISICO étendu sur un corpus total de 400 outils
techniques. Ce nouveau corpus reprend la liste des 380 outils de notre premier corpus
appliqué au modèle ISICO, étoffée de 20 références supplémentaires. La classification de ce corpus de 400 outils a été reprise à zéro afin de pouvoir appliquer correctement le modèle ISICO étendu. Précisons que lors de la constitution de ce corpus, nous avons mis l‟accent sur les outils techniques de type « usines à jeux », en accord avec notre problématique (p.57). Afin d‟éprouver notre modèle classificatoire, nous y avons cependant intégré quelques outils
de « modding » (p.50). Nous étudierons brièvement leur potentiel pour le Serious Game dans
la section suivante. Nous analyserons ensuite de manière beaucoup plus détaillée les nombreuses « usines à jeux » de notre corpus (p.166), ainsi que des représentants du « Jeu 2.0 » (p.200) et quelques outils explicitement destinés aux Serious Games (p.214).
2.1.4 CONSTRUCTION D’UNE BASE DE DONNEES EN LIGNE DES OUTILS TECHNIQUES
Afin de faciliter l‟accès à notre corpus, nous avons créé un site Internet qui rassemble les 400 outils techniques que nous avons étudiés au sein d‟une base de données. Ce site permet tout d‟abord de consulter des informations basiques sur les outils : nom, année de publication, nom et pays d‟origine du développeur et de l‟éditeur, mode de diffusion…Cette base de donnée recense également les informations de classification selon le modèle ISICO étendu. Il est donc possible d‟effectuer des recherches d‟outils techniques en utilisant les différents critères de ce modèle, tel qu‟illustré par la capture d‟écran ci-dessous :