Merci beaucoup =)

j'en profite pour laisser mon soundcloud car je mettrais les musiques au fur à mesure dessus (contrairement au bandcamp où j'attendrais d'avoir fini tout l'ost pour le poster complétement !)

En tout cas super taff de ta part (même si je l'avais déjà testé) =D

Test effectué !

Alors, bonne ergonomie.
Dash et double saut sympas.
Sympa de pouvoir s'accrocher aux falaises.

J'ai eu :

• un bug visuel : une image rouge qui est apparue - je te fais un screen demain.
• des bugs de perso coincé quand on fait trop de gauche-droite ou de combo de touches
• des difficultés à sélectionner dans le menu

La musique est bien sympa et les effets sonores aussi.
Je reteste demain, un peu plus reposé !

Après une attaque de chauve souris, le perso a gardé la pose avec le bouclier vers le haut même en marchant, et aussi graphiquement c'est beau mais le découpage se voit un peu a certains endroit par rapport au décor de fond, et de façon général ca fait un peu flou, peut être les effets de lumière un peu trop prononcés je sais pas.
Sinon le reste c'est cool.

C'est graphiquement très sympa je trouve, et ça répond bien ; après j'ai un peu plus de mal avec le panel de mouvements et coups dont j'ai du mal à voir où il est sensé mener dans l'état actuel de ce que tu montres.

Désolé de répondre si tard, j'ai été débordé !
Voici un screen du bug qui apparaît quand j'utilise le feu du bâton de fenouil.

Salut !

J'ai testé ça, et qqs remarques :
________

Les gaphismes sont très sympas, mais attention aux effets de lumière qui sont à mon sens trop violents, surtout concernant leur application au sprite, qui se fait j'ai l'impression de façon direct par rapport à l'intensité de l'éclairage local, qui lui est surtout lié à l'arrière-plan, mais du coup ça va pas pour le sprite qui est plus en avant. Typiquement les torches bleues sont entourées d'une aura de lumière intense, mais si le perso passe devant, cette aura ne doit pas s'appliquer au personnage, qui est devant la torche (et donc devant l'aura, qui n'a pas de raison de se trouver appliquée à une face qui orientée à l'opposée). De même tu as tendance à assombrir les arrières plan qui représentent des renfoncements de la parois rocheuse, logique, mais de la même façon que pour les halos cette assombrissement n'a pas de raison de s'appliquer au personnage qui lui reste sur le même plan, que l'arrière-plan soit soumis à des renfoncements ou non.

Sinon j'ai un problème d'upscale, quand je mets en plein écran Windows me renvoie du 640x480, ce qui ne semble pas être correct (ton jeu est en 16:9, j'imagine du 640x360, soit "le meilleur choix" à mon sens vu sa large compatibilité avec les résolutions modernes), mais je pense que tu devrais réaliser l'upscale dans ton programme, renvoyant une image finale dans la résolution de l'écran. Comme ça tu évites tout risque de problème comme celui que je rencontre.
________

La jouabilité est à mon sens grevée par pas mal d'écueils et d'approximations :

- L'accroche aux rebords devrait se faire plus directement et en tout cas pas en attendant la phase descendante du saut jusqu'à ce que le perso se trouve à une hauteur déterminé ; il faudrait que cela marche dés la phase ascendante, et sans doute préférable à une hauteur supérieur et/ou selon une marge plus important e (là c'est un peu la cata en terme de sensations comme en terme de lourdeur).

- Le dash ne devrait pas faire se retourner le personnage à la fin de l'anim, c'est plus perturbant qu'autre chose et n'a rien de nécessairement désiré par le joueur lorsqu'il effectue cette manœuvre. Tu devrais retourner le personnage que si le joueur a positionné son stick dans ce sens (opposé donc au sens du dash) une fois ce dernier démarré. Pour chipoter (mais qui serait bien en terme de sensation de jeu) une anim/posture de dash arrière lorsque le perso fait arrière + dash serait préférable ; et dans ce cas garder la direction inchangée en fin de dash (= sens opposé au sens du dash) sauf si le joueur a toujours le stick vers l'arrière à la fin du dash.

- La position accroupie pose énormément de lourdeur : elle devrait déjà je pense s'enclencher quand on marche dés le diagonal-bas et pas que stick en bas strict. De même, une fois accroupi, le personnage ne peut pas se retourner (peut-être un choix de game-design ? en tout cas pas pertinent à mon sens) et si on va vers l'arrière en passant par la diagonale, le personnage ne se relève pas (et ne se retourne du coup pas non plus), ce qui pour le coup est nécessairement un problème indésirable. (La chose ne se rencontre peut-être pas vraiment si on utilise un D-pad, mais avec le stick (soit dit en passant seul contrôle qui fonctionne avec ton jeu si on utilise une manette standard (= type "XBox")) on passe naturellement par cette diagonale si on veut se retourner debout depuis la position accroupie.

- Un truc pas super grave mais désagréable, c'est les écrans où le personnage se trouve à monter ou descendre en diagonal dans la profondeur du plan (pas en hauteur) alors qu'on avance juste vers l'avant. d'autant que cela n'a aucune justification dans les écrans où cela survient. Si tu as l'impression d'être gêné par des éléments de décors ( les moutons p.ex.), déjà ça ne gène pas que le personnage passe devant (ta représentation implique de façon naturelle que des sprites se chevauchent si l'un se trouve devant l'autre dans la profondeur) et au pire remonte à l'inverse ces éléments de décors plutôt que faire baisser la trajectoire du personnage.
________

En terme de game-design, je trouve ça pas bien satisfaisant non plus. Le fait de ne pouvoir frapper que vers l'avant ou encore la rigidité des déplacements ne s'accorde pas du tout avec les trajectoires des ennemis, notamment des chauve-souris, les deux ne vont pas du tout ensemble, comme si issus de deux jeux non compatibles dans leur gameplay. Un game-design satisfaisant implique que les capacités et comportements des ennemis soient en adéquation avec celles du joueurs, sinon ça va vraiment pas du tout.
________

Enfin, l'ergonomie souffre de problèmes assez importants de cohérence et d'intuitivité :

- P.ex. valider dans le menu de départ se fait avec "START" mais on valide avec "A" dans le menu suivant (peut-être avec "START" aussi dans ce cas d'ailleurs, mais dans tous les cas valider avec "A" et annuler/fermer/revenir en arrière avec "B" est devenu un standard qu'il me parait important de respecter autant que possible (et là, c'est clairement possible)).

- En jeu "X" et "Y" paraitrait les meilleurs choix par défaut pour assigner les armes (en lieu et place de "B" et "Y"). En plus de respecter les habitudes de beaucoup de jeux, cela permettrait de façon salutaire de préserver dans le menu d'inventaire les classiques "A" et "B" pour "valider" et "fermer" (puisque du coup on affecterait les armes avec "X" et "Y").

- Au niveau de la représentation des niveaux, y'a aussi des vrais problèmes de cohérence (ou en tout cas d'intuitivité) dans la façon dont s'enchainent les tableaux : j'entre dans un tableau en allant vers la droite, et je me retrouve à sortir par une porte placée sur l'arrière-plan (enfin, en fait on s'en rend compte quand on emprunte cette porte : "Ah, en fait c'était de là que je venais ??"). "Logiquement", si j'entre dans un tableau en allant vers la droite, on s'attend à entrer/sortir du suivant par son bord gauche. De même que quand on passe par une porte qui est dans la profondeur, c'est pas mal de sortir d'une porte dans la profondeur. Dans le même ordre d'idée, vu comment se structure ton niveau, ça me paraitrait pas mal de bien différencier ce qui constitue les salles périphériques par les portes en profondeur (bon, là ça va, c'est ce que tu as fait) de l'avancée du niveau, qui devraient globalement conserver la continuité par les bords de l'écran, ou quand se fait par une ouverture dans la profondeur (qui devrait rester je pense lié à certaines étapes particulières de la progression), prenant une représentation graphique bien différenciée apportant l'emphase (et la compréhension tacite) qu'il faut. Après, si tu veux jouer sur un aspect "labyrinthe" qui perde facilement le joueur ... pourquoi pas, mais ça me parait rarement réussi et pertinent comme choix, ou en tout cas demande d'être particulièrement réfléchi et soigneusement mis en œuvre pour s'avérer satisfaisant.

- A ce titre d'ailleurs, tu devrais à mon avis revoir les anims de franchissement de portes, qui alourdissent le jeu je trouve (sauter directement d'un écran à l'autre (sans anim donc) suffirait je pense ; ou à la limite une étape de dos puis une étape de face à l'écran suivant (apportant possiblement de la lisbilité à l'action par une bonne perception de sa continuité), et c'est tout).

- Un truc mineur sinon (mais qu'il faudra en tout cas changer à terme), c'est les retours à la ligne dans l'apparition des textes, qui renvoient à la ligne les mots en cours de leur écriture .... trééés désagréable à la lecture je trouve, les mots doivent s'écrire directement à leur bonne ligne d'attribution finale, et pas se sauver en cours de route sous les yeux du lecteur. :/
________

Bon, ça fait beaucoup de critique je te l'accorde ...
... et j'espère surtout ne pas te décourager, c'est tout sauf le but en tout cas, au contraire, tout cela ne relève pour l'essentiel que d'ajustements qui ne doivent pas nécessité de modifications fondamentales de ton code, donc plutôt positif ! En effet, techniquement tout semble rouler, donc le plus gros du travail parait tout à fait convaincant. Et d'ailleurs bravo pour cela !

________

Sinon, concernant la publication / diffusion de ton jeu (et entre-temps, de tes démos), je te conseille de jeter un œil à itch.io qui est justement dédié à cela :
https://itch.io/developers

Et évite (du moins tant que tu n'es pas dans une version finale) les programmes à installer (comme c'est le cas actuellement), qui rendent bien lourde la procédure juste pour tester une build ; cela t'expose au risque de refroidir certains et d'avoir moins de retours de joueurs.