Show pagesource | Old revisions | Discuss this article

Recent changes

You are here: Welcome » fr » Wintermute : Le livre en ligne » 3. Premier pas dans les entrailles de WME

3. Premier pas dans les entrailles de WME

Nous avons découvert les outils et nous avons appris les bases du script, il maintenant temps de voir comment ces connaissances s'applique à la conception d'un jeu. Avant de commencer ce tour nous allons d'abord faire un bref survol des types de fichiers que vous allez utiliser dans WME (et je recommande fortement d'utiliser cette convention de nomination):

*.script – sont les fichiers qui contiennent le programme proprement dit.
*.inc – sont les fichiers Include qui peuvent être intégré dans les fichiers de script. Leur but est de vous faire économiser des centaines de lignes de code, qui serait autrement répéter dans plusieurs fichiers. Le parfait exemple de ceci est le fichier data\scripts\base.inc. Vous intégrerez ce fichier dans presque tous les scripts.
*.scene – est le fichier qui contient la définition de la scène tel que défini dans l'éditeur de scène. Bien que vous puissiez définir ce fichier à la main, c'est beaucoup plus confortable d'utiliser sceneEdit pour faire le sale boulot.
*.sprite – produit de l'éditeur de sprite
*.actor – est le fichier qui définit l'acteur et ses animations.
*.entity – est le fichier qui stocke la définition des éléments sprite.
*.font – est le fichier de définition de police. C'est une interface entre la police effective et celle de WME. Actuellement, il existe deux types de polices pris en charge - de type bitmap et true-type.
*.window – est un fichier de définition des éléments de fenêtre GUI.
*.image – s'agit d'un fichier spécial pour stocker une image (avec la possibilité de tiling, etc.) Ceci est utile pour les éléments de l'interface graphique.
*.button – est un fichier contenant la définitions des boutons.

De plus WME a quelques fichiers spéciaux prédéfinis que vous pouvez également changer, mais ceux-ci sont par défaut:

default.game et startup.settings sont des fichiers créés par le Gestionnaire de projet et stockés dans le Package (principal) du jeu.
string.tab situé au même endroit contient la table de localisation pour les textes. (TRADUCTION A REVOIR)
items.items contient la définition des objets de l'inventaire utilisé dans le jeu (data\items)
responses.def est le fichier qui définit la manière dont la fenêtre de dialogue devrait ressembler.
inventory.def est le fichier qui définit à quoi ressemble la boite de l'inventaire (data\interface)

Mais assez parlé de cela et nous allons commencer avec la chose la plus simple - les ajustements de scène. Si nous explorons le contenu de l'une des scènes créées dans l'explorateur, nous allons voir qu'il y a toujours un fichier de scène et un dossier scr qui contient le fichier scene_init.script

WME lit le fichier de scène de la scène courante, prépare tous les nœuds tel que défini dans le fichier de scène, joint tous les scripts qui sont présents dans le fichier de scène et exécute le fichier appelé scene_init.script. C'est le fichier que nous allons examiner maintenant et je vais y ajouter mes commentaires:

#include "scripts\base.inc" 
 
// voici les trucs qui initialise la scène 
actor.SkipTo(733, 562); 		// On positionne l'acteur a une certaine position 
actor.Direction = DI_DOWN;	// On définit la direction vers laquelle il fait face 
actor.Active = true;			// On fait qu'il soit visible pour cette scène 
 
///////////////////////////////////////////////////////////////////////////////////////////////////////////// 
// état de la scène 
///////////////////////////////////////////////////////////////////////////////////////////////////////////// 
global Statewarehouse; 	// On créé une variable globale qui a le même nom que la scène précédé du mot State 
 
// Valeurs par defauts 
if(Statewarehouse==null)  	//Nous lançons le jeu pour la première fois donc la valeur n'a pas été encore initialisée 
{				 
  Statewarehouse.Visited = false;  //Nous n'avons jamais été dans la scène encore 
} 
//////////////////////////////////////////////////////////////////////////////// 
// scène de configuration en fonction des variables d'état 
//////////////////////////////////////////////////////////////////////////////// 
if(!Statewarehouse.Visited) //Si nous n'avons jamais été dans la scène 
{ 
  Statewarehouse.Visited = true; //Définir que nous sommes venu ici. 
 
  // ceci est notre première visite dans cette scène ... 
}

Maintenant cela peut vous paraitre débile comme script qui ne fait rien d'autre que de vérifier si nous somme aller dans une scène ou pas, mais croyez-moi, il y a plus qu'il n'y parait. Ceci est un script vraiment très astucieux qui compte avec beaucoup de possibilités différentes. il compte pour le jeu qui a été récemment lancé, il compte pour une scène revisitée, il compte du fait que vous pouvez avoir un événement spécial à l'entré de la scène. Rappelez-vous ces moments cinématographiques quand vous avez joué à une aventure, marchant dans une scène seulement pour voir le pont s'effondrer? Vous ne voudriez pas le voir s'effondrer à chaque fois que vous visitez cette scène? C'est sûr une fois suffit.

Alors maintenant, que nous avons découvert ce qui se passe dans ce script, c'est vraiment très simple. Comme il y a des milliers de méthodes différentes, j'ai décidé de choisir la manière douce façon de les présenter si besoin, même si Max étaient très malheureux avec moi la dernière fois, j'ai consulté des approches non-violentes.

Regardons un exemple du début du script.

actor.SkipTo(733, 562);

Nous savons que les objets ont leurs méthodes qui sont identifiable par leurs notation .name();. Alors purement et simplement nous appelons la méthode skipTo () de notre objet acteur. "actor" est une variable globale qui contient un objet acteur et est déclarée dans différent script. Maintenant, quelqu'un se lève et hurle: «Vous êtes un menteur, vous nous avez dit, que chaque variable globale doit être déclarée explicitement dans le script par un mot-clé global." Ha, je répondrais, que vous avez raison.Mais elle est là, mais sagement caché dans le fichier include base.inc. Vous constatez la puissance des includes? Vous n'avez pas à déclarer un acteur, que vous utiliserez pour presque chaque script. Il vous suffit de le mettre dans le fichier include et c'est tout. Le modèle fait le reste.

Donc revenons à notre objet acteur et regardons les méthodes que nous avons vu en tout premier et ajouter deux autres méthodes très utiles:

les méthodes et attributs de l'objet acteur
actor.SkipTo(x,y); - place un acteur à une position de l'écran donnée. Toujours ré-vérifier, que cette position est à l'intérieur d'une région.
actor.Direction = ?; - est un attribut qui définit la direction dans laquelle l'acteur attend. Nous avons 8 constantes (DI_UP, DI_DOWN, DI_LEFT, DI_RIGHT, DI_UPRIGHT, DI_UPLEFT, DI_DOWNRIGHT, DI_DOWNLEFT)
actor.Active = true / false; - est un attribut commun à tous les noeuds et acteurs qui le rend actif ou inactif (Visible ou invisible).
actor.GoTo(x,y); - au lieu de placer directement l'acteur, l'acteur se dirige vers coordonnées spécifiées.
actor.Talk(string); - L'acteur dit une ligne de texte.

Donc je parie que vous êtes impatient d'essayer les nouvelles méthodes en action. Travaillons sur notre scene_init.script alors! Ouvrez le fichier scene_init.script situé dans le dossier data→scenes→warehouse→scr. Notez qu'à partir de maintenant, lorsque je ferai référence à scene_init.script vous le trouverez facilement, sans mon aide. Localisez la ligne actor.Active = true; et ajoutez quelques lignes de plus derrière celle-ci de sorte vous obteniez le résultat suivant:

actor.Active = true; 
actor.GoTo(365,561); 
actor.Direction = DI_DOWN; 
actor.Talk("Quel magnifique entrepôt!");

Enregistrez votre script et lancez le jeu depuis le gestionnaire de projet. Avant que nous continuions, nous allons parler de l'un des plus importants aspects de la programmation du jeu dans WME.WME génère un fichier appelé wme.log qui est placé dans le répertoire racine du projet. C'est un fichier erreurs où tous les problèmes, erreurs de script, etc… sont stockées.Donc, si par exemple vous faite une faute de frappe dans le script, le jeu va tout simplement alerter de l'erreur au compilateur de scripts, mais ce fichier vous indique quel fichier et quelle ligne contient cette erreur. Apprenez donc à l'ouvrir souvent ou votre travail sera très lent.

Oh-key. Bougeons et essayons quelques interactions avec la scène. Ouvrez la scène d'entrepôt (warehouse) dans l'éditeur de scène à nouveau et sélectionnez l'entité région de la porte, que nous avons créé plus tôt.

Cliquez sur le bouton scripts. Et puis sur le bouton “New script” (Nouveau script).

Dans la boite de dialogue suivante, sélectionnez modèle "empty.script" sur le côté gauche et appuyez sur OK.

Cette opération va créer un fichier vide appelé door.script et le placer dans le dossier scr.

Elle attache également le fichier à l'entité à partir de maintenant vous êtes capable de récupérer une interaction avec notre porte. Appuyez sur OK à nouveau et enregistrer votre scène. Maintenant, ouvrez le fichier nouvellement créé, qui contient les éléments suivants:

#include "scripts\base.inc" 
 
//////////////////////////////////////////////////////////////////////////////// 
//on "event" 
//{ 
//  ... 
//}

Comme vous pouvez le voir ce n'est pas très utile. Il a intégré notre bon vieil ami base.inc mais à part ça il fait rien du tout. Nous devons le développer un peu.J'ai brièvement expliqué les évènements dans le chapitre script et maintenant il est temps de les utiliser. Changer le script pour lire:

#include "scripts\base.inc" 
on "LeftClick" 
{ 
	actor.Talk("J'ai cliqué sur la porte");	 
}

Sauvegardez le script, lancez le jeu et cliquez sur la porte avec le bouton gauche de la souris. Voila! Nous venons de définir notre première interaction avec le monde du jeu. Nous allons développer plus à ce sujet mais avant je vais vous offrir une liste de la plupart des événements utiles qui sont disponibles dans WME.

on "LeftClick" – Bouton gauche de la souris a été cliqué sur le nœud (entité).
on "RightClick" – Bouton droit de la souris a été cliqué sur le nœud (entité).
on "MiddleClick" – Bouton milieu de la souris a été cliqué sur le nœud (entité).
on "LeftDoubleClick" – Bouton gauche de la souris a été double-cliqué sur le nœud (entité).
on "RightDoubleClick" – Bouton droit de la souris a été double-cliqué sur le nœud (entité).
Il y a bien plus d'événements à utiliser, mais pour le début ça devrait aller avec ces derniers.

Les scripts attachés au nœud ont une autre caractéristique intéressante, Ils sont des partie de l'objet vous pouvez donc accéder à leurs paramètres par l'identifiant this.

Faisons l'expérience un peu avec ce concept. Changer le actor.Talk pour avoir:

actor.Talk(this.Name);

Si vous sauvegardez et lancez le jeu, lorsque vous allez cliquer sur la porte l'acteur dira "Door". Ça vous dit quelque chose? Mais bien sûr, c'est le nom nous avons mis dans l’éditeur de scène.Comme vous pouvez le voir, ce que nous avons établi dans l'éditeur de scène est facilement accessible à partir du script ce qui nous amène à une autre méthode pour l'acteur:

actor.GoToObject(Node); - Va aux coordonnées spécifiées dans l'éditeur de scène dans "Walk to" et se tourne alors vers la direction indiquée au même endroit.

Mais nous savons aussi que l'entité est représentée par le mot-clé this. Ca peut pas être plus simple que ça? Essayez de réécrire votre gestionnaire d'événement pour avoir:

on "LeftClick" 
{ 
	actor.GoToObject(this); 
	actor.Talk(this.Name);	 
}

Normalement si vous avez réglé correctement les coordonnées dans l'éditeur de scène, l'acteur doit aller à la porte et dire le mot "Door".

Dernière expérience avec notre fameuse porte le moment est de régler son paramètre Active sur False et donc de désactiver le hot-spot de la porte après l'avoir cliqué.

on "LeftClick" 
{ 
	actor.GoToObject(this); 
	actor.Talk(this.Name);	 
	this.Active = false; 
}

Nous avons égratigné en surface deux objets jusqu'ici. L'objet acteur et l'objet élément Région, que nous avons référencé par mot-clé this et caché en réglant son attribut Active sur false.

Laissez-moi revenir sur l'image que nous avons vu au début et regarder cette même image d'un point de vue des développeurs.

Maintenant, ça ne vous surprendra probablement pas que l'objet principal du jeu soit appelé Game(jeu). Vous pouvez aussi voir que tout dans ce schéma est dérivé de l'objet du jeu. Si nous regardons notre entité door (porte) de ce point de vue pour voir où elle est cachée, nous devrions aller par ce chemin:

Game → Scene → Door.

Nous savons que nous pouvons référencer un Scène comme Scène, mais ne vous laissez pas tromper.1)La scène est, dans la démo, en réalité définie dans le game.script qui est le cerveau maitre du jeu comme cela:

Scene = Game.Scene;

Dans base.inc notre scène est définie comme la global Scene; et parce que nous incluons base.inc dans tous nos fichiers, nous pouvons facilement faire référence un objet Scène de partout.

Comme on peut le deviner, l'objet jeu servirait pour des besoins globale du jeu tandis que l'objet Scene serait utile pour les opérations par scène. Laissez-moi vous présenter les fonctions les plus utilisées qui représentent très bien chaque objet.

Game.ChangeScene(filename); est une fonction qui change la scène. Il prend comme arguments un chemin vers le fichier. Scène
Scene.GetNode(NodeName); est une fonction qui retourne l'objet nommé NodeName de la scène.

Nous allons voir maintenant, quelque-chose qui va démontrer la puissance de WME. Retournez à votre scène de l’entrepôt (warehouse) dans l’éditeur de scène et apportons-y quelques modifications. Premièrement nous devrions créer une nouvelle région et l’appeler Exit. La positionner dans le coin inférieur gauche comme sur l'image suivante (vous devriez immédiatement découvrir à présent que c'est la forme rouge). Notez aussi la position dans l'arborescence de la scène. Si vous la placé au dessus le sol (floor), le mécanisme présenté ne fonctionnera pas parce que la région floor recouvrirai la région Exit et de cette façon la région Exit ne serais jamais vue. La dernière chose qui reste à faire est d'attacher un script à cette région. Utilisez un modèle vierge et enregistrer la scène.

Avant de poursuivre, nous allons discuter de deux autres événements(Nous connaissons déjà les événements en lien avec la souris).

on "ActorEntry" survient lorsque l'acteur entre dans la région courante. Ceci est la logique de base derrière ce qu'on appelle les régions pièges. Région piège signifie que l'acteur déclenche un événement en entrant dans certaine zone de l'écran.
on "ActorLeave" survient lorsque l'acteur quitte la région courante.

La dernière chose qui nous aurions besoin pour cet exemple est de prendre au joueur le contrôle du jeu.Ceci est la partie vitale d'une conception de jeu réussie. Nous voulons déclencher une scène et en plein milieu le joueur clique ailleurs, le personnage n'a pas fini toute la séquence et vous êtes coincé dans une boucle interminable.C'est le genre de cauchemar qu'ont rencontrés de nombreux créateurs nous allons donc l'éviter tant que c'est encore possible.

Game.Interactive = true / false; Prend le contrôle du jeu au joueur ou lui rend. Toujours se rappeler de remettre le jeu en mode interactif ou votre jeu va bloquer et les joueurs vont se fâcher. Il faut donc toujours penser au mode non-interactif comme un bloc.(avec un début et une fin)

Nous allons essayer de combiner ces idées dans notre premier jeu à logique complexe.

D'abord nous allons modifier le door.script pour qu'il ressemble à ça:

on "LeftClick"   
{ 
	Game.Interactive = false;    // Nous voulons que notre joueur fasse plusieurs choses à la fois et nous ne voulons pas être interrompu. 
	actor.GoToObject(this); 
	this.Active = false;  // Nous désactivons la porte afin que le hot-spot ne soit plus visible ou active du tout. 
	actor.Talk("Oh non. La porte est soudé.");	 
	Game.Interactive = true; // Permet au joueur de jouer de nouveau. 
}

Ensuite nous ouvrons le exit.script et ajoutons un nouvel événement dedans. Le fichier devrait ressembler à ça:

#include "scripts\base.inc" 
 
on "ActorEntry"  //L'acteur entre dans la région Exit 
{ 
	Game.Interactive  = false; 
	var door = Scene.GetNode("Door"); // Nous mettons dans la variable nommé door un objet correspondant au nom de porte de la scène 
 
	if (door.Active) // Si la porte n'a pas été cliqué, elle n'a pas été désactivé, ce voie sera utilisé 
	{ 
		actor.Talk("Je ne veux pas retourner à mon appart avant d’être sûr que je ne peux pas entrer dans l'entrepôt!"); 
	}	 
	else //nous savons que la porte est soudée donc nous pouvons quitter la scène 
	{ 
		actor.Talk("Eh bien, il n'y a vraiment aucun moyen d'entrer dans ce foutu entrepôt"); 
		Game.ChangeScene("scenes\room\room.scene"); 
	} 
	Game.Interactive = true; 
}

Okay. Il est temps de vous expliquer ce qui se passe là. Notre processus de réflexion comme un concepteur de jeu que le joueur est besoin d'entrer dans l’entrepôt mais la porte est soudée. Pour une raison quelconque, nous avons besoin que notre joueur découvre le fait que la porte est soudée de sorte que le jeu puisse continuer. Nous décidons donc de l'autoriser à changer de scène seulement après qu'il n'ai découvert que la porte de l’entrepôt est soudée.

Explication du code, nous avons la région qui devrait normalement être utilisé comme une région de sortie, mais nous avons ajouté la condition que tant que la région de la porte (door) était active (Ce qui veut dire que le joueur n'as pas cliqué dessus, parce que s'il l'avait fait la région de la porte serais passée inactive), le joueur ne peut pas quitter l'écran.

Sauvegarder tous les scripts et lancer le jeu. Testez le jeu à fond de sorte que vous soyez sûr que vous comprenez vraiment le codage derrière cette logique. C'est l'un des aspects essentiels de la conception de jeu d'aventure et si vous y arrivé bien, vous saurez en un rien de temps créer vos propres aventures.

Important:
Chose essentielle à savoir c'est comment fonctionne les chemins dans WME en général. Nous avons vu dans Game.ChangeScene("scenes\room\room.scene"); que nous n'avons pas commencé par le chemin des données. C'est tout à fait correcte! Écrivez-ça mille fois – Je n'inclurais jamais le nom du Package racine dans le chemin référencé. Pourquoi? Parce que cela fonctionnerait uniquement en mode debug, et lorsque vous compilez votre jeu dans les packages et le distribuez, ça ne marchera pas. La même chose s'applique à tous les fichiers (images, sons, etc.) Jamais référencer les fichiers en dehors des packages. Ils fonctionnerons en mode débogage, mais ne serons pas compilé et vous serez dans le pire des cauchemars. Pensez au Packages comme des répertoires racines virtuels et que tout référencement devrait partir de ce point. On en saura plus à ce sujet dans le chapitre sur les Packages.

Passons à la dernière partie de ce chapitre, qui couvrira les problèmes de Daemon (programme fonctionnant en tache de fond). Nous allons commencer tout de suite avec notre premier démon(Daemon). Avant d'expliquer comment ca marche, nous allons jeter un œil sur quelques nouvelles méthodes:

Game.AttachScript(filename); - Attache un nouveau fichier de script à l'objet jeu (Game), ce qui le rend global pour le jeu entier. Ce script est attaché jusqu'à ce qu'il soit détaché ou se termine.
Game.DetachScript(filename); - Détache un script de l'objet jeu (Game).

Scene.AttachScript(filename); - Attache un nouveau fichier de script à la scène courante, le rendant actif tant que le joueur ne change pas de scène courante, ou qu'il soit détaché ou se termine.
Scene.DetachScript(filename); - Détache un script de l'objet Scène.

Nous pouvons évidemment attacher un script à l'objet Scène dans l'éditeur de scènes ou un script à l'objet Jeu (Game) dans le gestionnaire de projets, mais nous voulons que notre script soit attaché au milieu du jeu.

La commande suivante que nous allons apprendre est absolument nécessaire pour écrire les Daemons. C'est la commande Sleep.

Sleep(time); - Met en pause le script pendant un certain nombre de millisecondes.

Sleep a deux fonctions. Première - il permet au script d'attendre certaine quantité de temps, et la deuxième - elle donne la main au flux du programme pour d'autre tâches. Là c'est le piège typique des Daemon:

var a = 0; 
while (1) // Boucle sans fin, c'est pareil que while(true) 
{ 
   a = a + 1; 
   if (a > 100) a = 0; 
}

Ne jamais faire cela. Ça va stopper votre ordinateur.Le Script prend toute la puissance de traitement et le reste du jeu ne peu plus reprendre le contrôle. En faisant cela, Windows non plus ne pourra recuperer la main ce qui entraine une extinction de l'ordinateur. Alors comment résoudre ce problème?

var a = 0; 
while (1) 
{ 
   a = a + 1; 
   if (a > 100) a = 0; 
   Sleep(1);		 
}

Ce Daemon est correcte (Souvenez vous du chapitre précédent), parce que ca peut reprend la main sur le script. Une milliseconde c'est ici symbolique. Le fait important est que vous donner la main.

Bon assez de théorie et façon quelques Daemon marrants avec les commandes que nous venons juste de voir. Oh attendez. Nous aurions besoin d'une commande supplémentaire:

Game.Msg(text); - Bien que nous l'ayons vu auparavant rappelons qu'elle affiche un message de débogage à l'écran.

Ce que nous allons faire est un drôle de petite séquence chronométrée, qui va se passer dans notre scène de l'entrepôt. Le scenario est le suivant. Le joueur examine la porte et découvre qu'il y a une bombe attachée dessus. S'il ne sort pas assez rapidement, la scène est rechargée (c'est la façon "fan d'aventures hardcore" de dire au joueur, qu'il est mort).

Premièrement nous allons créer le nouveau script dans le répertoire scr (à partir d'un modèle vierge (Empty template) ) et le nommer bomb.script.

Astuce : si vous êtes plus expérimenté, vous pouvez ajouter les nouveaux fichiers manuellement en créant un fichier texte avec une extension script créé dans le dossier correspondant.

Ensuite modifiez door.script pour avoir cela:

#include "scripts\base.inc" 
 
on "LeftClick"   
{ 
	Game.Interactive = false;    // Nous voulons que notre joueur fasse plusieurs choses à la fois et nous ne voulons pas être interrompu. 
	actor.GoToObject(this); 
	this.Active = false;  // Nous désactivons la porte afin que le hot-spot ne soit plus visible ou active du tout. 
	actor.Talk("Oh non. Il y a une bombe à retardement attachée à la porte! Je doit m’échapper avant qu'elle n'explose.");	 
	Scene.AttachScript("scenes\warehouse\scr\bomb.script"); 
	Game.Interactive = true; // Permet au joueur de jouer de nouveau. 
}

J'ai ajouté la ligne qui attache notre nouveau script et donc démarre le compte à rebours.
Maintenant regardons le contenu de bomb.script.

#include "scripts\base.inc" 
 
for (var timer=6;timer>-1;timer = timer -1)  // Mettons en place une boucle qui passerait de 6 à 0. 
{ 
	Game.Msg("compte à rebours: " + timer); //Affichons combien de temps il nous reste 
	Sleep(1000); // Pause une seconde (et laisse aussi la main au jeu pour d'autres tâches) 
} 
 
Game.Interactive = false; //Scène de la mort 
actor.Talk("J'suis mort. Essayez encore."); 
Game.ChangeScene("scenes\warehouse\warehouse.scene"); 
var door = Scene.GetNode("Door"); 
door.Active = true; // Si nous mourons, nous avons besoin de remettre la porte à son état actif ou nous ne pourrons pas découvrir la bombe de nouveau. 
Game.Interactive = true;

Et le dernier changement que nous allons faire est dans exit.script. Si vous trouvez la sortie à temps, l'acteur doit pouvoir s’échapper, mais s'il y arrive juste à temps et tout en disant sa ligne, le temps passe et qu'il meurt? Alors nous allons éviter cela en détachant le script de la bombe et le laisser parler ça serait quelque chose de plus raisonnable.

Donc le contenu de exit.script devrait ressembler à ça:

#include "scripts\base.inc" 
 
on "ActorEntry" 
{ 
	var door = Scene.GetNode("Door"); 
	Game.Interactive = false; 
	if (door.Active) 
	{ 
		actor.Talk("Je ne veux pas retourner à mon appart avant d’être sûr que je ne peux pas entrer dans l'entrepôt!"); 
	}	 
	else 
	{ 
		Scene.DetachScript("scenes\warehouse\scr\bomb.script"); 
		actor.Talk("Ouf. C'était juste"); 
		Game.ChangeScene("scenes\room\room.scene"); 
	} 
	Game.Interactive = true; 
}

Sauvegardez tout et testez notre petit système pour voir un peu plus sur les effets.

Pour clore ce chapitre je vais ajouter un petit changement à notre système. Ce changement n'est pas nécessaire dans notre exemple, mais il le serais dans d'autres cas. Pour le moment nous avons testé, si l'entité région door est active pour prendre une décision. Mais que faire si nous avons besoin d'appliquer cette même logique sur plus d'une scène? Si nous nous tenons dans une scène différentes, logiquement nous ne pouvons pas utiliser une entité de cette façon parce qu'elle ne fait plus partie de la scène courante.

Donc ce que nous pouvons faire c'est d'utiliser une variable globale. Faisons un changement dans nos scripts alors!

Ainsi la derniere liste de code de ce triplet de script sera :

bomb.script

#include "scripts\base.inc" 
 
for (var timer=6;timer>-1;timer = timer -1)  // Mettons en place une boucle qui passerait de 6 à 0. 
{ 
	Game.Msg("compte à rebours: " + timer); //Affichons combien de temps il nous reste 
	Sleep(1000); // Pause une seconde (et laisse aussi la main au jeu pour d'autres tâches) 
} 
 
Game.Interactive = false; //Scène de la mort 
actor.Talk("J'suis mort. Essayez encore."); 
var door = Scene.GetNode("Door"); 
door.Active = true; // Si nous mourons, nous avons besoin de remettre la porte à son état actif ou nous ne pourrons pas découvrir la bombe de nouveau. 
global doorClicked = false; 
Game.ChangeScene("scenes\warehouse\warehouse.scene"); 
Game.Interactive = true;

door.script

#include "scripts\base.inc" 
 
on "LeftClick"   
{ 
	Game.Interactive = false;    // Nous voulons que notre joueur fasse plusieurs choses à la fois et nous ne voulons pas être interrompu. 
	global doorClicked = true; 
	actor.GoToObject(this); 
	this.Active = false;  // Nous désactivons la porte afin que le hot-spot ne soit plus visible ou active du tout. 
	actor.Talk("Oh non. Il y a une bombe à retardement attachée à la porte! Je doit m’échapper avant qu'elle n'explose.");	 
	Scene.AttachScript("scenes\warehouse\scr\bomb.script"); 
	Game.Interactive = true; // Permet au joueur de jouer de nouveau. 
}

exit.script

#include "scripts\base.inc" 
 
on "ActorEntry" 
{ 
	var door = Scene.GetNode("Door"); 
	Game.Interactive = false; 
	global doorClicked; 
	if (!doorClicked) 
	{ 
		actor.Talk("Je ne veux pas retourner à mon appart avant d’être sûr que je ne peux pas entrer dans l'entrepôt!"); 
	}	 
	else 
	{ 
		Scene.DetachScript("scenes\warehouse\scr\bomb.script"); 
		actor.Talk("Ouf. C'était juste"); 
		Game.ChangeScene("scenes\room\room.scene"); 
	} 
	Game.Interactive = true; 
}

Nous avons vu dans ce chapitre quelques astuces intéressantes avec la façon dont on peut gérer la logique du jeu. Nous avons aussi appris quelques notions importantes pour lier les scène au code et nous sommes capable d'utiliser un certain nombre de commandes et de méthodes objet très basiques. Mais pour le moment nous avons tout le temps utilisé un grand nombre de codes d'une démo pré-compilés. Le prochain chapitre est au sujet du démarrage d'un projet à partir de zéro. Nous allons partir d'un projet vierge jusqu'à créer un jeu tout simple compilé. Alors restez à l'écoute, on y va.

1) Rappelez-vous ce problème de notation imbriqué?

fr/wmebook/ch3.txt · Last modified: 2011/10/25 13:49 by Anto0085

Show pagesource | Old revisions | Discuss this article