Aide et conseils pour moteur sur MMF 2

[limule]

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...)

[yoshi04]

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 
Par contre c'est dans la langue de Shakespeare attention !

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

[limule]

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 )
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... ...jamais de bol moi...

[Daru13]

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

Code Sélectionner Étendre


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


Code Sélectionner Étendre


Si $temps > 1
__$temps - 1
End


Code Sélectionner Étendre


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 .

[lock]

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

[limule]

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?

[Daru13]

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 ?

[limule]

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.

[Daru13]

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 .

[limule]

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
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!  ) 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..)

[yoshi04]

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" 


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  ).


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 

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 

[limule]

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!!
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 )
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 

[Daru13]

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' .

[limule]

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...

[yoshi04]

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.

[limule]

Ok mais comment fait-on pour dire :
Si link touche Objet(x), déplacer Objet(y) 25 à droite
? 
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...)

[yoshi04]

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"

[Daru13]

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

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

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

[limule]

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 

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

[yoshi04]

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

(Certains connaissent déjà ce sigle  )

[limule]

HAHA!! 
Je viens enfin de comprendre! 
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  )
Merci! Je vais enfin pouvoir avancer un peu mon moteur!

[limule]

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??

[Daru13]

Fais-le manuellement *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 .

[yoshi04]

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

[limule]

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!        
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 

[Zaki]

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 

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 :

Si 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é.

[Daru13]

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.

[limule]

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...

[yoshi04]

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 )

[Spring Up]

Salut les clickeurs,

Alors on cogite...

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.

[limule]

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é...>_<)

[Spring Up]

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

[limule]

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
Voila, et merci de m'aider

[Spring Up]

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).

[limule]

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!!

[Spring Up]

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.

[limule]

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!

[yoshi04]

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 !

[limule]

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

[Noxneo]

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

RPG Maker permet de le faire en 0 lignes 

[limule]

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

[limule]

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

[yoshi04]

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  )

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 

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 :



Lien du tuto : Tuto Systèmes de marche simple

[limule]

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 

[yoshi04]

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"

[limule]

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

[limule]

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

[Arca]

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.

[limule]

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?

[yoshi04]

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 !!!