Généralités sur les scripts

Un article de Wiki-Mapping.

Jump to: navigation, search

Sommaire

[modifier] Préambule

Les scripts sont la partie de la map qui permettent la plupart des interactions entre le joueur et l'environnement. Il est a savoir que la plupart des actions non triviales mettant en cause des éléments de la map requièrent l'utilisation de scripts. Il peut être dans certains cas même plus aisé de travailler avec des scripts qu'avec des entités, et cela pour l'aspect modulable des scripts, qui permettent une infinité de choses pour la peine qu'on se donne le temps de les comprendre.

Au delà des considérations de gameplay, les scripts apportent une véritable valeur ajoutée pour ce qui concerne l'immersion, et permet des petits plus agréables et qui donnent envie de revenir sur la map. Qui n'a jamais passé le warmup a se battre pour la possession du piano de Venice? ;o)

[modifier] Les éléments de base

Un script est un fichier texte que l'on peut créer a partir de n'importe quel éditeur de texte - Wordpad fait très bien l'affaire, si vous avez un éditeur avec coloration syntaxique, c'est encore mieux ! Une fois votre fichier créé, renomer le en nom_de_votre_map.script (il est nécessaire que les extensions de fichiers soient affichées)

Afin que tout fonctionne, le script est a mettre dans le dossier /maps, a coté du .bsp

Le script en lui même se décompose en blocs qui ont chacun un identifiant unique, et qui pourront être appelés selon les besoins du mappeur. Ainsi, chaque bloc est de la forme :


 nom_du_bloc
 {
  Ici le contenu du bloc...
 }


Afin d'éviter toute erreur, il est recommandé de fermer les blocs à leur création.

A l'intérieur de ces blocs, on peut encore créer des sous-blocs indépendants, toujours identifiés de manière unique. Ces sous blocs se divisent en deux catégories :

  • ceux qui sont définis par défaut dans ET et qui sont particuliers à l'entité a laquelle ils sont liés (EvenementsAssociesAuxEntites)
  • ceux que le mappeur peut ajouter a sa guise. Ces derniers sont précédés du mot-clé "trigger"

Ce qui donne :

 nom_du_bloc
 {
 	spawn
 	{
 		Contenu du sous_bloc spawn
 		Pas besoin du trigger dans ce cas
 		Le contenu est exécuté au chargement de l'entité (avec la map & le script)
 	}
 	trigger sous_bloc_1
 	{
 	  	Contenu du sous_bloc_1
 		On pourra l'appeler quand on veut
 	}
 	trigger sous_bloc_2
 	{
  	  	Contenu du sous_bloc_2
 		Idem
 	}
 }


La liste des sous blocs définis par défaut est disponible en annexe - cf. Liste des commandes

A l'intérieur des scripts, il est possible - et recommandé - d'écrire des commentaires. Ceux-ci sont précédés de //

 Ceci est ma ligne de script... // Ceci est le commentaire qui va avec

[modifier] Les impératifs / Recommandations :

Il faut créer un bloc de script nommé game_manager qui va contenir toutes les caractéristiques de la map :

Dans le sous-bloc spawn, on y trouvera l'inititalisation des variables.

En parallèle, il est nécessaire de mettre quelque part dans la map l'entité script_multiplayer. Cette entité va appeler le bloc game_manager au chargement de la map (voir les détails de l'entité pour les clés a entrer).

Dans chaque bloc de script, il faut mettre un sous-bloc "spawn" spécifiant si nécessaire l'état initial des variables/entités liées au bloc dont il fait partie.

Il est important de bien indenter (indenter correspond à présenter le script en utilisant à bon escient les tabulations. Voir les exemples de scripts) le script que l'on écrit afin que celui-ci soit lisible - Identifier les accolades qui se correspondent avec un millier de lignes de script et des dizaines de blocs/sous-blocs devient vite impossible.

[modifier] Accum

Afin de pouvoir créer quelquechose d'évolué, il est nécessaire d'avoir a sa disposition des variables dans lesquelles ont peut stocker les valeurs dont on a besoin. Ces variables portent le nom "accum". Il en existe de deux sortes :

  • Les globalaccums -variables globales- qui sont consultables et modifiables partout dans le script
  • Les accums classiques qui sont spécifiques au bloc dans lequel ils sont placés

Le nombre d'accums étant limité, on aura donc intéret a utiliser les accums classiques afin de conserver les globalaccums pour les éléments vraiment importants - ie. ceux auxquels ont fera référence aux quatres coins du script.

On peut utiliser ces accums de deux manières :

  • l'accum prend une seule valeur comprise entre 0 et 2^32-1 (on dispose alors d'un grand nombre d'état différent, pratique pour numéroter quelquechose qui peut prendre de grandes valeurs, par exemple les plots correspondant au trajet d'un véhicule ...)
  • l'accum dispose de 32 bits prenant les valeurs 0 ou 1 (on a alors un grand nombre de variable différente pouvant exprimer le vrai/faux, cassé/réparé etc ... On s'en sert notamment pour vérifier l'état des obstacles sur le trajet d'un véhicule ...)

Il est recommandé d'écrire clairement en entête du script/bloc un commentaire expliquant à quoi correspond chaque variable/bit.

[modifier] Comment le script se declenche ?

Les scripts peuvent se declencher de 3 manières :

  • A cause d'un événement dans la partie (début de la partie, fin de la partie)
  • A cause d'un changement de statut d'une entité (fin de construction, explosion d'un func_constructible). C'est généralement causé par un joueur actionnant un trigger mais pas forcément. Par exemple, une construction non finie qui après 30s d'innactivité revient à l'état non construit.
  • A cause d'un appel venant d'un autre script.

[modifier] Annexes

[modifier] Liste des commandes :

La liste des commandes est disponible en VO (anglais) sur le site de Chruker : ici

Une traduction éxiste sur ce wiki : Liste des commandes

Les noms de sous blocs définis par défaut sont disponibles dans le tableau en fin de page.

[modifier] Sources