Pas besoin de vous inscrire pour télécharger / No need to register for downloading.
Une fois inscrit, vous devez m'envoyer un mail pour valider votre compte / Once registered, you must send me an email for validating your account.
 S'enregistrer  |  FAQ  |  Lexique  |  Rechercher  |  Liste des Membres  |  Groupes d'utilisateurs 

 Annuaire  |  Connexion 

 Ce forum en page de démarrage

 Informations pratiques 
 Merci de lire les règles ! 

   Télécharger le sujet
04. Les bases de la programmation (suite)
Mike Werewolf
Loup-garou

Site Admin


Inscrit le: 07 Oct 2004
Messages: 1676
Karma: 52
plus / moins

Localisation: France
Répondre en citant
On rentre à présent dans le coeur de la programmation. Je vous conseille de garder Mugen Help ou Mugen Doc sous la main pour voir à quoi se rapportent les fonctions dont je parlerai (notamment le sctrl ChangeState).

On l'a vu dans le 01), les states sont donc comme des "mini programmes". Ils décrivent les différents mouvements du persos.

Les states se décomposent en deux parties : tout d'abord un "statedef" qui indique le début du state et un ou plusieurs "state controller" qui exécutent diverses actions. On ne délimite pas la fin d'un state. C'est la fin du fichier ou le début du state suivant qui marque la fin d'un state.

Attention, il arrive qu'on désigne un state controller par le terme "state". C'est le contexte qui permet de déterminer de quoi on parle. Par exemple : "dans quel state se trouve ton perso" = state ; "Faut utiliser un state -2 pour changer la variable" = state controller.

Le StateDef :

Il indique le début du state, et contient quelques paramètres optionnels. Voici la présentation complète d'un statedef :

Code:
[Statedef 200]
type = S
movetype = A
physics = S
anim = 200
velset = 0,0
ctrl = 0
poweradd = 100
juggle = 2
facep2 = 0
hitdefpersist = 0
movehitpersist = 1
hitcountpersist = 1
sprpriority = 3


On va détailler tout ceci.

Un statedef (et donc un state) commence toujours par une ligne [Statedef X] où X représente le numéro de state. On peut pratiquement utiliser n'importe quel numéro pour les states, mais il y a quand même des states réservés : de 0 à 199 (actions de base) et de 5000 à 5999 (touché + quelques actions diverses). Ces states sont utilisés dans le common1.cns.

Contrairement aux states controllers, on ne met pas de "repère" dans le statedef. On ne peut donc pas avoir [Statedef 200, stand light punch].

La suite, ce sont les paramètres du state, tous optionnels.

type : c'est la "position" du mouvement. Il peut avoir 5 valeur : S (Stand = debout), C (Crouch = accroupi), A (Air = aérien), L (Lying down = gisant au sol) et U (Unchanged = inchangé par rapport au précédent state utilisé par le joueur). Par défaut, la valeur est "S".

Exemples :
type = S : type = C :
type = A : type = L :

movetype : c'est le type de mouvement que l'on réalise. Il en existe 4 : U (pour unchanged, inchangé), H (Hit, touché par un coup), A (attack = attaque) et enfin I (Idle = "oisif" = tout ce qui n'est ni du H ni du A). La valeur par défaut est "I".

Exemples :
movetype = H : movetype = A
movetype = I

physics : c'est la "loi physique" que l'on va appliquer au personnage. On retrouve les valeurs principale du "type" (S, C, A, U) qui correspondent aux mêmes choses, plus une valeur N (None = aucune loi physique). Concrètement, si vous mettez S ou C, votre perso subira une "friction" qui le fera ralentir (en C, la friction est plus importante). Qu'est-ce que la friction ? C'est simplement le fait que même si on donne une vitesse constante au perso, il va peu à peu ralentir, car il "frotte" au sol lors de son déplacement. La friction est définie dans les constantes du perso.
Si vous mettez un physics = A, cette fois, votre perso subira les lois physiques de la gravité (donc même si vous lui donner une vitesse pour le faire monter dans les airs, il aura tendance à redescendre). L'autre effet de la gravité, c'est que lorsque votre personnage est au niveau du sol ou au-dessous, il passe automatiquement en state d'atterrissage (state 52 du common1.cns).
Bien évidemment, la plupart du temps, on fait correspondre le type et le physics.

Anim : c'est l'anim qui sera joué depuis le fichier AIR du personnage dès le début du state. Pour que l'animation ne change pas avec le début du state, ne mettez pas ce paramètre. Valeur défaut : même anim que le state précédent.

Velset : c'est la vitesse (en pixel par tick) qui sera donnée à votre perso au début du state. C'est l'équivalent d'un controller VelSet qu'on appliquerait avec un trigger "time = 0" (on y reviendra, ne vous inquiétez pas si ça ne vous parle pas !). Valeur par défaut : vitesse inchangée. Très souvent, le numéro d'anim correspond au numéro du state, mais ce n'est pas toujours le cas. Faites-le lorsque vous le pouvez, c'est beaucoup plus simple si vous avez à faire des recherches dans le CNS ou le AIR.

Ctrl : Le contrôle est un flag (comprenez, il vaut 1 si on l'a, 0 sinon). Il indique si le joueur qui contrôle le perso peut ou non effectuer une action. Explication : lorsque vous êtes en stance (debout, inactif), vous avez le contrôle, car si vous appuyez sur une touche, un coup sortira, si vous appuyez sur les flèches, le perso se déplacera. En revanche, lorsque vous sortez un coup, la plupart du temps, vous n'avez pas le contrôle : pendant que vous faites ce coup, si vous appuyez sur un des boutons ou sur les directions, il ne se passera rien. Ce paramètre du StateDef permet donc de fixer si, durant ce state, votre personnage aura ou non le contrôle. Pour être complet, il fixe la valeur du trigger "Ctrl" au début du state. Valeur défaut : 1.

Poweradd : C'est le power qui va être attribué au personnage pour avoir réalisé la commande. On se sert notamment de ce paramètre pour les hypers : on mettra un poweradd de -1000 pour un hyper utilisant une barre de power par exemple. Il a la même fonction qu'un PowerAdd déclenché sur un trigger "time = 0". Valeur défaut : 0.

Juggle : Le juggle ("jonglerie" en anglais) est un système de points qui permet de jongler avec l'adversaire, lorsque celui-ci est en chute dans les airs ("fall"). On ne se sert de ce paramètre que pour les states d'attaque. On a déjà vu dans les constantes (airjuggle) comment fonctionnait le juggle donc je n'y reviens pas. Valeur défaut : 0.

Exemple de fall :

Facep2 : Ce paramètre, s'il vaut 1, force le joueur à se tourner face à son adversaire s'il ne l'est pas au début du state.

Hitdefpersist : S'il vaut 1, les hitdefs du state précédent restent actifs. 0 par défaut.

Movehitpersist : S'il vaut 1, ce paramètre évite la réinitialisation des triggers MoveContact, MoveHit & MoveGuarded à 0 lors du passage du state précédent à ce state. 0 par défaut.

Hitcountpersist : A 1, le compteur de coups (trigger HitCount - combien de fois cette attaque a touché) du state précédent sera conservé dans ce state. A 0 (valeur par défaut), le compteur de coups sera réinitialisé lors du changement de state. Ce paramètre n'affecte pas le compteur de combo qui est affiché à l'écran. Voir la documentation sur les triggers hitcount et uniqhitcount pour voir comment vérifier le compteur de coups.

Sprpriority : Définit la priorité d'affichage des sprites. Les sprites ayant un sprpriority faible seront affichés au-dessous de ceux ayant un sprpriority élevé. La valeur de sprpriority est comprise entre -5 et +5. Par défaut, la valeur du sprpriority est inchangée.

Exemple, sur ce shot, Clara est affiché par-dessus KFM, parce que Clara a un sprpriority supérieur à celui de KFM :


La plupart du temps, on ne se sert pas de tous ces paramètres. Ceux que vous devez retenir sont surtout les suivants :
* type
* movetype
* physics
* anim
* ctrl
* velset
* juggle
* sprpriority (dans une moindre mesure)

Passons à la seconde partie du state :

Les State Controller :

D'abord, notez qu'on utilise plusieurs terme pour les désigner : state controller, controller, sctrl, et même state. Les state controller sont des fonctions "d'action" (entendez : "qui réalisent une action") par opposition aux triggers qui sont des fonction "d'information" (qui récupèrent des informations sans agir).

On va ensuite avoir en gros un sctrl pour chaque action à réaliser dans ce state (ou plusieurs, selon la complexité de l'action à réaliser). Il faut donc décomposer chacune des actions à accomplir. Exemple pour un coup normal :
- Afficher l'anim du coup
- Jouer un bruitage
- Définir le coup lui-même
- Revenir en stance

-> Afficher l'anim du coup, ça c'est réalisé par le StateDef, paramètre anim
-> Jouer un bruitage => On utilisera un sctrl "PlaySnd"
-> Définir un coup => On utilisera ensuite un sctrl "HitDef"
-> Revenir en stance => On utilisera enfin un sctrl "ChangeState".

Et notre State se présentera ainsi :

Code:
[State 200]
type = S
movetype = A
physics = A
anim = 200
ctrl = 0
velset = 0,0
juggle = 2
sprpriority = 2

[State 200, Bruitage]
type = PlaySnd
...

[State 200, Coup]
type = HitDef
...

[State 200, Retour en Stance]
type = ChangeState
value = 0
...


Découper ainsi chaque action à réaliser dans un state permet de "simplifier" en quelque sorte le code à créer. En effet, le fait de poser les "grandes lignes" d'un coup ou d'un mouvement vous permet de voir où vous aller, de ne pas avancer à l'aveuglette. Cette méthode fonctionne aussi bien avec un coup normal qu'avec un hyper ; simplement, le nombre d'action à réaliser sera plus grand. En faisant ainsi, on ne se retrouve plus avec un mouvement "immense" à coder, mais avec une succession de petites actions qui, additionnées les unes aux autres, donneront ce mouvement "immense".

Comment se présente un state controller ? En fait, on en a déjà vu, dans le CMD. Eh oui, rappelez-vous de la seconde partie :
- Elle commence par un [Statedef -1] (qui n'a aucun paramètre)
- Elle est suivie de plusieurs [State -1] avec un type précis.

En fait, la seconde partie du CMD est donc un immense et unique state. Ce state est particulier parce qu'il est négatif et qu'il fonctionne de façon un peu spéciale, mais à la base, c'est un state !

Revenons à nos sctrl : ils se construisent tous de la même façon (state -1 ou non) :
- Un [State X], où X correspond normalement au numéro du statedef dans lequel est placé le sctrl (donc -1 dans le CMD, puisqu'on a un [StateDef -1], et 200 dans l'exemple ci-dessus, puisqu'on a un [Statedef 200] juste avant). Cependant, même si le numéro ne correspond pas, le sctrl se déclenchera du moment qu'il est dans le state.
- Comme on l'a vu pour le CMD, on peut faire suivre le numéro d'un d'un repère (ici : "Bruitage", "Coup" et "Retour en Stance" sont des repères), en séparant le numéro et le repère par une virgule.
- La ligne suivante est "type = " suivi du nom du sctrl qu'on va utiliser.
- Ensuite, il y a plusieurs possibilités, mais classiquement, on opère ainsi : dans les state -1, on rajoute le paramètre "value" (paramètre du sctrl "ChangeState"), et en dernier, on met les triggers ; dans les autres state, c'est l'inverse : juste après le type, on met les triggers, et ensuite les paramètre de la fonction. Vu que le CMD a été vu, je reste sur la seconde présentation : on met les triggers (qu'on verra la prochaine fois ! ^^), et ensuite les paramètres. Il faut au minimum un trigger par sctrl.

Les paramètres se divisent en 3 catégories :
- Les paramètres "universels" optionnels. Ce sont des paramètres qu'on peut utiliser dans n'importe quel Sctrl (d'où leur qualificatif "universel"). Il en existe deux : ignorehitpause et persistent. Je reviendrais dessus plus loin.
- Les paramètres obligatoires de la fonction. Là, reportez-vous à la doc de la fonction pour les connaître. Par exemple, pour ChangeState, il y a un paramètre obligatoire qui est "value", qui correspond au numéro du state dans lequel on doit placer le perso.
- Les paramètres optionnels de la fonction. Idem, reportez-vous à la doc de la fonction. Par exemple, pour ChangeState, il y a deux paramètres optionnels qui sont "ctrl" et "anim".

Les paramètres universels :
ignorehitpause : lorsque votre perso frappe ou est frappé par un coup, il y a une courte pause, pour "marquer" l'impact. C'est ce qu'on appelle la hitpause. Durant cette pause, théoriquement, les sctrl ne sont pas vérifiés par Mugen. Cependant, si vous incluez ce paramètre en lui donnant une valeur de 1 (ignorehitpause = 1), dans ce cas, votre sctrl sera vérifié même pendant la hitpause. Valeur par défaut : 0 (le sctrl n'est pas vérifié pendant la hitpause).

persistent : les conditions d'activation d'un sctrl dans un state sont vérifiées à chaque tick, tant que le perso se trouve dans ce state. Cependant, il y a certaines fonctions qu'on ne souhaite déclencher qu'une seule fois, ou du moins, pas à chaque fois. Dans ce cas, on a recours au paramètre persistent. Il peut avoir plusieurs valeurs :
- persistent = 0 : dans ce cas, le sctrl n'est vérifié qu'une seule fois pendant tout le temps que le perso passe dans ce state. Si le perso sort du state puis y revient, ceci est réinitialisé, et le sctrl se rédéclenchera une fois.
- persistent = 1 (valeur par défaut) : le sctrl est déclenché à chaque fois que les conditions sont remplies.
- persistent = X (où X est une valeur supérieure à 1) : le sctrl est déclenché toutes les X fois que les conditions sont remplies.

Particularité des states aériens ayant un physics = A

Classiquement, un mouvement se construit ainsi : StateDef, puis les states correspondant aux actions à réaliser, puis un ChangeState pour renvoyer le perso en stance ou en crouch, selon le coup de base.

Toutefois, les coups aériens sont différents, du moins, la plupart d'entre eux. Si vous avez spécifié un physics = A, comme nous l'avons vu avant, une gravité est appliquée au personnage, ce qui le fait naturellement redescendre vers le sol. Et lorsque le personnage arrive au niveau du sol, il est automatiquement passé en state 52, le state d'atterrissage.

C'est pourquoi il y a deux règles à suivre pour les states aériens (ayant un physics = A).
- D'une part, les anims doivent avoir un looptime infini (nous l'avons déjà vu)
- D'autre part, le state ne doit pas se terminer par un ChangeState : celui-ci s'opérera automatiquement lorsque le perso arrivera au sol.

Les states particuliers : les states négatifs.

Les states négatifs sont des states particulier. On en a déjà vu un, le state -1. En fait, il y en a 3 (state -1, -2 et -3). Leurs particularités sont assez larges. Déjà, contrairement aux autres states, le perso n'est jamais placé dans ces states par un ChangeState.

Ces states sont plutôt propres à "l'environnement" du perso qu'au perso lui-même, dans le sens où justement, ils ne sont pas vérifiés selon le state dans lequel se trouve le perso. En effet, les sctrl de ces states sont vérifiés à chaque tick. Voici plus précisément leurs spécificités :

- State -1 : Ils sont exclusivement utilisés dans le CMD et utilisés pour la détection de commande et pour l'AI. La particularité, c'est qu'il n'y a qu'un seul state -1 déclenché à chaque tick (le premier dont les conditions sont réalisées).
- State -2 : Ils se trouvent dans le CNS. Ces sctrl sont tous vérifiés et éventuellement déclenchés à chaque tick du combat.
- State -3 : Exactement identiques aux states -2 à ceci près qu'ils ne sont vérifiés que lorsque le personnage utilise ses propres states (souvenez-vous du debug et de ce qui était expliqué lorsque les écritures sont en jaune : dans ce cas, les states -3 ne sont pas vérifiés, mais les states -2 le sont).

Voilà, je pense que si vous avez compris tout cela, vous connaissez maintenant le principe de la programmation. Il ne vous manquera plus que les triggers pour être potentiellement capable de tout coder, triggers que nous verrons la prochaine fois.

Mike Werewolf.
Mike Werewolf est absent 
Mike Werewolf
Loup-garou

Site Admin


Inscrit le: 07 Oct 2004
Messages: 1676
Karma: 52
plus / moins

Localisation: France
Répondre en citant
Au fait, ça fait deux sujets sur lesquels il n'y a pas de réponse ; j'ai largué tout le monde, ou c'est bon ? Je suis sur la partie suivante, mais il faudra encore attendre un peu avant de l'avoir...

Mike Werewolf.
Mike Werewolf est absent 
Masterstyle
Master of the Style

Créateur/Créatrice Mugen

Créateur/Créatrice Mugen

Inscrit le: 30 Déc 2004
Messages: 105
Karma: 0
plus / moins

Localisation:
Répondre en citant
tu pourrai donner un exemple qui utiliserai le Hitdefpersist et le Movehitpersist ? parcke parcke je vois pas comment les utiliser
Masterstyle est absent Kicker ce membre de ce sujet
Mike Werewolf
Loup-garou

Site Admin


Inscrit le: 07 Oct 2004
Messages: 1676
Karma: 52
plus / moins

Localisation: France
Répondre en citant
Citation:
tu pourrai donner un exemple qui utiliserai le Hitdefpersist et le Movehitpersist ? parcke parcke je vois pas comment les utiliser


Je t'avoue que je ne m'en suis jamais servi, et que les persos qui les utilisent sont plutôt rares.

Pour le Hitdefpersist : je pense que les cas où on s'en servirait, c'est pour un coup qui s'étale sur plusieurs states, tout en utilisant la même anim ; dans ce cas, on fait persister les HitDefs à travers les states pour que le coup puisse toucher quel que soit le state du coup dans lequel se trouve le perso.

Pour le Movehitpersist, je verrai plus ça dans un enchaînement, où tu utiliserais plusieurs states (un pour chaque coup) ; ex : dans un enchaînement, chaque coup correspond à un state, et on veut que chaque coup ait deux versions : une si le coup précédent a touché, une autre s'il a été bloqué. Mais pour ces deux versions, on utilise les mêmes HitDefs, PlaySnd, etc. Vu que le code est identique dans les deux versions, on ne fait qu'un state par coup, et on utilise un movehitpersist. On peut alors attribuer l'anim en fonction des valeurs de MoveHit et de MoveGuarded.

Mike Werewolf.
Mike Werewolf est absent 
Masterstyle
Master of the Style

Créateur/Créatrice Mugen

Créateur/Créatrice Mugen

Inscrit le: 30 Déc 2004
Messages: 105
Karma: 0
plus / moins

Localisation:
Répondre en citant
ok c plus clair merci
question bonus qui n'a rien avoir: lorsque ke l'AI se declenche eske le round suivant il reste actif ou bien il y a une remise a zero et doit etre activer a nouveau?
Masterstyle est absent Kicker ce membre de ce sujet
Mike Werewolf
Loup-garou

Site Admin


Inscrit le: 07 Oct 2004
Messages: 1676
Karma: 52
plus / moins

Localisation: France
Répondre en citant
Erf, ça dépend de plusieurs choses, en fait. Il y a plusieurs méthodes pour activer l'AI, et je ne les connais pas toutes. Cependant, normalement, l'AI est basée sur une variable qui vaut soit 0 (AI non activée) soit 1 (AI activée).

Donc ensuite, ça dépend :
- du numéro de la variable utilisée
- de la valeur du paramètre IntPersistIndex (dans [Data] du CNS du perso).

En effet, le IntPersistIndex indique jusqu'à quel numéro les variables seront réinitialisées entre les rounds. Donc si la variable de l'AI a un numéro supérieur (ou égal) à la valeur d'IntPersistIndex, elle ne sera pas remise à zéro au début des rounds suivants.

Si tu ne veux pas réinitialiser la var de l'AI (et donc ne pas avoir à redéclencher l'AI), il faut donc utiliser une var avec un numéro élevé (var(59) par exemple), et donner à IntPersistIndex une valeur égale ou inférieur à ce numéro. Wink

Mike Werewolf.
Mike Werewolf est absent 
Masterstyle
Master of the Style

Créateur/Créatrice Mugen

Créateur/Créatrice Mugen

Inscrit le: 30 Déc 2004
Messages: 105
Karma: 0
plus / moins

Localisation:
Répondre en citant
ah ok c est bon a savoir merci
Masterstyle est absent Kicker ce membre de ce sujet
04. Les bases de la programmation (suite)
Vous ne pouvez pas poster de nouveaux sujets dans ce forum
Vous ne pouvez pas répondre aux sujets dans ce forum
Vous ne pouvez pas éditer vos messages dans ce forum
Vous ne pouvez pas supprimer vos messages dans ce forum
Vous ne pouvez pas voter dans les sondages de ce forum
Toutes les heures sont au format GMT + 2 Heures  
Page 1 sur 1  
Télécharger le sujet
  
  
 Poster un nouveau sujet