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
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
On est contents que ça t'ait plu !
En LUA ça marche aussi :
varMalDeTete = 100
varAspirine = 30
if (varMalDeTete - varAspirine) > 50
then The_Icehouse = false
endif
--*commentaire: Help!!*--
Tu oublies varTisane, l'arme suprême pour éviter le false !
Attention, certains puristes te diront qu'une ligne de code ne doit jamais dépasser 80 caractères (parce que oui, on a encore des écrans en 320x240 :p).
Du coup il faut toujours écrire :
pour un booléen.
Pour être embêtant un peu ... oui sauf qu'une de 80 caractères sera probablement plus lisible (si bon nommage), qu'une de 250
Sans blague, on peut écrire ça ??!!
Il faut absolument que je teste !
En fait, je voulais juste titiller les puristes des "bonnes pratiques" en informatique.
Par exemple, je préfère écrire if(var == false) plutôt que if(!var). C'est plus visuel quand on lit du code à la va-vite.
Après, c'est bien de respecter les bonnes pratiques, mais je pense qu'il ne faut pas être psycho-rigide avec ça.
PS : Très bonne explication seldell, bravo
En fait, le if évalue ce qu'il y a entre parenthèses. Si c'est vrai, alors il fait ce qu'il y a dans la condition, sinon il ne le fait pas.
Ce qui est entre parenthèse doit rendre au final "vrai" ou "faux". Donc vous pouvez évaluer directement le contenu d'un booléan (true/false) qui est la situation la plus simple, soit évaluer le résultat d'une comparaison, comme toto==5, ou phrase=="coucou" qui sera traduit en vrai ou faux.
Du coup tester if(toto==vrai) c'est identique à tester if(toto) puisque la condition regarde déjà si ce qu'il y a dans la parenthèse est vrai sans avoir à le marquer. De la même manière, vous pouvez très bien mettre une valeur à une variable de la façon suivante :
toto = (val == 5);
Ici, le membre de droite doit être simplifié par l'ordi pour pouvoir stocker la valeur dans la variable toto. Donc le programme vérifiera d'abord le (val == 5) et le transformera en un booléan vrai ou faux qu'il pourra associer à toto. Par exemple :
val = 5;
toto = (val == 5); // (sera compris ici comme toto = true; après évaluation du membre de droite )
Merci ! Ca a l'air tout simple quand c'est bien expliqué par quelqu'un qui s'y connait !
Et comme le montre votre capture d'écran, les commentaires sont importants aussi.
Pages