• Aucun résultat trouvé

The Games Creator : menu principal (gauche) et exemple de jeu réalisable (droite)

Le fonctionnement de cet outil dans version Commodore 64 est on ne peut plus simple. Le logiciel s‟ouvre sur une arborescence faisant office de menu principal. L‟utilisateur y dirige un curseur comme s‟il déplaçait un personnage dans un labyrinthe, à la différence que chacune des terminaisons de l‟arborescence lance un éditeur permettant de créer un « morceau » de jeu vidéo. L‟éditeur de dessin permet de créer des « blocs », qui sont rangés en trois catégories : décor de fond, obstacle, et piège. L‟utilisateur peut ensuite utiliser ces blocs pour dessiner le niveau du jeu, en les assemblant à la manière d‟un puzzle. Selon la catégorie à laquelle appartient le bloc, il aura une influence différente dans le jeu : soit de bloquer le mouvement du joueur, soit de le tuer, ou aucune s‟il s‟agit d‟un décor. Bien que les niveaux ne peuvent être dessinés que sur un seul écran, il est possible d‟appliquer un

« scrolling horizontal » au niveau, qui défilera alors en boucle. L‟éditeur de dessin permet ensuite de créer des étapes d‟animations pour les deux catégories d‟éléments de jeu : le « joueur » et les « aliens ». La première catégorie d‟élément est l‟avatar contrôlé par le joueur, dont il est possible de configurer quelques paramètres tels que la vitesse de déplacement ou la capacité de tir, dans un menu dédié. Les « aliens » sont tous les autres objets actifs à l‟écran. Selon les paramètres qui leur auront été appliqués dans le menu de configuration idoine, il s‟agira d‟ennemis à éviter, d‟objets à récolter, ou d‟une porte qui permet de passer au niveau suivant. Un dernier éditeur permet enfin de créer et associer des sons aux différents éléments du jeu. Une fois les différentes « parties » du jeu ainsi créées, il est possible de tester le jeu résultant, puis de le sauvegarder sous forme autonome. La première version de cet outil, Games Designer, fonctionne sensiblement de la même manière. Précisons tout de même que Games Designer subit les limites techniques du Commodore Vic- 20, dont les capacités graphiques sont bien plus réduites que le Commodore 64. Une autre différence notable entre les deux versions de cet outil est le menu principal d‟édition. Dans The Games Creator il s‟agit d‟une arborescence que l‟on peut parcourir de manière non- linéaire. Il est ainsi possible de travailler sur chacun des aspects du jeu à tout moment, et dans l‟ordre souhaité. Dans Games Designer, ce menu principal n‟existe pas. Une fois lancé, le logiciel propose tout simplement chacun des éditeurs les uns après les autres, dans un ordre immuable : éditeur de dessin et d‟objets, éditeur de niveau, éditeur de son, assemblage du jeu final. Le processus de création est donc relativement fastidieux pour corriger un aspect précis du jeu, car il faut relancer le programme, puis quitter les éditeurs les uns après les autres jusqu‟à tomber sur celui que l‟on souhaite utiliser. Il est ici intéressant de noter que la première version de l‟outil forçait les différentes étapes du processus de création d‟un jeu vidéo, alors que les versions suivantes laissent l‟utilisateur libre de sa méthodologie de travail. Cela nous renvoie indirectement à la question de la formalisation d‟une « série d‟étapes » du

processus Game Design observée avec les outils théoriques (p.65).

Au final, cet outil perpétue la recette imaginée par Pinball Construction Set (Bill Budge, 1983) : un ensemble d‟éditeurs spécialisés pour chaque aspect du jeu (graphisme, son, niveau, règles de jeu…), et la possibilité d‟assembler le tout pour créer un nouveau jeu vidéo autonome. En explorant un genre de jeu différent de son prédécesseur, il contribue à améliorer un principe de fonctionnement qui sera repris par de nombreux autres outils, tels que Shoot‟Em-Up Construction Kit (Sensible Sofware, 1987) pour les jeux de tir ou Game-Maker (Recreational Software Design, 1991) pour les jeux de plateforme. De plus, l‟histoire de cette usine à jeux aux multiples noms illustre parfaitement la frontière ténue entre les mondes professionnel et amateur de la création vidéoludique. Au fond, ces deux mondes sont à la recherche d‟outils leur permettant de simplifier, et donc d‟accélérer, le processus de création d‟un jeu vidéo. Si aujourd‟hui la connaissance technique requise pour utiliser les outils professionnels les mets souvent hors de portée des amateurs (p.46), dans les années 80 les premières usines à jeux disponibles étaient accessibles à tous.

1.4 ZZT, L’IMPORTANCE DE LA CREATION COMMUNAUTAIRE

Si les usines à jeux des années 80 rencontrent un certain succès grâce au développement de la micro-informatique personnelle, la dimension communautaire des concepteurs de jeux amateurs est alors relativement peu développée. En effet, faute d‟Internet, seules des communautés « locales » se créent, que ce soit dans la cour d‟une école ou autour de serveurs BBS locaux. Avec le développement des serveurs BBS internationaux, suivi de celui d‟Internet, les Game Designers amateurs voient arriver des moyens de communications plus efficaces pour échanger leurs créations. Comme nous venons de le voir, les premières usines à jeux sont principalement le fruit de passionnés ou de petites sociétés d‟édition. Dans les années 1990, l‟avènement d‟Internet permettra à ces deux catégories de développeurs de distribuer plus facilement leurs produits sous une même bannière : le « shareware ». Ce mode

de distribution particulier, hérité du monde du logiciel utilitaire, consiste à diffuser une version gratuite mais limitée d‟un programme (Callahan, 2000; Knopf & Ford, 2000). Les usagers peuvent librement télécharger cette version limitée par le biais d‟Internet, de serveurs BBS ou la trouver sur les cédéroms accompagnant des magazines spécialisés. Si le programme leur plait, ils peuvent acheter la version complète en la commandant directement à son concepteur. Facile à mettre en place et peu onéreux, ce mode de distribution a séduit de nombreux particuliers et petites structures qui commercialisent des jeux ou des logiciels utilitaires. Parmi les jeux vidéo les plus connus de la sphère du « shareware » se trouvent Wolfenstein 3D (id Software, 1992), Doom (id Software, 1993) ou encore Duke Nukem 3D (3D Realms, 1996). A noter que tous ces titres sont livrés avec un éditeur de niveaux et sont

des piliers de la pratique du « modding » (p.310).

Au sein des nombreux logiciels commercialisés par le biais du « shareware », nous retrouvons des usines à jeux, à l‟image de ZZT (Tim Sweeney, 1991). Ce logiciel permet de

créer facilement des jeux d‟action-aventure utilisant des graphismes ASCII51

. Grâce aux BBS et à un Internet naissant, les Game Designers amateurs utilisant cette usine à jeux se sont structurés en une véritable communauté de créateurs, vouée à l‟échange de réalisations et de conseils. Le nom ZZT a d‟ailleurs été choisi pour que le logiciel apparaisse en dernière position sur les listings BBS, le rendant ainsi plus facile à trouver. La création de jeux avec ZZT est on ne peut plus simple. L‟outil principal est un éditeur de niveau, qui permet de créer des « tableaux » pouvant être liés entre eux par des « passages ». Comme tous les graphismes sont tirés de la table ASCII, il n‟y a pas besoin de dessiner les objets de jeu, mais juste de choisir le caractère et la couleur souhaitée dans une liste. Le jeu propose de nombreux objets préprogrammés, comme des ennemis ou des objets à récolter. Mais il permet également de créer ses propres comportements à partir d‟un langage de script propriétaire. Un élément baptisé « object » apparaît dans la liste des objets utilisables pour construire des niveaux. En le plaçant sur la scène, l‟utilisateur peut choisir son apparence graphique, mais aussi son comportement, en utilisant un langage de script dédié. Ce dernier suit le paradigme « Orienté Objet », et propose une trentaine de méthodes allant de « déplacer l‟objet » à « tirer un projectile » en passant par la modification de variables ou l‟envoi de messages entre objets. Ce langage permet ainsi d‟appréhender une forme simplifiée de programmation évènementielle liée au contexte du jeu. Au final, ZZT semble pensé pour faciliter au maximum la création de jeux d‟action-aventure avec ses objets préprogrammés, tout en conservant la possibilité d‟enrichir considérablement lesdites aventures par le biais d‟un langage de programmation. Par contre, ZZT ne permet pas d‟exporter directement ses jeux sous forme de fichier exécutable. Pour jouer à un jeu créé avec ZZT, il faut le charger dans le logiciel. Mais ce dernier étant librement disponible par le biais du « shareware », nous pouvons considérer qu‟il s‟agit encore de « création de nouveaux jeux autonomes » et non de « modification de jeux existants », même si cet outil se trouve à la frontière des deux critères de notre modèle classificatoire (p.160).

51

Acronyme de American Standard Code for Information Interchange. Il s‟agit d‟une norme informatique pour l‟encodage des caractères. Avant l‟apparition de moteurs graphiques performant, il était possible de détourner les fonctions d‟affichage textuel d‟un ordinateur pour simuler des dessins, en utilisant notamment les caractères spéciaux définit dans la norme ASCII.

Outline

Documents relatifs