Legend of Zelda : WIP

Démarré par Cyberclic, 07 Août 2011 à 20:38

0 Membres et 1 Invité sur ce sujet

07 Août 2011 à 20:38 Dernière édition: 25 Août 2011 à 21:44 par Cyberclic
Salut à compagnie,

Je me suis amusé à faire un petit moteur de Zelda à la Zelda 3 (ALTTP). Il est loin d'être complet et extraordinaire, mais j'ai bon espoir de m'approcher du moteur de la SNES.
Voilà une ébauche. N'hésitez pas à me faire par de vos remarques.

A terme, j'espère sortir un jeu complet.

Se joue au clavier, avec les touches de direction + Shift + Ctrl + Espace + Entrée
Prévu pour y jouer au pad, mais pas encore implémenté dans cette démo.

Download : http://download.margasoft.fr/zelda.zip

A+
Cyberclic

Bonjour,


C'est un bon début :) Mais comme c'est un WIP, il y a quelques éléments à rectifier. Voici ce que j'ai remarqué:


  • Link se déplace trop rapidement en diagonale. C'est une erreur que beaucoup de makers font: ils additionnent simplement le déplacement X et Y, alors le déplacement en diagonale est beaucoup plus rapide car la longueur d'une diagonale est plus longue que les côtés. Un arc de cercle autour du point de départ indiquerait la bonne distance autour de la position initiale.

    Enfin, voici un croquis agrandi pour représenter le tout(en supposant que Link se déplace de 3 pixels en ligne droite, ce qui est une bonne vitesse pour un moteur tournant en 30 fps):


    Dans le cas de ton moteur, Link parcours la distance représentée en bleu(~4.25px VS 3px), ce qui est trop long pour avoir une vitesse équivalente. L'arc de cercle dessiné en gris représente la distance que devrait parcourir Link. Il faudrait qu'il parcourt la ligne Orange(derrière la ligne bleue). Tu peux obtenir la vitesse diagonale avec la formule suivante: Cos(45) * 3, où 45 représente l'angle (45° donc) et 3, la vitesse en ligne droite (ici, 3 pixels donc), ce qui fait ~2,12. Enfin, cette formule calcule la distance de déplacement en X, il faudrait utiliser Sinus au lieu de Cosinus pour la distance Y, mais le résultat est le même pour un angle de 45° ^_^.

    Pour des objets qui ne se déplacent pas rapidement (comme Link), on peut simplifier le tout en utilisant le deux tiers de la vitesse (donc dans ce cas, un déplacement de 2px en X et Y), la vitesse "perdue" étant plutôt marginale.
    Voilà pourquoi les maths sont importants en programmation :ninja:

  • Si on se déplace en diagonale vers la clôture, le Sprite de Link rebondit sans arrêt sur le décors. Même chose si on se déplace vers les coins de la falaise à droite (en haut et en bas de la falaise).

    Étrangement, si Link porte un buisson, seulement le buisson rebondi, Link reste en place.

  • Si on se déplace en direction Bas-gauche vers la fin de la falaise à gauche, Link se met à glisser en direction Haut-gauche, alors qu'il devrait s'arrêter. Le même phénomène se produit si on se déplace en direction Haut-droite dans le bas de cette fin de falaise: Link se déplace en direction bas-droite alors qu'il devrait s'arrêter


    En rouge, la direction vers laquelle Link se déplace, en rouge foncé, la direction de déplacement lors de la collision

  • Link se déplace un peu trop lentement lorsqu'il porte un buisson, il faudrait l'accélérer un peu :)

  • Lorsqu'on lance un buisson, Link demeure figé jusqu'a ce que le buisson touche le sol. Normalement, Link devrait pouvoir bouger dès qu'il l'a lancé et non pas attendre que celui-ci éclate.

  • Lorsque Link coupe un buisson en chargeant son épée, la petite étincelle d'impact est toujours visible, elle ne devrait pas y être lors de la coupe d'un buisson ;) Enfin, c'est un détail mais bon :D

  • Lorsque Link fait face vers la gauche, le sprite est décalé de 1 pixel vers la gauche par rapport aux autres directions. Oui, je vois ce genre de petits détails :P

  • Les buissons n'éclatent pas sur les décors lorsqu'on les lance. Enfin, j'imagine que c'est prévu et simplement pas encore programmé ^_^



Pour l'éditeur de maps, ça me semble plutôt bien fait, par contre, est-ce normal que je ne vois pas le pointeur de ma souri? Ça va un peu mal car on se sait pas exactement où pointe la souri ^_^ Également, la petite liste de Tilesets semble ne pas fonctionner pour le moment

C'est simple et efficace pour le moment, après, j'imagine que d'autres fonctionnalités verront le jour, comme la possibilité de changer la taille des maps et pouvoir "remplir" la salle avec un tile en particulier (pour le moment, pour le gazon, c'est assez chiant de devoir "dessiner" toute la map pour mettre le fond vert ;)) :)



Voilà, quelques points pour rendre le tout meilleur ^_^

Bonne continuation :)

Merci pour tes conseils avisés !  :D

Citation de: HCkev le 08 Août 2011 à 04:19Link se déplace trop rapidement en diagonale. C'est une erreur que beaucoup de makers font: ils additionnent simplement le déplacement X et Y, alors le déplacement en diagonale est beaucoup plus rapide car la longueur d'une diagonale est plus longue que les côtés. Un arc de cercle autour du point de départ indiquerait la bonne distance autour de la position initiale.
En effet, Link se déplace trop rapidement en diagonale. Le problème c'est que MMF gère mal, pour ne pas dire pas du tout, les nombres à virgule. Je suis contraint d'utiliser des valeurs entières pour le nombre de pixel à utiliser pour le déplacement.

Actuellement, Link se déplace de 2px en X et en Y.
Une solution consisterait à ce que j'augmente sa vitesse de déplacement à 3px afin que je puisse attribuer 2px en X et Y lors du déplacement en diagonale.
Une autre solution consisterait à ce que j'utilise un timer.

Je vais voir ce que je peux faire.

Citation de: HCkev le 08 Août 2011 à 04:19
Si on se déplace en diagonale vers la clôture, le Sprite de Link rebondit sans arrêt sur le décors. Même chose si on se déplace vers les coins de la falaise à droite (en haut et en bas de la falaise).

Étrangement, si Link porte un buisson, seulement le buisson rebondi, Link reste en place.

Si on se déplace en direction Bas-gauche vers la fin de la falaise à gauche, Link se met à glisser en direction Haut-gauche, alors qu'il devrait s'arrêter. Le même phénomène se produit si on se déplace en direction Haut-droite dans le bas de cette fin de falaise: Link se déplace en direction bas-droite alors qu'il devrait s'arrêter
OK. Je vais corriger ça.

Citation de: HCkev le 08 Août 2011 à 04:19
Link se déplace un peu trop lentement lorsqu'il porte un buisson, il faudrait l'accélérer un peu :)
Là aussi, problème de restriction due à MMF. Il ne se déplace qu'à 1px.
Il faut que je trouve une parade, comme dit plus haut.

Citation de: HCkev le 08 Août 2011 à 04:19
Lorsqu'on lance un buisson, Link demeure figé jusqu'a ce que le buisson touche le sol. Normalement, Link devrait pouvoir bouger dès qu'il l'a lancé et non pas attendre que celui-ci éclate.
C'est voulu. Je vais réduire le temps de fige si ça pose problème.

Citation de: HCkev le 08 Août 2011 à 04:19
  • Lorsque Link coupe un buisson en chargeant son épée, la petite étincelle d'impact est toujours visible, elle ne devrait pas y être lors de la coupe d'un buisson ;) Enfin, c'est un détail mais bon :D
Comportement normal et identique à ALTTP sur SNES.

Citation de: HCkev le 08 Août 2011 à 04:19
Lorsque Link fait face vers la gauche, le sprite est décalé de 1 pixel vers la gauche par rapport aux autres directions. Oui, je vois ce genre de petits détails :P
Je connais ce soucis mais c'est intentionnel afin de me simplifier la tache pour la gestion des capteurs environnants de Link.

Citation de: HCkev le 08 Août 2011 à 04:19
  • Les buissons n'éclatent pas sur les décors lorsqu'on les lance. Enfin, j'imagine que c'est prévu et simplement pas encore programmé ^_^
Comme tu l'as deviné, pas encore implémenté ^^[/list][/list]
Posté le: 08 Août 2011 à 06:53
J'ai corrigé l'ensemble des problèmes cités. Encore merci pour ton aide, tu seras dans les crédits :)

25 Août 2011 à 21:46 #3 Dernière édition: 25 Août 2011 à 21:48 par Cyberclic
Nouvelle version du moteur avec toutes les corrections + implémentation des bombes,  du scrolling et de l'herbe.
Le lien est toujours le même : http://download.margasoft.fr/zelda.zip

J'ai blindé la map d'objets actifs, comme l'herbe, pour voir si ça tient le choc et si ça ne rame pas trop.
A priori ça fonctionne plutôt bien, vu que le moteur utilise DirectX 9 pour l'affichage. Dites-moi si ça rame.

26 Août 2011 à 01:33 #4 Dernière édition: 26 Août 2011 à 01:34 par Daru13
Ça semble plutôt bien parti,e t je n'ai pour ma part eu aucun lag, même en posant de nombreuse bombes sur l'herbe, etc ^^.
En revanche j'ai trouvé quelques bugs :P :

- Parfois, quand je pose plusieurs bombes à la suite rapidement, elle vont rester au stade du clignotement, et n'explosent pas (sauf si on les soulèvent avec Shift, auquel cas l'explosion se produit, pour la bombe soulevée j'entends, de suite).
- Ce n'est pas vraiment un bug, mais je te conseille de laisser Link passer sur les bombes posées (au lieu de les considérer comme obstacles, ça pourrait bloquer Link). Aussi, il faudrait réduire la "cadence de pose" je pense ^^.

Un screen pour les deux problèmes évoqués ci-dessus :


- Autre truc avec les bombes, quand on en pose une sur un rocher (ceux qu'on peux soulever) elle sera dessus, mais lors du changement d'écran elle passe en dessous.
- Aussi, une bombe placée devant Link lors d'une de ces transition va donner un carré noir, pas très joli (autant interdire l'utilisation d'objets durant un changement d'écran je pense ^^).
- Si on poe une bombe, la soulève et la jette de suite tout en en posant une seconde, des fois la bombe se place derrière Link il me semble (?).
- Dernière chose notée : petit bug de collision, on peux marcher sur la partie gauche de la statue la plus à gauche sur l'écran sur lequel on commence.

Hm sinon, si on omet les différents problème niveau mapping (mais je doute que ce soit ici l'aspect travaillé), il manque des trucs, genre le recul de Link face aux exposions, l'animation différente lorsque l'on marche sur l'eau (et la possibilité de se noyer ou de nager), mais je suppose que ça sera ajouté dans le futur :).

Bravo pour ce moteur en tout cas, on attends la suite... ^_^ !

    







Merci pour ton retour !

Citation de: Daru13 le 26 Août 2011 à 01:33Parfois, quand je pose plusieurs bombes à la suite rapidement, elle vont rester au stade du clignotement, et n'explosent pas (sauf si on les soulèvent avec Shift, auquel cas l'explosion se produit, pour la bombe soulevée j'entends, de suite).
Je n'ai pas réussi à reproduire le bug. De toute façon, je vais limiter le nombre de pose et réduire la cadence de pose. Ça devrait corriger le problème. Là c'était juste pour les tests.

Citation de: Daru13 le 26 Août 2011 à 01:33Ce n'est pas vraiment un bug, mais je te conseille de laisser Link passer sur les bombes posées (au lieu de les considérer comme obstacles, ça pourrait bloquer Link). Aussi, il faudrait réduire la "cadence de pose" je pense ^^.
J'ai hésité justement à faire comme pour ALTTP. Je me suis dit que passer au-dessus d'une bombe ça fait assez bizarre et assez moche. Mais bon, pourquoi pas si c'est mieux.

Citation de: Daru13 le 26 Août 2011 à 01:33Autre truc avec les bombes, quand on en pose une sur un rocher (ceux qu'on peux soulever) elle sera dessus, mais lors du changement d'écran elle passe en dessous.
C'est corrigé.

Citation de: Daru13 le 26 Août 2011 à 01:33Aussi, une bombe placée devant Link lors d'une de ces transition va donner un carré noir, pas très joli (autant interdire l'utilisation d'objets durant un changement d'écran je pense ^^).
Corrigé là aussi

Citation de: Daru13 le 26 Août 2011 à 01:33Si on poe une bombe, la soulève et la jette de suite tout en en posant une seconde, des fois la bombe se place derrière Link il me semble (?).
En effet. Ca sera corrigé quand je réduirais la cadence.

Citation de: Daru13 le 26 Août 2011 à 01:33Dernière chose notée : petit bug de collision, on peux marcher sur la partie gauche de la statue la plus à gauche sur l'écran sur lequel on commence.
C'est fait exprès pour éviter un bug de collision scrolling dans la map de test qui n'est pas adaptée au moteur.

Citation de: Daru13 le 26 Août 2011 à 01:33Hm sinon, si on omet les différents problème niveau mapping (mais je doute que ce soit ici l'aspect travaillé), il manque des trucs, genre le recul de Link face aux exposions, l'animation différente lorsque l'on marche sur l'eau (et la possibilité de se noyer ou de nager), mais je suppose que ça sera ajouté dans le futur :).
La map c'est une capture officielle de ALTTP, juste pour tester :D
Quant au recul des dégâts et à la marche sur l'eau c'est pas encore implémenté  ;)

J'ai testé, c'est un bon début je trouve! :)

Bien sûr il y a tous les problèmes précedemment cités, il faut absolument mettre une limite au nombre de bombe qu'on peut poser et enlever l'effet d'obstacle de la bombe.

Mis à part que j'avais un écran immense qui ne correspondait pas au cadre d'affichage normal (d'ailleurs quelle résolution d'écran comptes-tu mettre?).

Sinon aucun lag à signaler, c'est du tout bon, une fois ces éléments corrigés tu pourras sans problème passer à la suite.

26 Août 2011 à 14:40 #7 Dernière édition: 26 Août 2011 à 14:47 par Cyberclic
Merci :)

L'ensemble des problèmes cités ont été corrigé.
J'ai mis une limite de 2 bombes en même temps. Ca me semble correct, non ? Et on passe au travers des bombes.

Quant à la résolution, c'est celle du jeu jeu officiel, à savoir 256x224. La fenêtre d'affichage peut-être redimensionnée à la volé par l'utilisateur. Ça ferra un effet "stretch" en grossissant les pixels et en remplissant l'intégralité de la fenêtre, quitte à déformer l'affichage si le ratio n'est plus le même.

Je proposerais en option d'affichage de passer en ratio 1x1, 2x2, 3x3 ou 4x4, voire un plein écran avec proportion conservée (donc bande noire)
Actuellement on est à 3x3 (un grossissement de 3 fois donc, en X et en Y)

Je trouve que le fait d'avoir un fenêtre de jeu agrandie par rapport à la résolution normale est une bonne chose, parce que les moteurs Zelda (ou autre d'ailleurs) sur des petites fenêtres (genre taille d'un écran de GB ou proche, ça se voit souvent) je trouve ça un peu injouable personnellement :P.

La limite de deux bombes me semble également bien sinon :).

    







12 Septembre 2011 à 17:05 #9 Dernière édition: 12 Septembre 2011 à 17:09 par Cyberclic
Nouvelle version du moteur technique. Au programme :
- Correction des bugs précédents
- Ajout du système de dialogue avec coloration des mots et défilement fluide
- Gestion de l'eau
- Prémices d'un HUD (j'aurais besoin de vos avis là-dessus)
- Prémices de la carte du monde en 3D comme sur ALTTP. (ça n'est pas du Mode7, même si ça y ressemble :D)
- Gestion des manettes de jeux (Xbox, génériques) et de différents profils clavier
- Ajout de bonus dans les herbes et buissons
- Autres nouveautés diverses.

N'hésitez-pas à me remontrer les bugs afin que je puisse continuer sur un moteur sain  :D
Et donnez votre avis, surtout au niveau du HUD, encore incomplet.

Le lien de téléchargement, ne change pas :
http://download.margasoft.fr/zelda.zip

26 Septembre 2011 à 01:50 #10 Dernière édition: 26 Septembre 2011 à 01:55 par yoshi04
C'est une bonne initiative de te lancer dans un moteur ALTTP sur multimedia fusion :)
Les différents tutos "Alttp-like" pour MMF du forum sont sans aucun doute peu complets face à ton projet actuel, et si tu le souhaites, il pourra figurer dans la liste des tutoriaux de ce forum.

Par ailleurs, je n'utilise plus Windows ces temps ci, saurais-tu si un port vers Unix/OSX est prévu pour des futures version de MMF ? Après les jeux exportables pour flash/ipad et j'en passe, ça pourrait s'envisager non ? Surtout que des "concurrents" tels que Game develop 2 ont ce type de ports.

26 Septembre 2011 à 12:24 #11 Dernière édition: 26 Septembre 2011 à 12:30 par Cyberclic
Merci pour ton message.

Vu que j'utilise les logiciels Click (Klik&Play, The Game Factory, Multimedia Fusion) depuis plus de 15 ans, sans vouloir me venter, je maîtrise plutôt bien Multimédia Fusion  :D D'où mon choix de l'utiliser pour mon projet.

Quand le moteur sera prêt, je ne vois pas d'inconvénient à le proposer sous forme de tuto.

Actuellement, avec MMF2, on peut compiler en application Windows, Java, Flash, en application iOS (iPhone, iPad) et très bientôt en application MAC OS, Android et Windows Phone 7.
Par contre, toutes les extensions que j'utilise ne sont pas écrites pour ces différents runtime. Je serais donc bloqué.
Faudra attendre MMF3 pour enlever cette restriction.

Je compte donc sortir en parallèle une version light sur smartphone (iPhone, Android et WP7) qui interagira avec la version complète dispo sur Windows uniquement. Cette version light permettra de débloquer certaines choses sur le jeu complet.

Par contre pas sur que ça sorte sur iPhone, avec les restrictions de Copyright et de droit d'auteur, Apple ne validera surement pas mon jeu sur leur store. Possible que je le propose via Cydia dans ce cas.

Je viens de tester la nouvelle démo, ça commence à devenir vraiment sympa ! Et perso j'adore tes boites de dialogues :D !
Bref, bien moins de bugs trouvés par rapport à la version précédente... ^_^.

- Quand on a chargé l'attaque cyclone et qu'on longe le bord d'une statue (ou autre, probablement) en tapant avec l'épée, on peut parfois couper une touffe d'herbe quand on atteint un angle (en "glissant" contre l'angle quoi). Je ne sais pas si on peut qualifier ça de bug, mais il ne me semble pas, de mémoire, que ce genre de chose soit possible sur ALLTP - et autant le but n'est pas forcément de recopier à la lettre le moteur d'ALTTP, autant si on ne coupe jamais d'herbe ayant l'attaque cyclone chargée, ça fait bizarre quoi ^^.

- Si on est proche du haut d'un écran et qu'on jette une bombe à l'horizontale, elle sort de l'écran et disparait pour peu qu'elle passe la bord de cet écran.

- Pas gênant, mais je précise au cas où : c'est possible d'avoir trois bombes en même temps à l'écran. Si on en pose deux à la suite et qu'on en jette une des deux, il est possible d'en reposer une autre avant que celle jetée n'explose.

- Autre petit détail sur les bombes : si on en porte une et qu'elle explose, son champ d'action ne prendra pas les pieds de Link pour milieu mais celui de la bombe au dessus de sa tête, or à priori la bombe est au dessus des pieds de Link, donc l'explosion devrait à mon avis toucher les éléments un tile plus bas

- Je suppose que tu n'as simplement pas intégré ça, mais impossible de fermer la map une fois ouverte sans quitter le jeu ^^.

Bref, à part ces petites choses, t'as réussi à intégrer un HUD qui a de la gueule du premier coup, chapeau :P !
Niveau design il me semble bien (et le changer en fonction du périphérique d'entrée et de la config des touches c'est aussi vraiment bien vu, on voit rarement ça sur des moteurs Zelda !) ; une petite remarque sur le nom du bouton ou de la touche simplement, pas toujours très lisibles (éventuellement le mettre en petits caractères bien lisibles au niveau du contour du bouton sinon, mais bon, faut voir si ça passe si bien que ça - parce que bon, une fois qu'on a utilisé le moteur cinq minutes c'est pas bien dur de savoir quelle touche correspond à quel bouton, donc la visibilité de la touche affectée n'est pas vraiment primordiale :)).
Quant aux coeurs et à la barre de magie, ils sont très bien comme ça.
Ah, aussi, j'ai pas trouvé l'utilité du petit bouton gris dans le HUD, il correspond à quoi, la touche entrée ?

Par contre, je trouve que le HUD prend un peu trop de place, mais ça s'explique pas mal avec le grossissement de la fenêtre à mon avis (en gros, je trouve parfait de jouer en zoom x3, mais le HUD reste un agrandi du zoom x1, donc le fait qu'il prenne une place un peu grande peut se comprendre, vu qu'il n'est pas prévu pour une telle résolution à la base). Cela dit, il serait possible d'avoir un gain de place en cachant par exemple le bouton pour la touche espace lorsque aucune action n'est disponible (et donc ne l'afficher que quand Link se retrouve devant un panneau, personnage, etc...).

Encore bravo pour tout ça et pour ce que tu prévois de faire, et vivement la prochaine démo ! :)

    







28 Septembre 2011 à 19:52 #13 Dernière édition: 28 Septembre 2011 à 19:56 par Cyberclic
Merci, je suis heureux que tu apprécies mon modeste moteur. Les bugs cités seront corrigés.

Actuellement je planche un peu sur le menu pause (inventaire, quête statut). Accessible via la touche entrée ou le bouton start des manettes (le fameux bouton gris du HUD)
Je ne suis pas très doué niveau design, voilà une ébauche fait à la va vite des 2 écrans. Je recherche un truc sobre, sans fioriture. Si vous avez des idées pour améliorer tout ça niveau design sans pour autant alourdir le tout...


Je le trouve déjà pas mal comme ça... Peut-être un essai avec les carrés gris clair sous les objets en moins ?

Je te conseille également d'espacer un peu plus, verticalement, les objets à gauche du menu Statut quête (la bourse, le sac de bombes et le carquois donc), garder un même espacement que pour l'équipement de Link par exemple (à la droite du menu Inventaire) - surtout qu'il y a de la place de disponible en dessous de ces trois objets :).

    







Oups, les carrés gris clair c'était temporaire. Ça me servait juste de repère. C'est enlevé.
J'ai décalé un peu les objets comme tu as préconisé, et c'est bien mieux. Merci !

03 Septembre 2012 à 15:38 #16 Dernière édition: 03 Septembre 2012 à 16:43 par Cyberclic
En lisant certains projet ici, ça m'a donné envie de continuer un peu mon Zelda.
Voilà quelques images du menu sélection. Le fond d'écran scroll et change de couleur tout seul de manière fluide, pour un effet plutôt sympathique  :P





Le passage aux divers écrans menu et jeu est toujours fait de manière fluide, via des glissements et des rebonds comme sur iOS.

Pour ceux que ça intéresse, vous pouvez tester le menu en le téléchargeant ici :
http://download.margasoft.fr/menu-zelda.zip

Le programme keyboard.exe vous permet d'assigner les touches du clavier.
N'oubliez pas d'installer la police pkmndp.ttf fournie dans le zip

très sympa dis donc comme menu^^ . C'est cool que tu continu ton projet moteur  ^_^

03 Septembre 2012 à 16:08 #18 Dernière édition: 03 Septembre 2012 à 16:29 par Cyberclic
C'est en partie grace à toi que je m'y suis remis, surtout quand t'as commencé à utiliser MMF2  :D
J'ai édité pour rajouter un lien de téléchargement, si vous pouvez tester pour voir si c'est fluide ou pas...

Je viens de tester ton menu , c'est vachement bien dis donc . et Fonctionnel en plus .

Moi j'ai eu juste un petit bug. Le mot "OPTIONS" est en deux ligne dans la case . j'ai "OPTION" sur une ligne et "S" en dessous.

:D

Désolé, il te manque la police de caractère de Pokemon DP que j'utilise.
http://download.margasoft.fr/pkmndp.ttf

Je l'ai rajouté dans l'archive.

Le fond fait un peu mal aux yeux si on le regarde trop je trouve (le défilement de carrés plus sombres par dessus joue pas mal je pense ^^), mais à part ce détail-ci, le menu est très clean, fluide et beau, bravo !

Une petite suggestion quand même : lorsqu'on sélectionne un fichier sans partie enregistrée dessus, accéder directement à l'écran de sélection de nom me semble aussi simple (sachant que c'est la seule option possible dans ce cas-ci), plutôt que devoir cliquer sur le bouton de création, même si ce n'est pas une grosse perte de temps ^_^.

    







Merci pour vos retours.

Si vous avez des manettes de jeu, est-ce que ça les reconnais bien ? Normalement c'est Plug&Play à chaud. On branche et on peut sélectionner manette dans les options. On débranche et ça bascule aussitôt sur clavier qui devient seul choix disponible.
Je n'ai pu tester qu'avec mes 2 manettes (Xbox 360 for PC et manette de la Freebox V6), donc ceux qui ont des Logitech ou autres sont les bienvenus  :D

J'adore ton menu de selection, ce petit mix Zelda avec les couleurs de Mario 64 fais original, continue ainsi, nous sommes avec toi :)

23 Septembre 2012 à 22:24 #24 Dernière édition: 23 Septembre 2012 à 23:12 par Spring Up
Salut Cyberclic,

Niveau bombe, il n'y a pas de gestion des plans (link avec une bombe, bombe avec une autre bombe), je ne me souviens plus si le moteur original avait cela. Si oui, il y a cette solution passe partout.

http://clickmoteur.blogspot.fr/2011/01/gestion-des-plans-un-classique.html

En espérant t'avoir un peu aidé (niveau bogue), bonne continuation pour la suite.

A+
Moteurs cases à cocher (tgf, mmf).
De l'aide sur un blog pour finaliser:
http://clickmoteur.blogspot.com/

Salut Spring Up, merci pour ton retour.

L'absence de gestion de plan est voulu, pour coller au mieux au moteur original de Zelda 3 sur SNES qui en est aussi dépourvu.
De plus, avec MMF2, ça se met très facilement en place avec l'objet calque où une action est prévue pour.