Aide et conseils pour moteur sur MMF 2

Démarré par limule, 02 Décembre 2008 à 23:28

0 Membres et 1 Invité sur ce sujet

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

07 Janvier 2009 à 17:54 #64 Dernière édition: 07 Janvier 2009 à 17:56 par Neo2
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

07 Janvier 2009 à 18:00 #65 Dernière édition: 07 Janvier 2009 à 18:22 par limule
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 ;).

    







07 Janvier 2009 à 19:14 #69 Dernière édition: 08 Janvier 2009 à 18:09 par limule
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
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!

09 Janvier 2009 à 21:11 #71 Dernière édition: 09 Janvier 2009 à 22:01 par Spring Up
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
Moteurs cases à cocher (tgf, mmf).
De l'aide sur un blog pour finaliser:
http://clickmoteur.blogspot.com/

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 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
Voila! Si vous l'essayez merci de laisser un commentaire pour me dire les + mais surtout les - .

12 Janvier 2009 à 12:31 #77 Dernière édition: 12 Janvier 2009 à 12:45 par Spring Up
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
Moteurs cases à cocher (tgf, mmf).
De l'aide sur un blog pour finaliser:
http://clickmoteur.blogspot.com/

12 Janvier 2009 à 19:49 #78 Dernière édition: 12 Janvier 2009 à 22:44 par limule
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!   ;)

13 Janvier 2009 à 13:34 #79 Dernière édition: 13 Janvier 2009 à 19:38 par Spring Up
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.
Moteurs cases à cocher (tgf, mmf).
De l'aide sur un blog pour finaliser:
http://clickmoteur.blogspot.com/