Elecbyte poursuit son « CNS’s Las Hurrah », c’est à dire les améliorations qui vont être apportées au format CNS tout au long de la branche 1.x de Mugen, avant sa disparition annoncée à partir de la version 2.0.

Cette fois, Elecbyte a annoncé sur son blog l’apparition des « variables personnalisées ». Actuellement, Mugen dispose de 100 variables, réparties en 60 variables « entières » (qui ne prennent que des valeurs entières) et 40 « flottantes » (qui prennent donc des nombres à virgule), et nommées de façon uniforme : var(x) pour les variables entières, où x est un numéro allant de 0 à 59, et fvar(x) pour les variables flottantes, où x est un numéro allant de 0 à 39.

Ce système de variables permettait de faire pas mal de choses, mais restait assez limité par plusieurs points. D’une part, le nombre de variables ; si 100 variables, ça peut sembler énorme à première vue, il se trouve qu’à force, on peut rapidement atteindre cette limite, et on se retrouve à trouver des petites astuces pour réduire la consommation de variables pour un personnage (comme celle-ci). L’autre problème, c’est que toutes les variables ayant le même nom, seul l’index (le numéro) changeant, elles ne sont pas très « parlante ». Le développement d’un personnage s’étalant sur plusieurs mois généralement (voire plus, si on compte les updates), il faut soit une très bonne mémoire, soit tenir à jour une liste des variables utilisées pour savoir que var(58) correspond, par exemple, au nombre de rupees de Link tandis que la var(8) correspond au mode « invisible »…

Eh bien il sera prochainement (pas avant la version 1.1, quand même) de définir des variables avec un nom précis (comme en programmation, en fait). Il sera alors possible de mettre par exemple :

$money := 50
$invisibility := 0

Ce qui initierait une variable « money » avec une valeur de 50, et une autre variable « invisibility » à 0. On notera l’utilisation de l’opérateur d’assignation « := », relativement peu utilisé actuellement.

Les variables pourront être de type flottant ou entier, ou « flexible », c’est à dire qu’elles s’adapteront en fonction de la valeur assignée. Elecbyte étudie la possibilité de gérer également des chaînes de caractères (ex : $sex:= « male »). Néanmoins, même si Elecbyte convient de l’utilité de la chose, ce n’est pas une priorité, et cela rendrait obsolète tout ce qui utilise actuellement des chaînes de caractères. Et quid de la persistance de ces variables ? Actuellement, les variables sont remises à zéro à chaque nouveau round/match. On peut contourner ce fonctionnement via les paramètre « Int/FloatPersistIndex » du CNS et via le state 5900. Pour les nouvelles variables, leur persistance sera à définir individuellement, ce qui n’est pas plus mal.

L’autre nouveauté, ce seront des « Player variables », des variables de joueurs. Si j’ai bien compris ce que j’ai lu (désolé, c’est assez pointu pour les non-programmeurs – dont je fais partie – et donc mon interprétation peut être plus ou moins erronée ; n’hésitez pas à me corriger), il s’agirait de « mémoriser » une redirection (ou une série de redirections, puisque les redirections multiples seront alors possibles) en tant que variable pour « pointer » sur un joueur (ou helper) en particulier. Elecbyte explique qu’on peut considérer les redirections de triggers comme des « pointeurs » sur des personnages. Les variables de joueur permettraient donc de sauvegarder ces « pointeurs » afin de retrouver le personnage pointé.

J’imagine que ça pourrait être assez utile pour cibler un personnage qu’une redirection « classique » ne pourrait retrouver à coup sûr (les redirections basées sur « target » par exemple : une fois le coup fini, la redirection « target » est désactivée pour la victime du coup, alors qu’on peut encore avoir besoin d’agir sur ce personnage : on appelle alors notre « pointeur »).

Evidemment, l’utilisation de ces variables de joueur se soumettra à quelques principes de base, et notamment de vérifier si le personnage existe toujours. Car si on pointe un helper et que celui-ci est détruit (par un DestroySelf), il n’existe plus, et donc la variable ne pointera plus sur rien, ce qui provoquerait un bug.

Par défaut, les personnages « extérieurs » n’ont pas accès aux variables du joueur, à moins qu’elles n’aient été rendues « visibles » lors de leur déclaration. L’intérêt, c’est que si certaines variables permettront d’interagir avec les autres personnages, d’autres pourront rester « internes ».

C’est donc une assez grande nouveauté annoncée par Elecbyte, offrant de nouvelles possibilités, et les cas d’applications devraient être assez nombreux…

Cet article a été posté le Vendredi, avril 30th, 2010 à 18 h 41 min et est classé dans Général. Vous pouvez suivre les réponses à cet article via le flux RSS 2.0. Vous pouvez aller à la fin pour laisser un commentaire. Les trackbacks sont actuellement désactivés.