Animations des attaques

[ET-AD]

Je suis sur l'animation d'attaque PNJ. J'ai supposé monsterOne est un FireLord (extends PNJ) son attaque projète des boules de feu (Fireball extends Element) qui au contactent avec le joueur explosent et blessent le joueur.

Je rencontre des soucis avec les boules de feu. Je m'y prends peut être mal mais actuellement c'est Firelord qui créé Fireball et cela me pose quelques soucis en particuliers :

• tester déplacement (collision solid/joueur) de la fireball. Les collisions étant gérées par map (et je trouve cela cohérent mais je ne me vois pas passer la map en argument...)
• isOnEdge implémenté directement sur KeyPressed(xxx)
• Autre problème secondaire : Fireball actuellement extends Element car Mobile n'est pas Crossable (facilement corrigable mais je ne veux pas impacter le reste du code pour le moment)

Avant d'aller plus loin et de faire des modifications qui impacteraient d'autres parties du code, j'aimerais votre avis sur comment gérer le déplacement de la boule de feu proprement. De l'aide ne serait pas de trop.

• SHA: 470d950c5abd1eb77a660fce997082d98e4260a4

PS : j'ai rajouté les diagonales à Direction, pour que boule de feu puisse se déplacer en diagonale.

[caronpe]

Etienne, je sais pas si tu as compris le fonctionnement de github et je pense qu'il faut se voir pour discuter de ça et se mettre d'accord! Je sais pas si tu as remarqué mais cette issue m'est assigné... (Chaque membre de l'équipe s'attribut la tâche qu'il souhaite coder et le déclare en créant une Issue).

Bref nous venons de travailler encore une fois sur la même partie du programme et un choix va devoir se faire sur le code à garder ou conserver.

Il semble que tu sois plus avancé que moi donc ce sera surement ton code. (Permets moi donc d'être énervé d'avoir perdu 1heure de ma journée...).

[florentvitse]

Je suis d'accord avec PE

[florentvitse]

Et aussi Étienne tu veux faire trop de truc en même temps, faut réfléchir ensemble avant de commencer temps de changements Petit à petit !

[caronpe]

13 est là pour ça! Cette issue régule notre travail et gére l'organisation du groupe. (cf mon poste dans #13 à 16h)

[florentvitse]

@caronpe - Pour les attaques, dès que tu es en combat, je pense qu'il faudrait que tu intègres un genre de booléen pour savoir que le personnage est en combat, comme ça on serait obligé de combattre le monstre (après que l'on est appuyé pour la première fois sur ESPACE) -> De ce fait on ne pourrait pas partir en plein combat. Qu'en pense tu ?

[florentvitse]

Et tiens, si tu veux tester avec des rochers, j'ai trouver le correspond graphique :)

[ET-AD]

Wow je crois que j'ai loupé une discussion...

@caronpe Je ne comprends pas vraiment ta réaction. J'ai regardé ta branche avant de me lancer sur le développement "attack PNJ" et elle était orientée, sauf erreur de ma part, exclusivement sur le joueur, non les PNJ. J'ai pensé que tu continuais ton développement de l'attaque du Joueur... A cela j'ai imaginé qu'il pourrait être interressant de commencer à animer les PNJ pour que tu puisses tester et adapter ton développement sur les attaques du joueurs.

Maintenant rencontrant des difficultés sur Firelord/Fireball (PNJ), je me suis dit que si tu avais imaginé une attaque à distance pour le joueur, peut être tu pourrais m'aider sur Fireball. Deux actions différentes possèdent quelques similitudes. D'où mon post ici.

Après tu parles de discuter de gitHub mais je pense que l'on devrait d'abord discuter du gameplay (les combats, objectif du jeu,...) car pour le coup on ne s'est rien dit à ce sujet, mis à part un "laby RGP design pokemon qui n'est pas en tour par tour"

Je pense que le débat ci dessus provient d'une divergence de vision sur le gameplay. J'imaginais que les attaques Joueurs étaient dissociées de celles des PNJ.

[ET-AD]

Pour github, certes je ne m'attribue pas d'issue avant de développer. Maintenant je commit mes avancés toutes les heures (maximum). Le prof ayant dit de préférer les petits commit régulier plutôt que les gros commits. Peut être ai je mal interprété cette phrase ou son application ... ?

Après s'attribuer des tâches complètes.... personnellement, je préfère contribuer à pleins de petites tâches et avoir l'impression de coder "ensemble", le projet n'étant pas particulièrement immense pour justifier un partage si strict des tâches (selon moi). d'où les petits commits réguliers suggérés...?

J'espère que tu comprends maintenant pourquoi j'ai agi ainsi, je ne pensais pas à mal. Je vais faire attention maintenant à vous laisser votre issue.

@florentvitse tu codes au moins le double de moi ;) et les petits commits bien séparés permettent de faire des "reverts" en cas de soucis ou de changements d'idées.

[cdlm]

Si je peux me permettre— la communication par écrit est notoirement difficile, donc gardez la tête froide…

Il est plus ou moins inévitable que vous vous marchiez sur les pieds en codant à plusieurs sur un si petit programme. Moi même je ne sais pas ce qui est le plus pratique pour démarrer un projet à plusieurs. En général, quelqu'un·e écrit seul·e un prototype puis des collaborateurs viennent s'ajouter, soit l'implémentation est commencée en pair-programming co-localisé. D'autre part, le code n'est pas sacré, ce n'est pas grave d'en jeter ou d'en réécrire une partie plusieurs fois. Et je rappelle que c'est le ce que vous aurez tiré de l'expérience qui m'intéresse, plus que le résultat final ou les écueils du process.

[ET-AD]

Désolé si je parrais être aburpt dans mes messages, ce n'est pas intentionnel !

Aucune animosité de ma part, désolé. Je pense que l'on essaie juste de se comprendre ;)

PS ; je vais rajouter des smileys :p ça casse le côté parfois dur des messages ;)

[cdlm]

Justement, il n'y avait aucun reproche, juste une remarque générale et surtout pas personnelle. Je viens justement de tomber sur un blog qui parle de la communication, et à y réfléchir, c'est vrai que la part d'effort consacré à la communication dans les projets open-source qui marchent bien est surprenante.

[caronpe]

Le travail en équipe et à distance est effectivement difficile. C'est pour ça que j'ai essayé de passer plus de temps sur notre organisation que sur le code jusqu'ici (création de milestone pour les version, assignement des issues, attribution de type aux issues). Il est important de passer du temps à s'organiser AVANT de coder.

Je suis entiérement d'accord sur le fait de travailler en collaboration, il y a aucun probléme à cela et c'est même mieu! Mais comme je l'ai dis il faut penser à le déclarer pour pouvoir s'organiser. Il suffit de poster un petit message et s'assigner à la tâche.

Ensuite concernant les Commits il est necessaire effectivement de commiter réguliérement c'est plus facile pour gérer le projet et détécter des modifications, mais les commits ne servent pas à informer les autres utilisateurs du sujet que traite un personne, les issues sont là pour ça!

ps: je pense que tu ne recois pas les issues par mail comme Florent, Damien et moi. Essayes de régler ce probléme sinon tu ne peux pas suivre ce qui se dit.

Bon sinon d'un point de vu plus personnel t'inquiéte pas c'est que deux trois lignes de code rien de bien grave ;-)

[florentvitse]

J'aime l'effet de l'eau là, c'est pas mal du tout !

[caronpe]

Bon il n'y a plus réellement de dev sur cette partie issues. Il manque juste les animations d'attaque selon la direction du personnage (que du photoshop quoi) je ferai ça cette aprem tout en suivant le cours. Je ferme donc l'issue

[ET-AD]

Je sais pas s'il y a moyen de le faire pour les PNJ. flo en a parlé dans #30 version sans arène.. quoi que l'on peut toujours le réutiliser pour version avec arène.. Bref si tu maîtrise photoshop, peux-tu jeter un œil à animer les attaques/morts des PNJ stp?

• Attaque : je n'ai pas d'idée pour représenter
• Mort : peut être créer une explosion par dessus ou couper la tête (lol),etc... avant que le PNJ disparaisse C'est du détails mais tant que tu es dessus cela pourrait être sympa (si ça prend trop de temps laisse tomber)