Après quelques retours d'expériences sur la communication du jeu ou d'autres aspects moins techniques, l'Atelier Sentô retourne aujourd'hui sur Wintermute pour aborder un sujet important à tout programme : les variables et leurs usages récurrents.
De même qu'une horloge cache, derrière son apparence épurée, un réseau incompréhensible de rouages, un jeu vidéo doit son fonctionnement à des mécanismes secrets d'une grande complexité. Les graphismes et le gameplay ne sont que la partie émergée de l'iceberg. Comme nous utilisons un moteur de jeu simplifié, la majorité de ces mécanismes nous sont inconnus. Heureusement quelques outils très simples nous sont proposés pour personnaliser notre jeu. Parmi ceux-ci, les variables sont d'une importance capitale : une variable est comme une petite boîte qui contient une information. Cette information peut être une affirmation/négation (true/false), un nombre entier (1, 2, 3, …), un nombre décimal, un texte, ...
La mémoire du jeu
Imaginons un jeu vidéo où le joueur explore un manoir à la recherche d'un trésor, caché dans la cave. Quand le joueur commence sa partie, il ne sait pas où le trésor est enterré et on ne veut surtout pas qu'il le trouve en cliquant au hasard. On va donc désactiver par défaut la zone interactive du trésor.
Dans la bibliothèque du manoir, il y a un livre qui indique la localisation du trésor. Quand le joueur lit ce livre, il sait où est le trésor. Lorsque, ensuite, il descendra dans la cave, la zone interactive devra être activée pour qu'il puisse y cliquer et déterrer son butin.
Il faut savoir que dans un jeu, quand on quitte une scène, celle-ci est effacée de la mémoire pour n'être rechargée qu'au moment où on y entre à nouveau. En conséquent, le jeu oublie les actions effectuées dans une pièce au moment où le joueur la quitte. Si le jeu se souvenait de tout, sa mémoire serait saturée ! Les variables sont le moyen idéal de transporter une information entre deux scènes, en l'occurrence la bibliothèque la cave.
Créons une variable, appelons-là « variableLivre » et donnons-lui la valeur « false ». Tant que cette valeur reste négative, impossible de trouver le trésor. Mais dès que le joueur lit le livre, on change sa valeur pour « true ».
Maintenant réglons la zone interactive du trésor pour qu'elle s'affiche quand le joueur descend dans la cave et que « variableLivre = true ». Et voilà, le tour est joué ! Le joueur ne pourra déterrer le trésor qu'après avoir lu l'indice dans le livre.
Les variables sont comme des post-it qu'on punaiserait au mur pour garder trace des informations importantes, tout au long de notre aventure.
Pointer du doigt
Autre usage récurrent dans Wintermute, les variables servent à désigner un élément du jeu (une image, une zone interactive, un personnage...). Par exemple, on écrit :
Mizuka = Game.LoadActor("actors\mizuka.actor");
On vient de créer une variable « Mizuka » qui pointe vers les fichiers de notre personnage principal. Maintenant, à chaque fois qu'on écrira « Mizuka », le jeu saura exactement de qui on parle et on pourra facilement donner des ordres comme :
Mizuka.GoTo(850, 1300);
Mizuka.Direction = DI_DOWN;
Ce qui peut se traduire par : « Mizuka, s'il-te-plaît, peux-tu marcher jusqu'à ce point là-bas et te placer face à nous ? Merci !»
Pratique, non ?
Grâce aux variables, la programmation d'un jeu est considérablement simplifiée. On a même parfois l'impression d'écrire un scénario, avec des phrases normales. Il faut dire que Wintermute propose un langage clair et parfaitement adapté aux point & click. Pour les profanes que nous sommes, c'est un vrai soulagement !
Fil d'actualités
-
27/11/240
Sommaire
- Partie 1 - Présentation d'Atelier Sento
- Partie 2 - Premiers pas et prototype
- Partie 3 - Souvenirs d'Okinawa
- Partie 4 - Présentation du moteur Wintermute
- Partie 5 - Gérer les acteurs dans Wintermute
- Partie 6 - Guider le personnage
- Partie 7 - La mise en place des décors
- Hors série - Les jours où ça n'avance pas !
- Partie 8 - L'enregistrement des sons
- Partie 9 - Les énigmes
- Partie 10 - Les musiques
- Partie 11 - Communiquer en s'amusant
- Partie 12 - Un jeu made in tout le monde
- Partie 13 - Dans 60 ans...
- Partie 14 - Le scénario
- Partie 15 - L'intégration des personnages
- Partie 16 - Le regard des joueurs
- Partie 17 - Les variables
- Partie 18 - La traduction anglaise
- Partie 19 - En route pour 2016
- Partie 20 - Un chat pas comme les autres
- Partie 21 - La gestion de l'inventaire
- Partie 22 - La création de cutscenes
- Partie 23 - Faire bêta-tester son jeu
- Partie 24 - Interview de Nick Preston
- Partie 25 - Interview de Thorn
- Partie 26 - Anatomie d'une scène : l'idée de départ
- Partie 27 - Anatomie d'une scène : l'énigme
- Partie 28 - Anatomie d'une scène : le croquis
- Partie 29 - Rencontre avec le studio Ernestine – 1ère partie
- Partie 30 - Rencontre avec le studio Ernestine – 2e partie
- Partie 31 - Du papier à l'écran
- Partie 32 - L'école des fantômes
- Partie 33 - Développer un jeu avec des lycéens
- Partie 34 - Faire connaître son jeu
- Partie 35 - Sur les routes de France
- Partie 36 - Éloge des gribouillis
- Partie 37 - Un jeu dessiné par des enfants
- Partie 38 - La naissance d'un projet
- Partie 39 - Mélanger 2D et 3D
- Partie 40 - Adventure Creator
- Partie 41 - Designer des personnages
- Partie 42 - The Doll Shop
- Partie 43 - Donner de la profondeur
- Partie 44 - Des personnages en kit
Comments
Salut ! Génial comme article, au moins grâce à vous les joueurs auront plus conscience de la complexité de scripter un jeu entier.
Au fait, pour parler technique, je vois que vous codez en javascript, je me demande sur quel moteur vous êtes, sa ne ressemble pas à du Unity3D.
Mais pour détailler un peu plus le codage (pour ceux qui lisent jusqu'à la fin), sachez qu'en plus de devoir apprendre à coder une première fois, il faut pratiquement tout réapprendre lorsque qu'on change de langage de programmation (javascript, C#, C++...) ou de moteur de jeu (unity3d, Unreal engine, cryengine...).
C'est cool de voir des explications pour les néophytes. Cela dit, je penses que de bonnes pratiques sont importantes pour une gestion du code propre (et un code propre évite beaucoup de problèmes !) et if(toto==false) n'est pas une bonne protique , préférez lui une méthode retournant la valeur de toto, par exemple if(!toto()), sauf si toto est un variable de la classe alors ce n'est pas nécessaire , bien que je pense que le principe d'encapsulation doit être le plus souvent respecter ( le php est pas terrible pour ça d'ailleurs je trouve). Enfin bon tout ça pour dire d'éviter les variables globales (càd qui sont accessible partout dans le programme) car c'est une horreur en programmation et dangereux qui plus est . je conseil la lecture de coder proprement (qui n'est malheureusement plus éditer)
Je pense qu'au niveau où les variables sont utilisées dans ce jeu et présentées comme concept dans cet article, on est très loin de tenter de faire un cours des "bonnes pratiques" et c'est avant tout destiné au néophytes pour avoir une idée de la chose, d'autant que l'Atelier Sentô a appris sur le tas comme ils ont eu l'occasion de l'expliquer dans quelques articles
A je ne dis pas ça pour être désobligeant, je dis juste qu'une fois une mauvaise habitude installée c'est difficile de s'en défaire ( je sais de quoi je parle ^^)
Je ne l'ai pas pris de façon désobligeante, ne t'inquiète pas. Mais on est loin d'aller dans le genre de considérations à base de classes, de variable de classe, d'encapsulation, de méthodes ou même d'objet en général étant donné qu'on en est à "apprendre" l'utilité des variables.
Oui, je sais bien ... Et c'est normal il faut bien commencer ... et c'est très bien ainsi, c'était juste une petite remarque en passant parce que je sais à quel point ces principes peuvent être difficile à respecter même pour un dev expérimenté
Merci, Seldell !
えぇ?!あなたちはおきなわに行きますか?BDはとてもいいですよ。<3
いいえ、じょうだんですよ。沖縄へ行きたいですが、行けません。ゲームはまだ終わってないのです。
この漫画が好きでしたか。よかったです。どうもありがとう。:)
Non, mais alors, qu'est ce que j'ai rit en lisant la BD !!! Rien que pour ça bravo !!
Pages