Forum Solarus-Games francophone

Donc voila, cela fait plusieurs jours que je cherche des tuto pour MMF 2 qui pourraient m'aider mais je n'en trouve pas d'aproprié.
Le moteur de base que j'ai (inspiré de je-sais-plus-qui) utilise un detecteur pour les collisions avec le décor, il fonctionne assez bien mais j'ai peur de faire plus compliqué que necessaire...  Mais bon ce n'est pas ma priorité.
Mon problème désormais est que je n'arrive pas à faire un compteur (pour les futurs rubis) qui reste en bas à gauche de l'écran. J'ai essayé de le maintenir à (...;...) pixels de link (qui est au centre de la vue), mais dés que link s'approche du bord de la map le compteur disparait de la map...  <_<
Je ne me vois pas vraiment faire tout un travail pour si link est à X du bord faire se déplacer le compteur de X à droite puis quand link repart attendre X pour que le compteur se redéplace.
Est-ce que quelqu'un sait comment faire sa sur MMF 2?  :)

PS: j'aurai sûrement d'autres questions bientot alors merci de laisser ce post ouvert
(2)PS: Si quelqu'un a un super moteur sur MMF 2 je voudrais volontiers quelques infos  ^_^ (par exemple pour le coup d'épée j'utilise :animation (Epee) is playing + Overlapping (Herbe Haute) = Destroy (Herbe Haute) [en gros] , mais c'est pas pratique et pas du tout précis...)

Pour que le compteur reste à une zone fixe de l'écran :

Tu te places dans le rectangle en pointillé noir en haut à gauche de ta scène. Tu places ton compteur à l'intérieur du rectangle (ce sera sa place fixe sur l'écran vis à vis de la résolution de ton jeu ).

Ensuite tu vas dans les propriétés de ton compteur :

RunTime Option / Option du RunTime ==> Tu décoches Follow the frame / Suit la scène

Et le tour est joué, ton compteur est fixé à un endroit précis de l'écran :)

EDIT : pour l'épée, j'avais adapté un tutorial de l'excellent Benito un expert de MMF  :P
Par contre c'est dans la langue de Shakespeare attention !

http://www.zfgc.com/forum/index.php?topic=1312.msg16927#msg16927

Ok merci!
J'essayerais dès que j'aurai réussi à faire apparaître mon compteur devant mon background parce que ce c** veut pas passer devant >_< il veut absolument rester number 1... (bon faut dire que mon background est à la 56 ème place.... c'est long à expliquer... mdr)
Pis pour l'anglais bah sa me donnera une raison en plus d'apprendre mon voc! (meme si tondeuse à gazon sa me servira pas trop je pense :P)
Merci!


EDIT: Le compteur fonctionne mais lorsque link se deplace, le compteur laisse une trainée derriere lui. Comme si l'ecran ne se rafraichissait pas. (il continue d'afficher le compteur qui etait 2 pixels plus loin)

RE-EDIT: Le fichier est plus telechargeable... :cry3: ...jamais de bol moi...

Pour le coup d'épée, il suffit de poser une condition pour l'emplacement de link par rapport aux herbes et de sa direction, et de vérifier si a touche du coup d'épée est appuyée ;).

Exemple quand Link est vert la droite avec un masque de collision :
En supposant que ton appli tourne à 60FPS


Si touche action activée
__ Si (masque_colision_link_droit) est sur (herbe haute)
____Si $épée==1
______Si (Link) regarde à droite
________ Lancer animation (épée) sur (Link)
________ Lancer animation (herbe coupée) sur (herbe haute)
________ Jouer effet sonore (herbe coupée)
________ Définir $temps à 120
______End



Si $temps > 1
__$temps - 1
End



Si $temps==1
__Finir animation (épée)
__Finir animation (herbe coupée)
__ Finir effet sonore (herbe coupée)
End


Un peu long mais ça devrais marcher je pense ;).

 Pour tous ce qui est des anims du tuto de Daru, utilise des valeurs modifiable tu gagneras des lignes de codes. ;)

Ok, donc au lieu de faire si (Link) est au-dessus de (Herbe Haute), faire si (Detecteur de collision) est au dessus de (Herbe Haute)...
Sa pourrait marcher je vais essayer  ;) (sa sera de toute maniere plus précis et plus réaliste)
Sinon quelqu'un a une idée pour le compteur?

Ton jeu est limité à combien de FPS ? Tu as quoi comme machine ? Ton jeu est il gourmand en mémoire ?
Généralement, ça viens d'un rafraichissement pas assez rapide ça je crois, non ?

Justement je sais pas comment on peut voir les FPS sur MMF2 ni si on peut les modifier, mais sa me parait bizarre parce que Link aussi devrait réagir comme sa...
Ce n'est en tout cas pas à cause du poids du jeu car il n'y a pour l'instant qu'une seule scène test.
Je vais essayer de modifier 2-3 parametres on verra bien...
Sinon la j'essaie de faire rebondir Link quand il touche un enemi, le code y a pas de probleme mais j'arrive pas à le faire reculer... la aussi il va falloir que je fasse 2-3 test.

Pour faire reculer un objet il suffit de redéfinir x ou y selon sa position actuelle ;).
Par exemple, pour faire reculer ton monstre quand il est touché sur son flanc gauche : Cordonnée x du monstre : x(monstre)+5 ;).

Pour voir et régler les FPS, c'est dans les propriétés du runtime, clique sur l'icône qui porte le nom de ton appli' dans le menu généralement à gauche de MMF2 :).

Bon alors dommage c'est pas les FPS qui font le bug... Mais j'avais oublié de préciser que dès que l'écran ne bouge plus (soit arrêt du héros, soit trop proche du bord de la map), toutes les anciennes positions du compteur disparaissent. Peut-être que ce détail est important :unsure:
Pour les déplacements je vais essayer maintenant.  ;)
(Merci déjà pour toutes vos réponses! ^_^)

EDIT:Ok pour la collision  :) Mais je me demandais si il n'y aurait pas un moyen de faire automatiquement le recul dans la direction opposée ? (du coup, ou autre). Et (je sais je pose beaucoup de questions mais je les poserai tôt ou tard alors autant que ce soir maintenant!  :P) y a t'il un moyen pour que le déplacement soit moins saccadé? (je pourrais peut etre essayer de faire x==x-1 en boucle jusqu'à 20, pour qu'il recule de 20 mais je trouve sa bizarre..)

Conseils généraux pour un moteur Zelda sur MMF

1) Composition de "qualifier"

Déjà, définir des types globaux ou aussi "qualifier", pour ce qui va pouvoir interagir avec Link.
A titre d'exemple :


-collectable <=> objets qui lorsqu'ils sont détruits produisent aléatoirement un objet qui peut être ramassé par le héros, comme un petit coeur ou un rubis d'une certaine valeur.
Cela impliquerai de la sorte des fonctions qui vont détecter la destruction d'un collectable qui aurait disons par défaut une variable A définie. Cette variable A définissant le type d'objets que le collectable peut laisser tomber.

Exemple : Une variable A de 0 (par défaut) produit des rubis ou coeur, ce serait idéal pour un buisson ou un pot.
Il est possible aussi de revoir le principe de variable, en introduisant d'autres paramètres, mais l'idée est là.


-neutres <=> les objets neutres correspondent à des objets actifs (sous MMF) qui ne peuvent pas être traversés. En gros, ils agissent comme des décors de type obstacle, tout en restant de type actif. Tu appliquerais ce groupe aux objets comme les buissons qui bloquent tant qu'ils ne sont pas détruits, ou encore les pots...


-fragiles <=> objets que l'on peut détruire avec l'épée par exemple. On peut définir plusieurs groupes de niveau, qui correspondrait de la sorte à un groupe d'objet ne pouvant être détruit qu'avec une certaine épée, ou etc...


-soulevable <=> objets que Link peut soulever. Analogue au groupe fragile

[etc...]

L'avantage de ce type de programmation est que tu peux par exemple combiner collectable + fragile + soulevable + neutre pour créer un buisson tout à fait opérationnel !
Mais ce n'est qu'un début bien sûr ^^ Le principal est de faire des groupes suffisamment généraux pour ne pas faire de "sous-groupes" ou de "groupes à un membre"  :P


2) Principe de base du système d'épée (initiation)


On passe à la suite du problème  ^_^


Pour ton moteur d'épée, vu que MMF gère bien le système d'animation des sprites, je te conseille de profiter de cet atout (dont chris' c'est d'ailleurs inspiré dans ZSDX si je me ne trompe pas  :P ).


Donc tu dois tout d'abord voir si Link dispose de l'épée (normal), puis vérifier qu'aucune des animations de l'épée n'est en cours. Le cas échéant, tu te lances dans l'animation de Link et d'une petite sprite qui symbolise l'épée, ou plus particulièrement sont détecteur.
Link doit lors d'un coups d'épée, ne pas avoir d'épée dans son animation, mais tu dois par la suite rajouter un "detecteur-animation" de l'épée unique détachée de Link.


Cela te permet non seulement de tester facilement les collisions de l'épée, mais en plus d'éviter des bugs du type "Link ET l'épée" touchent un ennemi, ce qui implique que non seulement le monstre est touché, mais Link aussi (enfin exemple hein :) ça dépend de ton moteur de collision)


Après il te suffit toujours de jouer avec le début ou la fin des animations. Si une animation de l'épée est terminée, alors tu laisses Link bouger, sinon si le joueur a rappuyé et que l'animation en est à plus de 1/3 de son execution, on la relance.
Etc...

3) Moteur de l'ennemi type - qui se déplace (système de "ennemy_hurt")


On termine avec le mouvement de recul,

Encore une fois, MMF propose des mouvements prédéfinis qui ne sont parfois pas mauvais à négliger. Je t'invite donc à utiliser un mouvement de "balle à 8 directions" pour tes ennemis. De la sorte, lorsqu'ils sont touchés, tu les orientent dans la direction direction_actuelle+16 (demi-tour) puis tu les fais avancer tant qu'il n'y a pas de décor.
Ce système implique un petit système en plus dans le moteur des ennemis, qui gère le cas où ils sont touchés :
-direction fixe
-clignote ou change de couleur
-avance rapidement mais pendant peu de temps
-rebondis ou s'arrête contre un objet de type "décor"
[etc...]




Voilà ça me fait penser que je devrais peut être faire aussi un petit tutorial  pour son zelda sur MMF mais faut le temps hélas  :P

Bon courage, en attendant la réponse du maître Spring_up qui te proposera de très bon tutoriaux pour appréhender le logiciel  ;)

Merci pour ton long message sa va me laisser de quoi m'amuser pendant un petit bout de temps  ^_^
Si je reprend dans l'ordre alors ta premiere idée est très pratique c'est vrai mais ce qui le serait encore plus serait de pouvoir dire:
"Si détécteur( ou link) collisione un collectable alors détruire collectable et appeler event selon type du collectable (pour ajouter un rubis/coeur etc...)"
Et sa pour toutes les catégories. Mais ce n'est pas possible (en tout cas pas à ma connaissance). Et j'ai donc dans mon embryon de moteur le même code que si-dessus mais une fois pour les rubis et une autre fois pour les coeurs.
Mais si il est possible de dire
"Link peut porter tous les soulevable","Link ne peut pas traverser les neutres",... Et attribuer ces "capacités" aux objets, je veux bien que l'on m'explique!! :) :D ^_^
Sinon je reste avec mon code pour chaque objet et chaque possibilités d'actions. (J'espere ne pas m'être embrouillé dans mes pensées en écrivant sa :unsure: )
Deuxième point pour l'épée:
J'avais aussi pensé faire ça pour que ce soit très précis dans la zone d'action de l'épée. Mais je ne savais pas il serait possible de faire concorder exactement le mouvement de link avec l'affichage de l'épée... Et sa aurait été pas mal de boulot pour rien si sa ne fonctionnait pas. Mais si tu dis que c'est possible je vais m'y mettre.
Dernier point pour les rebondissements:
Je vois ce que tu veux dire. Je n'avais pas vu qu'on pouvait faire changer de direction comme sa! Sa me sera très utile! :) Par contre je n'ai pas compris comment définir le fait que ce ne soit pas un joueur qui déplace les personnages mais l'ordi. Je n'ai pas non plus compris comment faire avancer un objet.... J'aimerais bien pouvoir utiliser "Path Movement" ou qqch du genre mais MMF2 n'est pas vraiment d'accord... Tu pourrais m'expliquer comment faire ?  :)

PS: On pourrait bien simplifier les choses si quelqu'un me laissait jeter un coup d'oeil à un certain moteur d'une certaine démo faite avec MMF 2  :mrgreen:

Personnellement je suis en pleine conception d'un système d'IA trèès basique pour mon projet de concours;  j'utilise une zone de détection assez large circulaire est permanence attachée au monstres et invisibles, ainsi qu'un déplacement le plus aléatoire possible configuré à l'aide des déplacements auto ( dans els propriétés ) de MMF2.

Quand le heros est dans le masque de détection, je calcul sa position par rapport au monstre et je fait déplacer le monstre vers le heros tant que celui-ci est dans le masque :).

Mais il y a peut-être des objets pour le déplacement aléatoire, non ?
Faisable en manuel aussi, mais c'est plus chi... je trouve...

Ps : Bon tuto Yoshi' ^_^.

Je pense que ce systeme doit bien fonctionner mais moi mon probleme (enfin... un de mes problemes) est que je n'arrive pas a déplacer un objet. Je ne sais pas quelle fonction utiliser...

Regarde dans les mouvements prédéfinis (propriété d'un objet non décor).

Tu auras alors beaucoup de choix.

Pour une balle, tu peux choisir sa direction, sa vitesse max, et donc la faire avancer dans une direction à une certaine vitesse.

Ok mais comment fait-on pour dire :
Si link touche Objet(x), déplacer Objet(y) 25 à droite
?  :huh:
ou quelque chose comme sa? Parce que dans "mouvement" je n'ai pas trouver la fonction qui permet sa...
(Et si on choisit 8 directions, quel joueur doit on choisir dans propriétés? (on ne peut choisir que 1-2-3-4...), et si on choisit balle elle ne s'arrète pas et bouge partout...)

Non se sera plutôt :

Histoire de gérer le temps de déplacement : 3 lignes minimum (faut aussi penser à ce qui est condition d'arrêt annexe) :

Système ennemy hurt (encore une portion)

Ligne 1 (exemple) :

-Condition :
<Si Link touche objet(y)
<Ne faire qu'une fois si en boucle

-Action sur Objet(y) :
>Modifier vitesse : 15 // Vitesse quand il est touché
>Direction = Direction(Objet(y))+16
>Mouvement : commence (start)
>Modifier variable A :  A <-- 10

Ligne 2 (exemple):

-Condition :
<variable A d'un Objet(y) > 1

-Action sur Objet(y) :
>Variable A = valeur(A) - 1

Ligne 3 (exemple):

-Condition :
<variable A d'un Objet(y) = 1
<Ne faire qu'une fois si en boucle

-Action sur Objet(y) :
>Modifier vitesse : 20 //Vitesse initiale
>Direction = Regarde vers (Link) 
>Mouvement : commence (start)
>Variable A <-- 0

Dans cette portion de code, j'ai integré un pseudo système qui lorsque variableA de Objet(y) est égale à 1 lance l'objet(y) à une certaine vitesse dans sa direction opposée.

Il faudrait maintenant mettre d'autres conditions qui vont remettre la variableA à 0 ou autres pour stopper l'objet.
Tu peux aussi remplacer la variable A par un booléan, ou aussi nommé "drapeau" sur MMF
==>Drapeau activé ==> Interrupteur ON ==> Vrai
==>Drapeau desactivé ==> Interrupteur OFF ==> Faux

Ta balle tu peux cocher une case dans ses priorité qui dit "désactiver le mouvement au démarrage". Chose que tu peux également faire par toi même avec un "Début de la scène" ==> "Stopper le mouvement"

Sinon tu fais Position => Cordonnée x => x(monstre)+25
Avec une anim' si tu veux un truc joli :ninja:.

Sinon, la technique de Yoshi est plus simple et plus pratique :P.

Penses aussi à faire reculer Link quand un monstre le touche :).

Ok alors yoshi04 j'ai tout pigé jusqu'au start. Il signifie quoi? Que le mouvement commence. Sa parait logique. Mais comment on lui dit qu'il doit aller tout droit? (avancer enfait) C'est ce point que je ne comprend pas...
Je pense que ce start à un rapport avec le "movement #1" qui s'affiche dans les propriétés de l'objet. Mais ce "movement #1" ne peut pas être édité. Ou alors j'ai pas trouvé comment.
Tu peux m'eclaircir ce dernier point? Ensuite je te laisse aller dormir  :P

Daru13, ouais je sais que je peux utiliser position mais j'aime pas trop m'embrouiller avec des anims alors si je peux eviter :mrgreen:

Voilà une réponse illustrée,
Copyright schémas moches de Yoshi04 (C)

(Certains connaissent déjà ce sigle  B) )

(http://img262.imageshack.us/img262/6304/schemamocheyoshi0401zi3.png)

HAHA!!  :D
Je viens enfin de comprendre!  :mrgreen:
Ce que je pigeais pas c'était que le start ne disait pas dans quelle direction l'ennemi partait. Mais enfait il va tout droit dans la direction ou il regarde!
(Je pense que ce qui m'a bloqué c'est le fait de ne pas retrouver la meme chose que sur Rpg Maker, même si je ne l'ai plus utilisé depuis au moins 2ans  :P)
Merci! Je vais enfin pouvoir avancer un peu mon moteur! ^_^

Heuuuu je veux pas faire chier mais une idée pour que Link se déplace en arrière quand il se fait toucher?
Je pensais faire:
-Collision (detecteur) et (ennemi)
                      |
                     \/
-(Link) regarde en direction de (ennemi)
-Play animation (Touché)                                              <---L'animation Touché dans les propriétés de Link serait inversée (vu qu'il se
-(link) direction moins-16                                                    tourne de 180° juste après)
-Link start
....                                                                              <---Là je sais plus quoi mettre...

En plus "start" ne fonctionne pas sur link car il n'a pas boule 8 directions comme déplacement..

Une idée?? :)

Fais-le manuellement :mrgreen: *zbaf*

Pour l'arrêt, si on peux savoir si une anim' est finie tu pourrais essayer, sinon tu peux utiliser une boucle pour calculer le temps de déplacement :).

MMF2 autorise les mouvements multiples :)
Donc tu switches du mouvement "fixed" ou je ne sais plus quoi vers un autre mouvement "balle".
Idée comme une autre bien sûr ^^


Après juste à titre indicatif, utilisant MMF1.5 pour mon moteur zelda, j'ai tout fait "manuellement".

Je partais de deux compteurs, l'un pour x_link et un pour y_link, je fixais tout par rapport à ces valeurs, et je ne modifiais dans tous les cas que ces valeurs. Ce qui faisait au final que pour un mouvement fluide dans une direction, je me basais par rapport à un rapport direction et interaction (si Link touche un ennemi par exemple il faut partir dans le sens du monstre car il nous "pousse") puis à une modification répétitive du compteur.

Exemple d'algorithme :

//Déplacement de Link vers la gauche à une vitesse de 2pixels par (1/fréquence) pendant VariableA (1/fréquence)

Tant que  : VariableA > 1 Alors
          Modifier x_link <-- x_link-2
          Modifier VariableA <-- VariableA - 1

Bon de toute manière là je ne fais qu'un moteur test. Mais tu me conseille de tout faire manuellement? Sa me parait un peu se compliquer la vie mais c'est vrai il est possible que ce soit plus précis et plus maniable....
J'hésite maintenant...MERCI! :angry:        :P
Je devrais donc faire si je reprend depuis le début.. link a comme position x et y le coin en bas à gauche de l'ombre par exemple ensuite pour qu'il se déplace, il faut faire un test de touche, si la touche est appuyée le téleporter de 2 pixels en 2 pixels avec l'animation (marche), correspondante à la direction appuyée. Sa sa va.
Mais pour les obstalces je vois pas  :huh:

Citation de: limule le 04 Décembre 2008 à 19:37Je devrais donc faire si je reprend depuis le début.. link a comme position x et y le coin en bas à gauche de l'ombre par exemple ensuite pour qu'il se déplace, il faut faire un test de touche, si la touche est appuyée le téleporter de 2 pixels en 2 pixels avec l'animation (marche), correspondante à la direction appuyée. Sa sa va.
Mais pour les obstalces je vois pas  :huh:

Je sais pas comment marche MMF2 mais je peux te donner une approche théorique.
Tester avant de déplacer ton Link si la zone à laquelle il souhaite aller est un obstacle oopa.
En schéma, ça donne :

CitationSi touche droite pressé alors
{
   Si obstacle_dispo_x(link.x+2 (ou 18, ça dépend de tes sprites et de ta fonction) ) alors
   {
      image_link = link_droite_arret;
   }
   Autre
   {
      image_link = link_droite_marche;
      link.x+=2;
   }
}

obstacle_dispo_x(pos.x) est une fonction dans laquelle tu mets toutes les positions x de ta mappe dans laquelle il y a un obstacle.
Faire de même avec une fonction obstacle_dispo_y(pos.y) ou tenter de les combiner pour alléger la mémoire en faisant une fonction obstacle_dispo(pos.x,pos.y).
Voila, j'espère que ça t'as aidé.

Personnellement pour les obstacles, j'utilise des masques de collision ( un pour chaque côté ).
Tant qu'une masque est sur un décor, je déplace mon objet, pour toi ça sera Link.

Bon alors je vais tenter de recommencer mon moteur. Je verrai si j'essayerai avec les masque ou avec les positions, je dois de toute maniere déjà m'arranger pour les déplacements.
Merci! ;)

Edit: Je plante déjà avec les animations... J'arrive pas à faire qu'elle s'arrête dès qu'on arrète d'avancer. Parce que je met:
Négation: Une touche est appuyée -----> Changer l'animation pour (Stop)  (donc quand link est arrété l'animation passe à stop, mais sa fonctionne pas)

ReEdit:reussi  ;) mais j'utilise un timer et j'aime pas trop mais bon

ReReEdit: Ah bah nn... <_<

Je poste un dernier message pour t'aider ici, je pense que le mieux serait que je fasse un petit tuto qui montre comment j'avais procédé pour un zelda sur MMF1.5.
Ca inclura aussi quelques petits éléments annexes qui viennent de Benito ou de conseils de Christopho mais dans tous les cas ça viendra en temps voulu :)

Ultime conseil donc avant un certains temps : gère les animations de Link différemment.

Exemple : si string_Link = "arrêt", executer une fois si en boucle ==> appliquer à Link animation arrêt
Idem pour tout le reste :)

En gros, lorsque tu appuies sur un touche dans le cadre d'un déplacement, tu modifies le string_Link en "marche". Si aucune touche n'est vraisemblablement pressée, et que Link ne fait rien de particulier on change string_Link en "arrêt".

Fait attention dans tes anim' à bien mettre une boucle ou un élément qui fixe l'animation à un point précis (exemple Link prend son arc et tire la corde ==> il reste fixe avec la corde tendue)

Bye et désolé de ne pouvoir t'aider plus pour le moment...


PS : autre chose pendant que j'y pense.

Entre tout faire "manuellement" via des compteurs ou des variables c'est un choix, c'est plus dur, mais c'est contrôler tout ou du moins le plus possible (selon les limites de MMF) ce que tu fais.
En utilisant les systèmes tout faits du logiciel tu fais confiance à celui ci et donc tu n'as pas totalement le contrôle de l'objet, enfin pas de manière aussi précise.

Après l'utilisation des mouvements prédéfinis comme le type "balle" est parfois recommandé pour alléger le moteur ou pour éviter les complications dans l'algorithme.

En faisant tout manuellement, tu te "rapproches" du langage informatique brut en profitant des plus du logiciel comme le système d'actif, d'animation, de colision prédéfini etc... (ce qui est plus ou moins dur à faire en vrai code informatique mais tout à fait possible :) cf : ZSDX engine :P )

Salut les clickeurs,

Alors on cogite... :fonsde:

Voici un "petit" tuto TGF1 (scène 1024x1024), mis sous TGF2, sûrement compatible MMF2.
Il fait moins de 40 lignes, mais les bases sont là.

Moteur de déplacement (gestion collisions => CNL, animations, plans).
Moteur de tir (épée, buisson).
Le scrolling.
Le début d'une stratégie d'ensemble ("Layers" ou Faux calques, décor, plan, obstacle).

A l'origine les compteurs n'étaient pas dans la scène.
Ils sont là juste pour voir le problème, facile à résoudre avec des objets actifs "compteur" (compteur personnalisé).
A l'exemple des objets X et Y toujours au premier plan, à décortiquer dans propriétés.

Il y a deux fichiers, fichier.exe pour les curieux, et le fichier.mfa éditable avec TGF2 et MMF2.

http://dl.free.fr/qyDfoAgqq

Bon courage, très cordialement. :mrgreen:

Bonsoir!
Voila j'ai un petit problème avec mon moteur de déplacement ( inspiré de http://forums.zelda-solarus.com/index.php/topic,19268.0.html )
Le fait est que Link ne se déplace qu'une seule fois lorsque j'appuie sur une touche.
J'ai:
Mouvement = 1 ----> Set X_Link=X_Link + Deplacement_X
                              Set Y_Link=Y_Link + Deplacement_Y
(Deplacement X et Y sont déterminé pour chaque valeur de sens et mon Mouvement est le vit du tutoriel)
Le probleme est que cette action ne s'effectue qu'une seule fois...
Merci!
(dsl j'avais fait un méga long post mais l'ordi a planté...>_<)

Bonjour Limule,

Si avec MMF tu essayes de reproduire un moteur de déplacement pour Game Maker...
MMF permet de réaliser un moteur de déplacement case par case en 6 lignes.
Avec Game Maker, il sera difficile d'égaler cette performance.

Tu as cherché un moteur de déplacement MMF ou TGF compatible MMF?

Le plus simple serait de proposer ton fichier.mfa en téléchargement, pour pouvoir le corriger.
Avec par exemple cet outil.
http://rapidshare.com/

Merci de ton attention.

Edit:
Le moteur de 6 lignes, case par case, 4 directions:
http://dl.free.fr/getfile.pl?file=/okMJae4m

Bonjour,
merci pour le moteur, je ne l'ai pas encore étudié mais je vais le faire de suite.
Je me rend compte que mon explication n'est pas très explicite, alors comme suggéré voici le fichier:
http://rapidshare.com/files/178464692/Moteur_zelda.mfa.html (http://rapidshare.com/files/178464692/Moteur_zelda.mfa.html)
Voila, et merci de m'aider ^_^

Ton moteur ne peut pas fonctionner, sans ordre arrêter et démarrer car Link à un mouvement balle qui rebondit. En plus il y a des conditions contradictoires, entre parenthèses, Link ne bouge pas au lancement de la scène, car tu as modifié la décélération à 100.

Avec MMF2 pas besoin de variables pour réaliser ce type de moteur.
5 lignes pour un moteur de déplacement libre 4 directions, cela suffit au départ.

Voici un moteur pour commencer ton projet, avec un peu de pratique tu peux l'améliorer (gestion des plans).
http://dl.free.fr/okpfsdtVq

Edit:
Le moteur est évolutif (8 directions possibles) et adaptable à tout projet RPG.
Pour ma part, je préfère le moteur case par case qui simule un déplacement libre car il gère parfaitement les obstacles (gestion des collisions sans détecteur, moteur de 6 lignes proposé plus haut).

Merci pour ton moteur! Je pense que je vais me baser dessus au moins jusqu'a ce que j'ai de meilleurs connaissances en MMF2!  :)
Juste pour vérifier si j'ai bien compris le fonctionnement du moteur:
Le joueur appuie sur une direction, la vitesse de "Test" (seul objet que le joueur fait "vraiment" bouger) passe à 1. Cela ne fait pas se déplacer Link car il se situe sur "Base". Cela déclanche le déplacement de "Base" à la vitesse de 16 dans la direction de "Test". et change l'animation de Link. Quand la touche est relachée, tout s'arrete car la vitesse de "Test" repasse à 0.
Bon je vais pouvoir passer à autre chose!
Merci pour tes explications!! ^_^

C'est exactement cela, je t'ai proposé ce petit moteur pour que tu captes au moins deux choses.
1) Pour réaliser un moteur il est nécessaire de prendre en main sérieusement MMF.
2) Un moteur de déplacement MMF réclame souvent de mixer plusieurs mouvements.

Domaine RPG => Statique, balle qui rebondit, à huit directions.

Plus on maîtrise MMF et plus les moteurs réalisés sont variés, fiables, adaptables.
D'ailleurs le petit moteur proposé pour ton projet à un problème, car il y a un élément de trop,
réservé à un déplacement case par case (objet actif avec le mouvement balle qui rebondit).

Mais évidement tout est prévu, puisque tu arrives à suivre.
Tu lis d'abord ce tutoriel online (notion du tile ou de la tuile, du cahier des charges).
http://fcf.margasoft.fr/archive/viewtopic.php?f=11&t=454

Ensuite tu télécharges ce moteur, plus conforme à tes besoins.
Le même que celui du tutoriel online, par contre, je te laisse l'adapter à une tuile 16x16 et à ton cahier des charges,
les objectifs à atteindre (dans ton cas au moins pour une map).
Il fait 3 lignes, normalement plus facile à comprendre (lol).
http://dl.free.fr/uSr6HLjlk

A noter qu'un moteur de déplacement sans une stratégie d'ensemble, ne sert à rien, sauf à déplacer un sprite.

Afin que tu ne doutes pas de mes capacités, dans le domaine du moteur de déplacement RPG, une stratégie d'ensemble pour une map avec des faux calques => Obstacles, plans, escaliers, plate-forme, principe élémentaire pour de la 2D, (2D isométrique).
Compatible TGF et MMF, les commentaires sont aussi en français, il suffit de les éditer.
http://rapidshare.com/files/137823192/Engine_move_for_Reiner_s_tile.zip.html

Edit:

Le meilleur moteur de déplacement c'est celui que l'on comprend que ce soit avec MMF ou GM.

C'est un élément incontournable, il doit répondre à un cahier des charges,
à une stratégie d'ensemble pour un projet RPG.
Il est indispensable de se constituer une base de données moteurs.
Au minimum 4 moteurs.
Case par case 4 directions (notion variable).
Case par case 8 directions (attendre d'avoir un petit niveau en programmation).
Libre 4 directions.
Libre 8 directions.

Les moteurs dans mes messages sont proposés à titre indicatif, sans une stratégie d'ensemble,
ils ne détiennent pas la vérité, ils abordent des notions nécessaires à la réalisation d'une base de données moteurs,
on peut les améliorer.

Bonjour,
Mon cahier des charges s'apparanterait à cela :
-Mouvement 8 Dir
-Collisions et glissades (si le héros touche un mur horizontal, qu'il va haut-droite, pas qu'il s'arrete net mais qu'il glisse sur la droite à vitesse réduite)
-Gestion des ennemis et des objets "modifiables"(Haute herbes, pot, etc)

Pour l'instant c'est tout. Et encore, la gestion des ennemis c'est pas encore pour tout de suite.
Pour les collisions et les glissades j'aurais une idée mais en 16 ligne (juste la collision) par objets qui arrete le héros, et avec cela 8 detecteurs (un pour chaque direction), mais possibilité de passer a 5 detecteurs.
Bien sur il doit y avoir plusieurs manières d'optimiser cela... Je pense que je vais le programmer sur MMF2 et voir ce que cela donne.
Je vais aussi essayer de l'améliorer en m'inspirant des nombreux moteurs que tu m'a montré.
Merci! ^_^

Faire déjà un moteur de mouvement 8 directions libres avec des obstacles uniquement verticaux et horizontaux, le tout gérant la glissade dans le cas du multi-touche se sera déjà bien !

Après si tu souhaites intégrer des décors avec une pente de 45° en gérant encore une fois les "glissades" c'est tout une autre affaire, mais ça reste possible avec de multiples essais et donc de la pratique.

Bon courage !

C'est sur je serai deja assez fier de moi!   ^_^

CitationMMF permet de réaliser un moteur de déplacement case par case en 6 lignes.

RPG Maker permet de le faire en 0 lignes  :mellow:

Mais ensuite pour faire un moteur de déplacement 8 directions libre sur RpgMaker c'est plus compliqué...

Bonjour c'est de nouveau moi,
j'ai finalement décidé de faire un moteur de déplacement libre 8 directions (et essayer de faire déjà les glissade avec des décors verticaux et horizontaux uniquement)
J'ai donc 8 detecteur (je peux desendre a 5 mais c'est pour éviter de m'embrouiller  ^_^), mais le probleme c'est que quand link ce déplace, les détecteurs suivent mais 2-3 pixels derriere... J'ai placé leur coordonnée par rapport a link (j'ai utilisé comme base le petit moteur 4 directions que Spring Up m'avait fait (Test controlé par les touches direct., Base en balle 8 direct., et link en statique je crois))
Y aurait il un moyen pour que Link soit à la meme hauteur que les detecteurs?

Edit: J'ai trouvé, il suffit de placer les détecteurs par rapport à Base au lieu de Link :)

De mon côté je n'ai pas procédé exactement de la sorte pour le déplacement de la base "Link + détecteurs"

Tout d'abord, je commence au début par fixer la position des capteurs correctement autour de Link, sans que le joueur puisse interagir et donc fausser les positions (cela se fait au tout début).
Ensuite, je récupères les coordonnées X et Y actuelles de Link (qui peuvent varier en fonction de sa position initiale : exemple il sort d'une maison ou rentre d'une plaine au Sud ) et je place les valeurs X_Link et Y_Link dans deux compteurs nommés X_pos et Y_pos.

Une fois tout en place, je fixe jusqu'à la fin de la scène la base "Link + détecteurs" à la position X_pos (respectivement Y_pos) pour leurs positions X (respectivement position Y). Il faut pour que cela marche, arranger les "points chauds" ou "hot point" des capteurs et de Link de manière à ce que tout soit bien positionné.

Enfin, je change simplement les valeurs des compteurs pour déplacer l'ensemble. Le plus dur du boulot reste maintenant d'établir toutes les différentes conditions qui pourraient entrainer une modification de ces compteurs X_pos et Y_pos, en regardant les touches enfoncées, les éventuelles collisions avec les détecteurs et en interdisant certains cas.

Une autre indication :
J'utilisais 8 capteurs de collisions :
- 4 "corner" comme un carré n'ayant que deux côtés consécutifs.
- 2 traits horizontaux + 2 verticaux

Au final, j'avais un carré non plein, qui était "contenu" dans les "jambes" de Link, en laissant bien sûr dépasser la tête pour que Link ait sa tête qui dépasse sur le décor, en accord avec le perspective du jeu type Zelda 2d (comme alttp hein  :P )

Voilà, sur ce tu vas devoir gérer
- les cas où Link se déplace sans décors en face de lui : horizontal, vertical et diagonales
- les cas où une touche est pressée et qu'une collision se produit
- les cas où deux touches sont pressées et qu'une collision se produit
-autres cas (exemple : vu que MMF sépare les "décors" des "actifs" tu dois gérer le cas "glissade" entre un ensemble horizontal actif-décor, sinon Link va buter sur l'actif alors qu'il glisse parfaitement sur le décor)

Du boulot en perspective, mais l'algorithme se forme petit à petit, pour quelque chose de pas trop mal au final.
Et même s'il est sans doute possible de bien le simplifier avec MMF ou même du code normal, il a le mérite d'être efficace et de ne pas faire lagger  :D

Courage et montre nous tes essais ;)


EDIT : j'ose ajouter une autre petite contrainte que j'avais négligée pour mon moteur Zelda dans un premier temps. Tu dois gérer le déplacement en diagonale indépendament du mouvement Horizontal-Vertical. En effet, si tu utilises le simple fait que les deux se cumulent, tu aurais certes un beau déplacement en diagonale qui marche, mais ton personnage ira plus vite en diagonale qu'en ligne droite !
Il me semble qu'un tutorial portant sur cette problématique existe, je te passe le lien depuis zelda solarus : 

Je me suis permis de reprendre l'image pour que tu visualises le problème :

(http://img141.imageshack.us/img141/6185/23kt6lc5.png)

Lien du tuto : Tuto Systèmes de marche simple (http://forums.zelda-solarus.com/index.php/topic,19268.0.html)

Merci pour tes expliquations!  ^_^ (sa fait toujours plaisir de se faire aider  :) )
Pour le systeme avec les variables X_Link et Y_Link j'avais presque essayé (j'etait entrain de le faire) quand je me suis demandé si c'etait vraiment efficace et utile. Quelle maniere a tu utilisé pour faire que Link se déplace?
-Commande Start, Stop si c'est du balle 8 direction
-Avec les variables, X_Link-->X_Link+3 (etc..)
...
Car moi je pensais utiliser les variables pour déplacer le personnage, par exemple:
Si Haut est appuyée,
           Vitesse_X-->0
           Vitesse_Y-->3
           Mouvement-->1
Si Mouvement==1
          X_Link-->X_Link+Vitesse_X
          Y_Link-->Y_Link+Vitesse_Y
Enfin avec les directions et tout le reste (anim, etc..)
Je trouve ce systeme très pratique car pour les glissades il suffit de mettre une valeur à 0 tant que tel detecteur touche tel objet.
J'avais aussi pour cela utilisé le tutoriel dont tu explique une partie, mais il est à prioris fait pour Game Maker...
J'arrivais à tout controler (direction, sens etc... Cf: le tuto). Mais lorsque j'arrivais à mon:
Si Mouvement==1
          X_Link-->X_Link+Vitesse_X
          Y_Link-->Y_Link+Vitesse_Y
Au lieu que l'action se repète, Link ne se déplaçait que de 3 pixels, et je n'arrivais pas à trouver de solutions alors j'ai abandonné cette idée..
Enfin voila..
C'est pour ça que maintenant j'essaie de plus utiliser les outils de MMF2. Mais si tu as une solution pour mon ancien problème je l'écoute volontiers  :mrgreen:

Si tu comprends ce que tu fais et que cela te permet mieux, alors c'est parfait :)

Si tu souhaites suivre mes propositions, voici un extrait d'un moteur zelda où tu pourras voir les deux compteurs X_pos et Y_pos ainsi que les 8 capteurs de collision.


Sache que je n'ai qu'a modifier le compteur pour bouger l'ensemble, je n'ai aucune condition de type

"Always"/"Toujours" ==> SetPosition(X,Y) of "Detecteur01" to "Link"

Mais plutôt

"Always"/"Toujours" ==> Set X position of "Detecteur01" to "X_pos"

J'avoue que là je suis un peu embrouillé... Mais vu que je n'ai pas reussi à trouver de solution pour les déplacements avec les variables je vais essayer de faire sans.
Merci pour tes infos ;)

Juste pour savoir, quel technique utilisais-tu pour modifier tes variables de position??

Citation de: limule le 05 Janvier 2009 à 22:42
Juste pour savoir, quel technique utilisais-tu pour modifier tes variables de position??

Je suppose que c'est en changeant la valeur de cette variable. :)

Je le pensais aussi. Mais il faut que je soit plus précis alors.
Quel manière as-tu utilisée pour.."detecter un déplacement"? (Et encore c'est pas exactement sa..)
Je m'explique:
As-tu choisis que lorsque la touche Bas etait appuyée, Y_Link-->Y_Link - *une certaine valeure* ?
Ou plutot la manière utilisée dans le tutoriel, avec donc plusieurs variables pour d'abord calculer la direction et ensuite faire bouger Link?
Ou encore utilise tu un simple déplacement par touche directionnel (option de MMF2) et ensuite tu insère la position dans les variables?
...

J'espere être plus clair! ^_^


EDIT: J'ai relu ton post et ton moteur ressemble quand meme beaucoup à ce que je voulais faire au début, je vais faire qques tests et .....
Je viens de remarquer une différence qui a son importance quand meme! Moi je n'ai qu'un variable pour la position X de link toi tu as X_Link et X_pos! Quelle est la différence entre les deux?

Pour résumer :

Tu as l'ensemble "Link + 8 capteurs"

Chacun des objets constituant l'ensemble présentent respectivement une coordonnée X et Y.

Le but de l'opération, est de réduire toutes ces coordonnées à une seule coordonnée X et Y qui dirigerait le tout.
Cela correspond chez moi à X_pos et Y_pos.

Une fois que tu as réussi à créer l'ensemble "Link + capteurs", tu le déplaces simplement en modifiant X_pos et Y_pos.

Je rappelle au passage que ces deux variables constituent la position de l'ensemble par rapport au bord haut gauche de l'écran.
Donc si tu veux le déplacer horizontalement :

X_pos => (nombre de pixel à déplacer) + X_pos

idem pour la verticale

Y_pos => (nombre de pixel à déplacer) + Y_pos


Voilà je risque d'être absent un petit moment, donc je te dis à plus mais n'hésite pas à poser des questions je suis sûr qu'il y aura toujours quelqu'un pour y répondre.

[HS]
"Qu'est-ce que l'univers ?"

Ah non pas toi !!!  :paf:

Ok ça j'ai compris, mais pourquoi lorsque je met:
Si Mouvement==1
          X_Link-->X_Link+Vitesse_X
          Y_Link-->Y_Link+Vitesse_Y
Le déplacement ne s'effectue qu'une fois au lieu de s'effectuer le temps que Mouvement vaut 1? (Aaaaaaah si seulement il y avait un While dans MMF2...)
Je rappelle que Vitesse_X, Vitesse_Y sont le nombre de pixels pour le deplacement (ces variables varient entre 0, 2 et 3) et non pas une vitesse.
Pour le reste j'ai compris.
Merci de m'avoir aidé!  ;)
Au tour de qui maintenant??  :P

Il y a des boucles hein, dans MMF2 ;).
Pour ta méthode de déplacement, je sais aps si MMF2 répète automatiquement les actions, l'utilisation d'une boucle serait donc judicieuse en effet.

Comment gères-tu tes variables de vitesse ?

Une boucle sur MMF ?

Voilà un exemple pour se déplacer à droite :

Condition :

Tant que "Touche droite est appuyée"
Non(Tant que "Touche gauche est appuyée")
Non(Tant que "Touche haut est appuyée")
Non(Tant que "Touche bas est appuyée")
Si Capteur Droite ne touche pas un décor
Si Capteur Haut Droite ne touche pas un décor
Si Capteur Bas Droite ne touche pas un décor

Alors :

X_pos => X_pos + (vitesseLink)

Finish !

Après c'est l'un des cas le plus simple là ;)

Yoshi04:
Ouais j'utilise presque la meme chose mais en plusieurs étapes, le problème c'est que je ne peux pas mettre de "Tant que X est appuyée". Il me faudrait donc une boucle. Le problème c'est que je ne sais pas les utiliser...je vois chercher des infos dessus sur internet.
Daru13:
Pour les variables de vitesse j'utilise Sens (voir le tuto sur les déplacements), en gros, si Sens vaut 1, cela veut dire que Link se déplace à droite, je me alors Vitesse_X-->3, Vitesse_Y-->0.
Si Sens vaut 2, Link va vers le Bas alors je met Vitesse_X-->0, Vitesse_Y--> -3
Si Sens vaut 3, Link va en bas à droite, je met alors Vitesse_X-->2 Vitesse_Y--> -2
Etc...
Ce qui est pratique c'est que pour les colisions et les glissades il me suffit de modifier ces variables et le tour est joué (enfin je crois...  :mrgreen: )
Mais comme je l'ai déjà dit à la fin je me retrouve avec:
Si Mouvement==1
          X_Link-->X_Link+Vitesse_X
          Y_Link-->Y_Link+Vitesse_Y
Il faut que je mette ceci en boucle.. mais je ne sais pas comment faire..
J'aimerais au moins essayer cette manière, si elle ne fonctionne pas je ferai tt les cas comme Yoshi04 le propose.

Citation de: limule le 06 Janvier 2009 à 16:32
Yoshi04:
Ouais j'utilise presque la meme chose mais en plusieurs étapes, le problème c'est que je ne peux pas mettre de "Tant que X est appuyée".

Et à ton avis je fais comment ? J'utilise bel et bien une fonction simplifiée de MMF qui gére le maintient d'une touche ;)

En anglais : "Repeat while" (Joystick Left) is pressed

Au pire tu pouvais reprogrammer cette fonction, mais bon puisque MMF le propose  ^_^

Je met mon fichier pour que tu comprenne mieux ce que je veux dire par je ne peux pas mettre "Tant que X est appuyé"
http://rapidshare.com/files/180418196/Moteur_zelda.mfa.html (http://rapidshare.com/files/180418196/Moteur_zelda.mfa.html)
Je ne peux pas mettre de direction précise car mouvement==1 controle toute les directions en meme temps..
(Sens n'a pas encore été détérminé pour toute les directions, seulement pour haut et droite)

PS: Je pense que je ne peux pas faire de la manière que j'essaie, je vais devoir faire des modifications

Bah abandonne l'idée du "mouvement = 1"
Si Link peut se déplacer, tu le déplaces, sinon non. Pas besoin de variable pour ça.

En revanche, dans le cas où tu souhaites vraiment que Link ne bouge pas (cinématique par exemple) tu désactives un groupe mouvement dans lequel tu as placé tout ton code pour que Link bouge ;)

(en véritable code tu aurais eu besoin de la variable, mais là MMF propose le système de groupe donc profite en surtout ! )

Ok tant pis il me plaisait bien ce code mais bon..  ^_^

Le principal c'est que tu comprennes ce que tu fasses, et que tu essayes plusieurs façon de procéder, pour te tromper et donc t'améliorer.

J'ai fait qques tests avec ta technique et elle marche plutot bien!!  :mrgreen:
Mais y a juste un petit probleme.. mon héros se déplace à 3 pixels ce qui fait que des fois il "s'enfonce dans le décors et ensuite on peut seulement reculer, sans longer l'obstacle...
Donc il faudrait que je multiplie par 2 ou 3 les détecteurs...pour que Link ralentisse à l'approche du bord pour justement ne pas s'enfoncer.
Pas très pratique..
Peut-être il vaudrait mieux mettre des autres détécteurs derrière ceux que j'ai déjà et ensuite faire reculer link tant que le détécteur touche le décors (de 1 pixel à chaque fois)
Une idée?

Comment tu gères tes collisions ?

Comme Yoshi04 m'a conseillé de le faire,

Citation de: yoshi04 le 06 Janvier 2009 à 00:13
Une boucle sur MMF ?

Voilà un exemple pour se déplacer à droite :

Condition :

Tant que "Touche droite est appuyée"
Non(Tant que "Touche gauche est appuyée")
Non(Tant que "Touche haut est appuyée")
Non(Tant que "Touche bas est appuyée")
Si Capteur Droite ne touche pas un décor
Si Capteur Haut Droite ne touche pas un décor
Si Capteur Bas Droite ne touche pas un décor

Alors :

X_pos => X_pos + (vitesseLink)

Finish !

Après c'est l'un des cas le plus simple là ;)

VitesseLink vaut 3 ou 2 (selon ligne droite ou diagonale)

N'importe qui pourrait le comprendre, vitesseLink = distance en pixel de la marche de Link par boucle...
VitesseLink devrait être égale ou inférieur a 1 pour avoir un mouvement lisse.

Inférieur non, cela déformerait l'image. Egale à 1 ouais possible mais ensuite il faut que je trouve une manière pour qu'il aille plus lentement en diagonale, avec par exemple une variable.
Si j'ai pas d'autre choix je ferai comme sa, d'ailleurs je préfère cette solution à rajouter des détécteurs!

C'est simple, s'il va en diagonale, il suffit simplement d'augmenter X_pos une fois sur deux. ;)
Après, Link ira deux fois moins vite en diagonal, si tu veux de la précision, il faudra que X_pos augmente tous les X fois en horizontal/vertical, et les Y fois en diagonal, Y étant supérieur a X.
Je te laisse la partie mathématique pour connaitre X et Y :p

Quelqu'un s'est déjà chargé de cette partie!  :mrgreen:
En diagonale il doit aller au 2/3 de la vitesse horizontale/verticale, donc 1/3 des déplacement en diagonale ne doivent pas se faire. Bon je vais vite essayer de mettre cette variable!

Edit: Ouais bah au lieu d'aller moins vite en diagonale il va genre 3x plus vite... >_< Sa doit etre parce qu'il prend en compte le déplacement Droite, Bas, Droite-Bas en même temps, ce qui expliquerai le 3x plus rapide... Par contre la variable fonctionne (j'ai ajouté un compteur pour vérifier)
Comment sa se fait qu'il prenne le déplacement à droite avec alors que ce déplacement a dans ces conditions:
(Negate) Si la touche "Bas" est appuyée
??

La, je ne vois que deux solutions : demander de l'aide a quelqu'un qui a MMF, ou multiplier le Y de mon post précédent par 3 :p

Je pose donc la question à quelqu'un qui connait bien MMF2 ^^

Tant que touche droite pressée
Tant que touche bas pressée
[X] Tant que touche haut pressée
[X] Tant que touche gauche pressée

Link(x_pos) = Link(x_pos) + (Link(vitesse)/3)
Link(y_pos) = Link(y_pos) + (Link(vitesse)/3)

Et ça, ça donne quoi ? Et en changeant le diviseur ?
Aussi, pour ton problème de collisions, il te suffit de faire un système de collisions hors-déplacement je pense. Beaucoup plus pratique et tu pourra arriver autant de fois que tu voudra dans un obstacle en une fraction de seconde tu sera tranquille :P.

Aussi, pour éviter le déplacement bas + droite + bas-droite, il te suffit d'ajouter une condition telle une variable bool' pour les déplacements droite, gauche, haut et bas. Et dès que deux touches non opposés ( gauche-droite / bas-haut ) sont appuyés, tu met ta variable sur 1. tu peux même mettre les déplacements cités juste avant dans un groupe d'évent, c'est facile à activer/désactiver.
Mais penses bien à réactiver ces déplacements une fois que les touches sont relachées ;).

Tout d'abord j'ai effacé tt les Vitesse(Link) et je les ai remplacé par des valeurs, c'est plus facile de s'y retrouver.
Ensuite le code que tu as mis est celui que j'utilise. (Désormais Link se déplace d'un pixel par un pixel mais en 70 fps pour pas que le jeu soit trop lent, ce qui évitera aussi les problèmes de collisions!  :) )
J'ai essayé de désactiver le groupe "Droite" et "Bas" (directions tests) mais le problème c'est que MMF2 n'a pas de commande:
Dès que "Touche" est relachée
Donc c'est pas très pratique, je vais essayé de trouver une autre solution..
Que veux-tu dire par systeme hors-déplacement??

Edit: C'est quand même encourageant a part ce problème tout va bien!!! :D :lol: :) :lol: :D

ReEdit: YEEEAAH j'ai trouvé une manière pour que sa fonctionne (heureusement que j'ai mis "Droite", "Gauche", ... dans des groupes d'événement différents! ) :lol: :lol: :lol: :) :D ^_^ ^_^ ^_^ :linkbravo: :super: :mrgreen:

ReReEdit: Faut encore que je trouve un moyen pour qu'il aille plus lentement en diagonale... J'ai mis une variable qui, quand elle arrive à 3 elle fait que Link reste une frame sur place, mais elle sert a rien link va à la même vitesse.
Sinon j'ai essayé de le faire reculer de un quand la variable vaut 3 mais il va trop lentement... je verrai demain!
Je devrai peut etre aussi passer a du 32x32, parce que 16x16 je trouve pas sa tres beau...... >_<

ReReReEdit: Voila mon petit moteur: http://rapidshare.com/files/181104530/Allez_.mfa.html (http://rapidshare.com/files/181104530/Allez_.mfa.html)
Alors...? J'ai bien suivi mes cours!!?  :)
Bon Link ne va pas très vite en diagonale, et peut etre que 100Fps c'est beaucoup mais au moins j'ai pas trouvé de bug!  ^_^

Alors, je suis entrain de faire les glissement à une direction et tout d'un coup je me suis demandé si je devrai recopier ce code de déplacement une fois et modifier les collision pour qu'il fonctione aussi avec les collisions modifiables (herbes hautes, pots, etc...)
Parce que mon image "décors" ne peut etre modifiée en cours de partie je me trompe? Et va-t-il aussi falloir recopier le code pour différencier pot et herbes hautes l'un de l'autre??
Pour cela je pensais mettre un détécteur sous tous les objets pour lesquels les collisions peuvent se modifier et lorsque la collision n'a plus lieu d'être (herbe coupée) supprimer ce détécteur. Mais comment faire correspondre l'objet avec le détécteur qui va avec car sinon cela risque de supprimer tous les détécteurs d'un coup...
Merci!

Dans les 20 conditions pour une direction, je découvre, l'essentiel c'est de comprendre ton moteur.

Une image (objet actif) peut être modifiée en cours de partie, si tu as la notion de "Layer" ou faux calque,
mais pour un carré d'herbe...

Il est possible qu'un objet actif possède plusieurs directions, avec une image "pot" et une image "herbe haute".

Une stratégie d'ensemble, un moteur qui anticipe les problèmes, semble, à mon humble avis, une piste à prendre
en compte surtout pour plusieurs scènes, si le jeu se déroule dans une seule et unique scène pas de problème.

Edit:
Merci d'avoir partagé ton travail.
Pour le fun GO_V3 (exe et mfa), Vitesse maximum de Link=3 sur les diagonales aussi.
Anticipe les problèmes avec 2 variables, il fait moins de 10 lignes.
http://dl.free.fr/thQllr6BC

Chouette petit moteur! Bien condensé comme toujours! ^^
Mais je prefere tout de même le mien, tous les détécteurs me permettent de gérer les glissade exactement comme je veux, même si cela implique plus de lignes..
Je n'avais pas pensé à utiliser plusieurs directions pour insérer plusieurs images... Très bonne idée!!  ^_^
Je vais faire déjà les glissades "1 direction" et je vais essayer d'insérer cela!

C'est bien de suivre ce système de marche proposé simplement, ou même d'utiliser un système de détection. Cependant, si jamais tu voulais utiliser une autre alternative au script de marche, tu peux toujours te référer au tutoriel des Déplacements à collisions glissantes (http://forums.zelda-solarus.com/index.php/topic,17690.0.html) par HCkev, qui est légèrement plus complexe, et ne propose pas de système de programmation en particulier, mais qui a le mérite de donner un résultat satisfaisant pour peu que l'on comprenne ce qu'il faut faire :)

Je viens de lire le tutoriel, et c'est vrai que cette méthode doit être assez fiable, mais arrivé à la fin du tuto, une autre méthode est brièvement expliquée et c'est celle que j'utilise. Elle fonctionne très bien et ne me pose pour l'instant aucun problème.
As-tu pu la tester?

Non, ce doit être une des rares méthodes que je n'ai pas eu le temps de tester, et ce n'est pas cette année que j'aurais beaucoup de temps pour le faire, avec le boulot qu'on demande en Terminale S, et que j'ai du mal, mais je fais confiance à HCkev pour le coup, j'ai déjà pu voir ce que donnait sa programmation, en général, et c'est souvent bon.

Sinon, il est existe une autre méthode, assez semblable, mais qui demande vraiment beaucoup moins de code, que m'avait une fois montré Maxs, mais je ne sais plus en quoi elle consistait exactement (elle était différente de celle sur le tuto de la marche simple), mais tu pourras toujours essayer de le contacter si tu veux en savoir plus :)

Voila j'ai actualisé le lien maintenant les glissades fonctionnnent aussi avec une direction. Les décors sont un peu... minimalistes on va dire!  :P  Mais ce n'est pas mon problème principal pour l'instant.
http://rapidshare.com/files/181829096/Allez_.mfa.html (http://rapidshare.com/files/181829096/Allez_.mfa.html)
Voila! Si vous l'essayez merci de laisser un commentaire pour me dire les + mais surtout les - .

Pas de stratégie d'ensemble.

Risque de rester bloqué dans une scène.

Difficilement, adaptable à tout projet.

Changer de décors sans changer de scène, sans alourdir le moteur de déplacement.
Une stratégie obstacles pour peu de lignes (moteur GO_V3).
http://dl.free.fr/luYAgvsNn

Alors, tout d'abord merci de l'avoir essayé  ^_^, ensuite pour la stratégie d'ensemble ce n'est pas tout a fait juste, je n'ai surement pas pensé à tout car ce n'est pas possible, mais j'ai déjà pensé aux choses comme l'épée, porter des objets, bombe, arc, collisions avec les ennemis (les 8 detecteurs sont la pour savoir lequel à touché link), objets speciaux (rocher qui glisse et qui emporte link avec lui) , et je crois que c'est tout.  :)
Bien sur je ne sais pas si je vais facilement y arriver... mais bon!
Le risque de rester bloqué est possible c'est vrai, mais c'est pour ça que je continue d'imaginer différents cas où cela pourrait se produire.
Difficilement adaptable au projet je ne vois pas pourquoi..  :huh:
Pour les changements de scène vu que je n'en ai encore jamais fait je ne sais pas comment cela se passe... je vais essayer au plus vite.
Pour ce qui est de tes 2 moteurs, j'a déjà remarqué qu'il y avait un problème avec le premier de glissade en diagonale (Lorsque Link glisse contre un mur puis avance droit dessus, il avance d'un pixel, ce qui l'empêche de repartir en diagonale. Et je ne sais pas s'il fonctionne avec les glissades avec les murs à 45°). Pour le 2ème moteur, je ne crois pas qu'il y ait le meme problème que pour le premier mais par contre les glissades de face n'existent pas non plus, et je trouve le détécteur un peu vague avec les murs à 45°.
En tout cas je préfère mon moteur dans ces 2 cas, même s'il est plus voir trop long.

D'autre avis??


Edit: Bon je vais garder ce moteur pour faire mes autres tests. Et j'ai déjà une nouvelle question!  :D
Enfait je me demandais simplement s'il était possible de "créer" un chrono, ou une horloge. Parce que tout faire avec la seule qu'ils mettent à disposition dans le programme... c'est pas super. Et vu que je ne comprend pas la notion de fast loop ou autre ça m'aide pas non plus!..
La seule technique de substitution que je connais pour l'instant c'est "repeat while" et d'y ajouter une variable...Et encore elle marche une fois sur 2 avec moi.

Merci!   ;)

Difficilement adaptable à un autre projet (lol).

Les moteurs proposés sont adaptables, c'est à dire qu'ils sont capables de répondre à plusieurs cahiers des charges.
Il suffit de les modifier, ce sont des bases modulables.

"Il est indispensable de se constituer une base de données moteurs.
Au minimum 4 moteurs.
Case par case 4 directions (notion variable).
Case par case 8 directions (attendre d'avoir un petit niveau en programmation).
Libre 4 directions.
Libre 8 directions.

Les moteurs dans mes messages sont proposés à titre indicatif, sans une stratégie d'ensemble,
ils ne détiennent pas la vérité, ils abordent des notions nécessaires à la réalisation d'une base de
données moteurs, on peut les améliorer."

Je n'ai pas la prétention (ni l'envie) de faire un moteur qui colle au pixel près à ton cahier des charges, ce serait trop beau et trop facile, chacun doit travailler de son côté et ensuite on échange des idées.

Le moteur de déplacement est comme la tuile dans un jeu vidéo, c'est une base déterminante.
Gestion des changements de scènes, des combats, du système de sauvegarde, etc.

"En fait je me demandais simplement s'il était possible de "créer" un chrono, ou une horloge."
Tu as la possibilité d'utiliser un grand nombre de compteurs, c'est à toi de déterminer les usages.

"Et vu que je ne comprend pas la notion de fast loop ou autre ça m'aide pas non plus!.."
Pour une boucle rapide c'est hyper simple.

Tu initialises la boucle => un nom => exemple "rapido"
Ensuite tu mets sur la ligne de la boucle rapide, les actions à reproduire (x) fois.
Tu lances la boucle rapide "rapido" quand tu le souhaites, par exemple en début de scène, les actions
se répéteront très vite, (x) fois.
Utile par exemple pour gérer les plans dans un RPG Tactic (plusieurs personnages joueur et personnages non joueur, hauteur de la scène) => On gère l'avant plan ou l'arrière plan, à l'aide d'un qualifieur en 2 lignes.
Utile aussi pour afficher immédiatement un niveau (level editor).

Edit:
Ton moteur confirme que tu manques de deux notions.
1) Le contre moteur (FMaking 2).
2) "key wait" (LittleBoy 1).
http://pagesperso-orange.fr/spring-up/pages/01pag.html

Je me suis amusé à mettre sur ton moteur un "Key wait", cela fait moins de conditions d'un coup,
donc forcément plus léger pour mmf.
Le contre moteur n'est une obligation, c'est juste un truc en plus à savoir, un peu comme Fast Loop.